From nobody Fri Feb 1 11:57:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF553128B01 for ; Fri, 1 Feb 2019 11:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYIIVgnUgwNc for ; Fri, 1 Feb 2019 11:56:55 -0800 (PST) Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF0B130E88 for ; Fri, 1 Feb 2019 11:56:54 -0800 (PST) Received: by mail-it1-x142.google.com with SMTP id g85so11088420ita.3 for ; Fri, 01 Feb 2019 11:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V/xCMIeC2SNPAS3DLAlPLGFQyYN7n6w2S+pCAaZEh+4=; b=cYgOdrzFgJ5l+iNgyI93gF7s0OtyL4Nlzf+4zH/z7KIfipx1IT0urmfXwrfWCME5Yk VbgPZ8kvFcQDpg/pSu4f0w4z9oi2myD6wD8FyJ1K0W9QGhohS/czwl5JapwxaygN6pFO XbKQLQkycVKzJKerx03B2o0RmA/EWgULhk4hY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V/xCMIeC2SNPAS3DLAlPLGFQyYN7n6w2S+pCAaZEh+4=; b=Hsh7VjnvCW6E1yP2YPdcqUeiFNPUg3nZmFNUMu7n/9fjF8A0IClWKajlaqgKkR4EaL K1xTyWbJS5WrIEs2TizSEbG+C2rhX3DxlQ4ID7ZB7hBT5ElxBBv/Z/HTNc2ZJ4von6o6 1fRBpEkQk9rtzeF8rphL+7hGTIthNvW+u8d/MJe2gwDAw+pjS4yTH7uPNwgXi9gKgzU3 DtgssvwO2pG1nY6BKFjDIuE4MflyK5VK+iOpd7b3tW8NGR7eDzHZ+pOrxTyjtOMVvSJa r51ZPxLSvAeMp+MNkYujLJ1v98WjwzIYPbV+P2V7/fCCeo/XlVpwiZA6kEMO+c+JSItU mjBw== X-Gm-Message-State: AHQUAuYx5C7D34eD8mccak+V1hebS20LBgMPazymmo6kc7fUzAD58Stu PrEwHUQtDtJWKHMAvlsvvfDK/oWOGDOLjXsziJV/zCrKzWmkPQ4xjoJ3be6dtaM1xZAzRghL5B6 U8ZAaMuF+xGxHLw== X-Google-Smtp-Source: AHgI3IbICvOMzKvbFeMEK1eyQj7+nB3tQKwROGX+N6TbwEtvZ2fjjlJyYsfPZxoS7li4B7AMtBnMdeHF9+Htt5nQfTE= X-Received: by 2002:a24:6293:: with SMTP id d141mr2448785itc.124.1549051014010; Fri, 01 Feb 2019 11:56:54 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> In-Reply-To: From: Brian Campbell Date: Fri, 1 Feb 2019 12:56:27 -0700 Message-ID: To: Filip Skokan Cc: Dave Tonge , oauth Content-Type: multipart/alternative; boundary="0000000000006dfb900580da8b3f" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 19:56:59 -0000 --0000000000006dfb900580da8b3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm finally getting around to working on the document updates (there's quite a few things that came out of AD review too). As far as the issue in this thread goes though, I'm leaning towards adding "mtls_endpoints" as a new metadata parameter. Maybe mention that a 307 might happen but it'd be more of a considerations type text. On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell wrote: > I guess I should have also said or been more straightforward in saying > that I don't particularly want to try and discuss/define the use of a 307 > in the document. > > On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan wrote: > >> I don't know that the use of 307 would need to be discussed in the >>> document itself. >> >> >> If the clients are supposed to be ready for this, yeah. For instance, my >> client software by default doesn't follow redirects, in order for it to = be >> ready for mtls client authentication i'd have to know 307 is a possibili= ty >> and whitelist 307 as a valid code to be followed. >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I don't know that the use of 307 would need to be discussed in the >>> document itself. >>> >>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan wrote= : >>> >>>> I'm in favour of both 307 and metadata. >>>> >>>> - case 307 - I don't recall ever encountering an http client >>>> software that wouldn't have an option for following redirects, same= for a >>>> server side frameworks not having the option to do a 307 response w= ith a >>>> location header. >>>> - case 307 - Relying purely on a new metadata doesn't help in the >>>> scenario David put forth earlier about clients not being aware of u= sing >>>> mtls, a device policy of sorts. >>>> - case metadata - no second request if the client knows there's an >>>> mtls endpoint it should use. >>>> >>>> Maybe we should specify both as optional for an AS to deploy and a >>>> client to be ready for? >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge < >>>> dave.tonge@momentumft.co.uk> wrote: >>>> >>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although i= t >>>>> should be optional. >>>>> While a 307 redirect seems kind of elegant I worry, like you, that >>>>> not all clients would handle it appropriately. >>>>> There would probably need to be an error defined for clients who >>>>> attempt to use `tls_client_auth` at the regular endpoint. >>>>> >>>>> Dave >>>>> >>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>> >>>>>> Trying to summarize things somewhat here and focus in hopefully >>>>>> towards some decision. There's basically an idea on the table to add= an AS >>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be a = JSON >>>>>> object which contains endpoints that a client doing MTLS would use r= ather >>>>>> than the regular endpoints. A straw-man example might look like this= (with >>>>>> mtls_endpoints being that new parameter). >>>>>> >>>>>> { >>>>>> "issuer":"https://server.example.com", >>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>> "token_endpoint":"https://server.example.com/token", >>>>>> "token_endpoint_auth_methods_supported":[ >>>>>> "client_secret_basic","tls_client_auth", "none"], >>>>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>>>> ", >>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> * "mtls_endpoints":{ >>>>>> "token_endpoint":"https://mtls.example.com/token >>>>>> ", "userinfo_endpoint":"https://m= tls >>>>>> .example.com/userinfo >>>>>> ", "revocation_endpoint":"https://mt= ls >>>>>> ..example.com/revo >>>>>> " }* >>>>>> } >>>>>> >>>>>> The idea behind this is that "regular" clients (those not doing MTLS= ) >>>>>> will use the regular endpoints. And only the host/port of the endpoi= nts >>>>>> listed in mtls_endpoints will be set up to request TLS client certif= icates >>>>>> during handshake.. Thus any potential impact of the CertificateReque= st >>>>>> message being sent in the TLS handshake can be avoided for all the o= ther >>>>>> regular clients that are not going to do MTLS - including and most >>>>>> importantly in-browser javascript clients where there can be less th= an >>>>>> desirable UI presented to the end-user. >>>>>> >>>>>> The arguments in favor of that seem to be basically that it allows >>>>>> for AS deployments to support MTLS while still allowing for a "not b= roken" >>>>>> UX for end-users of clients (in-browser javascript clients) that are= n't >>>>>> doing MTLS. And that it's not much in terms of adding to the spec an= d >>>>>> complexity of implementations. >>>>>> >>>>>> The arguments against it seem to be 1) the bad UX isn't really that >>>>>> bad and/or will only happen to a subset of users 2) there are other = things >>>>>> that can be done, such as 307ing or renegotiation/post-handshake cli= ent >>>>>> auth, to avoid the bad UX. >>>>>> >>>>>> Speaking for myself, I'm kinda torn on it. >>>>>> >>>>>> I will say that, in addition to the folks that have pointed out that >>>>>> renegotiation just isn't possible in some cases, my experience tryin= g to do >>>>>> something like that in the past was not particularly successful or >>>>>> encouraging. That could have been my fault, of course, but still see= ms a >>>>>> relevant data point. I also have my doubts about the actual difficul= ty of >>>>>> getting an AS to issue a 307 like response for requests based on the >>>>>> calling client and the likelihood that some/all OAuth client softwar= e would >>>>>> handle it appropriately. >>>>>> >>>>>> >>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>>>> david@alkaline-solutions.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden < >>>>>>> neil.madden@forgerock.com> wrote: >>>>>>> > >>>>>>> > On 9 Jan 2019, at 05:54, David Waite >>>>>>> wrote: >>>>>>> >> >>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> >>> All of that is meant as an explanation of sorts to say that I >>>>>>> think that things are actually okay enough as is and that I'd like = to >>>>>>> retract the proposal I'd previously made about the MTLS draft intro= ducing a >>>>>>> new AS metadata parameter. It is admittedly interesting (ironic?) t= hat Neil >>>>>>> sent a message in support of the proposal as I was writing this. It= did >>>>>>> give me pause but ultimately didn't change my opinion that it's not= worth >>>>>>> it to add this new AS metadata parameter. >>>>>>> >> >>>>>>> >> Note that the AS could make a decision based on the token >>>>>>> endpoint request - such as a policy associated with the =E2=80=9Ccl= ient_id=E2=80=9D, or via >>>>>>> a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D i= ndicating MTLS was >>>>>>> desired by this public client installation. The AS could then to TL= S 1.2 >>>>>>> renegotiation, 1.3 post-handshake client authentication, or even us= e 307 >>>>>>> temporary redirects to another token endpoint to perform mutual >>>>>>> authentication. >>>>>>> > >>>>>>> > Renegotiation is an intriguing option, but it has some practical >>>>>>> difficulties. Our AS product runs in a Java servlet container, wher= e it is >>>>>>> pretty much impossible to dynamically trigger renegotiation without >>>>>>> accessing private internal APIs of the container. I also don=E2=80= =99t know how you >>>>>>> could coordinate this in the common scenario where TLS is terminate= d at a >>>>>>> load balancer/reverse proxy? >>>>>>> > >>>>>>> > A 307 redirect could work though as the server will know if the >>>>>>> client either uses mTLS for client authentication or has indicated = that it >>>>>>> wants certificate-bound access tokens, so it can redirect to a >>>>>>> mTLS-specific endpoint in those cases. >>>>>>> >>>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t = know a >>>>>>> way to have say a custom error code or WWW-Authenticate challenge t= o >>>>>>> trigger renegotiation on the reverse proxy - usually this is just a= static, >>>>>>> location-based directive. >>>>>>> >>>>>>> > >>>>>>> >> Both the separate metadata url and a =E2=80=9Cclient_assertion_t= ype=E2=80=9D-like >>>>>>> indicator imply that the client has multiple forms of authenticatio= n and is >>>>>>> choosing to use MTLS. The URL in particular I=E2=80=99m reluctant t= o add support >>>>>>> for, because I see it more likely a client would use MTLS without k= nowing >>>>>>> it (via a device-level policy being applied to a public web or nati= ve app) >>>>>>> than the reverse, where a single client (represented by a single cl= ient_id) >>>>>>> is dynamically picking between forms of authentication. >>>>>>> > >>>>>>> > That=E2=80=99s an interesting observation. Can you elaborate on t= he sorts >>>>>>> of device policy you are talking about? I am aware of e.g. mobile d= evice >>>>>>> management being used to push client certificates to iOS devices, b= ut I >>>>>>> think these are only available in Safari. >>>>>>> >>>>>>> The primary use is to set policy to rely on device level management >>>>>>> in controlled environments like enterprises when available. So an A= S may >>>>>>> try to detect a client certificate as an indicator of a managed dev= ice, use >>>>>>> that to assume a device with certain device-level authentication, s= ingle >>>>>>> user usage, remote wipe, etc. characteristics, and decide that it c= an >>>>>>> reduce user authentication requirements and/or expose additional sc= opes. >>>>>>> >>>>>>> On more thought, this is typically done as part of the user agent >>>>>>> hitting the authorization endpoint, as a separate native applicatio= n may be >>>>>>> interacting with the token endpoint, and in some operating systems = the >>>>>>> application=E2=80=99s network connections do not utilize (and may n= ot have access >>>>>>> to) the system certificate store. >>>>>>> >>>>>>> In terms of user agents, I believe you can perform similar behavior >>>>>>> (managed systems using client certificates on user agents transpare= ntly) on >>>>>>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) t= ypically >>>>>>> inherits device level policy. Firefox on desktop I assume you can d= o that >>>>>>> in limited fashion as well. >>>>>>> >>>>>>> -DW >>>>>> >>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). A= ny >>>>>> review, use, distribution or disclosure by others is strictly >>>>>> prohibited.... If you have received this communication in error, pl= ease >>>>>> notify the sender immediately by e-mail and delete the message and a= ny file >>>>>> attachments from your computer. Thank you.* >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >> >> --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000006dfb900580da8b3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm finally getting around to working= on the document updates (there's quite a few things that came out of A= D review too). As far as the issue in this thread goes though, I'm lean= ing towards adding "mtls_endpoints" as a new metadata parameter. = Maybe mention that a 307 might happen but it'd be more of a considerati= ons type text.

On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <= ;bcampbell@pingidentity.com> wrote:
I guess I should have also said or been more straightforward= in saying that I don't particularly want to try and discuss/define the= use of a 307 in the document.

On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <panva.ip@gmail.com> wrot= e:
I don't know that the use of 307 would need to be discussed= in the document itself.=C2=A0

If th= e clients are supposed to be ready for this, yeah. For instance, my client = software by default doesn't follow redirects, in order for it to be rea= dy for mtls client authentication i'd have to know 307 is a possibility= and whitelist 307 as a valid code to be followed.

S pozdravem,
Filip Skokan
<= /div>

On Tue, Jan = 15, 2019 at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
I do= n't know that the use of 307 would need to be discussed in the document= itself.

On Tue, = Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm in fa= vour of both 307 and metadata.=C2=A0
  • case 307 - I don'= ;t recall ever encountering an http client software that wouldn't have = an option for following redirects, same for a server side frameworks not ha= ving the option to do a 307 response with a location header.
  • ca= se 307 - Relying purely on a new metadata doesn't help in the scenario = David put forth earlier about clients not being aware of using mtls, a devi= ce policy of sorts.
  • case metadata - no second request if the cl= ient knows there's an mtls endpoint it should use.
= Maybe we should specify both as optional for an AS to deploy and a client t= o be ready for?

S pozdravem,
Filip Skoka= n


= On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@momentumft.co.uk> w= rote:
I'm in favour of the `mtls_endpoin= ts` metadata parameter - although it should be optional.
While a 307 = redirect seems kind of elegant I worry, like you,=C2=A0 that not all client= s would handle it appropriately.
<= font face=3D"trebuchet ms, sans-serif">There would probably need to be an e= rror defined for clients who attempt to use `tls_client_auth` at the regula= r endpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campb= ell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Trying to summarize things somewha= t here and focus in hopefully towards some decision. There's basically = an idea on the table to add an AS metadata parameter to the draft-ietf-oaut= h-mtls doc that would be a JSON object which contains endpoints that a clie= nt doing MTLS would use rather than the regular endpoints. A straw-man exam= ple might look like this (with mtls_endpoints being that new parameter).

{=C2=A0
=C2=A0 "issuer":"https://server.example.com",=
=C2=A0 "authorization_endpoint":"https://server.example.com/authz",
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[=C2= =A0 "client_secret_basic","tls_client_auth", "none= "],
=C2=A0 "userinfo_endpoint":"https://server..example.com/u= serinfo",
=C2=A0 "revocation_endpoint":"https://server.examp= le.com/revo",
=C2=A0 "jwks_uri":"https://server.example.= com/jwks.json",
=C2=A0 "mtls_endpoints":{=C2=A0 =C2=A0=C2=A0=C2=A0 "token_endpoint":"https://mtls.example.com/token&= quot;,
=C2=A0=C2=A0=C2=A0 "userinfo_endpoint":"https://mtls.example.com/use= rinfo",
=C2=A0=C2=A0=C2=A0 "revocation_endpoint":&quo= t;https://mtls..exampl= e.com/revo"
=C2=A0 }
}

The = idea behind this is that "regular" clients (those not doing MTLS)= will use the regular endpoints. And only the host/port of the endpoints li= sted in mtls_endpoints will be set up to request TLS client certificates du= ring handshake.. Thus any potential impact of the CertificateRequest messag= e being sent in the TLS handshake can be avoided for all the other regular = clients that are not going to do MTLS - including and most importantly in-b= rowser javascript clients where there can be less than desirable UI present= ed to the end-user.

The arguments in favor of= that seem to be basically that it allows for AS deployments to support MTL= S while still allowing for a "not broken" UX for end-users of cli= ents (in-browser javascript clients) that aren't doing MTLS. And that i= t's not much in terms of adding to the spec and complexity of implement= ations.

The arguments against it seem to be 1= ) the bad UX isn't really that bad and/or will only happen to a subset = of users 2) there are other things that can be done, such as 307ing or rene= gotiation/post-handshake client auth, to avoid the bad UX.
<= br>
Speaking for myself, I'm kinda torn on it.

I will say that, in addition to the folks that have pointed= out that renegotiation just isn't possible in some cases, my experienc= e trying to do something like that in the past was not particularly success= ful or encouraging. That could have been my fault, of course, but still see= ms a relevant data point. I also have my doubts about the actual difficulty= of getting an AS to issue a 307 like response for requests based on the ca= lling client and the likelihood that some/all OAuth client software would h= andle it appropriately.
=C2=A0

On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com&g= t; wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited....=C2=A0 If you have received this communication in = error, please notify the sender immediately by e-mail and delete the messag= e and any file attachments from your computer. Thank you.= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000006dfb900580da8b3f-- From nobody Fri Feb 1 12:40:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB75130EA1 for ; Fri, 1 Feb 2019 12:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.851 X-Spam-Level: X-Spam-Status: No, score=-8.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORrt5hMyX_6U for ; Fri, 1 Feb 2019 12:40:40 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE29130E8F for ; Fri, 1 Feb 2019 12:40:40 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x11KdFtn107869; Fri, 1 Feb 2019 20:40:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=+H7o2hBPowIDCJreXTWIdqvzgt1QZjPTxSr0ZwLK/tY=; b=tEA8TR99J3cG2Pow6Ht7FvSJfBxgidZrb21dE6THKOqY4ghBSDo671AdoA9CIrTg7M7v 9V/w2GQHa7XQX4RZ7gLqaNYWszb8HM+NLimn0kM+K89SIaRTJm/Yp12sIourGoryPKM2 dSbhmDWkaAGY7KCWpYgeiSqoXxTPXQl2ZcvX0X8f2xr6y6VagTDOn0gKlUpQoWQXnoTs oBKHBMwwl+Sp/ovwDrMpBi3DRP954WxVDpKMHh3+C8CcJckr8Zkhu5pgA+2TY5DzkzRw wMKYquAFXk1OAw0vYU7RXKsCNdLwiY6dwd4FpqMQ8igzaJ6TAHc+g4F5+HPSxUxVsu4H Nw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2q8eyv0s0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Feb 2019 20:40:37 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x11KebuH006312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Feb 2019 20:40:37 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x11Keafa020049; Fri, 1 Feb 2019 20:40:36 GMT Received: from dhcp-10-159-243-81.vpn.oracle.com (/10.159.243.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Feb 2019 12:40:36 -0800 From: Phil Hunt Message-Id: <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8CEC63B-B76A-44D9-B37C-26A6188D06DE" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Feb 2019 12:40:34 -0800 In-Reply-To: Cc: Filip Skokan , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9154 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902010146 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 20:40:44 -0000 --Apple-Mail=_E8CEC63B-B76A-44D9-B37C-26A6188D06DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was a bit confused by how the 307 would work. To confirm, Is the client having reached an MTLS optional endpoint being = redirected to an MTLS mandatory endpoint if the AT (or a cookie) is = detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the = browser invoke MTLS? Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 1, 2019, at 11:56 AM, Brian Campbell = wrote: >=20 > I'm finally getting around to working on the document updates (there's = quite a few things that came out of AD review too). As far as the issue = in this thread goes though, I'm leaning towards adding "mtls_endpoints" = as a new metadata parameter. Maybe mention that a 307 might happen but = it'd be more of a considerations type text.=20 >=20 > On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell = > wrote: > I guess I should have also said or been more straightforward in saying = that I don't particularly want to try and discuss/define the use of a = 307 in the document.=20 >=20 > On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan > wrote: > I don't know that the use of 307 would need to be discussed in the = document itself.=20 >=20 > If the clients are supposed to be ready for this, yeah. For instance, = my client software by default doesn't follow redirects, in order for it = to be ready for mtls client authentication i'd have to know 307 is a = possibility and whitelist 307 as a valid code to be followed. >=20 > S pozdravem, > Filip Skokan >=20 >=20 > On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell = > wrote: > I don't know that the use of 307 would need to be discussed in the = document itself.=20 >=20 > On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan > wrote: > I'm in favour of both 307 and metadata.=20 > case 307 - I don't recall ever encountering an http client software = that wouldn't have an option for following redirects, same for a server = side frameworks not having the option to do a 307 response with a = location header. > case 307 - Relying purely on a new metadata doesn't help in the = scenario David put forth earlier about clients not being aware of using = mtls, a device policy of sorts. > case metadata - no second request if the client knows there's an mtls = endpoint it should use. > Maybe we should specify both as optional for an AS to deploy and a = client to be ready for? >=20 > S pozdravem, > Filip Skokan >=20 >=20 > On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge = > = wrote: > I'm in favour of the `mtls_endpoints` metadata parameter - although it = should be optional. > While a 307 redirect seems kind of elegant I worry, like you, that = not all clients would handle it appropriately. > There would probably need to be an error defined for clients who = attempt to use `tls_client_auth` at the regular endpoint. >=20 > Dave >=20 > On Mon, 14 Jan 2019 at 22:29, Brian Campbell = > wrote: > Trying to summarize things somewhat here and focus in hopefully = towards some decision. There's basically an idea on the table to add an = AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a = JSON object which contains endpoints that a client doing MTLS would use = rather than the regular endpoints. A straw-man example might look like = this (with mtls_endpoints being that new parameter). >=20 > { =20 > "issuer":"https://server.example.com ", > "authorization_endpoint":"https://server.example.com/authz = ", > "token_endpoint":"https://server.example.com/token = ", > "token_endpoint_auth_methods_supported":[ = "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server..example.com/userinfo = ", > "revocation_endpoint":"https://server.example.com/revo = ", > "jwks_uri":"https://server.example.com/jwks.json = ", > "mtls_endpoints":{ =20 > "token_endpoint":"https://mtls.example.com/token = ", > "userinfo_endpoint":"https://mtls = .example.com/userinfo = ", > "revocation_endpoint":"https://mtls = ..example.com/revo = " > } > } >=20 > The idea behind this is that "regular" clients (those not doing MTLS) = will use the regular endpoints. And only the host/port of the endpoints = listed in mtls_endpoints will be set up to request TLS client = certificates during handshake.. Thus any potential impact of the = CertificateRequest message being sent in the TLS handshake can be = avoided for all the other regular clients that are not going to do MTLS = - including and most importantly in-browser javascript clients where = there can be less than desirable UI presented to the end-user.=20 >=20 > The arguments in favor of that seem to be basically that it allows for = AS deployments to support MTLS while still allowing for a "not broken" = UX for end-users of clients (in-browser javascript clients) that aren't = doing MTLS. And that it's not much in terms of adding to the spec and = complexity of implementations.=20 >=20 > The arguments against it seem to be 1) the bad UX isn't really that = bad and/or will only happen to a subset of users 2) there are other = things that can be done, such as 307ing or renegotiation/post-handshake = client auth, to avoid the bad UX.=20 >=20 > Speaking for myself, I'm kinda torn on it.=20 >=20 > I will say that, in addition to the folks that have pointed out that = renegotiation just isn't possible in some cases, my experience trying to = do something like that in the past was not particularly successful or = encouraging. That could have been my fault, of course, but still seems a = relevant data point. I also have my doubts about the actual difficulty = of getting an AS to issue a 307 like response for requests based on the = calling client and the likelihood that some/all OAuth client software = would handle it appropriately.=20 > =20 >=20 > On Fri, Jan 11, 2019 at 12:32 PM David Waite = > = wrote: >=20 >=20 > > On Jan 11, 2019, at 3:32 AM, Neil Madden > wrote: > >=20 > > On 9 Jan 2019, at 05:54, David Waite > wrote: > >>=20 > >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = > wrote: > >>>=20 > >> > >>=20 > >>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to = retract the proposal I'd previously made about the MTLS draft = introducing a new AS metadata parameter. It is admittedly interesting = (ironic?) that Neil sent a message in support of the proposal as I was = writing this. It did give me pause but ultimately didn't change my = opinion that it's not worth it to add this new AS metadata parameter. > >>=20 > >> Note that the AS could make a decision based on the token endpoint = request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D= indicating MTLS was desired by this public client installation. The AS = could then to TLS 1.2 renegotiation, 1.3 post-handshake client = authentication, or even use 307 temporary redirects to another token = endpoint to perform mutual authentication. > >=20 > > Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy? > >=20 > > A 307 redirect could work though as the server will know if the = client either uses mTLS for client authentication or has indicated that = it wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases. >=20 > Agreed. There are trade-offs for both. As you say, I don=E2=80=99t = know a way to have say a custom error code or WWW-Authenticate challenge = to trigger renegotiation on the reverse proxy - usually this is just a = static, location-based directive. >=20 > >=20 > >> Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication. > >=20 > > That=E2=80=99s an interesting observation. Can you elaborate on the = sorts of device policy you are talking about? I am aware of e.g. mobile = device management being used to push client certificates to iOS devices, = but I think these are only available in Safari. >=20 > The primary use is to set policy to rely on device level management in = controlled environments like enterprises when available. So an AS may = try to detect a client certificate as an indicator of a managed device, = use that to assume a device with certain device-level authentication, = single user usage, remote wipe, etc. characteristics, and decide that it = can reduce user authentication requirements and/or expose additional = scopes. >=20 > On more thought, this is typically done as part of the user agent = hitting the authorization endpoint, as a separate native application may = be interacting with the token endpoint, and in some operating systems = the application=E2=80=99s network connections do not utilize (and may = not have access to) the system certificate store. >=20 > In terms of user agents, I believe you can perform similar behavior = (managed systems using client certificates on user agents transparently) = on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) = typically inherits device level policy. Firefox on desktop I assume you = can do that in limited fashion as well. >=20 > -DW >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.... If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_E8CEC63B-B76A-44D9-B37C-26A6188D06DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = was a bit confused by how the 307 would work.

To confirm, Is the client having = reached an MTLS optional endpoint being redirected to an MTLS mandatory = endpoint if the AT (or a cookie) is detected to have a =E2=80=9Ccnf=E2=80=9D= claim in order to make the browser invoke MTLS?

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb 1, 2019, at 11:56 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I'm finally getting = around to working on the document updates (there's quite a few things = that came out of AD review too). As far as the issue in this thread goes = though, I'm leaning towards adding "mtls_endpoints" as a new metadata = parameter. Maybe mention that a 307 might happen but it'd be more of a = considerations type text.

On Wed, Jan = 16, 2019 at 5:52 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
I guess I = should have also said or been more straightforward in saying that I = don't particularly want to try and discuss/define the use of a 307 in = the document.

On Tue, Jan 15, 2019 = at 6:59 AM Filip Skokan <panva.ip@gmail.com> wrote:
I = don't know that the use of 307 would need to be discussed in the = document itself. 

If the clients are supposed to be ready = for this, yeah. For instance, my client software by default doesn't = follow redirects, in order for it to be ready for mtls client = authentication i'd have to know 307 is a possibility and whitelist 307 = as a valid code to be followed.

S pozdravem,
Filip = Skokan


On Tue, Jan 15, 2019 = at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
I don't = know that the use of 307 would need to be discussed in the document = itself.

On Tue, Jan 15, 2019 = at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm in favour of both 307 and metadata. 
  • case 307 - I don't recall ever = encountering an http client software that wouldn't have an option for = following redirects, same for a server side frameworks not having the = option to do a 307 response with a location header.
    • case 307 - Relying purely on a new metadata doesn't help in = the scenario David put forth earlier about clients not being aware of = using mtls, a device policy of sorts.
  • case metadata - no second request if the client knows there's = an mtls endpoint it should use.
Maybe we = should specify both as optional for an AS to deploy and a client to be = ready for?

S = pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge = <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.
While a 307 redirect seems kind of elegant I worry, like = you,  that not all clients would handle it = appropriately.
There would probably need = to be an error defined for clients who attempt to use `tls_client_auth` = at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at = 22:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying = to summarize things somewhat here and focus in hopefully towards some = decision. There's basically an idea on the table to add an AS metadata = parameter to the draft-ietf-oauth-mtls doc that would be a JSON object = which contains endpoints that a client doing MTLS would use rather than = the regular endpoints. A straw-man example might look like this (with = mtls_endpoints being that new parameter).

{ 
  "issuer":"https://server.example.com",
  = "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  = "token_endpoint_auth_methods_supported":[  = "client_secret_basic","tls_client_auth", "none"],
  = "userinfo_endpoint":"https://server..example.com/userinfo",  "revocation_endpoint":"https://server.example.com/revo",
  = "jwks_uri":"https://server.example.com/jwks.json",  "mtls_endpoints":{ 
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls..example.com/revo"
  = }
}

The idea behind this is that "regular" = clients (those not doing MTLS) will use the regular endpoints. And only = the host/port of the endpoints listed in mtls_endpoints will be set up = to request TLS client certificates during handshake.. Thus any potential = impact of the CertificateRequest message being sent in the TLS handshake = can be avoided for all the other regular clients that are not going to = do MTLS - including and most importantly in-browser javascript clients = where there can be less than desirable UI presented to the end-user.

The = arguments in favor of that seem to be basically that it allows for AS = deployments to support MTLS while still allowing for a "not broken" UX = for end-users of clients (in-browser javascript clients) that aren't = doing MTLS. And that it's not much in terms of adding to the spec and = complexity of implementations.

The arguments against it seem to be 1) = the bad UX isn't really that bad and/or will only happen to a subset of = users 2) there are other things that can be done, such as 307ing or = renegotiation/post-handshake client auth, to avoid the bad UX.

Speaking for myself, I'm kinda torn on it.

I = will say that, in addition to the folks that have pointed out that = renegotiation just isn't possible in some cases, my experience trying to = do something like that in the past was not particularly successful or = encouraging. That could have been my fault, of course, but still seems a = relevant data point. I also have my doubts about the actual difficulty = of getting an AS to issue a 307 like response for requests based on the = calling client and the likelihood that some/all OAuth client software = would handle it appropriately.
 

On = Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wrote:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> wrote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that = I think that things are actually okay enough as is and that I'd like to = retract the proposal I'd previously made about the MTLS draft = introducing a new AS metadata parameter. It is admittedly interesting = (ironic?) that Neil sent a message in support of the proposal as I was = writing this. It did give me pause but ultimately didn't change my = opinion that it's not worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token = endpoint request - such as a policy associated with the =E2=80=9Cclient_id= =E2=80=9D, or via a parameter in the ilk of =E2=80=9Cclient_assertion_type= =E2=80=9D indicating MTLS was desired by this public client = installation. The AS could then to TLS 1.2 renegotiation, 1.3 = post-handshake client authentication, or even use 307 temporary = redirects to another token endpoint to perform mutual authentication.
>
> Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the = client either uses mTLS for client authentication or has indicated that = it wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know = a way to have say a custom error code or WWW-Authenticate challenge to = trigger renegotiation on the reverse proxy - usually this is just a = static, location-based directive.

>
>> Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the = sorts of device policy you are talking about? I am aware of e.g. mobile = device management being used to push client certificates to iOS devices, = but I think these are only available in Safari.

The primary use is to set policy to rely on device level management in = controlled environments like enterprises when available. So an AS may = try to detect a client certificate as an indicator of a managed device, = use that to assume a device with certain device-level authentication, = single user usage, remote wipe, etc. characteristics, and decide that it = can reduce user authentication requirements and/or expose additional = scopes.

On more thought, this is typically done as part of the user agent = hitting the authorization endpoint, as a separate native application may = be interacting with the token endpoint, and in some operating systems = the application=E2=80=99s network connections do not utilize (and may = not have access to) the system certificate store.

In terms of user agents, I believe you can perform similar behavior = (managed systems using client certificates on user agents transparently) = on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) = typically inherits device level policy. Firefox on desktop I assume you = can do that in limited fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited....  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_E8CEC63B-B76A-44D9-B37C-26A6188D06DE-- From nobody Fri Feb 1 12:56:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F147130EB0 for ; Fri, 1 Feb 2019 12:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utGlWXsh-xgu for ; Fri, 1 Feb 2019 12:56:34 -0800 (PST) Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BBB124408 for ; Fri, 1 Feb 2019 12:56:33 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id g85so11380720ita.3 for ; Fri, 01 Feb 2019 12:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xk3L/QX+sayH+aCsFJTG0E1FeXP1MwyOi+LTRPMGY4Q=; b=Xxy/j+OzuPfzirYFPEuGAzwiWCkkTiNV+Hps9lFUtoM1HK63CtMfJj2hhC9j29AkLD QmOYnr8TJnuKbKyRLTQnwXGY9DmGnL27NxsWK1+MjgahwWevFTmpI4iIk947W3CFHpf/ rqCyI267th2DrU7sVldRZhiwL3klbjg1a187k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xk3L/QX+sayH+aCsFJTG0E1FeXP1MwyOi+LTRPMGY4Q=; b=JjiiMKTXAfL8/9UiHbCW9ERr8ZwT5eGc8NMoiyf2miywV6D6cDaBZcg1Ik/KzNMRCq Vo1TBM9k7bdrQhUPM6sH0Nnkf51RGaN5QVn0pCo0WV7JRXfgKbahnD3de9hxXBHKN/By 668Dz6C1O14u3MZ3BIrWeCiY4FHhGFfMqTpTZOLZc+PYNbuSxrWcCo4cxxC4j8gFaQQK +OZW7cq+SqrlJYfmlEhYU5J+uN39cJoyNAZsuDHx7O0uWIyUHY5Ps28yn79ZVhOh8IZS Ra8pOb3fgVKTcSbhT387hQ+lWjdHaSz4Gy/rcZ22D/Mnhiy3itYQMzFFUbInMh94YXVG aVVQ== X-Gm-Message-State: AHQUAubXmk6D3tmjUaZj3aaUyNlp7F555S5tULaLEfhuiCSnl6XKyJIb juir2vVBOwCbj39yVO3wmWXGopLcU22DFlzuL2I+h7/AVPAU+nZFHWRWS+Jy1BEnNOqXirgDjYm MDmnS8k9nTCnGC/CjRe4= X-Google-Smtp-Source: AHgI3IYuTxVud/e0oEKq0B2emTy5Za+lAdg2DDVVqEMYC9I9Yo2sUOYsf7BGOQ9eooNyWKWTOqvZDvlfyH7d7ZvENaM= X-Received: by 2002:a24:3987:: with SMTP id l129mr2527244ita.45.1549054592744; Fri, 01 Feb 2019 12:56:32 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> In-Reply-To: <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> From: Brian Campbell Date: Fri, 1 Feb 2019 13:56:06 -0700 Message-ID: To: Phil Hunt Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="000000000000bd21680580db6059" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 20:56:38 -0000 --000000000000bd21680580db6059 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It would be more a client having reached a non-MTLS endpoint and is 307'd to an MTLS enabled endpoint. On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote: > I was a bit confused by how the 307 would work. > > To confirm, Is the client having reached an MTLS optional endpoint being > redirected to an MTLS mandatory endpoint if the AT (or a cookie) is > detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the brows= er invoke MTLS? > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Feb 1, 2019, at 11:56 AM, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > I'm finally getting around to working on the document updates (there's > quite a few things that came out of AD review too). As far as the issue i= n > this thread goes though, I'm leaning towards adding "mtls_endpoints" as a > new metadata parameter. Maybe mention that a 307 might happen but it'd be > more of a considerations type text. > > On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell > wrote: > >> I guess I should have also said or been more straightforward in saying >> that I don't particularly want to try and discuss/define the use of a 30= 7 >> in the document. >> >> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan wrote: >> >>> I don't know that the use of 307 would need to be discussed in the >>>> document itself. >>> >>> >>> If the clients are supposed to be ready for this, yeah. For instance, m= y >>> client software by default doesn't follow redirects, in order for it to= be >>> ready for mtls client authentication i'd have to know 307 is a possibil= ity >>> and whitelist 307 as a valid code to be followed. >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> I don't know that the use of 307 would need to be discussed in the >>>> document itself. >>>> >>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan >>>> wrote: >>>> >>>>> I'm in favour of both 307 and metadata. >>>>> >>>>> - case 307 - I don't recall ever encountering an http client >>>>> software that wouldn't have an option for following redirects, sam= e for a >>>>> server side frameworks not having the option to do a 307 response = with a >>>>> location header. >>>>> - case 307 - Relying purely on a new metadata doesn't help in the >>>>> scenario David put forth earlier about clients not being aware of = using >>>>> mtls, a device policy of sorts. >>>>> - case metadata - no second request if the client knows there's an >>>>> mtls endpoint it should use. >>>>> >>>>> Maybe we should specify both as optional for an AS to deploy and a >>>>> client to be ready for? >>>>> >>>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> >>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge < >>>>> dave.tonge@momentumft.co.uk> wrote: >>>>> >>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although >>>>>> it should be optional. >>>>>> While a 307 redirect seems kind of elegant I worry, like you, that >>>>>> not all clients would handle it appropriately. >>>>>> There would probably need to be an error defined for clients who >>>>>> attempt to use `tls_client_auth` at the regular endpoint. >>>>>> >>>>>> Dave >>>>>> >>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>> >>>>>>> Trying to summarize things somewhat here and focus in hopefully >>>>>>> towards some decision. There's basically an idea on the table to ad= d an AS >>>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be a= JSON >>>>>>> object which contains endpoints that a client doing MTLS would use = rather >>>>>>> than the regular endpoints. A straw-man example might look like thi= s (with >>>>>>> mtls_endpoints being that new parameter). >>>>>>> >>>>>>> { >>>>>>> "issuer":"https://server.example.com", >>>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>>> "token_endpoint":"https://server.example.com/token", >>>>>>> "token_endpoint_auth_methods_supported":[ >>>>>>> "client_secret_basic","tls_client_auth", "none"], >>>>>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>>>>> ", >>>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * "mtls_endpoints":{ >>>>>>> "token_endpoint":"https://mtls.example.com/token >>>>>>> ", "userinfo_endpoint":"https://= mtls >>>>>>> .example.com/userinfo >>>>>>> ", "revocation_endpoint":"https://m= tls >>>>>>> ..example.com/revo >>>>>>> " }* >>>>>>> } >>>>>>> >>>>>>> The idea behind this is that "regular" clients (those not doing >>>>>>> MTLS) will use the regular endpoints. And only the host/port of the >>>>>>> endpoints listed in mtls_endpoints will be set up to request TLS cl= ient >>>>>>> certificates during handshake.. Thus any potential impact of the >>>>>>> CertificateRequest message being sent in the TLS handshake can be a= voided >>>>>>> for all the other regular clients that are not going to do MTLS - i= ncluding >>>>>>> and most importantly in-browser javascript clients where there can = be less >>>>>>> than desirable UI presented to the end-user. >>>>>>> >>>>>>> The arguments in favor of that seem to be basically that it allows >>>>>>> for AS deployments to support MTLS while still allowing for a "not = broken" >>>>>>> UX for end-users of clients (in-browser javascript clients) that ar= en't >>>>>>> doing MTLS. And that it's not much in terms of adding to the spec a= nd >>>>>>> complexity of implementations. >>>>>>> >>>>>>> The arguments against it seem to be 1) the bad UX isn't really that >>>>>>> bad and/or will only happen to a subset of users 2) there are other= things >>>>>>> that can be done, such as 307ing or renegotiation/post-handshake cl= ient >>>>>>> auth, to avoid the bad UX. >>>>>>> >>>>>>> Speaking for myself, I'm kinda torn on it. >>>>>>> >>>>>>> I will say that, in addition to the folks that have pointed out tha= t >>>>>>> renegotiation just isn't possible in some cases, my experience tryi= ng to do >>>>>>> something like that in the past was not particularly successful or >>>>>>> encouraging. That could have been my fault, of course, but still se= ems a >>>>>>> relevant data point. I also have my doubts about the actual difficu= lty of >>>>>>> getting an AS to issue a 307 like response for requests based on th= e >>>>>>> calling client and the likelihood that some/all OAuth client softwa= re would >>>>>>> handle it appropriately. >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>>>>> david@alkaline-solutions.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden < >>>>>>>> neil.madden@forgerock.com> wrote: >>>>>>>> > >>>>>>>> > On 9 Jan 2019, at 05:54, David Waite < >>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>> >> >>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>>> >>> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> All of that is meant as an explanation of sorts to say that I >>>>>>>> think that things are actually okay enough as is and that I'd like= to >>>>>>>> retract the proposal I'd previously made about the MTLS draft intr= oducing a >>>>>>>> new AS metadata parameter. It is admittedly interesting (ironic?) = that Neil >>>>>>>> sent a message in support of the proposal as I was writing this. I= t did >>>>>>>> give me pause but ultimately didn't change my opinion that it's no= t worth >>>>>>>> it to add this new AS metadata parameter. >>>>>>>> >> >>>>>>>> >> Note that the AS could make a decision based on the token >>>>>>>> endpoint request - such as a policy associated with the =E2=80=9Cc= lient_id=E2=80=9D, or via >>>>>>>> a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was >>>>>>>> desired by this public client installation. The AS could then to T= LS 1.2 >>>>>>>> renegotiation, 1.3 post-handshake client authentication, or even u= se 307 >>>>>>>> temporary redirects to another token endpoint to perform mutual >>>>>>>> authentication. >>>>>>>> > >>>>>>>> > Renegotiation is an intriguing option, but it has some practical >>>>>>>> difficulties. Our AS product runs in a Java servlet container, whe= re it is >>>>>>>> pretty much impossible to dynamically trigger renegotiation withou= t >>>>>>>> accessing private internal APIs of the container. I also don=E2=80= =99t know how you >>>>>>>> could coordinate this in the common scenario where TLS is terminat= ed at a >>>>>>>> load balancer/reverse proxy? >>>>>>>> > >>>>>>>> > A 307 redirect could work though as the server will know if the >>>>>>>> client either uses mTLS for client authentication or has indicated= that it >>>>>>>> wants certificate-bound access tokens, so it can redirect to a >>>>>>>> mTLS-specific endpoint in those cases. >>>>>>>> >>>>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t= know a >>>>>>>> way to have say a custom error code or WWW-Authenticate challenge = to >>>>>>>> trigger renegotiation on the reverse proxy - usually this is just = a static, >>>>>>>> location-based directive. >>>>>>>> >>>>>>>> > >>>>>>>> >> Both the separate metadata url and a >>>>>>>> =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that = the client has multiple >>>>>>>> forms of authentication and is choosing to use MTLS. The URL in pa= rticular >>>>>>>> I=E2=80=99m reluctant to add support for, because I see it more li= kely a client >>>>>>>> would use MTLS without knowing it (via a device-level policy being= applied >>>>>>>> to a public web or native app) than the reverse, where a single cl= ient >>>>>>>> (represented by a single client_id) is dynamically picking between= forms of >>>>>>>> authentication. >>>>>>>> > >>>>>>>> > That=E2=80=99s an interesting observation. Can you elaborate on = the sorts >>>>>>>> of device policy you are talking about? I am aware of e.g. mobile = device >>>>>>>> management being used to push client certificates to iOS devices, = but I >>>>>>>> think these are only available in Safari. >>>>>>>> >>>>>>>> The primary use is to set policy to rely on device level managemen= t >>>>>>>> in controlled environments like enterprises when available. So an = AS may >>>>>>>> try to detect a client certificate as an indicator of a managed de= vice, use >>>>>>>> that to assume a device with certain device-level authentication, = single >>>>>>>> user usage, remote wipe, etc. characteristics, and decide that it = can >>>>>>>> reduce user authentication requirements and/or expose additional s= copes. >>>>>>>> >>>>>>>> On more thought, this is typically done as part of the user agent >>>>>>>> hitting the authorization endpoint, as a separate native applicati= on may be >>>>>>>> interacting with the token endpoint, and in some operating systems= the >>>>>>>> application=E2=80=99s network connections do not utilize (and may = not have access >>>>>>>> to) the system certificate store. >>>>>>>> >>>>>>>> In terms of user agents, I believe you can perform similar behavio= r >>>>>>>> (managed systems using client certificates on user agents transpar= ently) on >>>>>>>> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) = typically >>>>>>>> inherits device level policy. Firefox on desktop I assume you can = do that >>>>>>>> in limited fashion as well. >>>>>>>> >>>>>>>> -DW >>>>>>> >>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). = Any >>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>> prohibited.... If you have received this communication in error, p= lease >>>>>>> notify the sender immediately by e-mail and delete the message and = any file >>>>>>> attachments from your computer. Thank you.* >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>> >>> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000bd21680580db6059 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would be more a client having reached a non-MTLS endpoi= nt and is 307'd to an MTLS enabled endpoint.

On Fri, Feb 1, 2019 = at 1:40 PM Phil Hunt <phil.hunt@= oracle.com> wrote:
I was a bit confused b= y how the 307 would work.

To confirm, Is the client havi= ng reached an MTLS optional endpoint being redirected to an MTLS mandatory = endpoint if the AT (or a cookie) is detected to have a =E2=80=9Ccnf=E2=80= =9D claim in order to make the browser invoke MTLS?

Phil

Oracle Corporat= ion, Cloud Security and Identity Architect
@independentid
www.independe= ntid.com
phil.hunt@oracle.com
<= /div>

On Feb 1, 2019, at 11:56 AM, Brian = Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I'm finally getting around = to working on the document updates (there's quite a few things that cam= e out of AD review too). As far as the issue in this thread goes though, I&= #39;m leaning towards adding "mtls_endpoints" as a new metadata p= arameter. Maybe mention that a 307 might happen but it'd be more of a c= onsiderations type text.

On Wed, Jan 16, 2019 at 5:52 AM Brian Ca= mpbell <= bcampbell@pingidentity.com> wrote:
I guess I should have also said = or been more straightforward in saying that I don't particularly want t= o try and discuss/define the use of a 307 in the document.

On Tue, Jan 15, 2019 at 6:59 AM F= ilip Skokan <pan= va.ip@gmail.com> wrote:
<= div dir=3D"ltr">
I d= on't know that the use of 307 would need to be discussed in the documen= t itself.=C2=A0

If the clients are s= upposed to be ready for this, yeah. For instance, my client software by def= ault doesn't follow redirects, in order for it to be ready for mtls cli= ent authentication i'd have to know 307 is a possibility and whitelist = 307 as a valid code to be followed.

S= pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell= <bcampb= ell@pingidentity.com> wrote:
I don't know that the use of 307 w= ould need to be discussed in the document itself.

On Tue, Jan 15, 2019 at 2:30 AM Filip Sko= kan <panva.ip@gm= ail.com> wrote:
I'm in favour of both 307 and metadata.=C2= =A0
  • case 307 - I don't recall ever encountering an ht= tp client software that wouldn't have an option for following redirects= , same for a server side frameworks not having the option to do a 307 respo= nse with a location header.
  • case 307 - Relying purely on a new = metadata doesn't help in the scenario David put forth earlier about cli= ents not being aware of using mtls, a device policy of sorts.
  • c= ase metadata - no second request if the client knows there's an mtls en= dpoint it should use.
Maybe we should specify both as o= ptional for an AS to deploy and a client to be ready for?

S pozdravem,
Filip Skokan=


On Tu= e, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:=
I'm in favour of the `mtls_endpoints` met= adata parameter - although it should be optional.
While a 307 redirec= t seems kind of elegant I worry, like you,=C2=A0 that not all clients would= handle it appropriately.
There would probably need to be an error de= fined for clients who attempt to use `tls_client_auth` at the regular endpo= int.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to summarize things somewhat here and= focus in hopefully towards some decision. There's basically an idea on= the table to add an AS metadata parameter to the draft-ietf-oauth-mtls doc= that would be a JSON object which contains endpoints that a client doing M= TLS would use rather than the regular endpoints. A straw-man example might = look like this (with mtls_endpoints being that new parameter).
{=C2=A0
=C2=A0 "issuer":"https://server.example.com",
=C2= =A0 "authorization_endpoint":"https://server.example.com/authz"= ,
=C2=A0 "token_endpoint":"https://server.example.com/token"= ,
=C2=A0 "token_endpoint_auth_methods_supported":[=C2=A0 "= ;client_secret_basic","tls_client_auth", "none"],<= br>=C2=A0 "userinfo_endpoint":"https://server..example.com/userinfo",
=C2=A0 "revocation_endpoint":"https://server.example.com/rev= o",
=C2=A0 "jwks_uri":"https://server.example.com/jwks.j= son",
=C2=A0 "mtls_endpoints":{=C2=A0
=C2=A0= =C2=A0=C2=A0 "token_endpoint":"https://mtls.example.com/token",=C2=A0=C2=A0=C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0=C2=A0=C2=A0 "revocation_endpoint":"https:= //mtls..example.com/re= vo"
=C2=A0 }
}

The idea beh= ind this is that "regular" clients (those not doing MTLS) will us= e the regular endpoints. And only the host/port of the endpoints listed in = mtls_endpoints will be set up to request TLS client certificates during han= dshake.. Thus any potential impact of the CertificateRequest message being = sent in the TLS handshake can be avoided for all the other regular clients = that are not going to do MTLS - including and most importantly in-browser j= avascript clients where there can be less than desirable UI presented to th= e end-user.

The arguments in favor of that se= em to be basically that it allows for AS deployments to support MTLS while = still allowing for a "not broken" UX for end-users of clients (in= -browser javascript clients) that aren't doing MTLS. And that it's = not much in terms of adding to the spec and complexity of implementations. =

The arguments against it seem to be 1) the ba= d UX isn't really that bad and/or will only happen to a subset of users= 2) there are other things that can be done, such as 307ing or renegotiatio= n/post-handshake client auth, to avoid the bad UX.

Speaking for myself, I'm kinda torn on it.

I will say that, in addition to the folks that have pointed out tha= t renegotiation just isn't possible in some cases, my experience trying= to do something like that in the past was not particularly successful or e= ncouraging. That could have been my fault, of course, but still seems a rel= evant data point. I also have my doubts about the actual difficulty of gett= ing an AS to issue a 307 like response for requests based on the calling cl= ient and the likelihood that some/all OAuth client software would handle it= appropriately.
=C2=A0

On Fri,= Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote= :


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited....=C2=A0 If you have received this communication in = error, please notify the sender immediately by e-mail and delete the messag= e and any file attachments from your computer. Thank you.= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
OAuth mailing list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth

<= /div>
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000bd21680580db6059-- From nobody Fri Feb 1 13:12:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848EB1312C8 for ; Fri, 1 Feb 2019 13:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.851 X-Spam-Level: X-Spam-Status: No, score=-8.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8wcQdOwdBma for ; Fri, 1 Feb 2019 13:12:04 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0FD130EB3 for ; Fri, 1 Feb 2019 13:12:04 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x11L4R7O091303; Fri, 1 Feb 2019 21:12:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=DpKhctuupVtZTrtuG2A0hmew/nsc82FMMhIAd7aTVt0=; b=DPYH7WL7MXllhM5qYccXbfGKwC+Eeejo+C/srG2KMCC4R/h3cgHHJa1gmGLSLhpMFZoq LmRjDepMd5uyDLvrTbLuP45m4T3tqh+adhE7QTvwCkW2xxThS1QUMWFQvaLeDDXhhk8B wgJu7PrhwRGzKdZbgUd6xLOkQUPEIGsfh2VB0JB6JXsQW9RTpcKyhMAcJGfE9Gpqxb+3 21BqtvJQEXzHxrxujEV5DpY5tF5Q718IP7lPwWHGXHf1DxRsOwzThFgs8dgMgFiKd2mY 7jvw23f8QekAeT49tNjn2Dm+e3JZq2Ja015n8bymjUJ4p5rTorJuocIMCn7Uk15qaiiT eg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2q8g6rrtkj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Feb 2019 21:12:02 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x11LC0ZB012887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Feb 2019 21:12:01 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x11LC0do021958; Fri, 1 Feb 2019 21:12:00 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Feb 2019 13:11:59 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-74F91A4F-E718-442A-AAAA-5C987694B66A Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Fri, 1 Feb 2019 13:11:58 -0800 Cc: Filip Skokan , oauth Content-Transfer-Encoding: 7bit Message-Id: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> To: Brian Campbell X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9154 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902010149 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:12:14 -0000 --Apple-Mail-74F91A4F-E718-442A-AAAA-5C987694B66A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If a client attempts to force mtls would typical tls terminators accept it e= nough to redirect? My worry is how optionality works in browsers. It seems like they have to hi= t an mtls required endpoint before they reliably use a client cert.=20 Phil > On Feb 1, 2019, at 12:56 PM, Brian Campbell w= rote: >=20 > It would be more a client having reached a non-MTLS endpoint and is 307'd t= o an MTLS enabled endpoint.=20 >=20 >> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote: >> I was a bit confused by how the 307 would work. >>=20 >> To confirm, Is the client having reached an MTLS optional endpoint being r= edirected to an MTLS mandatory endpoint if the AT (or a cookie) is detected t= o have a =E2=80=9Ccnf=E2=80=9D claim in order to make the browser invoke MTL= S? >>=20 >> Phil >>=20 >> Oracle Corporation, Cloud Security and Identity Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Feb 1, 2019, at 11:56 AM, Brian Campbell wrote: >>>=20 >>> I'm finally getting around to working on the document updates (there's q= uite a few things that came out of AD review too). As far as the issue in th= is thread goes though, I'm leaning towards adding "mtls_endpoints" as a new m= etadata parameter. Maybe mention that a 307 might happen but it'd be more of= a considerations type text.=20 >>>=20 >>>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell wrote: >>>> I guess I should have also said or been more straightforward in saying t= hat I don't particularly want to try and discuss/define the use of a 307 in t= he document.=20 >>>>=20 >>>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan wrote= : >>>>>> I don't know that the use of 307 would need to be discussed in the do= cument itself.=20 >>>>>=20 >>>>> If the clients are supposed to be ready for this, yeah. For instance, m= y client software by default doesn't follow redirects, in order for it to be= ready for mtls client authentication i'd have to know 307 is a possibility a= nd whitelist 307 as a valid code to be followed. >>>>>=20 >>>>> S pozdravem, >>>>> Filip Skokan >>>>>=20 >>>>>=20 >>>>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell wrote: >>>>>> I don't know that the use of 307 would need to be discussed in the do= cument itself.=20 >>>>>>=20 >>>>>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan wr= ote: >>>>>>> I'm in favour of both 307 and metadata.=20 >>>>>>> case 307 - I don't recall ever encountering an http client software t= hat wouldn't have an option for following redirects, same for a server side f= rameworks not having the option to do a 307 response with a location header.= >>>>>>> case 307 - Relying purely on a new metadata doesn't help in the scen= ario David put forth earlier about clients not being aware of using mtls, a d= evice policy of sorts. >>>>>>> case metadata - no second request if the client knows there's an mtl= s endpoint it should use. >>>>>>> Maybe we should specify both as optional for an AS to deploy and a c= lient to be ready for? >>>>>>>=20 >>>>>>> S pozdravem, >>>>>>> Filip Skokan >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge wrote: >>>>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although= it should be optional. >>>>>>>> While a 307 redirect seems kind of elegant I worry, like you, that= not all clients would handle it appropriately. >>>>>>>> There would probably need to be an error defined for clients who at= tempt to use `tls_client_auth` at the regular endpoint. >>>>>>>>=20 >>>>>>>> Dave >>>>>>>>=20 >>>>>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell wrote: >>>>>>>>> Trying to summarize things somewhat here and focus in hopefully to= wards some decision. There's basically an idea on the table to add an AS met= adata parameter to the draft-ietf-oauth-mtls doc that would be a JSON object= which contains endpoints that a client doing MTLS would use rather than the= regular endpoints. A straw-man example might look like this (with mtls_endp= oints being that new parameter). >>>>>>>>>=20 >>>>>>>>> { =20 >>>>>>>>> "issuer":"https://server.example.com", >>>>>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>>>>> "token_endpoint":"https://server.example.com/token", >>>>>>>>> "token_endpoint_auth_methods_supported":[ "client_secret_basic"= ,"tls_client_auth", "none"], >>>>>>>>> "userinfo_endpoint":"https://server..example.com/userinfo", >>>>>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>>>>> "mtls_endpoints":{ =20 >>>>>>>>> "token_endpoint":"https://mtls.example.com/token", >>>>>>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>>>>>>> "revocation_endpoint":"https://mtls..example.com/revo" >>>>>>>>> } >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> The idea behind this is that "regular" clients (those not doing MT= LS) will use the regular endpoints. And only the host/port of the endpoints l= isted in mtls_endpoints will be set up to request TLS client certificates du= ring handshake.. Thus any potential impact of the CertificateRequest message= being sent in the TLS handshake can be avoided for all the other regular cl= ients that are not going to do MTLS - including and most importantly in-brow= ser javascript clients where there can be less than desirable UI presented t= o the end-user.=20 >>>>>>>>>=20 >>>>>>>>> The arguments in favor of that seem to be basically that it allows= for AS deployments to support MTLS while still allowing for a "not broken" U= X for end-users of clients (in-browser javascript clients) that aren't doing= MTLS. And that it's not much in terms of adding to the spec and complexity o= f implementations.=20 >>>>>>>>>=20 >>>>>>>>> The arguments against it seem to be 1) the bad UX isn't really tha= t bad and/or will only happen to a subset of users 2) there are other things= that can be done, such as 307ing or renegotiation/post-handshake client aut= h, to avoid the bad UX.=20 >>>>>>>>>=20 >>>>>>>>> Speaking for myself, I'm kinda torn on it.=20 >>>>>>>>>=20 >>>>>>>>> I will say that, in addition to the folks that have pointed out th= at renegotiation just isn't possible in some cases, my experience trying to d= o something like that in the past was not particularly successful or encoura= ging. That could have been my fault, of course, but still seems a relevant d= ata point. I also have my doubts about the actual difficulty of getting an A= S to issue a 307 like response for requests based on the calling client and t= he likelihood that some/all OAuth client software would handle it appropriat= ely.=20 >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden wrote: >>>>>>>>>> >=20 >>>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite wrote: >>>>>>>>>> >>=20 >>>>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell wrote: >>>>>>>>>> >>>=20 >>>>>>>>>> >> >>>>>>>>>> >>=20 >>>>>>>>>> >>> All of that is meant as an explanation of sorts to say that I= think that things are actually okay enough as is and that I'd like to retra= ct the proposal I'd previously made about the MTLS draft introducing a new A= S metadata parameter. It is admittedly interesting (ironic?) that Neil sent a= message in support of the proposal as I was writing this. It did give me pa= use but ultimately didn't change my opinion that it's not worth it to add th= is new AS metadata parameter. >>>>>>>>>> >>=20 >>>>>>>>>> >> Note that the AS could make a decision based on the token endp= oint request - such as a policy associated with the =E2=80=9Cclient_id=E2=80= =9D, or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D= indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, o= r even use 307 temporary redirects to another token endpoint to perform mutu= al authentication. >>>>>>>>>> >=20 >>>>>>>>>> > Renegotiation is an intriguing option, but it has some practica= l difficulties. Our AS product runs in a Java servlet container, where it is= pretty much impossible to dynamically trigger renegotiation without accessi= ng private internal APIs of the container. I also don=E2=80=99t know how you= could coordinate this in the common scenario where TLS is terminated at a l= oad balancer/reverse proxy? >>>>>>>>>> >=20 >>>>>>>>>> > A 307 redirect could work though as the server will know if the= client either uses mTLS for client authentication or has indicated that it w= ants certificate-bound access tokens, so it can redirect to a mTLS-specific e= ndpoint in those cases. >>>>>>>>>>=20 >>>>>>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99= t know a way to have say a custom error code or WWW-Authenticate challenge t= o trigger renegotiation on the reverse proxy - usually this is just a static= , location-based directive. >>>>>>>>>>=20 >>>>>>>>>> >=20 >>>>>>>>>> >> Both the separate metadata url and a =E2=80=9Cclient_assertion= _type=E2=80=9D-like indicator imply that the client has multiple forms of au= thentication and is choosing to use MTLS. The URL in particular I=E2=80=99m r= eluctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publi= c web or native app) than the reverse, where a single client (represented by= a single client_id) is dynamically picking between forms of authentication.= >>>>>>>>>> >=20 >>>>>>>>>> > That=E2=80=99s an interesting observation. Can you elaborate on= the sorts of device policy you are talking about? I am aware of e.g. mobile= device management being used to push client certificates to iOS devices, bu= t I think these are only available in Safari. >>>>>>>>>>=20 >>>>>>>>>> The primary use is to set policy to rely on device level manageme= nt in controlled environments like enterprises when available. So an AS may t= ry to detect a client certificate as an indicator of a managed device, use t= hat to assume a device with certain device-level authentication, single user= usage, remote wipe, etc. characteristics, and decide that it can reduce use= r authentication requirements and/or expose additional scopes. >>>>>>>>>>=20 >>>>>>>>>> On more thought, this is typically done as part of the user agent= hitting the authorization endpoint, as a separate native application may be= interacting with the token endpoint, and in some operating systems the appl= ication=E2=80=99s network connections do not utilize (and may not have acces= s to) the system certificate store. >>>>>>>>>>=20 >>>>>>>>>> In terms of user agents, I believe you can perform similar behavi= or (managed systems using client certificates on user agents transparently) o= n macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typicall= y inherits device level policy. Firefox on desktop I assume you can do that i= n limited fashion as well. >>>>>>>>>>=20 >>>>>>>>>> -DW >>>>>>>>>=20 >>>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.... If yo= u have received this communication in error, please notify the sender immedi= ately by e-mail and delete the message and any file attachments from your co= mputer. Thank you._______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you. >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. --Apple-Mail-74F91A4F-E718-442A-AAAA-5C987694B66A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable If a client attempts to force mtls would ty= pical tls terminators accept it enough to redirect?

My wo= rry is how optionality works in browsers. It seems like they have to hit an m= tls required endpoint before they reliably use a client cert. 

<= div id=3D"AppleMailSignature" dir=3D"ltr">Phil

On = Feb 1, 2019, at 12:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

It would be more a cli= ent having reached a non-MTLS endpoint and is 307'd to an MTLS enabled endpo= int.

On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <phil.hunt@oracle.com> wrote:
= I was a bit confused by how the 307 would work.

To confir= m, Is the client having reached an MTLS optional endpoint being redirected t= o an MTLS mandatory endpoint if the AT (or a cookie) is detected to have a =E2= =80=9Ccnf=E2=80=9D claim in order to make the browser invoke MTLS?

Phil

Oracle Corporation, Cloud Security and Ident= ity Architect
@independentid
phil.hunt@oracle.com
<= /div>

On Feb 1, 2019, at 11:56 AM, Brian C= ampbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wro= te:

I'm finally getting around to workin= g on the document updates (there's quite a few things that came out of AD re= view too). As far as the issue in this thread goes though, I'm leaning towar= ds adding "mtls_endpoints" as a new metadata parameter. Maybe mention that a= 307 might happen but it'd be more of a considerations type text.
=

O= n Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <bcampbell@pingidentity.com> wro= te:
I guess I should have also said or been more straightforward in saying th= at I don't particularly want to try and discuss/define the use of a 307 in t= he document.

On Tu= e, Jan 15, 2019 at 6:59 AM Filip Skokan <panva.ip@gmail.com> wrote:
I don't know that the use of 307 would need to be discus= sed in the document itself. 

If t= he clients are supposed to be ready for this, yeah. For instance, my client s= oftware by default doesn't follow redirects, in order for it to be ready for= mtls client authentication i'd have to know 307 is a possibility and whitel= ist 307 as a valid code to be followed.

S= pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell &= lt;bcampbell= @pingidentity.com> wrote:
I don't know that the use of 307 would need t= o be discussed in the document itself.

On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com>= wrote:
I'm in favour of both 307 and metadata. 
  • c= ase 307 - I don't recall ever encountering an http client software that woul= dn't have an option for following redirects, same for a server side framewor= ks not having the option to do a 307 response with a location header.
  • case 307 - Relying purely on a new metadata doesn't help in the scenar= io David put forth earlier about clients not being aware of using mtls, a de= vice policy of sorts.
  • case metadata - no second request if the c= lient knows there's an mtls endpoint it should use.
Mayb= e we should specify both as optional for an AS to deploy and a client to be r= eady for?

S pozdravem= ,
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@momentumft= .co.uk> wrote:
I'm in favour of the `mtls_e= ndpoints` metadata parameter - although it should be optional.
<= div class=3D"gmail_default">While a 3= 07 redirect seems kind of elegant I worry, like you,  that not all clie= nts would handle it appropriately.
= There would probably need to be an e= rror defined for clients who attempt to use `tls_client_auth` at the regular= endpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell <b= campbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to summarize things somewhat here and focus i= n hopefully towards some decision. There's basically an idea on the table to= add an AS metadata parameter to the draft-ietf-oauth-mtls doc that would be= a JSON object which contains endpoints that a client doing MTLS would use r= ather than the regular endpoints. A straw-man example might look like this (= with mtls_endpoints being that new parameter).

{ 
&nb= sp; "issuer":"http= s://server.example.com",
  "authorization_endpoint":"https://server.example.c= om/authz",
  "token_endpoint":"https://server.example.com/token",
&nbs= p; "token_endpoint_auth_methods_supported":[  "client_secret_basic","tl= s_client_auth", "none"],
  "userinfo_endpoint":"https://server..example.com/us= erinfo",
  "revocation_endpoint":"https://server.example.com/revo",
&nb= sp; "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoin= ts":{ 
    "token_endpoint":"https://mtls.example.com/token",    "userinfo_endpoint":"https://mtls.example.com/userinfo",
  = ;  "revocation_endpoint":"https://mtls..example.com/revo"
  }
}

The idea behind this is that "regular" clients (those not d= oing MTLS) will use the regular endpoints. And only the host/port of the end= points listed in mtls_endpoints will be set up to request TLS client certifi= cates during handshake.. Thus any potential impact of the CertificateRequest= message being sent in the TLS handshake can be avoided for all the other re= gular clients that are not going to do MTLS - including and most importantly= in-browser javascript clients where there can be less than desirable UI pre= sented to the end-user.

The arguments in favor= of that seem to be basically that it allows for AS deployments to support M= TLS while still allowing for a "not broken" UX for end-users of clients (in-= browser javascript clients) that aren't doing MTLS. And that it's not much i= n terms of adding to the spec and complexity of implementations.
<= div>
The arguments against it seem to be 1) the bad UX isn't r= eally that bad and/or will only happen to a subset of users 2) there are oth= er things that can be done, such as 307ing or renegotiation/post-handshake c= lient auth, to avoid the bad UX.

Speaking for m= yself, I'm kinda torn on it.

I will say that, i= n addition to the folks that have pointed out that renegotiation just isn't p= ossible in some cases, my experience trying to do something like that in the= past was not particularly successful or encouraging. That could have been m= y fault, of course, but still seems a relevant data point. I also have my do= ubts about the actual difficulty of getting an AS to issue a 307 like respon= se for requests based on the calling client and the likelihood that some/all= OAuth client software would handle it appropriately.
 <= br>

On Fri, Jan 11, 2019 at 12:32 PM David Waite &l= t;david@al= kaline-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wrote= :
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> wro= te:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40pingide= ntity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I t= hink that things are actually okay enough as is and that I'd like to retract= the proposal I'd previously made about the MTLS draft introducing a new AS m= etadata parameter. It is admittedly interesting (ironic?) that Neil sent a m= essage in support of the proposal as I was writing this. It did give me paus= e but ultimately didn't change my opinion that it's not worth it to add this= new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint r= equest - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D, o= r via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D indi= cating MTLS was desired by this public client installation. The AS could the= n to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, or eve= n use 307 temporary redirects to another token endpoint to perform mutual au= thentication.
>
> Renegotiation is an intriguing option, but it has some practical diffic= ulties. Our AS product runs in a Java servlet container, where it is pretty m= uch impossible to dynamically trigger renegotiation without accessing privat= e internal APIs of the container. I also don=E2=80=99t know how you could co= ordinate this in the common scenario where TLS is terminated at a load balan= cer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client e= ither uses mTLS for client authentication or has indicated that it wants cer= tificate-bound access tokens, so it can redirect to a mTLS-specific endpoint= in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a wa= y to have say a custom error code or WWW-Authenticate challenge to trigger r= enegotiation on the reverse proxy - usually this is just a static, location-= based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_type= =E2=80=9D-like indicator imply that the client has multiple forms of authent= ication and is choosing to use MTLS. The URL in particular I=E2=80=99m reluc= tant to add support for, because I see it more likely a client would use MTL= S without knowing it (via a device-level policy being applied to a public we= b or native app) than the reverse, where a single client (represented by a s= ingle client_id) is dynamically picking between forms of authentication.
= >
> That=E2=80=99s an interesting observation. Can you elaborate on the sor= ts of device policy you are talking about? I am aware of e.g. mobile device m= anagement being used to push client certificates to iOS devices, but I think= these are only available in Safari.

The primary use is to set policy to rely on device level management in contr= olled environments like enterprises when available. So an AS may try to dete= ct a client certificate as an indicator of a managed device, use that to ass= ume a device with certain device-level authentication, single user usage, re= mote wipe, etc. characteristics, and decide that it can reduce user authenti= cation requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting th= e authorization endpoint, as a separate native application may be interactin= g with the token endpoint, and in some operating systems the application=E2=80= =99s network connections do not utilize (and may not have access to) the sys= tem certificate store.

In terms of user agents, I believe you can perform similar behavior (managed= systems using client certificates on user agents transparently) on macOS, W= indows, Chrome, and Android devices, Chrome (outside iOS) typically inherits= device level policy. Firefox on desktop I assume you can do that in limited= fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email may contain c= onfidential and privileged material for the sole use of the intended recipie= nt(s). Any review, use, distribution or disclosure by others is strictly pro= hibited....  If you have received this communication in error, please n= otify the sender immediately by e-mail and delete the message and any file a= ttachments from your computer. Thank you._________________= ______________________________
OAuth mailing list
OAuth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email may contain c= onfidential and privileged material for the sole use of the intended recipie= nt(s). Any review, use, distribution or disclosure by others is strictly pro= hibited.  If you have received this communication in error, please noti= fy the sender immediately by e-mail and delete the message and any file atta= chments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain c= onfidential and privileged material for the sole use of the intended recipie= nt(s). Any review, use, distribution or disclosure by others is strictly pro= hibited..  If you have received this communication in error, please not= ify the sender immediately by e-mail and delete the message and any file att= achments from your computer. Thank you.___________________= ____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /div>

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.= --Apple-Mail-74F91A4F-E718-442A-AAAA-5C987694B66A-- From nobody Fri Feb 1 13:14:36 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A71B130E8F for ; Fri, 1 Feb 2019 13:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4OR9IbIAkc8 for ; Fri, 1 Feb 2019 13:14:29 -0800 (PST) Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8158E124408 for ; Fri, 1 Feb 2019 13:14:29 -0800 (PST) Received: by mail-it1-x144.google.com with SMTP id m8so5958384itk.0 for ; Fri, 01 Feb 2019 13:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EZkPMgN5wMlsD1RCFGoxWSVtrffNemjtgY+Ykge5D0Q=; b=j+gpu7eG92aLYsIwb/lS/gDW741rtURq0QwpotcYfgrwEvEwwBW1ekPP/UN3jYJu7s hb2JtpF/lO8aj/5Te5U1zcJN3Y56mVepM1T88eQTsc+OyfwbDaw0c/s/H9TwYm2J2x7N +dYmaP6Km42UEFVAeba6V+wajYM+7CtGHgY9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EZkPMgN5wMlsD1RCFGoxWSVtrffNemjtgY+Ykge5D0Q=; b=GELoCsuNrLa8ae5JV6zOTHJy8RyBlRGTtMDx8pgWohlo3PGOkTbZKV4un0JPEeYLC1 Xpi5SQIpI+nfnaH7ghSzpIJOJoqWnmkbv07oODK5M+coluUXoeNWDnEskJ1nydOsa/Vd YT7fRJ9RLBtTS6FmH38Hr+PaIsoiIFnKUQZxV+F6CS6Mmq9AiPIQj+ORPwALZNGXOc+e J1hqnhBNxpbWd21paosH+vDeXfGjsnO9k61eCa/Ha+F8bwP57HLEpEZsGu9mXcVrx/tX QdHsUptJcfJLoW9rcbDvbNUgxroIlF+C3+EYxixWOVcTO34pieuntnSvuHgTvtocqfRv hsMg== X-Gm-Message-State: AHQUAua+WgSsfRbLuMer8TB4pyxMaAXFbhIzJqND5/P4TU1ObY4a9X2N NSyxOSiYwYxHdnrefxg0C/kekMoLhB+lYef70g25kkh+JyJdw3yj/XkkI2rrL7B0nIjRur/ncAo jSD21a6OCyfNpGg== X-Google-Smtp-Source: AHgI3IaJaw3hirgETzkBTqFv7+kvdGlqoQNHY5UygUKccl5UMaoNtDaiQRh7gVclXSB6DQUJG8lUgTos95YGPWz59Og= X-Received: by 2002:a24:6293:: with SMTP id d141mr2667204itc.124.1549055668525; Fri, 01 Feb 2019 13:14:28 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> In-Reply-To: From: Brian Campbell Date: Fri, 1 Feb 2019 14:14:01 -0700 Message-ID: To: Phil Hunt Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="000000000000dc3f620580dba0dd" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:14:34 -0000 --000000000000dc3f620580dba0dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The server has to ask during the handshake for a client to send a cert. On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt wrote: > If a client attempts to force mtls would typical tls terminators accept i= t > enough to redirect? > > My worry is how optionality works in browsers. It seems like they have to > hit an mtls required endpoint before they reliably use a client cert. > > Phil > > On Feb 1, 2019, at 12:56 PM, Brian Campbell > wrote: > > It would be more a client having reached a non-MTLS endpoint and is 307'd > to an MTLS enabled endpoint. > > On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote: > >> I was a bit confused by how the 307 would work. >> >> To confirm, Is the client having reached an MTLS optional endpoint being >> redirected to an MTLS mandatory endpoint if the AT (or a cookie) is >> detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the brow= ser invoke MTLS? >> >> Phil >> >> Oracle Corporation, Cloud Security and Identity Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Feb 1, 2019, at 11:56 AM, Brian Campbell < >> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: >> >> I'm finally getting around to working on the document updates (there's >> quite a few things that came out of AD review too). As far as the issue = in >> this thread goes though, I'm leaning towards adding "mtls_endpoints" as = a >> new metadata parameter. Maybe mention that a 307 might happen but it'd b= e >> more of a considerations type text. >> >> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I guess I should have also said or been more straightforward in saying >>> that I don't particularly want to try and discuss/define the use of a 3= 07 >>> in the document. >>> >>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan wrote= : >>> >>>> I don't know that the use of 307 would need to be discussed in the >>>>> document itself. >>>> >>>> >>>> If the clients are supposed to be ready for this, yeah. For instance, >>>> my client software by default doesn't follow redirects, in order for i= t to >>>> be ready for mtls client authentication i'd have to know 307 is a >>>> possibility and whitelist 307 as a valid code to be followed. >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> I don't know that the use of 307 would need to be discussed in the >>>>> document itself. >>>>> >>>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan >>>>> wrote: >>>>> >>>>>> I'm in favour of both 307 and metadata. >>>>>> >>>>>> - case 307 - I don't recall ever encountering an http client >>>>>> software that wouldn't have an option for following redirects, sa= me for a >>>>>> server side frameworks not having the option to do a 307 response= with a >>>>>> location header. >>>>>> - case 307 - Relying purely on a new metadata doesn't help in the >>>>>> scenario David put forth earlier about clients not being aware of= using >>>>>> mtls, a device policy of sorts. >>>>>> - case metadata - no second request if the client knows there's >>>>>> an mtls endpoint it should use. >>>>>> >>>>>> Maybe we should specify both as optional for an AS to deploy and a >>>>>> client to be ready for? >>>>>> >>>>>> S pozdravem, >>>>>> *Filip Skokan* >>>>>> >>>>>> >>>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge < >>>>>> dave.tonge@momentumft.co.uk> wrote: >>>>>> >>>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although >>>>>>> it should be optional. >>>>>>> While a 307 redirect seems kind of elegant I worry, like you, that >>>>>>> not all clients would handle it appropriately. >>>>>>> There would probably need to be an error defined for clients who >>>>>>> attempt to use `tls_client_auth` at the regular endpoint. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>>> Trying to summarize things somewhat here and focus in hopefully >>>>>>>> towards some decision. There's basically an idea on the table to a= dd an AS >>>>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be = a JSON >>>>>>>> object which contains endpoints that a client doing MTLS would use= rather >>>>>>>> than the regular endpoints. A straw-man example might look like th= is (with >>>>>>>> mtls_endpoints being that new parameter). >>>>>>>> >>>>>>>> { >>>>>>>> "issuer":"https://server.example.com", >>>>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>>>> "token_endpoint":"https://server.example.com/token", >>>>>>>> "token_endpoint_auth_methods_supported":[ >>>>>>>> "client_secret_basic","tls_client_auth", "none"], >>>>>>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>>>>>> ", >>>>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * "mtls_endpoints":{ >>>>>>>> "token_endpoint":"https://mtls.example.com/token >>>>>>>> ", "userinfo_endpoint":"https:/= /mtls >>>>>>>> .example.com/userinfo >>>>>>>> ", "revocation_endpoint":"https://= mtls >>>>>>>> ..example.com/revo >>>>>>>> " }* >>>>>>>> } >>>>>>>> >>>>>>>> The idea behind this is that "regular" clients (those not doing >>>>>>>> MTLS) will use the regular endpoints. And only the host/port of th= e >>>>>>>> endpoints listed in mtls_endpoints will be set up to request TLS c= lient >>>>>>>> certificates during handshake.. Thus any potential impact of the >>>>>>>> CertificateRequest message being sent in the TLS handshake can be = avoided >>>>>>>> for all the other regular clients that are not going to do MTLS - = including >>>>>>>> and most importantly in-browser javascript clients where there can= be less >>>>>>>> than desirable UI presented to the end-user. >>>>>>>> >>>>>>>> The arguments in favor of that seem to be basically that it allows >>>>>>>> for AS deployments to support MTLS while still allowing for a "not= broken" >>>>>>>> UX for end-users of clients (in-browser javascript clients) that a= ren't >>>>>>>> doing MTLS. And that it's not much in terms of adding to the spec = and >>>>>>>> complexity of implementations. >>>>>>>> >>>>>>>> The arguments against it seem to be 1) the bad UX isn't really tha= t >>>>>>>> bad and/or will only happen to a subset of users 2) there are othe= r things >>>>>>>> that can be done, such as 307ing or renegotiation/post-handshake c= lient >>>>>>>> auth, to avoid the bad UX. >>>>>>>> >>>>>>>> Speaking for myself, I'm kinda torn on it. >>>>>>>> >>>>>>>> I will say that, in addition to the folks that have pointed out >>>>>>>> that renegotiation just isn't possible in some cases, my experienc= e trying >>>>>>>> to do something like that in the past was not particularly success= ful or >>>>>>>> encouraging. That could have been my fault, of course, but still s= eems a >>>>>>>> relevant data point. I also have my doubts about the actual diffic= ulty of >>>>>>>> getting an AS to issue a 307 like response for requests based on t= he >>>>>>>> calling client and the likelihood that some/all OAuth client softw= are would >>>>>>>> handle it appropriately. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden < >>>>>>>>> neil.madden@forgerock.com> wrote: >>>>>>>>> > >>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite < >>>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>>> >> >>>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> All of that is meant as an explanation of sorts to say that I >>>>>>>>> think that things are actually okay enough as is and that I'd lik= e to >>>>>>>>> retract the proposal I'd previously made about the MTLS draft int= roducing a >>>>>>>>> new AS metadata parameter. It is admittedly interesting (ironic?)= that Neil >>>>>>>>> sent a message in support of the proposal as I was writing this. = It did >>>>>>>>> give me pause but ultimately didn't change my opinion that it's n= ot worth >>>>>>>>> it to add this new AS metadata parameter. >>>>>>>>> >> >>>>>>>>> >> Note that the AS could make a decision based on the token >>>>>>>>> endpoint request - such as a policy associated with the =E2=80=9C= client_id=E2=80=9D, or via >>>>>>>>> a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D= indicating MTLS was >>>>>>>>> desired by this public client installation. The AS could then to = TLS 1.2 >>>>>>>>> renegotiation, 1.3 post-handshake client authentication, or even = use 307 >>>>>>>>> temporary redirects to another token endpoint to perform mutual >>>>>>>>> authentication. >>>>>>>>> > >>>>>>>>> > Renegotiation is an intriguing option, but it has some practica= l >>>>>>>>> difficulties. Our AS product runs in a Java servlet container, wh= ere it is >>>>>>>>> pretty much impossible to dynamically trigger renegotiation witho= ut >>>>>>>>> accessing private internal APIs of the container. I also don=E2= =80=99t know how you >>>>>>>>> could coordinate this in the common scenario where TLS is termina= ted at a >>>>>>>>> load balancer/reverse proxy? >>>>>>>>> > >>>>>>>>> > A 307 redirect could work though as the server will know if the >>>>>>>>> client either uses mTLS for client authentication or has indicate= d that it >>>>>>>>> wants certificate-bound access tokens, so it can redirect to a >>>>>>>>> mTLS-specific endpoint in those cases. >>>>>>>>> >>>>>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99= t know a >>>>>>>>> way to have say a custom error code or WWW-Authenticate challenge= to >>>>>>>>> trigger renegotiation on the reverse proxy - usually this is just= a static, >>>>>>>>> location-based directive. >>>>>>>>> >>>>>>>>> > >>>>>>>>> >> Both the separate metadata url and a >>>>>>>>> =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that= the client has multiple >>>>>>>>> forms of authentication and is choosing to use MTLS. The URL in p= articular >>>>>>>>> I=E2=80=99m reluctant to add support for, because I see it more l= ikely a client >>>>>>>>> would use MTLS without knowing it (via a device-level policy bein= g applied >>>>>>>>> to a public web or native app) than the reverse, where a single c= lient >>>>>>>>> (represented by a single client_id) is dynamically picking betwee= n forms of >>>>>>>>> authentication. >>>>>>>>> > >>>>>>>>> > That=E2=80=99s an interesting observation. Can you elaborate on= the >>>>>>>>> sorts of device policy you are talking about? I am aware of e.g. = mobile >>>>>>>>> device management being used to push client certificates to iOS d= evices, >>>>>>>>> but I think these are only available in Safari. >>>>>>>>> >>>>>>>>> The primary use is to set policy to rely on device level >>>>>>>>> management in controlled environments like enterprises when avail= able. So >>>>>>>>> an AS may try to detect a client certificate as an indicator of a= managed >>>>>>>>> device, use that to assume a device with certain device-level >>>>>>>>> authentication, single user usage, remote wipe, etc. characterist= ics, and >>>>>>>>> decide that it can reduce user authentication requirements and/or= expose >>>>>>>>> additional scopes. >>>>>>>>> >>>>>>>>> On more thought, this is typically done as part of the user agent >>>>>>>>> hitting the authorization endpoint, as a separate native applicat= ion may be >>>>>>>>> interacting with the token endpoint, and in some operating system= s the >>>>>>>>> application=E2=80=99s network connections do not utilize (and may= not have access >>>>>>>>> to) the system certificate store. >>>>>>>>> >>>>>>>>> In terms of user agents, I believe you can perform similar >>>>>>>>> behavior (managed systems using client certificates on user agent= s >>>>>>>>> transparently) on macOS, Windows, Chrome, and Android devices, Ch= rome >>>>>>>>> (outside iOS) typically inherits device level policy. Firefox on = desktop I >>>>>>>>> assume you can do that in limited fashion as well. >>>>>>>>> >>>>>>>>> -DW >>>>>>>> >>>>>>>> >>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>>> privileged material for the sole use of the intended recipient(s).= Any >>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>> prohibited.... If you have received this communication in error, = please >>>>>>>> notify the sender immediately by e-mail and delete the message and= any file >>>>>>>> attachments from your computer. Thank you.* >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly prohibi= ted. >>>>> If you have received this communication in error, please notify the s= ender >>>>> immediately by e-mail and delete the message and any file attachments= from >>>>> your computer. Thank you.* >>>> >>>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000dc3f620580dba0dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The server has to ask during the handshake for a client to= send a cert.

On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <phil.hunt@oracle.com> wrote:
If a clie= nt attempts to force mtls would typical tls terminators accept it enough to= redirect?

My worry is how optionality works in browsers= . It seems like they have to hit an mtls required endpoint before they reli= ably use a client cert.=C2=A0

Phil

On Feb 1, 20= 19, at 12:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

<= /div>
It would b= e more a client having reached a non-MTLS endpoint and is 307'd to an M= TLS enabled endpoint.

On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
<= div>I was a bit confused by how the 307 would work.

To c= onfirm, Is the client having reached an MTLS optional endpoint being redire= cted to an MTLS mandatory endpoint if the AT (or a cookie) is detected to h= ave a =E2=80=9Ccnf=E2=80=9D claim in order to make the browser invoke MTLS?=



I= 9;m finally getting around to working on the document updates (there's = quite a few things that came out of AD review too). As far as the issue in = this thread goes though, I'm leaning towards adding "mtls_endpoint= s" as a new metadata parameter. Maybe mention that a 307 might happen = but it'd be more of a considerations type text.

On Wed, Jan 1= 6, 2019 at 5:52 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
I gue= ss I should have also said or been more straightforward in saying that I do= n't particularly want to try and discuss/define the use of a 307 in the= document.

On Tue= , Jan 15, 2019 at 6:59 AM Filip Skokan <panva.ip@gmail.com> wrote:
I don't know that the use of 307 would need to = be discussed in the document itself.=C2=A0

If the clients are supposed to be ready for this, yeah. For instance= , my client software by default doesn't follow redirects, in order for = it to be ready for mtls client authentication i'd have to know 307 is a= possibility and whitelist 307 as a valid code to be followed.

S pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 2:54 PM Brian Ca= mpbell <= bcampbell@pingidentity.com> wrote:
I don't know that the use of= 307 would need to be discussed in the document itself.

On Tue, Jan 15, 2019 at 2:30 AM Fili= p Skokan <panva.= ip@gmail.com> wrote:
I'm in favour of both 307 and metadat= a.=C2=A0
  • case 307 - I don't recall ever encountering = an http client software that wouldn't have an option for following redi= rects, same for a server side frameworks not having the option to do a 307 = response with a location header.
  • case 307 - Relying purely on a= new metadata doesn't help in the scenario David put forth earlier abou= t clients not being aware of using mtls, a device policy of sorts.
    • =
  • case metadata - no second request if the client knows there's an mt= ls endpoint it should use.
Maybe we should specify both= as optional for an AS to deploy and a client to be ready for?

S p= ozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <= dave.tonge= @momentumft.co.uk> wrote:
I'm in fa= vour of the `mtls_endpoints` metadata parameter - although it should be opt= ional.
While a 307 redirect seems kind of elegant I worry, like you,= =C2=A0 that not all clients would handle it appropriately.
There woul= d probably need to be an error defined for clients who attempt to use `tls_= client_auth` at the regular endpoint.

Dave

On Mon, 14 Jan 201= 9 at 22:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to = summarize things somewhat here and focus in hopefully towards some decision= . There's basically an idea on the table to add an AS metadata paramete= r to the draft-ietf-oauth-mtls doc that would be a JSON object which contai= ns endpoints that a client doing MTLS would use rather than the regular end= points. A straw-man example might look like this (with mtls_endpoints being= that new parameter).

{=C2=A0
=C2=A0 "issuer":&= quot;https://serv= er.example.com",
=C2=A0 "authorization_endpoint":&quo= t;https://se= rver.example.com/authz",
=C2=A0 "token_endpoint":&quo= t;https://se= rver.example.com/token",
=C2=A0 "token_endpoint_auth_metho= ds_supported":[=C2=A0 "client_secret_basic","tls_client= _auth", "none"],
=C2=A0 "userinfo_endpoint":&qu= ot;https:= //server..example.com/userinfo",
=C2=A0 "revocation_endpoi= nt":"https://server.example.com/revo",
=C2=A0 "jwks_uri"= :"h= ttps://server.example.com/jwks.json",
=C2=A0 "mtls_endp= oints":{=C2=A0
=C2=A0=C2=A0=C2=A0 "token_endpoint":"= ;https://mtls.= example.com/token",
=C2=A0=C2=A0=C2=A0 "userinfo_endpoint&= quot;:"https://mtls.example.com/userinfo",
=C2=A0=C2=A0=C2=A0 "revocat= ion_endpoint":"https://mtls..example.com/revo"
=C2=A0 }
}
<= div>
The idea behind this is that "regular" clients= (those not doing MTLS) will use the regular endpoints. And only the host/p= ort of the endpoints listed in mtls_endpoints will be set up to request TLS= client certificates during handshake.. Thus any potential impact of the Ce= rtificateRequest message being sent in the TLS handshake can be avoided for= all the other regular clients that are not going to do MTLS - including an= d most importantly in-browser javascript clients where there can be less th= an desirable UI presented to the end-user.

Th= e arguments in favor of that seem to be basically that it allows for AS dep= loyments to support MTLS while still allowing for a "not broken" = UX for end-users of clients (in-browser javascript clients) that aren't= doing MTLS. And that it's not much in terms of adding to the spec and = complexity of implementations.

The arguments = against it seem to be 1) the bad UX isn't really that bad and/or will o= nly happen to a subset of users 2) there are other things that can be done,= such as 307ing or renegotiation/post-handshake client auth, to avoid the b= ad UX.

Speaking for myself, I'm kinda tor= n on it.

I will say that, in addition to the = folks that have pointed out that renegotiation just isn't possible in s= ome cases, my experience trying to do something like that in the past was n= ot particularly successful or encouraging. That could have been my fault, o= f course, but still seems a relevant data point. I also have my doubts abou= t the actual difficulty of getting an AS to issue a 307 like response for r= equests based on the calling client and the likelihood that some/all OAuth = client software would handle it appropriately.
=C2=A0

On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkal= ine-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wro= te:
>
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> w= rote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org> wrote:
>>>
>> <snip>
>>
>>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to r= etract the proposal I'd previously made about the MTLS draft introducin= g a new AS metadata parameter. It is admittedly interesting (ironic?) that = Neil sent a message in support of the proposal as I was writing this. It di= d give me pause but ultimately didn't change my opinion that it's n= ot worth it to add this new AS metadata parameter.
>>
>> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>
> Renegotiation is an intriguing option, but it has some practical diffi= culties. Our AS product runs in a Java servlet container, where it is prett= y much impossible to dynamically trigger renegotiation without accessing pr= ivate internal APIs of the container. I also don=E2=80=99t know how you cou= ld coordinate this in the common scenario where TLS is terminated at a load= balancer/reverse proxy?
>
> A 307 redirect could work though as the server will know if the client= either uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific endp= oint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99t know a w= ay to have say a custom error code or WWW-Authenticate challenge to trigger= renegotiation on the reverse proxy - usually this is just a static, locati= on-based directive.

>
>> Both the separate metadata url and a =E2=80=9Cclient_assertion_typ= e=E2=80=9D-like indicator imply that the client has multiple forms of authe= ntication and is choosing to use MTLS. The URL in particular I=E2=80=99m re= luctant to add support for, because I see it more likely a client would use= MTLS without knowing it (via a device-level policy being applied to a publ= ic web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of authenticati= on.
>
> That=E2=80=99s an interesting observation. Can you elaborate on the so= rts of device policy you are talking about? I am aware of e.g. mobile devic= e management being used to push client certificates to iOS devices, but I t= hink these are only available in Safari.

The primary use is to set policy to rely on device level management in cont= rolled environments like enterprises when available. So an AS may try to de= tect a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user usage= , remote wipe, etc. characteristics, and decide that it can reduce user aut= hentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting t= he authorization endpoint, as a separate native application may be interact= ing with the token endpoint, and in some operating systems the application= =E2=80=99s network connections do not utilize (and may not have access to) = the system certificate store.

In terms of user agents, I believe you can perform similar behavior (manage= d systems using client certificates on user agents transparently) on macOS,= Windows, Chrome, and Android devices, Chrome (outside iOS) typically inher= its device level policy. Firefox on desktop I assume you can do that in lim= ited fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited....=C2=A0 If you have received this communication in = error, please notify the sender immediately by e-mail and delete the messag= e and any file attachments from your computer. Thank you.= _______________________________________________
OAuth mailing list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000dc3f620580dba0dd-- From nobody Fri Feb 1 13:28:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DA8130EC2 for ; Fri, 1 Feb 2019 13:28:47 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCMpOYTtOGuS for ; Fri, 1 Feb 2019 13:28:44 -0800 (PST) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D357130EB4 for ; Fri, 1 Feb 2019 13:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1549056523; bh=6EToU2jEcGhQE9Qzwk8gvAqPQt2q9DupbJiS0iXrBPQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=fBzSM+NHU3Q3ktd4ujb973lh514Z4lpPXdaT0qKwIxxNCfEMfxjDQbYo2BP1yeh9KQUiJ4aLr4i+kSC3IrdUZYrvM/BKV80VWCVQR/qgPEdKqgBZ4okxaP84S/H/Mb5YRSI05bPp3OP29+difpkc6tRVU8H1X1ZN9BwfuTbmN1+e4McbH0RBEHClyiaSRW5QiGi01I0TlrDnDGyI9wRnNQ7ufahn8juyg1Qnn1HvfwtYzItRA86c+Ic9lxA+ghRWTOqE9TW6cEuatvNM5/ILUAjfpmi3b364LjZY5oYd+mrHORcvaMY1pC6Kxk4kvAvTqwSbY5DNXXVm9QWApr38Rw== X-YMail-OSG: wQSLpY4VM1l.mG0xkGcH0Hi4nVc1_Ck3..BGE.i6zVJdTW7Xy67BueoLT_.BtfS S1hySL29s32AOWIMxtUqqCzXStnm4wQxgENDvbiqekS2YLf3HKRRly33q.6P8ydFThPrPaOAqR5y YWI3bjdw6Y9pK6EP7wlTzZ_UVGA.Yz2yB0LrMvHsEtjvLurTClAxmf0C1SvLJUKLZigRjSyEjhHA rOeVkoVN3sAT6pZLDUTLZEFjpsto4uZXUrDp.5qhB3Y2fjTokAO6ishb.hEk56FW5WVIvHVQ77RC q2_4nlMC1Im.Xd05QYJ_GvFPcqQWkugHLb5YfMyjoeqVDy2iZ_ufQAL.Z9ue44efC2X4yv4cCga6 aU5dPSNXXI0HUuDz8TJT0IX4INVzABDeq96np6wQWgXBrFxdtfTxQ5mY7hWg0_aybJN3_fXiDvy9 9s3ZMA5FcORP6roVYgZE0bxhr7mIQ8a7yB98yYO_T2Cuazs8eeUzeKhEeDdpNF.0vhUXPgthEYSz 3ueuo0IPoVzx7DV7LLLbjnxcEJCVMjNCypOYL.B2zglxCBkppDrjJG0GnqVXquVNJkjpSTmHFWR3 08SPycBZFoM6yjtvwLBHmdQKMHeZVhu35nyYYeHbOr9BidEG.ejVq34KoyfSrNXJl0_8OL.ymZ85 FyZjet4yJARZ2AY7Fl.ZbejqUaZSr0WAOwRO1FNk_tLRFpzZpB._g6WU_QHzS1ryLSVAyzM9Fy6o LXAXrPfl0T2pCi3QoFQGIQ1o1uAp1XYcADAcbagYzR9Ud3WNyYG9qU35aLU4ca7ouuqq0u44WlSt XaN6pCzWpY9rB01s.LrcLue8I9FsUoPPD_qLawNu0HN1g6Phwsi92j5i5uP.hFzpKvfj7fMv__lP DiOCIbTIW0HutMWzjbEXo5EBy02eq9JqaxJIPQX_bxU0HtoYUBUfzxn6U_7k2sRXxToiQInasB1D eh04fq6Q3YAN5ZiASjT.4SpTmURpScss.Vgfq2RQPXYOGszhOp0Bd3i531BrTNg_N6mH5osb8tkI oM.kUFr7Lpj3Y0iU3Cfp2e84cq2f77C4lnGFmfylY1hmS0taDetYXGS.SI._4IQSBpGkx Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Feb 2019 21:28:43 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 52694e526060e0e71cf3171dda78c39b; Fri, 01 Feb 2019 21:28:40 +0000 (UTC) To: Brian Campbell , Dave Tonge Cc: oauth References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> From: George Fletcher Organization: AOL LLC Message-ID: <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> Date: Fri, 1 Feb 2019 16:28:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C32420BF4274A28571B079D1" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:28:47 -0000 This is a multi-part message in MIME format. --------------C32420BF4274A28571B079D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values? On 1/15/19 8:48 AM, Brian Campbell wrote: > It would definitely be optional, apologies if that wasn't made clear. > It'd be something to the effect of optional for the AS to include and > clients doing MTLS would use it when present in AS metadata. > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - > although it should be optional. > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------C32420BF4274A28571B079D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:
It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------C32420BF4274A28571B079D1-- From nobody Fri Feb 1 13:31:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7DF131309 for ; Fri, 1 Feb 2019 13:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_Z5opXn-lOQ for ; Fri, 1 Feb 2019 13:31:06 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5652130F03 for ; Fri, 1 Feb 2019 13:31:03 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id g85so11548497ita.3 for ; Fri, 01 Feb 2019 13:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FIkIh8Gsv9220efgOJQyWKJ4crtqMAwNtlK8SV8hArk=; b=Ocs8uHK+nIdzKwchIWK2lUhlY9acL5fvaxo8l6ewwXCHXXepx8g58lwWY9BP4XVbom bUOJXNrx/oKVFxs1d7B+uBszxmf9+PaIOaC6uc4PspVTajaHVzOgtOHoG3Q+854zuD0x 03MqG3EOoYjh6qWb8y4VRtTxbteg0NacOBXcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FIkIh8Gsv9220efgOJQyWKJ4crtqMAwNtlK8SV8hArk=; b=VKed8oW/FR7VmLP8mU3RUu/eI3FROUh8tPr3FkFnbAOGWfoMG9F+F/QzHd2YyunJcv RmlwWk6AxvpCrC6Z7d479tzBdjPrQCO+28Lj1NSAC48BRHGHvWsTQu0Gu9E0PLBYBlrj U1l3PW0V5gpuLQqIq87OZCb0lvPJ2D5weyTsln054xVgs/SEErCPxV7yE8V1ikPfuBDM pSNMwb+DmcT/aJw1QU5X7ImkaS1L0JTvmDou6VAEvIzdHW68VK15FGPOagWuMH2uLkeq nanfnPjjMHXI7NyvPecjbhA05MQgZZoyavmiadMv0Vr1uG2pIqxFZCSwyt2DzGjwIcJZ hGLw== X-Gm-Message-State: AJcUukeHfhVEi7b0Mfu5UtqIrZbSbSJvSjCYi+afZh3gVSNyIVAIAR4E uQMnlrTHYVNz4tAp1kkx2kLcq/jojMf8zdwOkW6Uqlm3eA+GZlBqhv4zZY78GNeOP3uh7SolIaz 5a4cvj8ZoB0pj+cmU X-Google-Smtp-Source: ALg8bN7Jwe0REMXrYohdJo3tLQwVFNq4iZmDz6z9HNf+RpJSPqf70dgbCYDFW2BQEQd5R8MNHRSeO9Qlm56zm6WvIAQ= X-Received: by 2002:a02:5f9d:: with SMTP id x29mr27464395jad.28.1549056663097; Fri, 01 Feb 2019 13:31:03 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> In-Reply-To: <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> From: Brian Campbell Date: Fri, 1 Feb 2019 14:30:36 -0700 Message-ID: To: George Fletcher Cc: Dave Tonge , oauth Content-Type: multipart/alternative; boundary="0000000000002430580580dbdc50" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:31:12 -0000 --0000000000002430580580dbdc50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that would work. On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000002430580580dbdc50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, that would work.=C2=A0

On Fri, Feb 1, 2019 at 2:28= PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8= :48 AM, Brian Campbell wrote:
=20
It would definitely be optional, apologies if that wasn'= t made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.<= /div>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
= 
____________=
___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf=
.org/mailman/listinfo/oauth


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000002430580580dbdc50-- From nobody Fri Feb 1 13:32:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743E5130EC2 for ; Fri, 1 Feb 2019 13:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.841 X-Spam-Level: X-Spam-Status: No, score=-8.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWGcuHUGcS8J for ; Fri, 1 Feb 2019 13:32:13 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89C0130EBE for ; Fri, 1 Feb 2019 13:32:12 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x11LT7qQ089621; Fri, 1 Feb 2019 21:32:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=0O42hZsosClsMvMkUZdmdIHuaM3s7S4ah7a/eRdT1bw=; b=OMQefKiU8Sv9RsqHXt0iDzl8K29KIsrvB/94ZahJ5L0W44EByZR1joS2DR9QqpBm0j8v lpeAGDpKqtNpaP3FgjK9WlrxYk2OwHuJZkgg4zz8Q2kT2P5bLCm0govyhTwYywKvWBEl AKHLjbuLIaCh1A0KY/eMGY9/bVHVRRUHLx8We4fLgwRriA6BsVfW6BP8Gz/K/CxCKSO1 70HzcCe6xKNyCR4Z32lIV51IJ3NzOadPuPa+PlA6xSNIzYYlHH8PiueDN94g6ZO9FeG2 v5efgXT7D5mOPNm/AyTbuEDIwg+pGfqPeHWmUZLrE0eKrBbQFT2S1ry/MPOWJWhBZFBm /g== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2q8d2es5t0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Feb 2019 21:32:10 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x11LW8MH016399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Feb 2019 21:32:09 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x11LW700015828; Fri, 1 Feb 2019 21:32:07 GMT Received: from dhcp-10-159-243-81.vpn.oracle.com (/10.159.243.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Feb 2019 13:32:06 -0800 From: Phil Hunt Message-Id: <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_78464D9B-812D-4EC9-A272-F29DFCE70A1D" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Feb 2019 13:32:04 -0800 In-Reply-To: Cc: Filip Skokan , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9154 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902010152 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:32:18 -0000 --Apple-Mail=_78464D9B-812D-4EC9-A272-F29DFCE70A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That way works. But one of the modes on most tls terminators is client = cert optional. This works ok when you want dual mode to support bearer and mtls for = apps (e.g. mobile) because the client will decide to use MTLS. With = browsers, they only use it if forced. Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 1, 2019, at 1:14 PM, Brian Campbell = wrote: >=20 > The server has to ask during the handshake for a client to send a = cert.=20 >=20 > On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt > wrote: > If a client attempts to force mtls would typical tls terminators = accept it enough to redirect? >=20 > My worry is how optionality works in browsers. It seems like they have = to hit an mtls required endpoint before they reliably use a client cert.=20= >=20 > Phil >=20 > On Feb 1, 2019, at 12:56 PM, Brian Campbell = > wrote: >=20 >> It would be more a client having reached a non-MTLS endpoint and is = 307'd to an MTLS enabled endpoint.=20 >>=20 >> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt > wrote: >> I was a bit confused by how the 307 would work. >>=20 >> To confirm, Is the client having reached an MTLS optional endpoint = being redirected to an MTLS mandatory endpoint if the AT (or a cookie) = is detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the = browser invoke MTLS? >>=20 >> Phil >>=20 >> Oracle Corporation, Cloud Security and Identity Architect >> @independentid >> www.independentid.com = phil.hunt@o= racle.com >>=20 >>> On Feb 1, 2019, at 11:56 AM, Brian Campbell = > wrote: >>>=20 >>> I'm finally getting around to working on the document updates = (there's quite a few things that came out of AD review too). As far as = the issue in this thread goes though, I'm leaning towards adding = "mtls_endpoints" as a new metadata parameter. Maybe mention that a 307 = might happen but it'd be more of a considerations type text.=20 >>>=20 >>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell = > wrote: >>> I guess I should have also said or been more straightforward in = saying that I don't particularly want to try and discuss/define the use = of a 307 in the document.=20 >>>=20 >>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan > wrote: >>> I don't know that the use of 307 would need to be discussed in the = document itself.=20 >>>=20 >>> If the clients are supposed to be ready for this, yeah. For = instance, my client software by default doesn't follow redirects, in = order for it to be ready for mtls client authentication i'd have to know = 307 is a possibility and whitelist 307 as a valid code to be followed. >>>=20 >>> S pozdravem, >>> Filip Skokan >>>=20 >>>=20 >>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell = > wrote: >>> I don't know that the use of 307 would need to be discussed in the = document itself.=20 >>>=20 >>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan > wrote: >>> I'm in favour of both 307 and metadata.=20 >>> case 307 - I don't recall ever encountering an http client software = that wouldn't have an option for following redirects, same for a server = side frameworks not having the option to do a 307 response with a = location header. >>> case 307 - Relying purely on a new metadata doesn't help in the = scenario David put forth earlier about clients not being aware of using = mtls, a device policy of sorts. >>> case metadata - no second request if the client knows there's an = mtls endpoint it should use. >>> Maybe we should specify both as optional for an AS to deploy and a = client to be ready for? >>>=20 >>> S pozdravem, >>> Filip Skokan >>>=20 >>>=20 >>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge = > = wrote: >>> I'm in favour of the `mtls_endpoints` metadata parameter - although = it should be optional. >>> While a 307 redirect seems kind of elegant I worry, like you, that = not all clients would handle it appropriately. >>> There would probably need to be an error defined for clients who = attempt to use `tls_client_auth` at the regular endpoint. >>>=20 >>> Dave >>>=20 >>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell = > wrote: >>> Trying to summarize things somewhat here and focus in hopefully = towards some decision. There's basically an idea on the table to add an = AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a = JSON object which contains endpoints that a client doing MTLS would use = rather than the regular endpoints. A straw-man example might look like = this (with mtls_endpoints being that new parameter). >>>=20 >>> { =20 >>> "issuer":"https://server.example.com = ", >>> "authorization_endpoint":"https://server.example.com/authz = ", >>> "token_endpoint":"https://server.example.com/token = ", >>> "token_endpoint_auth_methods_supported":[ = "client_secret_basic","tls_client_auth", "none"], >>> "userinfo_endpoint":"https://server..example.com/userinfo = ", >>> "revocation_endpoint":"https://server.example.com/revo = ", >>> "jwks_uri":"https://server.example.com/jwks.json = ", >>> "mtls_endpoints":{ =20 >>> "token_endpoint":"https://mtls.example.com/token = ", >>> "userinfo_endpoint":"https://mtls = .example.com/userinfo = ", >>> "revocation_endpoint":"https://mtls = ..example.com/revo = " >>> } >>> } >>>=20 >>> The idea behind this is that "regular" clients (those not doing = MTLS) will use the regular endpoints. And only the host/port of the = endpoints listed in mtls_endpoints will be set up to request TLS client = certificates during handshake.. Thus any potential impact of the = CertificateRequest message being sent in the TLS handshake can be = avoided for all the other regular clients that are not going to do MTLS = - including and most importantly in-browser javascript clients where = there can be less than desirable UI presented to the end-user.=20 >>>=20 >>> The arguments in favor of that seem to be basically that it allows = for AS deployments to support MTLS while still allowing for a "not = broken" UX for end-users of clients (in-browser javascript clients) that = aren't doing MTLS. And that it's not much in terms of adding to the spec = and complexity of implementations.=20 >>>=20 >>> The arguments against it seem to be 1) the bad UX isn't really that = bad and/or will only happen to a subset of users 2) there are other = things that can be done, such as 307ing or renegotiation/post-handshake = client auth, to avoid the bad UX.=20 >>>=20 >>> Speaking for myself, I'm kinda torn on it.=20 >>>=20 >>> I will say that, in addition to the folks that have pointed out that = renegotiation just isn't possible in some cases, my experience trying to = do something like that in the past was not particularly successful or = encouraging. That could have been my fault, of course, but still seems a = relevant data point. I also have my doubts about the actual difficulty = of getting an AS to issue a 307 like response for requests based on the = calling client and the likelihood that some/all OAuth client software = would handle it appropriately.=20 >>> =20 >>>=20 >>> On Fri, Jan 11, 2019 at 12:32 PM David Waite = > = wrote: >>>=20 >>>=20 >>> > On Jan 11, 2019, at 3:32 AM, Neil Madden = > wrote: >>> >=20 >>> > On 9 Jan 2019, at 05:54, David Waite > wrote: >>> >>=20 >>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = > wrote: >>> >>>=20 >>> >> >>> >>=20 >>> >>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to = retract the proposal I'd previously made about the MTLS draft = introducing a new AS metadata parameter. It is admittedly interesting = (ironic?) that Neil sent a message in support of the proposal as I was = writing this. It did give me pause but ultimately didn't change my = opinion that it's not worth it to add this new AS metadata parameter. >>> >>=20 >>> >> Note that the AS could make a decision based on the token = endpoint request - such as a policy associated with the =E2=80=9Cclient_id= =E2=80=9D, or via a parameter in the ilk of =E2=80=9Cclient_assertion_type= =E2=80=9D indicating MTLS was desired by this public client = installation. The AS could then to TLS 1.2 renegotiation, 1.3 = post-handshake client authentication, or even use 307 temporary = redirects to another token endpoint to perform mutual authentication. >>> >=20 >>> > Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy? >>> >=20 >>> > A 307 redirect could work though as the server will know if the = client either uses mTLS for client authentication or has indicated that = it wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases. >>>=20 >>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t = know a way to have say a custom error code or WWW-Authenticate challenge = to trigger renegotiation on the reverse proxy - usually this is just a = static, location-based directive. >>>=20 >>> >=20 >>> >> Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication. >>> >=20 >>> > That=E2=80=99s an interesting observation. Can you elaborate on = the sorts of device policy you are talking about? I am aware of e.g. = mobile device management being used to push client certificates to iOS = devices, but I think these are only available in Safari. >>>=20 >>> The primary use is to set policy to rely on device level management = in controlled environments like enterprises when available. So an AS may = try to detect a client certificate as an indicator of a managed device, = use that to assume a device with certain device-level authentication, = single user usage, remote wipe, etc. characteristics, and decide that it = can reduce user authentication requirements and/or expose additional = scopes. >>>=20 >>> On more thought, this is typically done as part of the user agent = hitting the authorization endpoint, as a separate native application may = be interacting with the token endpoint, and in some operating systems = the application=E2=80=99s network connections do not utilize (and may = not have access to) the system certificate store. >>>=20 >>> In terms of user agents, I believe you can perform similar behavior = (managed systems using client certificates on user agents transparently) = on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) = typically inherits device level policy. Firefox on desktop I assume you = can do that in limited fashion as well. >>>=20 >>> -DW >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.... If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_78464D9B-812D-4EC9-A272-F29DFCE70A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
That way works. But one of the modes on most tls terminators = is client cert optional.

This works ok when you want dual mode to support bearer and = mtls for apps (e.g. mobile) because the client will decide to use MTLS. =  With browsers, they only use it if forced.

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb 1, 2019, at 1:14 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

The = server has to ask during the handshake for a client to send a cert. 

On Fri, Feb 1, 2019 at 2:12 = PM Phil Hunt <phil.hunt@oracle.com> wrote:
If a client attempts to force mtls would typical = tls terminators accept it enough to redirect?

My worry is how optionality works in = browsers. It seems like they have to hit an mtls required endpoint = before they reliably use a client cert. 

Phil

On Feb 1, 2019, at 12:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

It would be more a client having = reached a non-MTLS endpoint and is 307'd to an MTLS enabled = endpoint. 

On Fri, Feb 1, 2019 at 1:40 PM Phil = Hunt <phil.hunt@oracle.com> wrote:
I was a bit confused by how the 307 would work.

To confirm, Is the = client having reached an MTLS optional endpoint being redirected to an = MTLS mandatory endpoint if the AT (or a cookie) is detected to have a = =E2=80=9Ccnf=E2=80=9D claim in order to make the browser invoke = MTLS?

Phil

Oracle Corporation, Cloud Security and Identity = Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb = 1, 2019, at 11:56 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I'm finally getting around to working on the = document updates (there's quite a few things that came out of AD review = too). As far as the issue in this thread goes though, I'm leaning = towards adding "mtls_endpoints" as a new metadata parameter. Maybe = mention that a 307 might happen but it'd be more of a considerations = type text. 

On Wed, Jan 16, 2019 at 5:52 AM Brian = Campbell <bcampbell@pingidentity.com> = wrote:
I guess I should have = also said or been more straightforward in saying that I don't = particularly want to try and discuss/define the use of a 307 in the = document. 

On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan = <panva.ip@gmail.com> wrote:
I don't know that the use of 307 would need to be discussed = in the document itself. 

If the clients are supposed to be ready = for this, yeah. For instance, my client software by default doesn't = follow redirects, in order for it to be ready for mtls client = authentication i'd have to know 307 is a possibility and whitelist 307 = as a valid code to be followed.

S = pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell = <bcampbell@pingidentity.com> wrote:
I don't know that the use of 307 would need to be = discussed in the document itself. 

On = Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm in favour of both 307 and = metadata. 
  • case = 307 - I don't recall ever encountering an http client software that = wouldn't have an option for following redirects, same for a server side = frameworks not having the option to do a 307 response with a location = header.
  • case 307 - Relying purely on a = new metadata doesn't help in the scenario David put forth earlier about = clients not being aware of using mtls, a device policy of sorts.
  • case metadata - no second request if the = client knows there's an mtls endpoint it should use.
Maybe we should specify both as optional for an AS to deploy = and a client to be ready for?

S pozdravem,
Filip Skokan


On = Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata = parameter - although it should be optional.
While a 307 redirect seems kind of elegant I worry, like = you,  that not all clients would handle it = appropriately.
There would probably need = to be an error defined for clients who attempt to use `tls_client_auth` = at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at = 22:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to summarize things somewhat here and = focus in hopefully towards some decision. There's basically an idea on = the table to add an AS metadata parameter to the draft-ietf-oauth-mtls = doc that would be a JSON object which contains endpoints that a client = doing MTLS would use rather than the regular endpoints. A straw-man = example might look like this (with mtls_endpoints being that new = parameter).

{  
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_= supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server..example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{  
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://= mtls.example.com/userinfo",
    "revocation_endpoint":"https:= //mtls..example.com/revo"
  }
}

The = idea behind this is that "regular" clients (those not doing MTLS) will = use the regular endpoints. And only the host/port of the endpoints = listed in mtls_endpoints will be set up to request TLS client = certificates during handshake.. Thus any potential impact of the = CertificateRequest message being sent in the TLS handshake can be = avoided for all the other regular clients that are not going to do MTLS = - including and most importantly in-browser javascript clients where = there can be less than desirable UI presented to the end-user. 

The arguments in favor = of that seem to be basically that it allows for AS deployments to = support MTLS while still allowing for a "not broken" UX for end-users of = clients (in-browser javascript clients) that aren't doing MTLS. And that = it's not much in terms of adding to the spec and complexity of = implementations. 

The = arguments against it seem to be 1) the bad UX isn't really that bad = and/or will only happen to a subset of users 2) there are other things = that can be done, such as 307ing or renegotiation/post-handshake client = auth, to avoid the bad UX. 

Speaking for myself, I'm = kinda torn on it. 

I = will say that, in addition to the folks that have pointed out that = renegotiation just isn't possible in some cases, my experience trying to = do something like that in the past was not particularly successful or = encouraging. That could have been my fault, of course, but still seems a = relevant data point. I also have my doubts about the actual difficulty = of getting an AS to issue a 307 like response for requests based on the = calling client and the likelihood that some/all OAuth client software = would handle it appropriately. 
 

On = Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden = <neil.madden@forgerock.com> wrote:
> 
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> wrote:
>> 
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
>>> 
>> = <snip>
>> 
>>> = All of that is meant as an explanation of sorts to say that I think that = things are actually okay enough as is and that I'd like to retract the = proposal I'd previously made about the MTLS draft introducing a new AS = metadata parameter. It is admittedly interesting (ironic?) that Neil = sent a message in support of the proposal as I was writing this. It did = give me pause but ultimately didn't change my opinion that it's not = worth it to add this new AS metadata parameter.
>> 
>> Note that the AS could make a decision based on the = token endpoint request - such as a policy associated with the = =E2=80=9Cclient_id=E2=80=9D, or via a parameter in the ilk of = =E2=80=9Cclient_assertion_type=E2=80=9D indicating MTLS was desired by = this public client installation. The AS could then to TLS 1.2 = renegotiation, 1.3 post-handshake client authentication, or even use 307 = temporary redirects to another token endpoint to perform mutual = authentication.
> 
> = Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy?
> 
> A 307 = redirect could work though as the server will know if the client either = uses mTLS for client authentication or has indicated that it wants = certificate-bound access tokens, so it can redirect to a mTLS-specific = endpoint in those cases.

Agreed. There are = trade-offs for both. As you say, I don=E2=80=99t know a way to have say = a custom error code or WWW-Authenticate challenge to trigger = renegotiation on the reverse proxy - usually this is just a static, = location-based directive.

> 
>> = Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2=80=9D= -like indicator imply that the client has multiple forms of = authentication and is choosing to use MTLS. The URL in particular I=E2=80=99= m reluctant to add support for, because I see it more likely a client = would use MTLS without knowing it (via a device-level policy being = applied to a public web or native app) than the reverse, where a single = client (represented by a single client_id) is dynamically picking = between forms of authentication.
> 
> = That=E2=80=99s an interesting observation. Can you elaborate on the = sorts of device policy you are talking about? I am aware of e.g. mobile = device management being used to push client certificates to iOS devices, = but I think these are only available in Safari.

The primary use is to set policy to rely on device level = management in controlled environments like enterprises when available. = So an AS may try to detect a client certificate as an indicator of a = managed device, use that to assume a device with certain device-level = authentication, single user usage, remote wipe, etc. characteristics, = and decide that it can reduce user authentication requirements and/or = expose additional scopes.

On more thought, = this is typically done as part of the user agent hitting the = authorization endpoint, as a separate native application may be = interacting with the token endpoint, and in some operating systems the = application=E2=80=99s network connections do not utilize (and may not = have access to) the system certificate store.

In terms of user agents, I believe you can perform similar = behavior (managed systems using client certificates on user agents = transparently) on macOS, Windows, Chrome, and Android devices, Chrome = (outside iOS) typically inherits device level policy. Firefox on desktop = I assume you can do that in limited fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited....  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
<= /div>
CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
CONFIDENTIALITY NOTICE: = This email may contain confidential and privileged material for the sole = use of the intended recipient(s). Any review, use, distribution or = disclosure by others is strictly prohibited.  If you have received = this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your = computer. Thank you.

= --Apple-Mail=_78464D9B-812D-4EC9-A272-F29DFCE70A1D-- From nobody Fri Feb 1 13:43:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78409130EBE for ; Fri, 1 Feb 2019 13:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFezrUiQHc4F for ; Fri, 1 Feb 2019 13:43:35 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F8B130EC2 for ; Fri, 1 Feb 2019 13:43:34 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id k7so6957224iob.6 for ; Fri, 01 Feb 2019 13:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j8qqDleC4G9O94XHdNN7liw4qu0LW/HOm+JuH0PcsOM=; b=PsWI4xa6BkTkmWbCtAlTcS5zba/4Ug2KQg1UMFg7PDbp1HqjrZP4fgxWxmD4E16eUB lXNSLEgxMsrME4ZgLfZHD7QCqBece/PiT/LGpz7bo0Ixx1mOYhHPAE5Xn7ThOIjkrcZI sVpVe3oQbQA1B8BOHpCV7WB8JD9BDYOrKoLew= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j8qqDleC4G9O94XHdNN7liw4qu0LW/HOm+JuH0PcsOM=; b=KRGVcoyN3ewImzoU1CNCMXHrBL0EKrP41m6i2u8g5fTg4IEgaegOkXGZInTsp2BIVX Zjl5UiM+zGWGn0aF1qDl32RVqhRcWMl6/xicqw9jIA9Alr+VlElEd2JUJKk0lrckwNdv B5AjamSkO1z8Lfz+kOe+UlyQVOJeflRajAuc+YQQhwH8NGIHtho5+vwL43CrpZ09dHAo yOkxUeGmWlrOhKuDdfZ96/cnd1P8OjPg8q2TrQdGkaLWHXYrHKK/yIdcy0oZlkWR+Xzc HmkIW1LZRoRUz+yisQou2xVluDzMxUA/3L4aMZdiaBmLD5YbGnQMtEsaUb1gCF3LV9zo kUXA== X-Gm-Message-State: AHQUAubGswIsdKtpkmtmTLOvsNEnlvaYciKMVw5pqjRLcOlaRPQGYCvB oRuBuGieI8y+5bxjfpVIGt+si5U3ogNmNCP2N+dzUYTb7mM3/FqVNlP/dshSVJ42WHmNn8G5Kq2 RyrmuKQqvUN4BjQ== X-Google-Smtp-Source: AHgI3IaK6hAzKADz2QKZdCqVbJF0we33PjbEi9pjN1PxFoJqo+c1ldMTCBQmLpVn1UiodYKCiVu8zMHhY0gGLRkTd+c= X-Received: by 2002:a5d:8597:: with SMTP id f23mr127540ioj.238.1549057413671; Fri, 01 Feb 2019 13:43:33 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com> In-Reply-To: <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com> From: Brian Campbell Date: Fri, 1 Feb 2019 14:43:07 -0700 Message-ID: To: Phil Hunt Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="000000000000e116160580dc087b" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:43:41 -0000 --000000000000e116160580dc087b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I guess I'm not clear what you are driving at. On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt wrote: > That way works. But one of the modes on most tls terminators is client > cert optional. > > This works ok when you want dual mode to support bearer and mtls for apps > (e.g. mobile) because the client will decide to use MTLS. With browsers, > they only use it if forced. > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Feb 1, 2019, at 1:14 PM, Brian Campbell > wrote: > > The server has to ask during the handshake for a client to send a cert. > > On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt wrote: > >> If a client attempts to force mtls would typical tls terminators accept >> it enough to redirect? >> >> My worry is how optionality works in browsers. It seems like they have t= o >> hit an mtls required endpoint before they reliably use a client cert. >> >> Phil >> >> On Feb 1, 2019, at 12:56 PM, Brian Campbell >> wrote: >> >> It would be more a client having reached a non-MTLS endpoint and is 307'= d >> to an MTLS enabled endpoint. >> >> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote: >> >>> I was a bit confused by how the 307 would work. >>> >>> To confirm, Is the client having reached an MTLS optional endpoint bein= g >>> redirected to an MTLS mandatory endpoint if the AT (or a cookie) is >>> detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the bro= wser invoke MTLS? >>> >>> Phil >>> >>> Oracle Corporation, Cloud Security and Identity Architect >>> @independentid >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> On Feb 1, 2019, at 11:56 AM, Brian Campbell < >>> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: >>> >>> I'm finally getting around to working on the document updates (there's >>> quite a few things that came out of AD review too). As far as the issue= in >>> this thread goes though, I'm leaning towards adding "mtls_endpoints" as= a >>> new metadata parameter. Maybe mention that a 307 might happen but it'd = be >>> more of a considerations type text. >>> >>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> I guess I should have also said or been more straightforward in saying >>>> that I don't particularly want to try and discuss/define the use of a = 307 >>>> in the document. >>>> >>>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan >>>> wrote: >>>> >>>>> I don't know that the use of 307 would need to be discussed in the >>>>>> document itself. >>>>> >>>>> >>>>> If the clients are supposed to be ready for this, yeah. For instance, >>>>> my client software by default doesn't follow redirects, in order for = it to >>>>> be ready for mtls client authentication i'd have to know 307 is a >>>>> possibility and whitelist 307 as a valid code to be followed. >>>>> >>>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> >>>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> I don't know that the use of 307 would need to be discussed in the >>>>>> document itself. >>>>>> >>>>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan >>>>>> wrote: >>>>>> >>>>>>> I'm in favour of both 307 and metadata. >>>>>>> >>>>>>> - case 307 - I don't recall ever encountering an http client >>>>>>> software that wouldn't have an option for following redirects, s= ame for a >>>>>>> server side frameworks not having the option to do a 307 respons= e with a >>>>>>> location header. >>>>>>> - case 307 - Relying purely on a new metadata doesn't help in >>>>>>> the scenario David put forth earlier about clients not being awa= re of using >>>>>>> mtls, a device policy of sorts. >>>>>>> - case metadata - no second request if the client knows there's >>>>>>> an mtls endpoint it should use. >>>>>>> >>>>>>> Maybe we should specify both as optional for an AS to deploy and a >>>>>>> client to be ready for? >>>>>>> >>>>>>> S pozdravem, >>>>>>> *Filip Skokan* >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge < >>>>>>> dave.tonge@momentumft.co.uk> wrote: >>>>>>> >>>>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - althoug= h >>>>>>>> it should be optional. >>>>>>>> While a 307 redirect seems kind of elegant I worry, like you, tha= t >>>>>>>> not all clients would handle it appropriately. >>>>>>>> There would probably need to be an error defined for clients who >>>>>>>> attempt to use `tls_client_auth` at the regular endpoint. >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> Trying to summarize things somewhat here and focus in hopefully >>>>>>>>> towards some decision. There's basically an idea on the table to = add an AS >>>>>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be= a JSON >>>>>>>>> object which contains endpoints that a client doing MTLS would us= e rather >>>>>>>>> than the regular endpoints. A straw-man example might look like t= his (with >>>>>>>>> mtls_endpoints being that new parameter). >>>>>>>>> >>>>>>>>> { >>>>>>>>> "issuer":"https://server.example.com", >>>>>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>>>>> "token_endpoint":"https://server.example.com/token", >>>>>>>>> "token_endpoint_auth_methods_supported":[ >>>>>>>>> "client_secret_basic","tls_client_auth", "none"], >>>>>>>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>>>>>>> ", >>>>>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * "mtls_endpoints":{ "token_endpoint":"https://mtls.example= .com/token >>>>>>>>> ", "userinfo_endpoint":"https:= //mtls >>>>>>>>> .example.com/userinfo >>>>>>>>> ", "revocation_endpoint":"https:/= /mtls >>>>>>>>> ..example.com/revo >>>>>>>>> " }* >>>>>>>>> } >>>>>>>>> >>>>>>>>> The idea behind this is that "regular" clients (those not doing >>>>>>>>> MTLS) will use the regular endpoints. And only the host/port of t= he >>>>>>>>> endpoints listed in mtls_endpoints will be set up to request TLS = client >>>>>>>>> certificates during handshake.. Thus any potential impact of the >>>>>>>>> CertificateRequest message being sent in the TLS handshake can be= avoided >>>>>>>>> for all the other regular clients that are not going to do MTLS -= including >>>>>>>>> and most importantly in-browser javascript clients where there ca= n be less >>>>>>>>> than desirable UI presented to the end-user. >>>>>>>>> >>>>>>>>> The arguments in favor of that seem to be basically that it allow= s >>>>>>>>> for AS deployments to support MTLS while still allowing for a "no= t broken" >>>>>>>>> UX for end-users of clients (in-browser javascript clients) that = aren't >>>>>>>>> doing MTLS. And that it's not much in terms of adding to the spec= and >>>>>>>>> complexity of implementations. >>>>>>>>> >>>>>>>>> The arguments against it seem to be 1) the bad UX isn't really >>>>>>>>> that bad and/or will only happen to a subset of users 2) there ar= e other >>>>>>>>> things that can be done, such as 307ing or renegotiation/post-han= dshake >>>>>>>>> client auth, to avoid the bad UX. >>>>>>>>> >>>>>>>>> Speaking for myself, I'm kinda torn on it. >>>>>>>>> >>>>>>>>> I will say that, in addition to the folks that have pointed out >>>>>>>>> that renegotiation just isn't possible in some cases, my experien= ce trying >>>>>>>>> to do something like that in the past was not particularly succes= sful or >>>>>>>>> encouraging. That could have been my fault, of course, but still = seems a >>>>>>>>> relevant data point. I also have my doubts about the actual diffi= culty of >>>>>>>>> getting an AS to issue a 307 like response for requests based on = the >>>>>>>>> calling client and the likelihood that some/all OAuth client soft= ware would >>>>>>>>> handle it appropriately. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden < >>>>>>>>>> neil.madden@forgerock.com> wrote: >>>>>>>>>> > >>>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite < >>>>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>>>> >> >>>>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>>>>> >>> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> All of that is meant as an explanation of sorts to say that = I >>>>>>>>>> think that things are actually okay enough as is and that I'd li= ke to >>>>>>>>>> retract the proposal I'd previously made about the MTLS draft in= troducing a >>>>>>>>>> new AS metadata parameter. It is admittedly interesting (ironic?= ) that Neil >>>>>>>>>> sent a message in support of the proposal as I was writing this.= It did >>>>>>>>>> give me pause but ultimately didn't change my opinion that it's = not worth >>>>>>>>>> it to add this new AS metadata parameter. >>>>>>>>>> >> >>>>>>>>>> >> Note that the AS could make a decision based on the token >>>>>>>>>> endpoint request - such as a policy associated with the =E2=80= =9Cclient_id=E2=80=9D, or via >>>>>>>>>> a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80= =9D indicating MTLS was >>>>>>>>>> desired by this public client installation. The AS could then to= TLS 1.2 >>>>>>>>>> renegotiation, 1.3 post-handshake client authentication, or even= use 307 >>>>>>>>>> temporary redirects to another token endpoint to perform mutual >>>>>>>>>> authentication. >>>>>>>>>> > >>>>>>>>>> > Renegotiation is an intriguing option, but it has some >>>>>>>>>> practical difficulties. Our AS product runs in a Java servlet co= ntainer, >>>>>>>>>> where it is pretty much impossible to dynamically trigger renego= tiation >>>>>>>>>> without accessing private internal APIs of the container. I also= don=E2=80=99t know >>>>>>>>>> how you could coordinate this in the common scenario where TLS i= s >>>>>>>>>> terminated at a load balancer/reverse proxy? >>>>>>>>>> > >>>>>>>>>> > A 307 redirect could work though as the server will know if th= e >>>>>>>>>> client either uses mTLS for client authentication or has indicat= ed that it >>>>>>>>>> wants certificate-bound access tokens, so it can redirect to a >>>>>>>>>> mTLS-specific endpoint in those cases. >>>>>>>>>> >>>>>>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80= =99t know a >>>>>>>>>> way to have say a custom error code or WWW-Authenticate challeng= e to >>>>>>>>>> trigger renegotiation on the reverse proxy - usually this is jus= t a static, >>>>>>>>>> location-based directive. >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> >> Both the separate metadata url and a >>>>>>>>>> =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply tha= t the client has multiple >>>>>>>>>> forms of authentication and is choosing to use MTLS. The URL in = particular >>>>>>>>>> I=E2=80=99m reluctant to add support for, because I see it more = likely a client >>>>>>>>>> would use MTLS without knowing it (via a device-level policy bei= ng applied >>>>>>>>>> to a public web or native app) than the reverse, where a single = client >>>>>>>>>> (represented by a single client_id) is dynamically picking betwe= en forms of >>>>>>>>>> authentication. >>>>>>>>>> > >>>>>>>>>> > That=E2=80=99s an interesting observation. Can you elaborate o= n the >>>>>>>>>> sorts of device policy you are talking about? I am aware of e.g.= mobile >>>>>>>>>> device management being used to push client certificates to iOS = devices, >>>>>>>>>> but I think these are only available in Safari. >>>>>>>>>> >>>>>>>>>> The primary use is to set policy to rely on device level >>>>>>>>>> management in controlled environments like enterprises when avai= lable. So >>>>>>>>>> an AS may try to detect a client certificate as an indicator of = a managed >>>>>>>>>> device, use that to assume a device with certain device-level >>>>>>>>>> authentication, single user usage, remote wipe, etc. characteris= tics, and >>>>>>>>>> decide that it can reduce user authentication requirements and/o= r expose >>>>>>>>>> additional scopes. >>>>>>>>>> >>>>>>>>>> On more thought, this is typically done as part of the user agen= t >>>>>>>>>> hitting the authorization endpoint, as a separate native applica= tion may be >>>>>>>>>> interacting with the token endpoint, and in some operating syste= ms the >>>>>>>>>> application=E2=80=99s network connections do not utilize (and ma= y not have access >>>>>>>>>> to) the system certificate store. >>>>>>>>>> >>>>>>>>>> In terms of user agents, I believe you can perform similar >>>>>>>>>> behavior (managed systems using client certificates on user agen= ts >>>>>>>>>> transparently) on macOS, Windows, Chrome, and Android devices, C= hrome >>>>>>>>>> (outside iOS) typically inherits device level policy. Firefox on= desktop I >>>>>>>>>> assume you can do that in limited fashion as well. >>>>>>>>>> >>>>>>>>>> -DW >>>>>>>>> >>>>>>>>> >>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>>>> privileged material for the sole use of the intended recipient(s)= . Any >>>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>>> prohibited.... If you have received this communication in error,= please >>>>>>>>> notify the sender immediately by e-mail and delete the message an= d any file >>>>>>>>> attachments from your computer. Thank you.* >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). A= ny >>>>>> review, use, distribution or disclosure by others is strictly prohib= ited. >>>>>> If you have received this communication in error, please notify the = sender >>>>>> immediately by e-mail and delete the message and any file attachment= s from >>>>>> your computer. Thank you.* >>>>> >>>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e116160580dc087b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess I'm not clear what you are driving at.

On = Fri, Feb 1, 2019 at 2:32 PM Phil Hunt <phil.hunt@oracle.com> wrote:
T= hat way works. But one of the modes on most tls terminators is client cert = optional.

This works ok when you want dual mode to= support bearer and mtls for apps (e.g. mobile) because the client will dec= ide to use MTLS.=C2=A0 With browsers, they only use it if forced.

Phil

Oracle Corporat= ion, Cloud Security and Identity Architect
@independentid
www.independe= ntid.com
phil.hunt@oracle.com
<= /div>

On Feb 1, 2019, at 1:14 PM, Brian C= ampbell <bcampbell@pingidentity.com> wrote:

The server has to ask during the handshake for a client to send a cert.= =C2=A0

On Fri, Feb 1, 2019 at 2:12 PM Phil= Hunt <phil.hu= nt@oracle.com> wrote:
If a client attempts to force mtls would typ= ical tls terminators accept it enough to redirect?

My wo= rry is how optionality works in browsers. It seems like they have to hit an= mtls required endpoint before they reliably use a client cert.=C2=A0
Phil

On Feb 1, 2019, at = 12:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

It would be more = a client having reached a non-MTLS endpoint and is 307'd to an MTLS ena= bled endpoint.=C2=A0

On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <phil.hunt@oracle.com= > wrote:
I was a bit confused by how the 307 would work.

To conf= irm, Is the client having reached an MTLS optional endpoint being redirecte= d to an MTLS mandatory endpoint if the AT (or a cookie) is detected to have= a =E2=80=9Ccnf=E2=80=9D claim in order to make the browser invoke MTLS?

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
phil.hunt@oracle.co= m

On Feb 1, 2019,= at 11:56 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dma= rc.ietf.org> wrote:

I'm finally getting around = to working on the document updates (there's quite a few things that cam= e out of AD review too). As far as the issue in this thread goes though, I&= #39;m leaning towards adding "mtls_endpoints" as a new metadata p= arameter. Maybe mention that a 307 might happen but it'd be more of a c= onsiderations type text.=C2=A0

=
On Wed, Jan 16, 2019 at 5:52 AM Brian= Campbell <bcampbell@pingidentity.com> wrote:
I guess I should have also sa= id or been more straightforward in saying that I don't particularly wan= t to try and discuss/define the use of a 307 in the document.=C2=A0
=
On Tue, Jan 15, 2019 at 6:5= 9 AM Filip Skokan <panva.ip@gmail.com> wrote:
I don't know that the use of 307 would need to be discussed in the d= ocument itself.=C2=A0

If the clients= are supposed to be ready for this, yeah. For instance, my client software = by default doesn't follow redirects, in order for it to be ready for mt= ls client authentication i'd have to know 307 is a possibility and whit= elist 307 as a valid code to be followed.

S pozdravem,
Filip Skokan=


On Tu= e, Jan 15, 2019 at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote= :
I don't know that the use of 307 would need to be discussed in the d= ocument itself.=C2=A0

On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
=
I&#= 39;m in favour of both 307 and metadata.=C2=A0
  • case 307 -= I don't recall ever encountering an http client software that wouldn&#= 39;t have an option for following redirects, same for a server side framewo= rks not having the option to do a 307 response with a location header.
    <= /li>
  • case 307 - Relying purely on a new metadata doesn't help in the= scenario David put forth earlier about clients not being aware of using mt= ls, a device policy of sorts.
  • case metadata - no second request= if the client knows there's an mtls endpoint it should use.
<= /div>
Maybe we should specify both as optional for an AS to deploy and = a client to be ready for?

S pozdravem,=
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <dave.tonge@moment= umft.co.uk> wrote:
I'm in favour o= f the `mtls_endpoints` metadata parameter - although it should be optional.=
While a 307 redirect seems kind of elegant I worry, like you,=C2=A0 = that not all clients would handle it appropriately.
There would prob= ably need to be an error defined for clients who attempt to use `tls_client= _auth` at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at 2= 2:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
Trying to summari= ze things somewhat here and focus in hopefully towards some decision. There= 's basically an idea on the table to add an AS metadata parameter to th= e draft-ietf-oauth-mtls doc that would be a JSON object which contains endp= oints that a client doing MTLS would use rather than the regular endpoints.= A straw-man example might look like this (with mtls_endpoints being that n= ew parameter).

{=C2=A0=C2=A0
=C2=A0=C2=A0"issuer":&q= uot;https://serve= r.example.com",
=C2=A0=C2=A0"authorization_endpoint":&q= uot;https://= server.example.com/authz",
=C2=A0=C2=A0"token_endpoint"= :"https= ://server.example.com/token",
=C2=A0=C2=A0"token_endpoint_au= th_methods_supported":[=C2=A0 "client_secret_basic","tl= s_client_auth", "none"],
=C2=A0=C2=A0"userinfo_endpoin= t":"https://server..example.com/userinfo",
=C2=A0=C2=A0"r= evocation_endpoint":"https://server.example.com/revo",
=C2=A0=C2=A0&= quot;jwks_uri":"https://server.example.com/jwks.json",
=C2= =A0=C2=A0= "mtls_endpoints":{=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0&quo= t;token_endpoint":"https://mtls.example.com/token",
=C2=A0=C2=A0=C2= =A0=C2=A0= "userinfo_endpoint":"https://mtls.example.com/userinfo",
= =C2=A0=C2=A0=C2=A0=C2=A0"revocation_endpoint":"https://mtls..example.com/revo&qu= ot;
=C2=A0=C2=A0}
}

The idea behind th= is is that "regular" clients (those not doing MTLS) will use the = regular endpoints. And only the host/port of the endpoints listed in mtls_e= ndpoints will be set up to request TLS client certificates during handshake= .. Thus any potential impact of the CertificateRequest message being sent i= n the TLS handshake can be avoided for all the other regular clients that a= re not going to do MTLS - including and most importantly in-browser javascr= ipt clients where there can be less than desirable UI presented to the end-= user.=C2= =A0

The arguments in favor of that seem= to be basically that it allows for AS deployments to support MTLS while st= ill allowing for a "not broken" UX for end-users of clients (in-b= rowser javascript clients) that aren't doing MTLS. And that it's no= t much in terms of adding to the spec and complexity of implementations.=C2=A0

The arguments against it seem to be 1) the b= ad UX isn't really that bad and/or will only happen to a subset of user= s 2) there are other things that can be done, such as 307ing or renegotiati= on/post-handshake client auth, to avoid the bad UX.=C2=A0

<= /div>
Speaking for myself, I'm kinda torn on it.=C2=A0
=
I will say that, in addition to the folks that have pointed = out that renegotiation just isn't possible in some cases, my experience= trying to do something like that in the past was not particularly successf= ul or encouraging. That could have been my fault, of course, but still seem= s a relevant data point. I also have my doubts about the actual difficulty = of getting an AS to issue a 307 like response for requests based on the cal= ling client and the likelihood that some/all OAuth client software would ha= ndle it appropriately.=C2=A0
=C2=A0
=

On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com= > wrote:

=
> On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com>= wrote:
>=C2=A0
> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-= solutions.com> wrote:
>>=C2=A0
>>> On Dec 28, 201= 8, at 3:55 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= > wrote:
>>>=C2=A0
>> <snip>
>>=C2=A0
>>> All of that is meant as an explanation of sorts to say th= at I think that things are actually okay enough as is and that I'd like= to retract the proposal I'd previously made about the MTLS draft intro= ducing a new AS metadata parameter. It is admittedly interesting (ironic?) = that Neil sent a message in support of the proposal as I was writing this. = It did give me pause but ultimately didn't change my opinion that it= 9;s not worth it to add this new AS metadata parameter.
>>=C2=A0
= >> Note that the AS could make a decision based on the token endpoint= request - such as a policy associated with the =E2=80=9Cclient_id=E2=80=9D= , or via a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS coul= d then to TLS 1.2 renegotiation, 1.3 post-handshake client authentication, = or even use 307 temporary redirects to another token endpoint to perform mu= tual authentication.
>=C2=A0
> Renegotiation is an intriguing opt= ion, but it has some practical difficulties. Our AS product runs in a Java = servlet container, where it is pretty much impossible to dynamically trigge= r renegotiation without accessing private internal APIs of the container. I= also don=E2=80=99t know how you could coordinate this in the common scenar= io where TLS is terminated at a load balancer/reverse proxy?
>=C2=A0> A 307 redirect could work though as the server will know if the clien= t either uses mTLS for client authentication or has indicated that it wants= certificate-bound access tokens, so it can redirect to a mTLS-specific end= point in those cases.

Agreed. There are trade-offs for both. As you = say, I don=E2=80=99t know a way to have say a custom error code or WWW-Auth= enticate challenge to trigger renegotiation on the reverse proxy - usually = this is just a static, location-based directive.

>=C2=A0
>>= ; Both the separate metadata url and a =E2=80=9Cclient_assertion_type=E2=80= =9D-like indicator imply that the client has multiple forms of authenticati= on and is choosing to use MTLS. The URL in particular I=E2=80=99m reluctant= to add support for, because I see it more likely a client would use MTLS w= ithout knowing it (via a device-level policy being applied to a public web = or native app) than the reverse, where a single client (represented by a si= ngle client_id) is dynamically picking between forms of authentication.
= >=C2= =A0
> That=E2=80=99s an interesting observation. Can you elabo= rate on the sorts of device policy you are talking about? I am aware of e.g= . mobile device management being used to push client certificates to iOS de= vices, but I think these are only available in Safari.

The primary u= se is to set policy to rely on device level management in controlled enviro= nments like enterprises when available. So an AS may try to detect a client= certificate as an indicator of a managed device, use that to assume a devi= ce with certain device-level authentication, single user usage, remote wipe= , etc. characteristics, and decide that it can reduce user authentication r= equirements and/or expose additional scopes.

On more thought, this i= s typically done as part of the user agent hitting the authorization endpoi= nt, as a separate native application may be interacting with the token endp= oint, and in some operating systems the application=E2=80=99s network conne= ctions do not utilize (and may not have access to) the system certificate s= tore.

In terms of user agents, I believe you can perform similar beh= avior (managed systems using client certificates on user agents transparent= ly) on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) ty= pically inherits device level policy. Firefox on desktop I assume you can d= o that in limited fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited....=C2=A0 If = you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from you= r computer. Thank you.___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th



___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth
<= /div>
CONFIDENTIALITY NOTICE: This email may contain confiden= tial and privileged material for the sole use of the intended recipient(s).= Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.

CONFIDENTIALITY NOTICE: T= his email may contain confidential and privileged material for the sole use= of the intended recipient(s). Any review, use, distribution or disclosure = by others is strictly prohibited..=C2=A0 If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf= .org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may c= ontain confidential and privileged material for the sole use of the intende= d recipient(s). Any review, use, distribution or disclosure by others is st= rictly prohibited.=C2=A0 If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message and a= ny file attachments from your computer. Thank you.
<= /blockquote>

CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e116160580dc087b-- From nobody Fri Feb 1 14:18:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E592F130EBE for ; Fri, 1 Feb 2019 14:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.053 X-Spam-Level: X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPl2Jksg__ox for ; Fri, 1 Feb 2019 14:18:00 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21B3130EC2 for ; Fri, 1 Feb 2019 14:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1549059480; x=1580595480; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=knYE4afg+p+4y5mqAYgLMHcNxsNd4M77ZtWcXfT6p7Q=; b=nDdrd+gDaTHzDFuXiCzOqMMQ7GJlCFw1VcPsiZvzajcqViBJe5epomWW /hrpm8R+RRK0cSx4wktairXiEcfKwnw9dRz0JFtVDfIbdN7ZPdCOdhCaB r1XuRzE/0I7T4+trfJClv3qnc1utIwzUlOFF5FvvrHPkdY6IAAsDxpAqC I=; X-IronPort-AV: E=Sophos;i="5.56,549,1539648000"; d="scan'208,217";a="757065477" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2019 22:17:58 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id x11MHtr6109937 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Feb 2019 22:17:57 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 1 Feb 2019 22:17:56 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 1 Feb 2019 22:17:56 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Fri, 1 Feb 2019 22:17:56 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell , "George Fletcher" CC: oauth Thread-Topic: [OAUTH-WG] MTLS and in-browser clients using the token endpoint Thread-Index: AQHUlkcL/yDmEBVqa0adnr6fSi/LlqWUfw6AgABVLoCAEb7YgIADcjUAgACW8wCABNeIgIAAwlgAgABPYwCAGzgkgIAAAIsA//+HHIA= Date: Fri, 1 Feb 2019 22:17:56 +0000 Message-ID: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.164] Content-Type: multipart/alternative; boundary="_000_F5841CEABA744F17977AA78922CDC68Camazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 22:18:03 -0000 --_000_F5841CEABA744F17977AA78922CDC68Camazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBzdHJpa2VzIG1lIGFzIGEgdmVyeSBwcm9taW5lbnQgYW5kIGNvbmZ1c2luZyBjaGFuZ2Ug dG8gc3VwcG9ydCB3aGF0IHNlZW1zIHRvIGJlIGEgbWlub3JpdHkgdXNlIGNhc2UuIEnigJltIGdl dHRpbmcgYSBoZWFkYWNoZSBqdXN0IHRoaW5raW5nIGFib3V0IHRoZSB0ZXh0IG5lZWRlZCB0byBj bGFyaWZ5IHdoZW4gdGhlIEFTIHNob3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2AgYW5kIHdo ZW4gdGhlIGNsaWVudCBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9lbmRwb2lu dC5gIFdoeSBpcyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3ZlciB0aGUg Y2FzZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1tVExTPw0K DQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTog T0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IEZy aWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBNDQpUbzogR2VvcmdlIEZsZXRjaGVyIDxn ZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogb2F1dGggPG9hdXRoQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRz IHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpZZXMsIHRoYXQgd291bGQgd29yay4NCg0KT24g RnJpLCBGZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBh b2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3 cm90ZToNCldoYXQgaWYgdGhlIEFTIHdhbnRzIHRvIE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rp b25zLiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRoZSBvcHRpb25hbCAibXRsc19lbmRwb2ludHMiIGFu ZCBqdXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRhIHZhbHVlcz8NCk9uIDEvMTUvMTkgODo0OCBB TSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQpJdCB3b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFs LCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcg dG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVu dHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbiBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0K DQpPbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VA bW9tZW50dW1mdC5jby51azxtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3Jv dGU6DQpJJ20gaW4gZmF2b3VyIG9mIHRoZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFt ZXRlciAtIGFsdGhvdWdoIGl0IHNob3VsZCBiZSBvcHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZ IE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVn ZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMp LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5 IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBm cm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuDQo= --_000_F5841CEABA744F17977AA78922CDC68Camazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7 DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzdHJpa2VzIG1lIGFzIGEg dmVyeSBwcm9taW5lbnQgYW5kIGNvbmZ1c2luZyBjaGFuZ2UgdG8gc3VwcG9ydCB3aGF0IHNlZW1z IHRvIGJlIGEgbWlub3JpdHkgdXNlIGNhc2UuIEnigJltIGdldHRpbmcgYSBoZWFkYWNoZSBqdXN0 IHRoaW5raW5nIGFib3V0IHRoZSB0ZXh0IG5lZWRlZCB0byBjbGFyaWZ5IHdoZW4gdGhlIEFTIHNo b3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2AgYW5kIHdoZW4gdGhlIGNsaWVudA0KIHNob3Vs ZCB1c2UgdGhhdCB2ZXJzdXMgdXNpbmcgYHRva2VuX2VuZHBvaW50LmAgV2h5IGlzIHRoZSAzMDcg c3RhdHVzIGNvZGUgaW5zdWZmaWNpZW50IHRvIGNvdmVyIHRoZSBjYXNlIHdoZXJlIGEgc2luZ2xl IEFTIHN1cHBvcnRzIGJvdGggbVRMUyBhbmQgbm9uLW1UTFM/PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTQwcGluZ2lkZW50 aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBGZWJy dWFyeSAxLCAyMDE5IGF0IDE6MzEgUE08YnI+DQo8Yj5UbzogPC9iPkdlb3JnZSBGbGV0Y2hlciAm bHQ7Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+ b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09B VVRILVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBv aW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ZZXMsIHRoYXQgd291bGQgd29yay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBH ZW9yZ2UgRmxldGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1h cmMuaWV0Zi5vcmciPjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkhlbHZldGljYSI+V2hhdCBpZiB0aGUgQVMgd2FudHMgdG8gT05MWSBzdXBwb3J0IE1UTFMgY29u bmVjdGlvbnMuIERvZXMgaXQgbm90IHNwZWNpZnkgdGhlIG9wdGlvbmFsICZxdW90O210bHNfZW5k cG9pbnRzJnF1b3Q7IGFuZCBqdXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRhIHZhbHVlcz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8xNS8x OSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBkZWZp bml0ZWx5IGJlIG9wdGlvbmFsLCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4g SXQnZCBiZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRv IGluY2x1ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbiBwcmVzZW50 IGluIEFTIG1ldGFkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBKYW4gMTUsIDIwMTkgYXQgMjowNCBBTSBEYXZlIFRvbmdlICZsdDs8YSBo cmVmPSJtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+ ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbjowLi44ZXgiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+SSdtIGluIGZhdm91ciBvZiB0aGUg YG10bHNfZW5kcG9pbnRzYCBtZXRhZGF0YSBwYXJhbWV0ZXIgLSBhbHRob3VnaCBpdCBzaG91bGQg YmUgb3B0aW9uYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUNCiBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwv aT4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRo IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7 Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5D T05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+ PC9pPjwvYj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F5841CEABA744F17977AA78922CDC68Camazoncom_-- From nobody Fri Feb 1 14:49:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F73130EE0 for ; Fri, 1 Feb 2019 14:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.841 X-Spam-Level: X-Spam-Status: No, score=-8.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paq94UQC7nDV for ; Fri, 1 Feb 2019 14:49:21 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B10130ED1 for ; Fri, 1 Feb 2019 14:49:21 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x11MnJOP005206; Fri, 1 Feb 2019 22:49:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=jS3xuc3ZUuvry19XTY/ICrjQk1i13tNWxmrAhdjUCi8=; b=suL2mLXJnEBn2aMyRfkALBuseE0W/qexJ71GGmqhTjGAgFxHocsTDyhlt/k4e5zZEa2u ldrJr5IMibPLv2O53Dw+I9DwqX6qz8PffbXC6+uoxn7ivX/mGgy50wQQY9/Ja6BU8+ow 5ZOKE1mDxaViIlkCo621OrjYf2d9aygkz9PAZ/uwl1slPrILxAZjkpOa6qVp0AAfIk9l RMtHx73RfM9h33YUff4uc/qWGBcgFzS7eDEN7BGc9/YZJNMm6/MP2RkKYZbyTtG9WtlC mDy1VcS8tw98dKa4hRmU9sAglJHW8xjFOLqMRgm5Xb/MjBUZ9c2CdOQB6Pudn9Gc4a0w Bg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2q8eyv16pm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Feb 2019 22:49:18 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x11MnHEQ005694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Feb 2019 22:49:18 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x11MnHtE012309; Fri, 1 Feb 2019 22:49:17 GMT Received: from dhcp-10-159-243-81.vpn.oracle.com (/10.159.243.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Feb 2019 14:49:16 -0800 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CB3D3628-127F-40A7-BF9C-E8396C8D03FD" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Feb 2019 14:49:14 -0800 In-Reply-To: Cc: Filip Skokan , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com> X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9154 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902010162 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 22:49:26 -0000 --Apple-Mail=_CB3D3628-127F-40A7-BF9C-E8396C8D03FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, Let me turn this around. Is it possible for a single endpoint to have = MTLS clients (mutual auth) and bearer clients (server auth TLS)? =20 I had thought that client certificate authen can be made optional, but I = must confess I=E2=80=99m confused as to how optionality works in TLS = when it comes to client certificate authentication. If we have to do multiple endpoints for the APIs and/or the token = endpoints, we have to send clients to the correct endpoints to make TLS = set up correctly. If this is the case, I think Brian is right=E2=80=94we= need a parameter. Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 1, 2019, at 1:43 PM, Brian Campbell = wrote: >=20 > I guess I'm not clear what you are driving at.=20 >=20 > On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt > wrote: > That way works. But one of the modes on most tls terminators is client = cert optional. >=20 > This works ok when you want dual mode to support bearer and mtls for = apps (e.g. mobile) because the client will decide to use MTLS. With = browsers, they only use it if forced. >=20 > Phil >=20 > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com = phil.hunt@o= racle.com >=20 >> On Feb 1, 2019, at 1:14 PM, Brian Campbell = > wrote: >>=20 >> The server has to ask during the handshake for a client to send a = cert.=20 >>=20 >> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt > wrote: >> If a client attempts to force mtls would typical tls terminators = accept it enough to redirect? >>=20 >> My worry is how optionality works in browsers. It seems like they = have to hit an mtls required endpoint before they reliably use a client = cert.=20 >>=20 >> Phil >>=20 >> On Feb 1, 2019, at 12:56 PM, Brian Campbell = > wrote: >>=20 >>> It would be more a client having reached a non-MTLS endpoint and is = 307'd to an MTLS enabled endpoint.=20 >>>=20 >>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt > wrote: >>> I was a bit confused by how the 307 would work. >>>=20 >>> To confirm, Is the client having reached an MTLS optional endpoint = being redirected to an MTLS mandatory endpoint if the AT (or a cookie) = is detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the = browser invoke MTLS? >>>=20 >>> Phil >>>=20 >>> Oracle Corporation, Cloud Security and Identity Architect >>> @independentid >>> www.independentid.com = phil.hunt@o= racle.com >>>=20 >>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell = > wrote: >>>>=20 >>>> I'm finally getting around to working on the document updates = (there's quite a few things that came out of AD review too). As far as = the issue in this thread goes though, I'm leaning towards adding = "mtls_endpoints" as a new metadata parameter. Maybe mention that a 307 = might happen but it'd be more of a considerations type text.=20 >>>>=20 >>>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell = > wrote: >>>> I guess I should have also said or been more straightforward in = saying that I don't particularly want to try and discuss/define the use = of a 307 in the document.=20 >>>>=20 >>>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan > wrote: >>>> I don't know that the use of 307 would need to be discussed in the = document itself.=20 >>>>=20 >>>> If the clients are supposed to be ready for this, yeah. For = instance, my client software by default doesn't follow redirects, in = order for it to be ready for mtls client authentication i'd have to know = 307 is a possibility and whitelist 307 as a valid code to be followed. >>>>=20 >>>> S pozdravem, >>>> Filip Skokan >>>>=20 >>>>=20 >>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell = > wrote: >>>> I don't know that the use of 307 would need to be discussed in the = document itself.=20 >>>>=20 >>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan > wrote: >>>> I'm in favour of both 307 and metadata.=20 >>>> case 307 - I don't recall ever encountering an http client software = that wouldn't have an option for following redirects, same for a server = side frameworks not having the option to do a 307 response with a = location header. >>>> case 307 - Relying purely on a new metadata doesn't help in the = scenario David put forth earlier about clients not being aware of using = mtls, a device policy of sorts. >>>> case metadata - no second request if the client knows there's an = mtls endpoint it should use. >>>> Maybe we should specify both as optional for an AS to deploy and a = client to be ready for? >>>>=20 >>>> S pozdravem, >>>> Filip Skokan >>>>=20 >>>>=20 >>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge = > = wrote: >>>> I'm in favour of the `mtls_endpoints` metadata parameter - although = it should be optional. >>>> While a 307 redirect seems kind of elegant I worry, like you, that = not all clients would handle it appropriately. >>>> There would probably need to be an error defined for clients who = attempt to use `tls_client_auth` at the regular endpoint. >>>>=20 >>>> Dave >>>>=20 >>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell = > wrote: >>>> Trying to summarize things somewhat here and focus in hopefully = towards some decision. There's basically an idea on the table to add an = AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a = JSON object which contains endpoints that a client doing MTLS would use = rather than the regular endpoints. A straw-man example might look like = this (with mtls_endpoints being that new parameter). >>>>=20 >>>> { =20 >>>> "issuer":"https://server.example.com = ", >>>> "authorization_endpoint":"https://server.example.com/authz = ", >>>> "token_endpoint":"https://server.example.com/token = ", >>>> "token_endpoint_auth_methods_supported":[ = "client_secret_basic","tls_client_auth", "none"], >>>> "userinfo_endpoint":"https://server..example.com/userinfo = ", >>>> "revocation_endpoint":"https://server.example.com/revo = ", >>>> "jwks_uri":"https://server.example.com/jwks.json = ", >>>> "mtls_endpoints":{ =20 >>>> "token_endpoint":"https://mtls.example.com/token = ", >>>> "userinfo_endpoint":"https://mtls = .example.com/userinfo = ", >>>> "revocation_endpoint":"https://mtls = ..example.com/revo = " >>>> } >>>> } >>>>=20 >>>> The idea behind this is that "regular" clients (those not doing = MTLS) will use the regular endpoints. And only the host/port of the = endpoints listed in mtls_endpoints will be set up to request TLS client = certificates during handshake.. Thus any potential impact of the = CertificateRequest message being sent in the TLS handshake can be = avoided for all the other regular clients that are not going to do MTLS = - including and most importantly in-browser javascript clients where = there can be less than desirable UI presented to the end-user.=20 >>>>=20 >>>> The arguments in favor of that seem to be basically that it allows = for AS deployments to support MTLS while still allowing for a "not = broken" UX for end-users of clients (in-browser javascript clients) that = aren't doing MTLS. And that it's not much in terms of adding to the spec = and complexity of implementations.=20 >>>>=20 >>>> The arguments against it seem to be 1) the bad UX isn't really that = bad and/or will only happen to a subset of users 2) there are other = things that can be done, such as 307ing or renegotiation/post-handshake = client auth, to avoid the bad UX.=20 >>>>=20 >>>> Speaking for myself, I'm kinda torn on it.=20 >>>>=20 >>>> I will say that, in addition to the folks that have pointed out = that renegotiation just isn't possible in some cases, my experience = trying to do something like that in the past was not particularly = successful or encouraging. That could have been my fault, of course, but = still seems a relevant data point. I also have my doubts about the = actual difficulty of getting an AS to issue a 307 like response for = requests based on the calling client and the likelihood that some/all = OAuth client software would handle it appropriately.=20 >>>> =20 >>>>=20 >>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite = > = wrote: >>>>=20 >>>>=20 >>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden = > wrote: >>>> >=20 >>>> > On 9 Jan 2019, at 05:54, David Waite = > = wrote: >>>> >>=20 >>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = > wrote: >>>> >>>=20 >>>> >> >>>> >>=20 >>>> >>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to = retract the proposal I'd previously made about the MTLS draft = introducing a new AS metadata parameter. It is admittedly interesting = (ironic?) that Neil sent a message in support of the proposal as I was = writing this. It did give me pause but ultimately didn't change my = opinion that it's not worth it to add this new AS metadata parameter. >>>> >>=20 >>>> >> Note that the AS could make a decision based on the token = endpoint request - such as a policy associated with the =E2=80=9Cclient_id= =E2=80=9D, or via a parameter in the ilk of =E2=80=9Cclient_assertion_type= =E2=80=9D indicating MTLS was desired by this public client = installation. The AS could then to TLS 1.2 renegotiation, 1.3 = post-handshake client authentication, or even use 307 temporary = redirects to another token endpoint to perform mutual authentication. >>>> >=20 >>>> > Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy? >>>> >=20 >>>> > A 307 redirect could work though as the server will know if the = client either uses mTLS for client authentication or has indicated that = it wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases. >>>>=20 >>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t = know a way to have say a custom error code or WWW-Authenticate challenge = to trigger renegotiation on the reverse proxy - usually this is just a = static, location-based directive. >>>>=20 >>>> >=20 >>>> >> Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication. >>>> >=20 >>>> > That=E2=80=99s an interesting observation. Can you elaborate on = the sorts of device policy you are talking about? I am aware of e.g. = mobile device management being used to push client certificates to iOS = devices, but I think these are only available in Safari. >>>>=20 >>>> The primary use is to set policy to rely on device level management = in controlled environments like enterprises when available. So an AS may = try to detect a client certificate as an indicator of a managed device, = use that to assume a device with certain device-level authentication, = single user usage, remote wipe, etc. characteristics, and decide that it = can reduce user authentication requirements and/or expose additional = scopes. >>>>=20 >>>> On more thought, this is typically done as part of the user agent = hitting the authorization endpoint, as a separate native application may = be interacting with the token endpoint, and in some operating systems = the application=E2=80=99s network connections do not utilize (and may = not have access to) the system certificate store. >>>>=20 >>>> In terms of user agents, I believe you can perform similar behavior = (managed systems using client certificates on user agents transparently) = on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) = typically inherits device level policy. Firefox on desktop I assume you = can do that in limited fashion as well. >>>>=20 >>>> -DW >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.... If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_CB3D3628-127F-40A7-BF9C-E8396C8D03FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Brian,

Let me turn this around. Is it possible for a single endpoint = to have MTLS clients (mutual auth) and bearer clients (server auth TLS)? =  

I had = thought that client certificate authen can be made optional, but I must = confess I=E2=80=99m confused as to how optionality works in TLS when it = comes to client certificate authentication.

If we have to do multiple endpoints for = the APIs and/or the token endpoints, we have to send clients to the = correct endpoints to make TLS set up correctly.   If this is the = case, I think Brian is right=E2=80=94we need a parameter.

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb 1, 2019, at 1:43 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I = guess I'm not clear what you are driving at. 

On Fri, Feb 1, 2019 at 2:32 = PM Phil Hunt <phil.hunt@oracle.com> wrote:
That way = works. But one of the modes on most tls terminators is client cert = optional.

This = works ok when you want dual mode to support bearer and mtls for apps = (e.g. mobile) because the client will decide to use MTLS.  With = browsers, they only use it if forced.

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb = 1, 2019, at 1:14 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

The server has to ask during the = handshake for a client to send a cert. <= br class=3D"">

On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <phil.hunt@oracle.com> wrote:
If a client attempts to force mtls would typical = tls terminators accept it enough to redirect?

My worry is how optionality works in = browsers. It seems like they have to hit an mtls required endpoint = before they reliably use a client cert. 

Phil

On Feb 1, 2019, at 12:56 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

It would be more a client having = reached a non-MTLS endpoint and is 307'd to an MTLS enabled = endpoint. <= br class=3D"">

On Fri, Feb 1, 2019 at 1:40 PM Phil = Hunt <phil.hunt@oracle.com> wrote:
I was a bit confused by how the 307 would work.

To confirm, Is the = client having reached an MTLS optional endpoint being redirected to an = MTLS mandatory endpoint if the AT (or a cookie) is detected to have a = =E2=80=9Ccnf=E2=80=9D claim in order to make the browser invoke = MTLS?

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb = 1, 2019, at 11:56 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

I'm finally getting = around to working on the document updates (there's quite a few things = that came out of AD review too). As far as the issue in this thread goes = though, I'm leaning towards adding "mtls_endpoints" as a new metadata = parameter. Maybe mention that a 307 might happen but it'd be more of a = considerations type text. <= br class=3D"">

On Wed, Jan 16, 2019 at 5:52 AM Brian = Campbell <bcampbell@pingidentity.com> = wrote:
I guess I should have = also said or been more straightforward in saying that I don't = particularly want to try and discuss/define the use of a 307 in the = document. <= br class=3D"">

On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan = <panva.ip@gmail.com> wrote:
I don't know that the use of 307 would need to be discussed = in the document itself. 

If the clients are supposed to be ready = for this, yeah. For instance, my client software by default doesn't = follow redirects, in order for it to be ready for mtls client = authentication i'd have to know 307 is a possibility and whitelist 307 = as a valid code to be followed.

S pozdravem,
Filip = Skokan


On Tue, Jan 15, 2019 = at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
I don't know that the use of 307 would need to be = discussed in the document itself. <= br class=3D"">

On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan = <panva.ip@gmail.com> wrote:
I'm in favour of both 307 and = metadata. 
  • case = 307 - I don't recall ever encountering an http client software that = wouldn't have an option for following redirects, same for a server side = frameworks not having the option to do a 307 response with a location = header.
  • case 307 - Relying purely on a = new metadata doesn't help in the scenario David put forth earlier about = clients not being aware of using mtls, a device policy of sorts.
  • case metadata - no second request if the = client knows there's an mtls endpoint it should use.
Maybe we should specify both as optional for an AS to deploy = and a client to be ready for?

S = pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge = <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata = parameter - although it should be optional.
While a 307 redirect seems kind of elegant I worry, like = you,  that not all clients would handle it = appropriately.
There would probably need = to be an error defined for clients who attempt to use `tls_client_auth` = at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at = 22:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying to summarize things somewhat here and = focus in hopefully towards some decision. There's basically an idea on = the table to add an AS metadata parameter to the draft-ietf-oauth-mtls = doc that would be a JSON object which contains endpoints that a client = doing MTLS would use rather than the regular endpoints. A straw-man = example might look like this (with mtls_endpoints being that new = parameter).

{  <= br class=3D"">  "= issuer":"https://server.example.com",
  "= authorization_endpoint":"https://server.example.com/authz",
  "= token_endpoint":"https://server.example.com/token",
  "= token_endpoint_auth_methods_supported":[  = "client_secret_basic","tls_client_auth", "none"],
  "= userinfo_endpoint":"https://server..example.com/userinfo",  "= revocation_endpoint":"https://server.example.com/revo",
  "= jwks_uri":"https://server.example.com/jwks.json",  "= mtls_endpoints":{  <= br class=3D"">    "= token_endpoint":"https://mtls.example.com/token",
    "= userinfo_endpoint":"https://mtls.example.com/userinfo",
    "= revocation_endpoint":"https://mtls..example.com/revo"
  }=
}

The idea behind this is that "regular" = clients (those not doing MTLS) will use the regular endpoints. And only = the host/port of the endpoints listed in mtls_endpoints will be set up = to request TLS client certificates during handshake.. Thus any potential = impact of the CertificateRequest message being sent in the TLS handshake = can be avoided for all the other regular clients that are not going to = do MTLS - including and most importantly in-browser javascript clients = where there can be less than desirable UI presented to the = end-user. <= br class=3D"">

The arguments in favor of that seem to be basically that it = allows for AS deployments to support MTLS while still allowing for a = "not broken" UX for end-users of clients (in-browser javascript clients) = that aren't doing MTLS. And that it's not much in terms of adding to the = spec and complexity of implementations. <= br class=3D"">

The arguments against it seem to be 1) the bad UX isn't = really that bad and/or will only happen to a subset of users 2) there = are other things that can be done, such as 307ing or = renegotiation/post-handshake client auth, to avoid the bad UX. <= br class=3D"">

Speaking for myself, I'm kinda torn on it. <= br class=3D"">

I= will say that, in addition to the folks that have pointed out that = renegotiation just isn't possible in some cases, my experience trying to = do something like that in the past was not particularly successful or = encouraging. That could have been my fault, of course, but still seems a = relevant data point. I also have my doubts about the actual difficulty = of getting an AS to issue a 307 like response for requests based on the = calling client and the likelihood that some/all OAuth client software = would handle it appropriately. <= br class=3D"">
 

On = Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote:


> On Jan 11, 2019, at 3:32 AM, Neil Madden = <neil.madden@forgerock.com> wrote:
> <= br class=3D"">> On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> wrote:
>> <= br class=3D"">>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
>>> <= br class=3D"">>> <snip>
>> <= br class=3D"">>>> All of that is meant as an explanation of = sorts to say that I think that things are actually okay enough as is and = that I'd like to retract the proposal I'd previously made about the MTLS = draft introducing a new AS metadata parameter. It is admittedly = interesting (ironic?) that Neil sent a message in support of the = proposal as I was writing this. It did give me pause but ultimately = didn't change my opinion that it's not worth it to add this new AS = metadata parameter.
>> <= br class=3D"">>> Note that the AS could make a decision based on = the token endpoint request - such as a policy associated with the = =E2=80=9Cclient_id=E2=80=9D, or via a parameter in the ilk of = =E2=80=9Cclient_assertion_type=E2=80=9D indicating MTLS was desired by = this public client installation. The AS could then to TLS 1.2 = renegotiation, 1.3 post-handshake client authentication, or even use 307 = temporary redirects to another token endpoint to perform mutual = authentication.
> <= br class=3D"">> Renegotiation is an intriguing option, but it has = some practical difficulties. Our AS product runs in a Java servlet = container, where it is pretty much impossible to dynamically trigger = renegotiation without accessing private internal APIs of the container. = I also don=E2=80=99t know how you could coordinate this in the common = scenario where TLS is terminated at a load balancer/reverse proxy?
> <= br class=3D"">> A 307 redirect could work though as the server will = know if the client either uses mTLS for client authentication or has = indicated that it wants certificate-bound access tokens, so it can = redirect to a mTLS-specific endpoint in those cases.

Agreed. There are trade-offs for both. As you say, I don=E2=80=99= t know a way to have say a custom error code or WWW-Authenticate = challenge to trigger renegotiation on the reverse proxy - usually this = is just a static, location-based directive.

> <= br class=3D"">>> Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication.
> <= br class=3D"">> That=E2=80=99s an interesting observation. Can you = elaborate on the sorts of device policy you are talking about? I am = aware of e.g. mobile device management being used to push client = certificates to iOS devices, but I think these are only available in = Safari.

The primary use is to set policy to = rely on device level management in controlled environments like = enterprises when available. So an AS may try to detect a client = certificate as an indicator of a managed device, use that to assume a = device with certain device-level authentication, single user usage, = remote wipe, etc. characteristics, and decide that it can reduce user = authentication requirements and/or expose additional scopes.

On more thought, this is typically done as = part of the user agent hitting the authorization endpoint, as a separate = native application may be interacting with the token endpoint, and in = some operating systems the application=E2=80=99s network connections do = not utilize (and may not have access to) the system certificate = store.

In terms of user agents, I believe = you can perform similar behavior (managed systems using client = certificates on user agents transparently) on macOS, Windows, Chrome, = and Android devices, Chrome (outside iOS) typically inherits device = level policy. Firefox on desktop I assume you can do that in limited = fashion as well.

-DW

CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use = of the intended recipient(s). Any review, use, distribution or = disclosure by others is strictly prohibited....  If you have = received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments = from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
<= /div>
CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use = of the intended recipient(s). Any review, use, distribution or = disclosure by others is strictly prohibited..  If you have received = this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your = computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use = of the intended recipient(s). Any review, use, distribution or = disclosure by others is strictly prohibited.  If you have received = this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your = computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

= --Apple-Mail=_CB3D3628-127F-40A7-BF9C-E8396C8D03FD-- From nobody Fri Feb 1 15:16:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCA7130EEB for ; Fri, 1 Feb 2019 15:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQAKjQW_Rwyq for ; Fri, 1 Feb 2019 15:16:47 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32618130DFA for ; Fri, 1 Feb 2019 15:16:47 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id c9so12428976itj.1 for ; Fri, 01 Feb 2019 15:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1aJqNyGPAXpvkC0oDjCaLZNMveJkbkwqpI/wp+9a5a4=; b=d004ofxoJiYyT8poSNEynnoHpYf3S8SgAcwhvgEMG6iPMYMpP7amJk1NujtPaaO9O7 Sd8TD/vePMKdOxgikf6Djv5uXuC8EQxW9PcPJuihg6k1xbVmlX8wLDXJOMZf3Dh0Jp88 f+c0vca7Se+cWqta/IVMM3uBDRCWZWzNUw93I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1aJqNyGPAXpvkC0oDjCaLZNMveJkbkwqpI/wp+9a5a4=; b=bJJ8qzLju4ikV6EzsvHAGeUqQaZ11QzS5yo0e31TZ5nN2rCNHB6lY79lOHP04fe7F9 E91k2y8qtCFL3DMpoaKB/MEuzwB85e3mBqGmZN8nvDhXsCXT2R2klhNFhcoefUhneIrz /7qlBr73biobx5gbc5pshM4qBirUlgdHJkhuEYQfXnZ7akMi5yAQRl9rORyMTYosTWXt Ad3LETveZg/ktbGmHGcvvBXY6PkX1vr3pm+O3G7dxIn17nrqYspVo8vK8p+MPsqdTvdW BndKqyjxAL4mvP14qu8gAEkhJ4JztN6RhjkXgfpigMNUa8Oi8RxCroQY+wRbn3NAMsUX M2kQ== X-Gm-Message-State: AHQUAua9crSpv0bR3fpeZKA1ypB09fcCliwnWqdvw1dSdHsaxD46lxWH OwVRy/Jr78D17yxHbcJUDSxdJj+22/r5fr7Ain+WhTCx/paCVgsimSECAB7789cDzq2qD2pkS9a +8ggS4LUWtTga8A== X-Google-Smtp-Source: AHgI3IYLaKKpUaerS1EP2Y2bM4smdV0DqqL+iT01M9os2CpS9KVkIA2y/aeVv66q5mnLUwvdb7mNXIB2zRSRFkxTom4= X-Received: by 2002:a24:3987:: with SMTP id l129mr2871973ita.45.1549063006304; Fri, 01 Feb 2019 15:16:46 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> In-Reply-To: From: Brian Campbell Date: Fri, 1 Feb 2019 16:16:19 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: George Fletcher , oauth Content-Type: multipart/alternative; boundary="00000000000039d8600580dd56ee" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 23:16:50 -0000 --00000000000039d8600580dd56ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one. Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time. I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread. But it seems like the rough consensus of the group here is in favor of it. On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000039d8600580dd56ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It doesn't seem like= that confusing or large of a change to me - if the client is doing MTLS an= d the given endpoint is present in `mtls_endpoints`, then it uses that one.= =C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flex= ibility in deployment options. I personally think getting a 307 approach de= ployed and working would be more complicated and error prone.=C2=A0

It is a minority use case at the moment but there are fo= rces in play, like the push for increased security in general and to have j= avascript clients use the code flow, that suggest it won't be terribly = unusual to see an AS that wants to support MTLS clients and javascript/spa = clients at the same time.

I've personally= wavered back and forth in this thread on whether or not to add the new met= adata (or something like it). With my reasoning each way kinda explained so= mewhere back in the 40 or so messages that make up this thread.=C2=A0 But i= t seems like the rough consensus of the group here is in favor of it.
<= /div>



<= br>
On Fri,= Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmar= c.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should= provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code = insufficient to cover the case where a single AS supports both mTLS and non= -mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS met= adata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000039d8600580dd56ee-- From nobody Fri Feb 1 15:26:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC503130F67 for ; Fri, 1 Feb 2019 15:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZTBzf3v5oqx for ; Fri, 1 Feb 2019 15:26:45 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456EA130DFA for ; Fri, 1 Feb 2019 15:26:45 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id k7so7154840iob.6 for ; Fri, 01 Feb 2019 15:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MtY2IiKp3QIVjREUIrsA2JsvVm55XXviL83iNN3qDVU=; b=hOb80nOrgVMP9etWTlYqBEXp04aIsPtIh4IYELdzuxWge6tzoGWdCvX9urxihMRZHW T1WnioMhcHBc99eEbqXbVsS14qecZqJjPlUzhAW9In2Ic7epAXhzlONmY11J8jivAGjh O0BdFZGG8C2hmZfqzchLKywtHx6g8u07uIT+8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MtY2IiKp3QIVjREUIrsA2JsvVm55XXviL83iNN3qDVU=; b=sF28jFZJv2ANQh6Z9th9BLDEB4gC+h9jOM79/YGcF4Ee6sJrxQ4vqb6Ixh5tqEu6jY rQYLYjeXSQMuiNHQpsDPs3afOGek5jqB8SrBPKRTgcxY40RVNhX/vMH8PBPGXKtFT8GS 3gf2prQd6aiyI4qfbSuAJWmvaQyCPZmlVxLtli/gL23eqNqeWEpO3N3AMcvf83jaTv5J 4lXawHq1lObx4TPhDUeQ3aWv9H2wwJAK1x3dGsp6vii6HX94jjDWviRM6NSd3lqcID+r 4UAwsyFAvymi/N4W+lkURUcliBCWLUidycX7WYWbg8Ubu0LWSIw+1WJXRUGgWtHy8YxN /NCw== X-Gm-Message-State: AHQUAuZi1Pob4ckdlw/0pcV20jE+3Un+HBhf4D6rYfPIe2CRyXCeLkZ+ oPIvffpJNu0kQ7+M8q30bNK/Zl3Gs9qltSKrRO9sI89RWDvf2k7ukmhqUc/E8LYZhm10n7oAaJr 6rrTuAWJ5/TVCBg== X-Google-Smtp-Source: ALg8bN5vM/lfIQINKXC+SCWSzAOtSOzx6QvVQ2iU9AQQFC75+siMhqFUpR+SgNGu1xSsIHAwlMGnDI9rfPjrSn7/O2Y= X-Received: by 2002:a6b:b345:: with SMTP id c66mr24507227iof.59.1549063604184; Fri, 01 Feb 2019 15:26:44 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com> In-Reply-To: From: Brian Campbell Date: Fri, 1 Feb 2019 16:26:17 -0700 Message-ID: To: Phil Hunt Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="000000000000dcc62e0580dd7908" Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 23:26:50 -0000 --000000000000dcc62e0580dd7908 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes client certificate authen can be made optional. In the optional case the server still sends the CertificateRequest message during the handshake which efficiently asks the client to present a cert. The client send a cert or not at that point. In the optional case, the server will continue with the connection even when no client cert is presented. In the required case, the server will terminate the handshake when no client cert is presented. So yes, optional is possible. The potential problem is the (sometimes pretty bad and/or confusing) UI that browsers will present to the end-user anytime the CertificateRequest message is sent by the server in the handshake. And that message is sent in the optional case and the required case. Giving an AS a way to avoid the potentially bad UX for the end user is the impetus behind this whole discussion. On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt wrote: > Brian, > > Let me turn this around. Is it possible for a single endpoint to have MTL= S > clients (mutual auth) and bearer clients (server auth TLS)? > > I had thought that client certificate authen can be made optional, but I > must confess I=E2=80=99m confused as to how optionality works in TLS when= it comes > to client certificate authentication. > > If we have to do multiple endpoints for the APIs and/or the token > endpoints, we have to send clients to the correct endpoints to make TLS s= et > up correctly. If this is the case, I think Brian is right=E2=80=94we ne= ed a > parameter. > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Feb 1, 2019, at 1:43 PM, Brian Campbell > wrote: > > I guess I'm not clear what you are driving at. > > On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt wrote: > >> That way works. But one of the modes on most tls terminators is client >> cert optional. >> >> This works ok when you want dual mode to support bearer and mtls for app= s >> (e.g. mobile) because the client will decide to use MTLS. With browsers= , >> they only use it if forced. >> >> Phil >> >> Oracle Corporation, Cloud Security and Identity Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Feb 1, 2019, at 1:14 PM, Brian Campbell >> wrote: >> >> The server has to ask during the handshake for a client to send a cert. >> >> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt wrote: >> >>> If a client attempts to force mtls would typical tls terminators accept >>> it enough to redirect? >>> >>> My worry is how optionality works in browsers. It seems like they have >>> to hit an mtls required endpoint before they reliably use a client cert= . >>> >>> Phil >>> >>> On Feb 1, 2019, at 12:56 PM, Brian Campbell >>> wrote: >>> >>> It would be more a client having reached a non-MTLS endpoint and is >>> 307'd to an MTLS enabled endpoint. >>> >>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt wrote: >>> >>>> I was a bit confused by how the 307 would work. >>>> >>>> To confirm, Is the client having reached an MTLS optional endpoint >>>> being redirected to an MTLS mandatory endpoint if the AT (or a cookie)= is >>>> detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the br= owser invoke MTLS? >>>> >>>> Phil >>>> >>>> Oracle Corporation, Cloud Security and Identity Architect >>>> @independentid >>>> www.independentid.com >>>> >>>> phil.hunt@oracle.com >>>> >>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell < >>>> bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: >>>> >>>> I'm finally getting around to working on the document updates (there's >>>> quite a few things that came out of AD review too). As far as the issu= e in >>>> this thread goes though, I'm leaning towards adding "mtls_endpoints" a= s a >>>> new metadata parameter. Maybe mention that a 307 might happen but it'd= be >>>> more of a considerations type text. >>>> >>>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> I guess I should have also said or been more straightforward in sayin= g >>>>> that I don't particularly want to try and discuss/define the use of a= 307 >>>>> in the document. >>>>> >>>>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan >>>>> wrote: >>>>> >>>>>> I don't know that the use of 307 would need to be discussed in the >>>>>>> document itself. >>>>>> >>>>>> >>>>>> If the clients are supposed to be ready for this, yeah. For instance= , >>>>>> my client software by default doesn't follow redirects, in order for= it to >>>>>> be ready for mtls client authentication i'd have to know 307 is a >>>>>> possibility and whitelist 307 as a valid code to be followed. >>>>>> >>>>>> S pozdravem, >>>>>> *Filip Skokan* >>>>>> >>>>>> >>>>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>>>> I don't know that the use of 307 would need to be discussed in the >>>>>>> document itself. >>>>>>> >>>>>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan >>>>>>> wrote: >>>>>>> >>>>>>>> I'm in favour of both 307 and metadata. >>>>>>>> >>>>>>>> - case 307 - I don't recall ever encountering an http client >>>>>>>> software that wouldn't have an option for following redirects, = same for a >>>>>>>> server side frameworks not having the option to do a 307 respon= se with a >>>>>>>> location header. >>>>>>>> - case 307 - Relying purely on a new metadata doesn't help in >>>>>>>> the scenario David put forth earlier about clients not being aw= are of using >>>>>>>> mtls, a device policy of sorts. >>>>>>>> - case metadata - no second request if the client knows there's >>>>>>>> an mtls endpoint it should use. >>>>>>>> >>>>>>>> Maybe we should specify both as optional for an AS to deploy and a >>>>>>>> client to be ready for? >>>>>>>> >>>>>>>> S pozdravem, >>>>>>>> *Filip Skokan* >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge < >>>>>>>> dave.tonge@momentumft.co.uk> wrote: >>>>>>>> >>>>>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - >>>>>>>>> although it should be optional. >>>>>>>>> While a 307 redirect seems kind of elegant I worry, like you, >>>>>>>>> that not all clients would handle it appropriately. >>>>>>>>> There would probably need to be an error defined for clients who >>>>>>>>> attempt to use `tls_client_auth` at the regular endpoint. >>>>>>>>> >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >>>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>>> Trying to summarize things somewhat here and focus in hopefully >>>>>>>>>> towards some decision. There's basically an idea on the table to= add an AS >>>>>>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would b= e a JSON >>>>>>>>>> object which contains endpoints that a client doing MTLS would u= se rather >>>>>>>>>> than the regular endpoints. A straw-man example might look like = this (with >>>>>>>>>> mtls_endpoints being that new parameter). >>>>>>>>>> >>>>>>>>>> { >>>>>>>>>> "issuer":"https://server.example.com", >>>>>>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>>>>>> "token_endpoint":"https://server.example.com/token", >>>>>>>>>> "token_endpoint_auth_methods_supported":[ >>>>>>>>>> "client_secret_basic","tls_client_auth", "none"], >>>>>>>>>> "userinfo_endpoint":"https://server..example.com/userinfo >>>>>>>>>> ", >>>>>>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * "mtls_endpoints":{ "token_endpoint":"https://mtls.exampl= e.com/token >>>>>>>>>> ", "userinfo_endpoint":"https= ://mtls >>>>>>>>>> .example.com/userinfo >>>>>>>>>> ", "revocation_endpoint":"https:= //mtls >>>>>>>>>> ..example.com/revo >>>>>>>>>> " }* >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> The idea behind this is that "regular" clients (those not doing >>>>>>>>>> MTLS) will use the regular endpoints. And only the host/port of = the >>>>>>>>>> endpoints listed in mtls_endpoints will be set up to request TLS= client >>>>>>>>>> certificates during handshake.. Thus any potential impact of the >>>>>>>>>> CertificateRequest message being sent in the TLS handshake can b= e avoided >>>>>>>>>> for all the other regular clients that are not going to do MTLS = - including >>>>>>>>>> and most importantly in-browser javascript clients where there c= an be less >>>>>>>>>> than desirable UI presented to the end-user. >>>>>>>>>> >>>>>>>>>> The arguments in favor of that seem to be basically that it >>>>>>>>>> allows for AS deployments to support MTLS while still allowing f= or a "not >>>>>>>>>> broken" UX for end-users of clients (in-browser javascript clien= ts) that >>>>>>>>>> aren't doing MTLS. And that it's not much in terms of adding to = the spec >>>>>>>>>> and complexity of implementations. >>>>>>>>>> >>>>>>>>>> The arguments against it seem to be 1) the bad UX isn't really >>>>>>>>>> that bad and/or will only happen to a subset of users 2) there a= re other >>>>>>>>>> things that can be done, such as 307ing or renegotiation/post-ha= ndshake >>>>>>>>>> client auth, to avoid the bad UX. >>>>>>>>>> >>>>>>>>>> Speaking for myself, I'm kinda torn on it. >>>>>>>>>> >>>>>>>>>> I will say that, in addition to the folks that have pointed out >>>>>>>>>> that renegotiation just isn't possible in some cases, my experie= nce trying >>>>>>>>>> to do something like that in the past was not particularly succe= ssful or >>>>>>>>>> encouraging. That could have been my fault, of course, but still= seems a >>>>>>>>>> relevant data point. I also have my doubts about the actual diff= iculty of >>>>>>>>>> getting an AS to issue a 307 like response for requests based on= the >>>>>>>>>> calling client and the likelihood that some/all OAuth client sof= tware would >>>>>>>>>> handle it appropriately. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite < >>>>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden < >>>>>>>>>>> neil.madden@forgerock.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite < >>>>>>>>>>> david@alkaline-solutions.com> wrote: >>>>>>>>>>> >> >>>>>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>>>>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>>>>>>> >>> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >>> All of that is meant as an explanation of sorts to say that >>>>>>>>>>> I think that things are actually okay enough as is and that I'd= like to >>>>>>>>>>> retract the proposal I'd previously made about the MTLS draft i= ntroducing a >>>>>>>>>>> new AS metadata parameter. It is admittedly interesting (ironic= ?) that Neil >>>>>>>>>>> sent a message in support of the proposal as I was writing this= . It did >>>>>>>>>>> give me pause but ultimately didn't change my opinion that it's= not worth >>>>>>>>>>> it to add this new AS metadata parameter. >>>>>>>>>>> >> >>>>>>>>>>> >> Note that the AS could make a decision based on the token >>>>>>>>>>> endpoint request - such as a policy associated with the =E2=80= =9Cclient_id=E2=80=9D, or via >>>>>>>>>>> a parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80= =9D indicating MTLS was >>>>>>>>>>> desired by this public client installation. The AS could then t= o TLS 1.2 >>>>>>>>>>> renegotiation, 1.3 post-handshake client authentication, or eve= n use 307 >>>>>>>>>>> temporary redirects to another token endpoint to perform mutual >>>>>>>>>>> authentication. >>>>>>>>>>> > >>>>>>>>>>> > Renegotiation is an intriguing option, but it has some >>>>>>>>>>> practical difficulties. Our AS product runs in a Java servlet c= ontainer, >>>>>>>>>>> where it is pretty much impossible to dynamically trigger reneg= otiation >>>>>>>>>>> without accessing private internal APIs of the container. I als= o don=E2=80=99t know >>>>>>>>>>> how you could coordinate this in the common scenario where TLS = is >>>>>>>>>>> terminated at a load balancer/reverse proxy? >>>>>>>>>>> > >>>>>>>>>>> > A 307 redirect could work though as the server will know if >>>>>>>>>>> the client either uses mTLS for client authentication or has in= dicated that >>>>>>>>>>> it wants certificate-bound access tokens, so it can redirect to= a >>>>>>>>>>> mTLS-specific endpoint in those cases. >>>>>>>>>>> >>>>>>>>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80= =99t know >>>>>>>>>>> a way to have say a custom error code or WWW-Authenticate chall= enge to >>>>>>>>>>> trigger renegotiation on the reverse proxy - usually this is ju= st a static, >>>>>>>>>>> location-based directive. >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >> Both the separate metadata url and a >>>>>>>>>>> =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply th= at the client has multiple >>>>>>>>>>> forms of authentication and is choosing to use MTLS. The URL in= particular >>>>>>>>>>> I=E2=80=99m reluctant to add support for, because I see it more= likely a client >>>>>>>>>>> would use MTLS without knowing it (via a device-level policy be= ing applied >>>>>>>>>>> to a public web or native app) than the reverse, where a single= client >>>>>>>>>>> (represented by a single client_id) is dynamically picking betw= een forms of >>>>>>>>>>> authentication. >>>>>>>>>>> > >>>>>>>>>>> > That=E2=80=99s an interesting observation. Can you elaborate = on the >>>>>>>>>>> sorts of device policy you are talking about? I am aware of e.g= . mobile >>>>>>>>>>> device management being used to push client certificates to iOS= devices, >>>>>>>>>>> but I think these are only available in Safari. >>>>>>>>>>> >>>>>>>>>>> The primary use is to set policy to rely on device level >>>>>>>>>>> management in controlled environments like enterprises when ava= ilable. So >>>>>>>>>>> an AS may try to detect a client certificate as an indicator of= a managed >>>>>>>>>>> device, use that to assume a device with certain device-level >>>>>>>>>>> authentication, single user usage, remote wipe, etc. characteri= stics, and >>>>>>>>>>> decide that it can reduce user authentication requirements and/= or expose >>>>>>>>>>> additional scopes. >>>>>>>>>>> >>>>>>>>>>> On more thought, this is typically done as part of the user >>>>>>>>>>> agent hitting the authorization endpoint, as a separate native = application >>>>>>>>>>> may be interacting with the token endpoint, and in some operati= ng systems >>>>>>>>>>> the application=E2=80=99s network connections do not utilize (a= nd may not have >>>>>>>>>>> access to) the system certificate store. >>>>>>>>>>> >>>>>>>>>>> In terms of user agents, I believe you can perform similar >>>>>>>>>>> behavior (managed systems using client certificates on user age= nts >>>>>>>>>>> transparently) on macOS, Windows, Chrome, and Android devices, = Chrome >>>>>>>>>>> (outside iOS) typically inherits device level policy. Firefox o= n desktop I >>>>>>>>>>> assume you can do that in limited fashion as well. >>>>>>>>>>> >>>>>>>>>>> -DW >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>>>>> privileged material for the sole use of the intended recipient(s= ). Any >>>>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>>>> prohibited.... If you have received this communication in error= , please >>>>>>>>>> notify the sender immediately by e-mail and delete the message a= nd any file >>>>>>>>>> attachments from your computer. Thank you.* >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). = Any >>>>>>> review, use, distribution or disclosure by others is strictly prohi= bited. >>>>>>> If you have received this communication in error, please notify the= sender >>>>>>> immediately by e-mail and delete the message and any file attachmen= ts from >>>>>>> your computer. Thank you.* >>>>>> >>>>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000dcc62e0580dd7908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes client certificate a= uthen can be made optional. In the optional case the server still sends the= CertificateRequest message during the handshake which efficiently asks the= client to present a cert. The client send a cert or not at that point. In = the optional case, the server will continue with the connection even when n= o client cert is presented. In the required case, the server will terminate= the handshake when no client cert is presented.

So yes, optional is possible. The potential problem is the = (sometimes pretty bad and/or confusing) UI that browsers will present to th= e end-user anytime the CertificateRequest message is sent by the server in = the handshake. And that message is sent in the optional case and the requir= ed case. Giving an AS a way to avoid the potentially bad UX for the end use= r is the impetus behind this whole discussion.

On Fri, Feb = 1, 2019 at 3:49 PM Phil Hunt <ph= il.hunt@oracle.com> wrote:
Brian,

Let me turn this around. Is it possible for a single = endpoint to have MTLS clients (mutual auth) and bearer clients (server auth= TLS)? =C2=A0

I had thought that client certificat= e authen can be made optional, but I must confess I=E2=80=99m confused as t= o how optionality works in TLS when it comes to client certificate authenti= cation.

If we have to do multiple endpoints for th= e APIs and/or the token endpoints, we have to send clients to the correct e= ndpoints to make TLS set up correctly. =C2=A0 If this is the case, I think = Brian is right=E2=80=94we need a parameter.

<= div>
Phil

Oracle Corp= oration, Cloud Security and Identity Architect
phil.hunt@oracle.com

On Feb 1, 2019, at 1:43 PM, Brian C= ampbell <bcampbell@pingidentity.com> wrote:

I guess I'm not clear what you are driving at.=C2=A0

On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt <phil.hunt@oracle.com>= wrote:
That way works. But one of the modes on most tls terminators is client ce= rt optional.

This works ok when you want dual mode= to support bearer and mtls for apps (e.g. mobile) because the client will = decide to use MTLS.=C2=A0 With browsers, they only use it if forced.
<= div>

=
Phil

Or= acle Corporation, Cloud Security and Identity Architect
@independ= entid
phil.hunt@oracle.com

On Feb 1, 2019, at 1:14 PM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

The server has to ask during the handshake for a client to se= nd a cert.=C2=A0

On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <phil.hunt@oracle.com> wrote:
If a c= lient attempts to force mtls would typical tls terminators accept it enough= to redirect?

My worry is how optionality works in brows= ers. It seems like they have to hit an mtls required endpoint before they r= eliably use a client cert.=C2=A0

Phil

On Feb 1, 2019, at 12:56 PM,= Brian Campbell <bcampbell@pingidentity.com> wrote:

It would be more a client = having reached a non-MTLS endpoint and is 307'd to an MTLS enabled endp= oint.=C2=A0

On Fri, Feb 1, 2019 at 1:40 PM Phi= l Hunt <phil.h= unt@oracle.com> wrote:
I was a bit confused by how the 307 would work.

=
To confirm, Is the client having reached an MTLS optional endpoi= nt being redirected to an MTLS mandatory endpoint if the AT (or a cookie) i= s detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the brows= er invoke MTLS?

Phil

Oracle Corporation, Cloud Security and Identity Architect
@= independentid
phil.hunt@oracle.com
<= /div>

<= blockquote type=3D"cite">
On Feb 1, 2019, at 11:56 AM, Brian Campbell &= lt;bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
I'm finally getting around t= o working on the document updates (there's quite a few things that came= out of AD review too). As far as the issue in this thread goes though, I&#= 39;m leaning towards adding "mtls_endpoints" as a new metadata pa= rameter. Maybe mention that a 307 might happen but it'd be more of a co= nsiderations type text.=C2=A0

=
On Wed, Ja= n 16, 2019 at 5:52 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
=
I = guess I should have also said or been more straightforward in saying that I= don't particularly want to try and discuss/define the use of a 307 in = the document.=C2=A0

On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan &l= t;panva.ip@gmail.co= m> wrote:
I don't know = that the use of 307 would need to be discussed in the document itself.=C2= =A0

If the clients are supposed to b= e ready for this, yeah. For instance, my client software by default doesn&#= 39;t follow redirects, in order for it to be ready for mtls client authenti= cation i'd have to know 307 is a possibility and whitelist 307 as a val= id code to be followed.

S pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 2:54 PM Brian Cam= pbell <b= campbell@pingidentity.com> wrote:
I don't know that the use of = 307 would need to be discussed in the document itself.= =C2=A0

On T= ue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm i= n favour of both 307 and metadata.=C2=A0
  • case 307 - I don= 't recall ever encountering an http client software that wouldn't h= ave an option for following redirects, same for a server side frameworks no= t having the option to do a 307 response with a location header.
    • case 307 - Relying purely on a new metadata doesn't help in the scena= rio David put forth earlier about clients not being aware of using mtls, a = device policy of sorts.
  • case metadata - no second request if th= e client knows there's an mtls endpoint it should use.
<= div>Maybe we should specify both as optional for an AS to deploy and a clie= nt to be ready for?

S pozdravem,
Filip Skokan


On Tue, Jan 15, 2019 at 10:05 AM Da= ve Tonge <dave.tonge@momentumft.co.uk> wrote:
= I'm in favour of the `mtls_endpoints` metadata parameter - although it = should be optional.
While a 307 redirect seems kind of elegant I worr= y, like you,=C2=A0 that not all clients would handle it appropriately.

Dave

On Mon= , 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc= .ietf.org> wrote:
Trying to summarize things somewhat here and focus in hopefully towards s= ome decision. There's basically an idea on the table to add an AS metad= ata parameter to the draft-ietf-oauth-mtls doc that would be a JSON object = which contains endpoints that a client doing MTLS would use rather than the= regular endpoints. A straw-man example might look like this (with mtls_end= points being that new parameter).

{=C2=A0= =C2=A0
=C2=A0=C2=A0"issuer":&= quot;https://serv= er.example.com",
=C2=A0=C2=A0"au= thorization_endpoint":"https://server.example.com/authz",
=C2=A0<= span class=3D"gmail-m_-4703586467612229554gmail-m_-5947349452251463933Apple= -converted-space">=C2=A0"token_endpoint":"https://server.example.= com/token",
=C2=A0=C2=A0"token_e= ndpoint_auth_methods_supported":[=C2=A0 "client_secret_basic"= ;,"tls_client_auth", "none"],
=C2=A0=C2=A0"userinfo_endpoint":"https://server..example.com/user= info",
=C2=A0=C2=A0"revocation_e= ndpoint":"https://server.example.com/revo",
=C2=A0=C2=A0"jwks_uri":"https://server.example.com/jwks.json= ",
=C2=A0=C2=A0"mtls_endpoints&qu= ot;:{=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0"token_endpoint":"https://mtls.example.com/token= ",
=C2=A0=C2=A0=C2=A0=C2=A0"userinfo= _endpoint":"https://mtls.example.com/userinfo",
=C2=A0=C2=A0=C2=A0=C2=A0"revocation_endpoint":"https://mtls..example.com/revo"
=C2=A0=C2=A0}
}
The idea behind this is that "regular" clients (th= ose not doing MTLS) will use the regular endpoints. And only the host/port = of the endpoints listed in mtls_endpoints will be set up to request TLS cli= ent certificates during handshake.. Thus any potential impact of the Certif= icateRequest message being sent in the TLS handshake can be avoided for all= the other regular clients that are not going to do MTLS - including and mo= st importantly in-browser javascript clients where there can be less than d= esirable UI presented to the end-user.=C2=A0
<= /div>

The arguments in favor of that seem to be basicall= y that it allows for AS deployments to support MTLS while still allowing fo= r a "not broken" UX for end-users of clients (in-browser javascri= pt clients) that aren't doing MTLS. And that it's not much in terms= of adding to the spec and complexity of implementations.=C2=A0

The arguments against it seem t= o be 1) the bad UX isn't really that bad and/or will only happen to a s= ubset of users 2) there are other things that can be done, such as 307ing o= r renegotiation/post-handshake client auth, to avoid the bad UX.=C2=A0

Speaking for myself, I&#= 39;m kinda torn on it.=C2=A0

I will say that, in addition to the folks that have pointed out th= at renegotiation just isn't possible in some cases, my experience tryin= g to do something like that in the past was not particularly successful or = encouraging. That could have been my fault, of course, but still seems a re= levant data point. I also have my doubts about the actual difficulty of get= ting an AS to issue a 307 like response for requests based on the calling c= lient and the likelihood that some/all OAuth client software would handle i= t appropriately.=C2=A0
=C2=A0



> On Jan 11, 2019, at 3:32 AM, Neil Madden <= ;neil.madden= @forgerock.com> wrote:
>=C2=A0
&g= t; On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> wro= te:
>>=C2=A0
>>> On Dec 28, = 2018, at 3:55 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org> wrote:
>>>=C2=A0
>&= gt; <snip>
>>=C2=A0
>>>= ; All of that is meant as an explanation of sorts to say that I think that = things are actually okay enough as is and that I'd like to retract the = proposal I'd previously made about the MTLS draft introducing a new AS = metadata parameter. It is admittedly interesting (ironic?) that Neil sent a= message in support of the proposal as I was writing this. It did give me p= ause but ultimately didn't change my opinion that it's not worth it= to add this new AS metadata parameter.
>>=C2= =A0
>> Note that the AS could make a decision based on the = token endpoint request - such as a policy associated with the =E2=80=9Cclie= nt_id=E2=80=9D, or via a parameter in the ilk of =E2=80=9Cclient_assertion_= type=E2=80=9D indicating MTLS was desired by this public client installatio= n. The AS could then to TLS 1.2 renegotiation, 1.3 post-handshake client au= thentication, or even use 307 temporary redirects to another token endpoint= to perform mutual authentication.
>=C2=A0<= br>> Renegotiation is an intriguing option, but it has some practical di= fficulties. Our AS product runs in a Java servlet container, where it is pr= etty much impossible to dynamically trigger renegotiation without accessing= private internal APIs of the container. I also don=E2=80=99t know how you = could coordinate this in the common scenario where TLS is terminated at a l= oad balancer/reverse proxy?
>=C2=A0
>= A 307 redirect could work though as the server will know if the client eit= her uses mTLS for client authentication or has indicated that it wants cert= ificate-bound access tokens, so it can redirect to a mTLS-specific endpoint= in those cases.

Agreed. There are trade-offs for both. As you say, = I don=E2=80=99t know a way to have say a custom error code or WWW-Authentic= ate challenge to trigger renegotiation on the reverse proxy - usually this = is just a static, location-based directive.

>= =C2=A0
>> Both the separate metadata url and a =E2=80=9Ccli= ent_assertion_type=E2=80=9D-like indicator imply that the client has multip= le forms of authentication and is choosing to use MTLS. The URL in particul= ar I=E2=80=99m reluctant to add support for, because I see it more likely a= client would use MTLS without knowing it (via a device-level policy being = applied to a public web or native app) than the reverse, where a single cli= ent (represented by a single client_id) is dynamically picking between form= s of authentication.
>=C2=A0
> That= =E2=80=99s an interesting observation. Can you elaborate on the sorts of de= vice policy you are talking about? I am aware of e.g. mobile device managem= ent being used to push client certificates to iOS devices, but I think thes= e are only available in Safari.

The primary use is to set policy to = rely on device level management in controlled environments like enterprises= when available. So an AS may try to detect a client certificate as an indi= cator of a managed device, use that to assume a device with certain device-= level authentication, single user usage, remote wipe, etc. characteristics,= and decide that it can reduce user authentication requirements and/or expo= se additional scopes.

On more thought, this is typically done as par= t of the user agent hitting the authorization endpoint, as a separate nativ= e application may be interacting with the token endpoint, and in some opera= ting systems the application=E2=80=99s network connections do not utilize (= and may not have access to) the system certificate store.

In terms o= f user agents, I believe you can perform similar behavior (managed systems = using client certificates on user agents transparently) on macOS, Windows, = Chrome, and Android devices, Chrome (outside iOS) typically inherits device= level policy. Firefox on desktop I assume you can do that in limited fashi= on as well.

-DW

CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the so= le use of the intended recipient(s). Any review, use, distribution or discl= osure by others is strictly prohibited....=C2=A0 If you have received this = communication in error, please notify the sender immediately by e-mail and = delete the message and any file attachments from your computer. Thank you.<= /font>_______________________________________________
OAuth m= ailing list
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CO= NFIDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, dist= ribution or disclosure by others is strictly prohibited.=C2=A0 If you have = received this communication in error, please notify the sender immediately = by e-mail and delete the message and any file attachments from your compute= r. Thank you.

CONFIDENTIALITY NOTICE: This email may contain = confidential and privileged material for the sole use of the intended recip= ient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..=C2=A0 If you have received this communication in error, please= notify the sender immediately by e-mail and delete the message and any fil= e attachments from your computer. Thank you._____________= __________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth

CONFIDENTIALITY NOTICE: This email may contain confidential an= d privileged material for the sole use of the intended recipient(s). Any re= view, use, distribution or disclosure by others is strictly prohibited.=C2= =A0 If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited.=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confiden= tial and privileged material for the sole use of the intended recipient(s).= Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000dcc62e0580dd7908-- From nobody Fri Feb 1 16:03:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E90213102E for ; Fri, 1 Feb 2019 16:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.052 X-Spam-Level: X-Spam-Status: No, score=-19.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7WL-SW7PyyU for ; Fri, 1 Feb 2019 16:03:26 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6C6130EC2 for ; Fri, 1 Feb 2019 16:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1549065805; x=1580601805; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8L7ZXL2ftUfa/lYo5owwniACLBeuQxoWGuOIIsDsVEE=; b=AeIaBkuwPPRlTo1zAYyJ6gwk7DDmNAWXfDlYhOrj3LoG2QlhKBC0Q1YJ wfN+08DlIms8mNkOl42pRS/JJecGTnIg/n8yxUL0vkTqXTU7jqTSvWzF1 ov5FG9FVdtqmps4tFRxd4jyGnD9VQ3gBiB8aUviWa4bmmtDH5vTiWpsxX U=; X-IronPort-AV: E=Sophos;i="5.56,550,1539648000"; d="scan'208,217";a="785123023" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2019 00:03:23 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id x1203IPF098381 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Feb 2019 00:03:21 GMT Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 2 Feb 2019 00:03:20 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 2 Feb 2019 00:03:20 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Sat, 2 Feb 2019 00:03:20 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell CC: George Fletcher , oauth Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint Thread-Index: AQHUlkcL/yDmEBVqa0adnr6fSi/LlqWUfw6AgABVLoCAEb7YgIADcjUAgACW8wCABNeIgIAAwlgAgABPYwCAGzgkgIAAAIsA//+HHICAAJZugP//hwYA Date: Sat, 2 Feb 2019 00:03:20 +0000 Message-ID: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.169] Content-Type: multipart/alternative; boundary="_000_CC05C96533084449A1E2EDA0119BE5D2amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 00:03:29 -0000 --_000_CC05C96533084449A1E2EDA0119BE5D2amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZnVzaW9uIGZyb20gdGhlIEFT4oCZcyBwZXJzcGVjdGl2ZToNCg0KICAxLiAgSWYgSSBvbmx5 IHN1cHBvcnQgbVRMUywgZG8gSSBuZWVkIHRvIGluY2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91 cmkgYW5kIG10bHNfZW5kcG9pbnRzPyBTaG91bGQgSSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8g T3Igc2V0IGl0IHRvIHRoZSBlbXB0eSBzdHJpbmc/DQogIDIuICBXaGF0IGlmIEkgb25seSBzdXBw b3J0IG1UTFMgZm9yIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IG5vdCByZXZvY2F0aW9uIG9yIHVz ZXIgaW5mbz8NCiAgMy4gIEhvdyBkbyBJIHNwZWNpZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBm b3IgdGhlIG1UTFMgdG9rZW4gZW5kcG9pbnQ/IERvZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRo b2RzIGFwcGx5IHRvIGJvdGggdGhlIG1UTFMgYW5kIG5vbi1tVExTIGVuZHBvaW50cz8NCiAgNC4g IEnigJltIHVzaW5nIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cuIERvIEkgaW5jbHVkZSBhIG1U TFMtZW5hYmxlZCBkZXZpY2VfYXV0aG9yaXphdGlvbl9lbmRwb2ludCB1bmRlciBtdGxzX2VuZHBv aW50cz8NCg0KQ29uZnVzaW9uIGZyb20gdGhlIGNsaWVudOKAmXMgcGVyc3BlY3RpdmU6DQoNCiAg MS4gIEFzIGZhciBhcyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQg a25vdyBhbnl0aGluZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xp ZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0 byB1c2UgdGhhdCB0byBhdXRoZW50aWNhdGUgbWUuDQogIDIuICBNeSBBUyBtZXRhZGF0YSBwYXJz ZXIgY3Jhc2hlZCBiZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2lu dF91cmkuDQogIDMuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIGl0IGRp ZG7igJl0IGV4cGVjdCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBhcyBhIHBhcmFtZXRlciB2 YWx1ZS4NCiAgNC4gIFRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZv ciBtdGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRvPw0KICA1LiAgSSBkb27igJl0IGtub3cgd2hh dCB0aGF0IOKAnG3igJ0gbWVhbnMsIGJ1dCB0aGV5IHRvbGQgbWUgdG8gdXNlIEhUVFBTLCBzbyBJ IHNob3VsZCB1c2UgdGhlIG9uZSB3aXRoIOKAnHRsc+KAnSBpbiBpdHMgbmFtZSwgcmlnaHQ/DQoN ClllcywgeW91IGNhbiB3cml0ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0 aGVzZS4gQnV0IHlvdeKAmWxsIGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFy LWJ1dC1zbGlnaHRseS1kaWZmZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBB bmQgaW1wbGVtZW50ZXJzIHdpbGwgc3RpbGwgZ2V0IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hh bmdlIGludHJvZHVjZXMgb3Bwb3J0dW5pdGllcyBmb3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRo YXQgZG8gbm90IGV4aXN0IG5vdywgYW5kIGZvcmNlcyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBw b3J0cyBtVExTLiBJbiBjb250cmFzdCwgdGhlIDMwNyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVk IHdoZW4gYW4gQVMgd2FudHMgdG8gc3VwcG9ydCBib3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMgaW4g aXRzIGJlaGF2aW9yIGFuZCBtZWFuaW5nLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21h bg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBp bmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDEs IDIwMTkgYXQgMzoxNyBQTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hh bm5hQGFtYXpvbi5jb20+DQpDYzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPiwg b2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTog W09BVVRILVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVu ZHBvaW50DQoNCkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxhcmdlIG9m IGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0aGUgZ2l2 ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0IHVzZXMg dGhhdCBvbmUuICBPdGhlcndpc2UgaXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2ludC4gSXQgZ2l2 ZXMgYW4gQVMgYSBsb3Qgb2YgZmxleGliaWxpdHkgaW4gZGVwbG95bWVudCBvcHRpb25zLiBJIHBl cnNvbmFsbHkgdGhpbmsgZ2V0dGluZyBhIDMwNyBhcHByb2FjaCBkZXBsb3llZCBhbmQgd29ya2lu ZyB3b3VsZCBiZSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBwcm9uZS4NCg0KSXQgaXMgYSBt aW5vcml0eSB1c2UgY2FzZSBhdCB0aGUgbW9tZW50IGJ1dCB0aGVyZSBhcmUgZm9yY2VzIGluIHBs YXksIGxpa2UgdGhlIHB1c2ggZm9yIGluY3JlYXNlZCBzZWN1cml0eSBpbiBnZW5lcmFsIGFuZCB0 byBoYXZlIGphdmFzY3JpcHQgY2xpZW50cyB1c2UgdGhlIGNvZGUgZmxvdywgdGhhdCBzdWdnZXN0 IGl0IHdvbid0IGJlIHRlcnJpYmx5IHVudXN1YWwgdG8gc2VlIGFuIEFTIHRoYXQgd2FudHMgdG8g c3VwcG9ydCBNVExTIGNsaWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNh bWUgdGltZS4NCg0KSSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQgZm9ydGggaW4gdGhp cyB0aHJlYWQgb24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0YWRhdGEgKG9yIHNv bWV0aGluZyBsaWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkga2luZGEgZXhwbGFp bmVkIHNvbWV3aGVyZSBiYWNrIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAg dGhpcyB0aHJlYWQuICBCdXQgaXQgc2VlbXMgbGlrZSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRo ZSBncm91cCBoZXJlIGlzIGluIGZhdm9yIG9mIGl0Lg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxLCAy MDE5IGF0IDM6MTggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn Pj4gd3JvdGU6DQpUaGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVz aW5nIGNoYW5nZSB0byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2Fz ZS4gSeKAmW0gZ2V0dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQg bmVlZGVkIHRvIGNsYXJpZnkgd2hlbiB0aGUgQVMgc2hvdWxkIHByb3ZpZGUgYG10bHNfZW5kcG9p bnRzYCBhbmQgd2hlbiB0aGUgY2xpZW50IHNob3VsZCB1c2UgdGhhdCB2ZXJzdXMgdXNpbmcgYHRv a2VuX2VuZHBvaW50LmAgV2h5IGlzIHRoZSAzMDcgc3RhdHVzIGNvZGUgaW5zdWZmaWNpZW50IHRv IGNvdmVyIHRoZSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIGJvdGggbVRMUyBhbmQg bm9uLW1UTFM/DQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkN Cg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQw cGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29t QGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMx IFBNDQpUbzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy4uaWV0Zi5vcmc+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBp ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g TVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpZ ZXMsIHRoYXQgd291bGQgd29yay4NCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdl b3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCldoYXQgaWYgdGhlIEFTIHdhbnRzIHRv IE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rpb25zLiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRoZSBv cHRpb25hbCAibXRsc19lbmRwb2ludHMiIGFuZCBqdXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRh IHZhbHVlcz8NCk9uIDEvMTUvMTkgODo0OCBBTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQpJdCB3 b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFsLCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFk ZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3Ig dGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hl biBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0KDQpPbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0 IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51azxtYWlsdG86ZGF2ZS50 b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3JvdGU6DQpJJ20gaW4gZmF2b3VyIG9mIHRoZSBgbXRs c19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhvdWdoIGl0IHNob3VsZCBiZSBv cHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1 dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCg0KDQpDT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku IEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5p Y2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkg ZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZy b20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBU aGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlh bCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZp ZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj b21wdXRlci4gVGhhbmsgeW91Lg0K --_000_CC05C96533084449A1E2EDA0119BE5D2amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1 IDMgMCAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2lu LWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAxOTI4MjAwMzsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0MjcxNzgwMjggNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTczMTAz MDQyMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDM0 MDMwMzYwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjIwMzkyMzQyNzg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE1NzAyNDQzNTAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0K QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxldmVs NA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNvbmZ1c2lvbiBmcm9tIHRoZSBBU+KAmXMgcGVyc3BlY3RpdmU6PG86cD48L286cD48 L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzIiPklmIEkgb25seSBzdXBwb3J0IG1UTFMsIGRvIEkgbmVlZCB0byBpbmNs dWRlIGJvdGggdG9rZW5fZW5kcG9pbnRfdXJpIGFuZCBtdGxzX2VuZHBvaW50cz8gU2hvdWxkIEkg b21pdCB0b2tlbl9lbmRwb2ludF91cmk/IE9yIHNldCBpdCB0byB0aGUgZW1wdHkgc3RyaW5nPzxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPldoYXQgaWYgSSBvbmx5IHN1cHBvcnQg bVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQgbm90IHJldm9jYXRpb24gb3IgdXNlciBp bmZvPzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkhvdyBkbyBJIHNwZWNpZnkg YXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1UTFMgdG9rZW4gZW5kcG9pbnQ/IERvZXMg dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5IHRvIGJvdGggdGhlIG1UTFMgYW5kIG5v bi1tVExTIGVuZHBvaW50cz88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj5J4oCZ bSB1c2luZyB0aGUgT0F1dGggMi4wIERldmljZSBGbG93LiBEbyBJIGluY2x1ZGUgYSBtVExTLWVu YWJsZWQgZGV2aWNlX2F1dGhvcml6YXRpb25fZW5kcG9pbnQgdW5kZXIgbXRsc19lbmRwb2ludHM/ PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbmZ1c2lvbiBmcm9tIHRoZSBjbGllbnTi gJlzIHBlcnNwZWN0aXZlOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5BcyBmYXIgYXMgSSBr bm93LCBJ4oCZbSBhIHB1YmxpYyBjbGllbnQsIGFuZCBkb27igJl0IGtub3cgYW55dGhpbmcgYWJv dXQgbVRMUywgYnV0IHRoZSBJVCBhZG1pbnMgaW5zdGFsbGVkIGNsaWVudCBjZXJ0cyBpbiB0aGVp ciB1c2Vyc+KAmSBicm93c2VycyBhbmQgdGhlIEFTIGV4cGVjdHMgdG8gdXNlIHRoYXQgdG8gYXV0 aGVudGljYXRlDQogbWUuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+TXkgQVMg bWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVjYXVzZSB0aGUgbVRMUy1vbmx5IEFTIG9taXR0ZWQg dG9rZW5fZW5kcG9pbnRfdXJpLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPk15 IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRv IGVuY291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlk ZSBhIHZhbHVlIGZvciBtdGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRvPzxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkkgZG9u4oCZdCBrbm93IHdoYXQgdGhhdCDigJxt4oCdIG1l YW5zLCBidXQgdGhleSB0b2xkIG1lIHRvIHVzZSBIVFRQUywgc28gSSBzaG91bGQgdXNlIHRoZSBv bmUgd2l0aCDigJx0bHPigJ0gaW4gaXRzIG5hbWUsIHJpZ2h0PzxvOnA+PC9vOnA+PC9saT48L29s Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ZZXMsIHlvdSBjYW4gd3JpdGUgbm9ybWF0aXZlIHRleHQgdGhhdCBhbnN3ZXJz IG1vc3Qgb2YgdGhlc2UuIEJ1dCB5b3XigJlsbCBoYXZlIHRvIGNsZWFybHkgY292ZXIgYSBsb3Qg b2Ygc2ltaWxhci1idXQtc2xpZ2h0bHktZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgYmUgdmVyeSBl eHBsaWNpdC4gQW5kIGltcGxlbWVudGVycyB3aWxsIHN0aWxsIGdldCBpdCB3cm9uZy4gVGhlIG1l dGFkYXRhIGNoYW5nZSBpbnRyb2R1Y2VzDQogb3Bwb3J0dW5pdGllcyBmb3IgY29uZnVzaW9uIGFu ZCBmYWlsdXJlIHRoYXQgZG8gbm90IGV4aXN0IG5vdywgYW5kIGZvcmNlcyB0aGVtIG9uIGV2ZXJ5 b25lIHdobyBzdXBwb3J0cyBtVExTLiBJbiBjb250cmFzdCwgdGhlIDMwNyByZWRpcmVjdCBpcyBv bmx5IHJlcXVpcmVkIHdoZW4gYW4gQVMgd2FudHMgdG8gc3VwcG9ydCBib3RoLCBhbmQgaXMgdW5h bWJpZ3VvdXMgaW4gaXRzIGJlaGF2aW9yIGFuZCBtZWFuaW5nLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElk ZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkJyaWFu IENhbXBiZWxsICZsdDtiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQ TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsg Jmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5HZW9yZ2UgRmxldGNo ZXIgJmx0O2dmZmxldGNoQGFvbC5jb20mZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10g TVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JdCBkb2Vzbid0IHNlZW0gbGlrZSB0aGF0IGNvbmZ1c2luZyBvciBsYXJn ZSBvZiBhIGNoYW5nZSB0byBtZSAtIGlmIHRoZSBjbGllbnQgaXMgZG9pbmcgTVRMUyBhbmQgdGhl IGdpdmVuIGVuZHBvaW50IGlzIHByZXNlbnQgaW4gYG10bHNfZW5kcG9pbnRzYCwgdGhlbiBpdCB1 c2VzIHRoYXQgb25lLiZuYnNwOyBPdGhlcndpc2UgaXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2lu dC4gSXQgZ2l2ZXMgYW4gQVMgYSBsb3Qgb2YNCiBmbGV4aWJpbGl0eSBpbiBkZXBsb3ltZW50IG9w dGlvbnMuIEkgcGVyc29uYWxseSB0aGluayBnZXR0aW5nIGEgMzA3IGFwcHJvYWNoIGRlcGxveWVk IGFuZCB3b3JraW5nIHdvdWxkIGJlIG1vcmUgY29tcGxpY2F0ZWQgYW5kIGVycm9yIHByb25lLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNlIGF0IHRoZSBtb21lbnQgYnV0IHRoZXJlIGFyZSBm b3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVzaCBmb3IgaW5jcmVhc2VkIHNlY3VyaXR5IGluIGdl bmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlwdCBjbGllbnRzIHVzZSB0aGUgY29kZSBmbG93LCB0 aGF0IHN1Z2dlc3QgaXQgd29uJ3QgYmUgdGVycmlibHkgdW51c3VhbCB0byBzZWUgYW4gQVMgdGhh dCB3YW50cyB0bw0KIHN1cHBvcnQgTVRMUyBjbGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGll bnRzIGF0IHRoZSBzYW1lIHRpbWUuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ3ZlIHBlcnNvbmFsbHkgd2F2ZXJlZCBiYWNrIGFuZCBmb3J0 aCBpbiB0aGlzIHRocmVhZCBvbiB3aGV0aGVyIG9yIG5vdCB0byBhZGQgdGhlIG5ldyBtZXRhZGF0 YSAob3Igc29tZXRoaW5nIGxpa2UgaXQpLiBXaXRoIG15IHJlYXNvbmluZyBlYWNoIHdheSBraW5k YSBleHBsYWluZWQgc29tZXdoZXJlIGJhY2sgaW4gdGhlIDQwIG9yIHNvIG1lc3NhZ2VzIHRoYXQg bWFrZSB1cCB0aGlzIHRocmVhZC4mbmJzcDsgQnV0IGl0DQogc2VlbXMgbGlrZSB0aGUgcm91Z2gg Y29uc2Vuc3VzIG9mIHRoZSBncm91cCBoZXJlIGlzIGluIGZhdm9yIG9mIGl0LiA8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6MTggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVu dCBhbmQgY29uZnVzaW5nIGNoYW5nZSB0byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5v cml0eSB1c2UgY2FzZS4gSeKAmW0gZ2V0dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJv dXQgdGhlIHRleHQgbmVlZGVkIHRvIGNsYXJpZnkgd2hlbg0KIHRoZSBBUyBzaG91bGQgcHJvdmlk ZSBgbXRsc19lbmRwb2ludHNgIGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGF0IHZl cnN1cyB1c2luZyBgdG9rZW5fZW5kcG9pbnQuYCBXaHkgaXMgdGhlIDMwNyBzdGF0dXMgY29kZSBp bnN1ZmZpY2llbnQgdG8gY292ZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgQVMgc3VwcG9ydHMg Ym90aCBtVExTIGFuZCBub24tbVRMUz88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50 aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwg RmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBNPGJyPg0KPGI+VG86IDwvYj5HZW9yZ2UgRmxldGNo ZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPm9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbT0FVVEgtV0ddIE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4g ZW5kcG9pbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5ZZXMsIHRoYXQgd291bGQgd29yay4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEZlYiAxLCAyMDE5 IGF0IDI6MjggUE0gR2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86 NDBhb2wuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhb2wuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj YSI+V2hhdCBpZiB0aGUgQVMgd2FudHMgdG8gT05MWSBzdXBwb3J0IE1UTFMgY29ubmVjdGlvbnMu IERvZXMgaXQgbm90IHNwZWNpZnkgdGhlIG9wdGlvbmFsICZxdW90O210bHNfZW5kcG9pbnRzJnF1 b3Q7IGFuZCBqdXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRhIHZhbHVlcz88L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxLzE1LzE5IDg6NDgg QU0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgd291bGQgZGVmaW5pdGVs eSBiZSBvcHRpb25hbCwgYXBvbG9naWVzIGlmIHRoYXQgd2Fzbid0IG1hZGUgY2xlYXIuIEl0J2Qg YmUgc29tZXRoaW5nIHRvIHRoZSBlZmZlY3Qgb2Ygb3B0aW9uYWwgZm9yIHRoZSBBUyB0byBpbmNs dWRlIGFuZCBjbGllbnRzIGRvaW5nIE1UTFMgd291bGQgdXNlIGl0IHdoZW4NCiBwcmVzZW50IGlu IEFTIG1ldGFkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFR1ZSwgSmFuIDE1LCAyMDE5IGF0IDI6MDQgQU0gRGF2ZSBUb25nZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51ayIgdGFyZ2V0PSJfYmxhbmsi PmRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss c2Fucy1zZXJpZiI+SSdtIGluIGZhdm91ciBvZiB0aGUgYG10bHNfZW5kcG9pbnRzYCBtZXRhZGF0 YSBwYXJhbWV0ZXIgLSBhbHRob3VnaCBpdCBzaG91bGQgYmUgb3B0aW9uYWwuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZQ0KIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg Y29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy Pg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBk aXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0 ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0 cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4u Jm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CC05C96533084449A1E2EDA0119BE5D2amazoncom_-- From nobody Fri Feb 1 16:37:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348C1312CB for ; Fri, 1 Feb 2019 16:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.841 X-Spam-Level: X-Spam-Status: No, score=-8.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_jjMuiIvf0M for ; Fri, 1 Feb 2019 16:37:41 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CBF1312ED for ; Fri, 1 Feb 2019 16:37:41 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x120YRcS036706; Sat, 2 Feb 2019 00:37:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=gsP3SlhcUTBm+2doONbuVih30DF42CCT2cH9McjyEoQ=; b=mr2tgHD/xv/F4wSztF3zt1biZIYz0ds2F0/syaDLCQOyHHYTZzeRXE5+GyyiNSRM4RLL c5Tatz9tJfvqPwv30sPs3AGbiXW6BL9CsPE9YF7ovgxGDEcdQSAdlndMgav8yj5ZZiz1 1/SmExerRJVb71cosvorWdPgBwROTY3ymsr1i+aRbKCmfkGGYhXOPfm5eZUaQDXF/QW6 INnRXurP+7ISiJLen5Zg3cYudME45ynx7n3DrLhU4GRw1XQF4sSEb9rYVosbhITmnh0Z FpYHNGar74bIRN3tmps2Ch8BbT5jGoNkVULpSW66LkFQy+mgLtb+YyfbQ56SiKNDaMKH cw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2q8g6rsc7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 02 Feb 2019 00:37:38 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x120bcDK003414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 2 Feb 2019 00:37:38 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x120bbGK008696; Sat, 2 Feb 2019 00:37:37 GMT Received: from dhcp-10-159-226-51.vpn.oracle.com (/10.159.226.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Feb 2019 16:37:36 -0800 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D06E427A-EC40-46DB-80A4-D96CBEEB3F6B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Feb 2019 16:37:34 -0800 In-Reply-To: Cc: Filip Skokan , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com> X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9154 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902020002 Archived-At: Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 00:37:55 -0000 --Apple-Mail=_D06E427A-EC40-46DB-80A4-D96CBEEB3F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, Thanks for clarifying. Given the browser uncertainty that happens with = optional configs and browsers, I agree with your suggestion of using = =E2=80=98mtls_endpoints=E2=80=99. I=E2=80=99m expecting this will be a big deal as we migrate apps and = clients. We have to make sure old clients keep working and don=E2=80=99t = do unexpected things. Because of this, returning the CertificateRequest = message may cause problems for legacy clients. It seems practical to = just to tell the MTLS clients where they will definitely work given they = will make changes to support MTLS certs anyway. Thanks. Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 1, 2019, at 3:26 PM, Brian Campbell = wrote: >=20 > Yes client certificate authen can be made optional. In the optional = case the server still sends the CertificateRequest message during the = handshake which efficiently asks the client to present a cert. The = client send a cert or not at that point. In the optional case, the = server will continue with the connection even when no client cert is = presented. In the required case, the server will terminate the handshake = when no client cert is presented.=20 >=20 > So yes, optional is possible. The potential problem is the (sometimes = pretty bad and/or confusing) UI that browsers will present to the = end-user anytime the CertificateRequest message is sent by the server in = the handshake. And that message is sent in the optional case and the = required case. Giving an AS a way to avoid the potentially bad UX for = the end user is the impetus behind this whole discussion.=20 >=20 > On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt > wrote: > Brian, >=20 > Let me turn this around. Is it possible for a single endpoint to have = MTLS clients (mutual auth) and bearer clients (server auth TLS)? =20 >=20 > I had thought that client certificate authen can be made optional, but = I must confess I=E2=80=99m confused as to how optionality works in TLS = when it comes to client certificate authentication. >=20 > If we have to do multiple endpoints for the APIs and/or the token = endpoints, we have to send clients to the correct endpoints to make TLS = set up correctly. If this is the case, I think Brian is right=E2=80=94we= need a parameter. >=20 > Phil >=20 > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com = phil.hunt@o= racle.com >=20 >> On Feb 1, 2019, at 1:43 PM, Brian Campbell = > wrote: >>=20 >> I guess I'm not clear what you are driving at.=20 >>=20 >> On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt > wrote: >> That way works. But one of the modes on most tls terminators is = client cert optional. >>=20 >> This works ok when you want dual mode to support bearer and mtls for = apps (e.g. mobile) because the client will decide to use MTLS. With = browsers, they only use it if forced. >>=20 >> Phil >>=20 >> Oracle Corporation, Cloud Security and Identity Architect >> @independentid >> www.independentid.com = phil.hunt@o= racle.com >>=20 >>> On Feb 1, 2019, at 1:14 PM, Brian Campbell = > wrote: >>>=20 >>> The server has to ask during the handshake for a client to send a = cert.=20 >>>=20 >>> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt > wrote: >>> If a client attempts to force mtls would typical tls terminators = accept it enough to redirect? >>>=20 >>> My worry is how optionality works in browsers. It seems like they = have to hit an mtls required endpoint before they reliably use a client = cert.=20 >>>=20 >>> Phil >>>=20 >>> On Feb 1, 2019, at 12:56 PM, Brian Campbell = > wrote: >>>=20 >>>> It would be more a client having reached a non-MTLS endpoint and is = 307'd to an MTLS enabled endpoint.=20 >>>>=20 >>>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt > wrote: >>>> I was a bit confused by how the 307 would work. >>>>=20 >>>> To confirm, Is the client having reached an MTLS optional endpoint = being redirected to an MTLS mandatory endpoint if the AT (or a cookie) = is detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to make the = browser invoke MTLS? >>>>=20 >>>> Phil >>>>=20 >>>> Oracle Corporation, Cloud Security and Identity Architect >>>> @independentid >>>> www.independentid.com = phil.hunt@o= racle.com >>>>=20 >>>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell = > wrote: >>>>>=20 >>>>> I'm finally getting around to working on the document updates = (there's quite a few things that came out of AD review too). As far as = the issue in this thread goes though, I'm leaning towards adding = "mtls_endpoints" as a new metadata parameter. Maybe mention that a 307 = might happen but it'd be more of a considerations type text.=20 >>>>>=20 >>>>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell = > wrote: >>>>> I guess I should have also said or been more straightforward in = saying that I don't particularly want to try and discuss/define the use = of a 307 in the document.=20 >>>>>=20 >>>>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan > wrote: >>>>> I don't know that the use of 307 would need to be discussed in the = document itself.=20 >>>>>=20 >>>>> If the clients are supposed to be ready for this, yeah. For = instance, my client software by default doesn't follow redirects, in = order for it to be ready for mtls client authentication i'd have to know = 307 is a possibility and whitelist 307 as a valid code to be followed. >>>>>=20 >>>>> S pozdravem, >>>>> Filip Skokan >>>>>=20 >>>>>=20 >>>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell = > wrote: >>>>> I don't know that the use of 307 would need to be discussed in the = document itself.=20 >>>>>=20 >>>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan > wrote: >>>>> I'm in favour of both 307 and metadata.=20 >>>>> case 307 - I don't recall ever encountering an http client = software that wouldn't have an option for following redirects, same for = a server side frameworks not having the option to do a 307 response with = a location header. >>>>> case 307 - Relying purely on a new metadata doesn't help in the = scenario David put forth earlier about clients not being aware of using = mtls, a device policy of sorts. >>>>> case metadata - no second request if the client knows there's an = mtls endpoint it should use. >>>>> Maybe we should specify both as optional for an AS to deploy and a = client to be ready for? >>>>>=20 >>>>> S pozdravem, >>>>> Filip Skokan >>>>>=20 >>>>>=20 >>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge = > = wrote: >>>>> I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional. >>>>> While a 307 redirect seems kind of elegant I worry, like you, = that not all clients would handle it appropriately. >>>>> There would probably need to be an error defined for clients who = attempt to use `tls_client_auth` at the regular endpoint. >>>>>=20 >>>>> Dave >>>>>=20 >>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell = > wrote: >>>>> Trying to summarize things somewhat here and focus in hopefully = towards some decision. There's basically an idea on the table to add an = AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a = JSON object which contains endpoints that a client doing MTLS would use = rather than the regular endpoints. A straw-man example might look like = this (with mtls_endpoints being that new parameter). >>>>>=20 >>>>> { =20 >>>>> "issuer":"https://server.example.com = ", >>>>> "authorization_endpoint":"https://server.example.com/authz = ", >>>>> "token_endpoint":"https://server.example.com/token = ", >>>>> "token_endpoint_auth_methods_supported":[ = "client_secret_basic","tls_client_auth", "none"], >>>>> "userinfo_endpoint":"https://server..example.com/userinfo = ", >>>>> "revocation_endpoint":"https://server.example.com/revo = ", >>>>> "jwks_uri":"https://server.example.com/jwks.json = ", >>>>> "mtls_endpoints":{ =20 >>>>> "token_endpoint":"https://mtls.example.com/token = ", >>>>> "userinfo_endpoint":"https://mtls = .example.com/userinfo = ", >>>>> "revocation_endpoint":"https://mtls = ..example.com/revo = " >>>>> } >>>>> } >>>>>=20 >>>>> The idea behind this is that "regular" clients (those not doing = MTLS) will use the regular endpoints. And only the host/port of the = endpoints listed in mtls_endpoints will be set up to request TLS client = certificates during handshake.. Thus any potential impact of the = CertificateRequest message being sent in the TLS handshake can be = avoided for all the other regular clients that are not going to do MTLS = - including and most importantly in-browser javascript clients where = there can be less than desirable UI presented to the end-user.=20 >>>>>=20 >>>>> The arguments in favor of that seem to be basically that it allows = for AS deployments to support MTLS while still allowing for a "not = broken" UX for end-users of clients (in-browser javascript clients) that = aren't doing MTLS. And that it's not much in terms of adding to the spec = and complexity of implementations.=20 >>>>>=20 >>>>> The arguments against it seem to be 1) the bad UX isn't really = that bad and/or will only happen to a subset of users 2) there are other = things that can be done, such as 307ing or renegotiation/post-handshake = client auth, to avoid the bad UX.=20 >>>>>=20 >>>>> Speaking for myself, I'm kinda torn on it.=20 >>>>>=20 >>>>> I will say that, in addition to the folks that have pointed out = that renegotiation just isn't possible in some cases, my experience = trying to do something like that in the past was not particularly = successful or encouraging. That could have been my fault, of course, but = still seems a relevant data point. I also have my doubts about the = actual difficulty of getting an AS to issue a 307 like response for = requests based on the calling client and the likelihood that some/all = OAuth client software would handle it appropriately.=20 >>>>> =20 >>>>>=20 >>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite = > = wrote: >>>>>=20 >>>>>=20 >>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden = > wrote: >>>>> >=20 >>>>> > On 9 Jan 2019, at 05:54, David Waite = > = wrote: >>>>> >>=20 >>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell = > wrote: >>>>> >>>=20 >>>>> >> >>>>> >>=20 >>>>> >>> All of that is meant as an explanation of sorts to say that I = think that things are actually okay enough as is and that I'd like to = retract the proposal I'd previously made about the MTLS draft = introducing a new AS metadata parameter. It is admittedly interesting = (ironic?) that Neil sent a message in support of the proposal as I was = writing this. It did give me pause but ultimately didn't change my = opinion that it's not worth it to add this new AS metadata parameter. >>>>> >>=20 >>>>> >> Note that the AS could make a decision based on the token = endpoint request - such as a policy associated with the =E2=80=9Cclient_id= =E2=80=9D, or via a parameter in the ilk of =E2=80=9Cclient_assertion_type= =E2=80=9D indicating MTLS was desired by this public client = installation. The AS could then to TLS 1.2 renegotiation, 1.3 = post-handshake client authentication, or even use 307 temporary = redirects to another token endpoint to perform mutual authentication. >>>>> >=20 >>>>> > Renegotiation is an intriguing option, but it has some practical = difficulties. Our AS product runs in a Java servlet container, where it = is pretty much impossible to dynamically trigger renegotiation without = accessing private internal APIs of the container. I also don=E2=80=99t = know how you could coordinate this in the common scenario where TLS is = terminated at a load balancer/reverse proxy? >>>>> >=20 >>>>> > A 307 redirect could work though as the server will know if the = client either uses mTLS for client authentication or has indicated that = it wants certificate-bound access tokens, so it can redirect to a = mTLS-specific endpoint in those cases. >>>>>=20 >>>>> Agreed. There are trade-offs for both. As you say, I don=E2=80=99t = know a way to have say a custom error code or WWW-Authenticate challenge = to trigger renegotiation on the reverse proxy - usually this is just a = static, location-based directive. >>>>>=20 >>>>> >=20 >>>>> >> Both the separate metadata url and a = =E2=80=9Cclient_assertion_type=E2=80=9D-like indicator imply that the = client has multiple forms of authentication and is choosing to use MTLS. = The URL in particular I=E2=80=99m reluctant to add support for, because = I see it more likely a client would use MTLS without knowing it (via a = device-level policy being applied to a public web or native app) than = the reverse, where a single client (represented by a single client_id) = is dynamically picking between forms of authentication. >>>>> >=20 >>>>> > That=E2=80=99s an interesting observation. Can you elaborate on = the sorts of device policy you are talking about? I am aware of e.g. = mobile device management being used to push client certificates to iOS = devices, but I think these are only available in Safari. >>>>>=20 >>>>> The primary use is to set policy to rely on device level = management in controlled environments like enterprises when available. = So an AS may try to detect a client certificate as an indicator of a = managed device, use that to assume a device with certain device-level = authentication, single user usage, remote wipe, etc. characteristics, = and decide that it can reduce user authentication requirements and/or = expose additional scopes. >>>>>=20 >>>>> On more thought, this is typically done as part of the user agent = hitting the authorization endpoint, as a separate native application may = be interacting with the token endpoint, and in some operating systems = the application=E2=80=99s network connections do not utilize (and may = not have access to) the system certificate store. >>>>>=20 >>>>> In terms of user agents, I believe you can perform similar = behavior (managed systems using client certificates on user agents = transparently) on macOS, Windows, Chrome, and Android devices, Chrome = (outside iOS) typically inherits device level policy. Firefox on desktop = I assume you can do that in limited fashion as well. >>>>>=20 >>>>> -DW >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.... If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_D06E427A-EC40-46DB-80A4-D96CBEEB3F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian,

Thanks for clarifying. Given the browser uncertainty that = happens with optional configs and browsers, I agree with = your suggestion of using =E2=80=98mtls_endpoints=E2=80=99.

I=E2=80=99m expecting = this will be a big deal as we migrate apps and clients. We have to make = sure old clients keep working and don=E2=80=99t do unexpected things. = Because of this, returning the CertificateRequest message may cause = problems for legacy clients. It seems practical to just to tell the MTLS = clients where they will definitely work given they will make changes to = support MTLS certs anyway.

Thanks.

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb 1, 2019, at 3:26 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Yes = client certificate authen can be made optional. In the optional case the = server still sends the CertificateRequest message during the handshake = which efficiently asks the client to present a cert. The client send a = cert or not at that point. In the optional case, the server will = continue with the connection even when no client cert is presented. In = the required case, the server will terminate the handshake when no = client cert is presented.

So yes, optional is = possible. The potential problem is the (sometimes pretty bad and/or = confusing) UI that browsers will present to the end-user anytime the = CertificateRequest message is sent by the server in the handshake. And = that message is sent in the optional case and the required case. Giving = an AS a way to avoid the potentially bad UX for the end user is the = impetus behind this whole discussion.
On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Brian,

Let me turn this around. Is it possible = for a single endpoint to have MTLS clients (mutual auth) and bearer = clients (server auth TLS)?  

I had thought that client certificate = authen can be made optional, but I must confess I=E2=80=99m confused as = to how optionality works in TLS when it comes to client certificate = authentication.

If we have to do multiple endpoints for the APIs and/or the = token endpoints, we have to send clients to the correct endpoints to = make TLS set up correctly.   If this is the case, I think Brian is = right=E2=80=94we need a parameter.

<= div style=3D"overflow-wrap: break-word;" class=3D"">
Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb 1, 2019, at 1:43 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I guess I'm not clear what you are driving = at. <= br class=3D"">

On Fri, Feb 1, = 2019 at 2:32 PM Phil Hunt <phil.hunt@oracle.com> wrote:
That = way works. But one of the modes on most tls terminators is client cert = optional.

This = works ok when you want dual mode to support bearer and mtls for apps = (e.g. mobile) because the client will decide to use MTLS.  With = browsers, they only use it if forced.

<= div class=3D"">
Phil

Oracle Corporation, Cloud Security and Identity = Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb = 1, 2019, at 1:14 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

The server has to ask during the handshake = for a client to send a cert. 

On Fri, Feb 1, = 2019 at 2:12 PM Phil Hunt <phil.hunt@oracle.com> wrote:
If a = client attempts to force mtls would typical tls terminators accept it = enough to redirect?

My= worry is how optionality works in browsers. It seems like they have to = hit an mtls required endpoint before they reliably use a client = cert. 

Phil

On Feb 1, 2019, at 12:56 PM, Brian = Campbell <bcampbell@pingidentity.com> = wrote:

It = would be more a client having reached a non-MTLS endpoint and is 307'd = to an MTLS enabled endpoint. 

On Fri, Feb = 1, 2019 at 1:40 PM Phil Hunt <phil.hunt@oracle.com> wrote:
I was a bit confused = by how the 307 would work.

To confirm, Is the client having reached an MTLS optional = endpoint being redirected to an MTLS mandatory endpoint if the AT (or a = cookie) is detected to have a =E2=80=9Ccnf=E2=80=9D claim in order to = make the browser invoke MTLS?

<= div class=3D"">
Phil

Oracle Corporation, Cloud Security and Identity = Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Feb = 1, 2019, at 11:56 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

<= div class=3D"">
I'm= finally getting around to working on the document updates (there's = quite a few things that came out of AD review too). As far as the issue = in this thread goes though, I'm leaning towards adding "mtls_endpoints" = as a new metadata parameter. Maybe mention that a 307 might happen but = it'd be more of a considerations type text. 

On Wed, Jan = 16, 2019 at 5:52 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
I guess I = should have also said or been more straightforward in saying that I = don't particularly want to try and discuss/define the use of a 307 in = the document. 

On Tue, Jan 15, 2019 = at 6:59 AM Filip Skokan <panva.ip@gmail.com> wrote:
I don't know that the use of 307 would need to be discussed = in the document itself. 

If the clients are supposed to be ready = for this, yeah. For instance, my client software by default doesn't = follow redirects, in order for it to be ready for mtls client = authentication i'd have to know 307 is a possibility and whitelist 307 = as a valid code to be followed.

S pozdravem,
Filip Skokan


On = Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
I don't = know that the use of 307 would need to be discussed in the document = itself. 

On Tue, Jan 15, 2019 = at 2:30 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'm in favour of both 307 and metadata. 
  • case 307 - I don't recall ever = encountering an http client software that wouldn't have an option for = following redirects, same for a server side frameworks not having the = option to do a 307 response with a location header.
    • case 307 - Relying purely on a new metadata doesn't help in = the scenario David put forth earlier about clients not being aware of = using mtls, a device policy of sorts.
  • case metadata - no second request if the client knows there's = an mtls endpoint it should use.
Maybe we = should specify both as optional for an AS to deploy and a client to be = ready for?

S pozdravem,
Filip = Skokan


On Tue, Jan 15, 2019 = at 10:05 AM Dave Tonge <dave.tonge@momentumft.co.uk> = wrote:
I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.
While a 307 redirect seems kind of elegant I worry, like = you,  that not all clients would handle it = appropriately.
There would probably need = to be an error defined for clients who attempt to use `tls_client_auth` = at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at = 22:29, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Trying = to summarize things somewhat here and focus in hopefully towards some = decision. There's basically an idea on the table to add an AS metadata = parameter to the draft-ietf-oauth-mtls doc that would be a JSON object = which contains endpoints that a client doing MTLS would use rather than = the regular endpoints. A straw-man example might look like this (with = mtls_endpoints being that new parameter).

{  
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[ = "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server..example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{  
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls..example.com/revo"
  }
}

The idea behind this is = that "regular" clients (those not doing MTLS) will use the regular = endpoints. And only the host/port of the endpoints listed in = mtls_endpoints will be set up to request TLS client certificates during = handshake.. Thus any potential impact of the CertificateRequest message = being sent in the TLS handshake can be avoided for all the other regular = clients that are not going to do MTLS - including and most importantly = in-browser javascript clients where there can be less than desirable UI = presented to the end-user. 

The arguments in favor of that seem to = be basically that it allows for AS deployments to support MTLS while = still allowing for a "not broken" UX for end-users of clients = (in-browser javascript clients) that aren't doing MTLS. And that it's = not much in terms of adding to the spec and complexity of = implementations. 

The arguments against it seem to be 1) = the bad UX isn't really that bad and/or will only happen to a subset of = users 2) there are other things that can be done, such as 307ing or = renegotiation/post-handshake client auth, to avoid the bad UX. 

Speaking for myself, I'm kinda torn on = it. 

I will say that, in addition to the = folks that have pointed out that renegotiation just isn't possible in = some cases, my experience trying to do something like that in the past = was not particularly successful or encouraging. That could have been my = fault, of course, but still seems a relevant data point. I also have my = doubts about the actual difficulty of getting an AS to issue a 307 like = response for requests based on the calling client and the likelihood = that some/all OAuth client software would handle it appropriately. 
 

On = Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote:


> On = Jan 11, 2019, at 3:32 AM, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> On 9 Jan 2019, at 05:54, = David Waite <david@alkaline-solutions.com> = wrote:
>> 
>>> On Dec 28, 2018, = at 3:55 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>>> 
>> <snip>
>> 
>>> All of that is = meant as an explanation of sorts to say that I think that things are = actually okay enough as is and that I'd like to retract the proposal I'd = previously made about the MTLS draft introducing a new AS metadata = parameter. It is admittedly interesting (ironic?) that Neil sent a = message in support of the proposal as I was writing this. It did give me = pause but ultimately didn't change my opinion that it's not worth it to = add this new AS metadata parameter.
>> 
>> Note that the AS = could make a decision based on the token endpoint request - such as a = policy associated with the =E2=80=9Cclient_id=E2=80=9D, or via a = parameter in the ilk of =E2=80=9Cclient_assertion_type=E2=80=9D = indicating MTLS was desired by this public client installation. The AS = could then to TLS 1.2 renegotiation, 1.3 post-handshake client = authentication, or even use 307 temporary redirects to another token = endpoint to perform mutual authentication.
> 
> Renegotiation is an = intriguing option, but it has some practical difficulties. Our AS = product runs in a Java servlet container, where it is pretty much = impossible to dynamically trigger renegotiation without accessing = private internal APIs of the container. I also don=E2=80=99t know how = you could coordinate this in the common scenario where TLS is terminated = at a load balancer/reverse proxy?
> 
> A 307 redirect could work = though as the server will know if the client either uses mTLS for client = authentication or has indicated that it wants certificate-bound access = tokens, so it can redirect to a mTLS-specific endpoint in those = cases.

Agreed. There are trade-offs for = both. As you say, I don=E2=80=99t know a way to have say a custom error = code or WWW-Authenticate challenge to trigger renegotiation on the = reverse proxy - usually this is just a static, location-based = directive.

> 
>> Both the separate = metadata url and a =E2=80=9Cclient_assertion_type=E2=80=9D-like = indicator imply that the client has multiple forms of authentication and = is choosing to use MTLS. The URL in particular I=E2=80=99m reluctant to = add support for, because I see it more likely a client would use MTLS = without knowing it (via a device-level policy being applied to a public = web or native app) than the reverse, where a single client (represented = by a single client_id) is dynamically picking between forms of = authentication.
> 
> That=E2=80=99s an = interesting observation. Can you elaborate on the sorts of device policy = you are talking about? I am aware of e.g. mobile device management being = used to push client certificates to iOS devices, but I think these are = only available in Safari.

The primary use = is to set policy to rely on device level management in controlled = environments like enterprises when available. So an AS may try to detect = a client certificate as an indicator of a managed device, use that to = assume a device with certain device-level authentication, single user = usage, remote wipe, etc. characteristics, and decide that it can reduce = user authentication requirements and/or expose additional scopes.

On more thought, this is typically done as = part of the user agent hitting the authorization endpoint, as a separate = native application may be interacting with the token endpoint, and in = some operating systems the application=E2=80=99s network connections do = not utilize (and may not have access to) the system certificate = store.

In terms of user agents, I believe = you can perform similar behavior (managed systems using client = certificates on user agents transparently) on macOS, Windows, Chrome, = and Android devices, Chrome (outside iOS) typically inherits device = level policy. Firefox on desktop I assume you can do that in limited = fashion as well.

-DW

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited....  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
<= /div>
CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

= --Apple-Mail=_D06E427A-EC40-46DB-80A4-D96CBEEB3F6B-- From nobody Fri Feb 1 23:39:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313D5124BF6 for ; Fri, 1 Feb 2019 23:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoC7SNzcWc5h for ; Fri, 1 Feb 2019 23:39:46 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B97128766 for ; Fri, 1 Feb 2019 23:39:44 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id m22so8372828wml.3 for ; Fri, 01 Feb 2019 23:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sj5VU7mA+jn2r5jt5gxVhahV8Lv9QWhmkX+JZ59cSm8=; b=IrqrjX5xa6qGgUQiZ9y4ttNoRdgVQebFvFMyxahCgq4knMDTsVxCUT6OzGuZ6/b+1q 6Oqmt2CkM1dUQtwT6QvaCcyIxbk2i4FO3jn3ADNprYd2dAXUWSElZ6XA7cWZLPcL/R3m s151mRqc+A6gzyNRc+uueo/HzLKEIBkJLd1t4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sj5VU7mA+jn2r5jt5gxVhahV8Lv9QWhmkX+JZ59cSm8=; b=gYSvPnvoqql68GjzLW41zJGNUJsSesbUoCaWMGg+VXvYbLiQKXtBX0qP5iAT26woyp 2zX9lOR4Mzxs6324Wkpb3zRYnE/q3Nww18cyUotAhPwykPB5wrBOp0Mm6n+VpLVbv4YV cB7x34f2t/mFiSSkyKGSEr9rrlVg0Qyn2t3pLns4EQwsZ9bfsvs8QFf2GndxIIo13miG fkMfSklAgefoFg9Lbnc4HKhovChCGQiv9klVE1hTu+QiUcCWtfRv2dvjfbKbJNEKm/Ah QXEqgHAFusUxNzGbN4aE3t3H9cc54T2niZWrSzhPLCyVmUnpv+yLGYqBOTQVW6gF4wLL PH1w== X-Gm-Message-State: AHQUAubmSM4cpttC/htKVlBDzYKgPgdnrnzApbfDaNXl6RlIg48l0VuS Ibgi8RI7u4CdnemvDtjpyxoX3HSu4bg= X-Google-Smtp-Source: AHgI3IbYhn+Ra5DgPbNfbQoH1Y8b0g6KtoYD6bwEmuF8o4/bkesRsvlDFEj5KRFMGsY3I9FTrE/A+w== X-Received: by 2002:a1c:8851:: with SMTP id k78mr5580784wmd.51.1549093182361; Fri, 01 Feb 2019 23:39:42 -0800 (PST) Received: from [192.168.1.65] (148.132.93.209.dyn.plus.net. [209.93.132.148]) by smtp.gmail.com with ESMTPSA id m6sm6814412wrv.24.2019.02.01.23.39.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 23:39:41 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-CBE4A511-ED73-4066-BD16-4B57A84617EE Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Sat, 2 Feb 2019 07:39:39 +0000 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> To: "Richard Backman, Annabelle" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 07:39:49 -0000 --Apple-Mail-CBE4A511-ED73-4066-BD16-4B57A84617EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we go down the 307 route, shouldn=E2=80=99t it rather be a 308 (permanent= ) redirect? It seems unnecessary for the client to keep trying the original e= ndpoint or have to remember cache-control/expires timeouts.=20 =E2=80=94 Neil > On 2 Feb 2019, at 00:03, Richard Backman, Annabelle wrote: >=20 > Confusion from the AS=E2=80=99s perspective: > If I only support mTLS, do I need to include both token_endpoint_uri and m= tls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng? > What if I only support mTLS for the token endpoint, but not revocation or u= ser info? > How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints? > I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled d= evice_authorization_endpoint under mtls_endpoints? > =20 > Confusion from the client=E2=80=99s perspective: > As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyt= hing about mTLS, but the IT admins installed client certs in their users=E2=80= =99 browsers and the AS expects to use that to authenticate me. > My AS metadata parser crashed because the mTLS-only AS omitted token_endpo= int_uri. > My AS metadata parser crashed because it didn=E2=80=99t expect to encounte= r a JSON object as a parameter value. > The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what d= o I do? > I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me= to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right? > =20 > Yes, you can write normative text that answers most of these. But you=E2=80= =99ll have to clearly cover a lot of similar-but-slightly-different scenario= s and be very explicit. And implementers will still get it wrong. The metada= ta change introduces opportunities for confusion and failure that do not exi= st now, and forces them on everyone who supports mTLS. In contrast, the 307 r= edirect is only required when an AS wants to support both, and is unambiguou= s in its behavior and meaning. > =20 > --=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Brian Campbell > Date: Friday, February 1, 2019 at 3:17 PM > To: "Richard Backman, Annabelle" > Cc: George Fletcher , oauth > Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients us= ing the token endpoint > =20 > It doesn't seem like that confusing or large of a change to me - if the cl= ient is doing MTLS and the given endpoint is present in `mtls_endpoints`, th= en it uses that one. Otherwise it uses the regular endpoint. It gives an AS= a lot of flexibility in deployment options. I personally think getting a 30= 7 approach deployed and working would be more complicated and error prone.=20= > =20 > It is a minority use case at the moment but there are forces in play, like= the push for increased security in general and to have javascript clients u= se the code flow, that suggest it won't be terribly unusual to see an AS tha= t wants to support MTLS clients and javascript/spa clients at the same time.= > =20 > I've personally wavered back and forth in this thread on whether or not to= add the new metadata (or something like it). With my reasoning each way kin= da explained somewhere back in the 40 or so messages that make up this threa= d. But it seems like the rough consensus of the group here is in favor of i= t. > =20 > =20 > =20 > =20 > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: > This strikes me as a very prominent and confusing change to support what s= eems to be a minority use case. I=E2=80=99m getting a headache just thinking= about the text needed to clarify when the AS should provide `mtls_endpoints= ` and when the client should use that versus using `token_endpoint.` Why is t= he 307 status code insufficient to cover the case where a single AS supports= both mTLS and non-mTLS? > =20 > --=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Brian Campbell > Date: Friday, February 1, 2019 at 1:31 PM > To: George Fletcher > Cc: oauth > Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoi= nt > =20 > Yes, that would work.=20 > =20 > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: > What if the AS wants to ONLY support MTLS connections. Does it not specify= the optional "mtls_endpoints" and just use the normal metadata values? >=20 > On 1/15/19 8:48 AM, Brian Campbell wrote: > It would definitely be optional, apologies if that wasn't made clear. It'd= be something to the effect of optional for the AS to include and clients do= ing MTLS would use it when present in AS metadata. > =20 > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge w= rote: > I'm in favour of the `mtls_endpoints` metadata parameter - although it sho= uld be optional. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf..org/mailman/listinfo/oauth > =20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-CBE4A511-ED73-4066-BD16-4B57A84617EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If w= e go down the 307 route, shouldn=E2=80=99t it rather be a 308 (permanent) re= direct? It seems unnecessary for the client to keep trying the original endp= oint or have to remember cache-control/expires timeouts. 

=E2=80=94 Neil
On 2 Feb 2019, at 00:03, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.or= g> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri an= d mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty s= tring?
  2. What if I only support mTLS for the token endpoin= t, but not revocation or user info?
  3. How do I specify aut= hentication methods for the mTLS token endpoint? Does token_endpoint_auth_me= thods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2= =80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_= authorization_endpoint under mtls_endpoints?

 

Confusion from the client=E2=80=99s perspective:=

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know a= nything about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only= AS omitted token_endpoint_uri.
  3. My AS metadata parser cr= ashed because it didn=E2=80=99t expect to encounter a JSON object as a param= eter value.
  4. The mTLS-only AS didn=E2=80=99t provide a va= lue for mtls_endpoints, what do I do?
  5. I don=E2=80=99t kn= ow what that =E2=80=9Cm=E2=80=9D means, but they told me to use HTTPS, so I s= hould use the one with =E2=80=9Ctls=E2=80=9D in its name, right?<= /li>

 

Yes, you can write normative text that answers most o= f these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sligh= tly-different scenarios and be very explicit. And implementers will still ge= t it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces t= hem on everyone who supports mTLS. In contrast, the 307 redirect is only req= uired when an AS wants to support both, and is unambiguous in its behavior a= nd meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From:= Brian Campbell <= bcampbell=3D= 40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@= aol.com>, oauth <oauth@ietf.org<= /a>>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clien= ts using the token endpoint

 

It doesn't seem like that confusing or large of a cha= nge to me - if the client is doing MTLS and the given endpoint is present in= `mtls_endpoints`, then it uses that one.  Otherwise it uses the regula= r endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approac= h deployed and working would be more complicated and error prone. =

 

It is a minority use case at the moment but there are= forces in play, like the push for increased security in general and to have= javascript clients use the code flow, that suggest it won't be terribly unu= sual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread= on whether or not to add the new metadata (or something like it). With my r= easoning each way kinda explained somewhere back in the 40 or so messages th= at make up this thread.  But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

This strikes me as a very prominent and confusing change to support w= hat seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that v= ersus using `token_endpoint.` Why is the 307 status code insufficient to cov= er the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.or= g>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token e= ndpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf= .org> wrote:

What if the AS wants to ONLY support= MTLS connections. Does it not specify the optional "mtls_endpoints" and jus= t use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear= . It'd be something to the effect of optional for the AS to include and clie= nts doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk&= gt; wrote:

I'm i= n favour of the `mtls_endpoints` metadata parameter - although it should be o= ptional.


CONFIDENTIALITY NOTICE: This email may c= ontain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is stri= ctly prohibited..  If you have received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you. 

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

 


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-CBE4A511-ED73-4066-BD16-4B57A84617EE-- From nobody Mon Feb 4 05:28:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975EB130E27 for ; Mon, 4 Feb 2019 05:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q50q77J9W7S0 for ; Mon, 4 Feb 2019 05:28:04 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E9E128CF3 for ; Mon, 4 Feb 2019 05:28:04 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id z7so21012240iti.0 for ; Mon, 04 Feb 2019 05:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=faFTp51x3G9uEz1LiIyAaIHtOMvMqpnBcQX1iGa+8JQ=; b=QLgfLJuOrwdEBfH4jspPNxyy1X6Sa3k5GS/VNp83xXVoe3AtNk7kMciTvBIQR67Pi1 hOdVB3A34OGqhpuUUBVBppjWO7+X0aC/NA8UsO1toYtK9sJ4nhMub/9ZNNtfQGX9dbFP jCpCEuRXm0MjEzrFMI09uO7jEJuDnHV3zZETY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=faFTp51x3G9uEz1LiIyAaIHtOMvMqpnBcQX1iGa+8JQ=; b=GbU5ZXJnfKfmRxGfszT4RgBmMiuTuVZl42f50B4YTqdQKo94U51/nYFXTdBxTfCQeP 4MJwqO/QOtYEQqELMZCQr72phkAOOsLMaDbHD31YrK9903ToYwtXtr/4RwqHFwyd1sUw FT24x84tL3fCMfF2aUELxMg5BFDh1NREiC5647TmF9cGagyWbCbxD6I7ypnn9Ynp2D2p Sx7PdkN4LaCvu1FPvlvLje8RDMgAANRT+ZjEerBgfm0E+nRXhULgc2wBwJwvEmtmw/Fi y3bQCtfhrwTxcRKXXXMdL4q/iEpnZBImQNGzl8IttrtMQzU+ALk1VWPbHrO2WL8x2HCr V1Mg== X-Gm-Message-State: AHQUAubGXN4arHhHeQQU5c/xGvuyZxO7pxBmifuMOfJwJWAjZvCP6PZb R1OGuuQqd7EV9RO8qSjavo7+2tqSr/da1lNA1qugOBwaPAexkBbGEDz8uQ6WZHGo/Waz40mFV5S LgjRu67cj4+yzNw== X-Google-Smtp-Source: AHgI3IYbhQOuTSNaJwaUdzsxF7YfmQwcFYVFSxoD6jvFv1DJdZqhXb3uw4VvXMlvEG1WaE70jzwzIYm9ku9kMAJu3Mw= X-Received: by 2002:a6b:b408:: with SMTP id d8mr2682795iof.138.1549286883136; Mon, 04 Feb 2019 05:28:03 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> In-Reply-To: From: Brian Campbell Date: Mon, 4 Feb 2019 06:27:35 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: George Fletcher , oauth Content-Type: multipart/alternative; boundary="000000000000534537058111769b" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 13:28:07 -0000 --000000000000534537058111769b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted. All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid. And I'd really like to post an update to this draft about a month or two ago. On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle wrote: > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Date: *Friday, February 1, 2019 at 3:17 PM > *To: *"Richard Backman, Annabelle" > *Cc: *George Fletcher , oauth > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher <40aol.com@dmarc..ietf.org>> > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000534537058111769b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Those points of confusion strike me as somewhat hypothetical or h= yperbolic. But your general point is taken and your position of being anti = additional metadata on this issue is noted.

=
All of which leaves me a bit uncertain about how to proceed. The= re seem to be a range of opinions on this point and gauging consensus is pr= oving elusive for me. That's confounded by my own opinion on it being s= omewhat fluid.

And I'd really like to post= an update to this draft about a month or two ago.






On Fri, Feb 1, 2019 at 5:03 PM Rich= ard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
<= /div>

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to = include both token_endpoint_uri and mtls_endpoints? Should I omit token_end= point_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, = but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token en= dpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTL= S endpoints?
  4. I=E2= =80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device= _authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a publi= c client, and don=E2=80=99t know anything about mTLS, but the IT admins ins= talled client certs in their users=E2=80=99 browsers and the AS expects to = use that to authenticate me.
  2. My AS metadata= parser crashed because the mTLS-only AS omitted token_endpoint_uri.=
  3. My AS metadata parser cra= shed because it didn=E2=80=99t expect to encounter a JSON object as a param= eter value.
  4. The mTL= S-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I do?<= u>
  5. I don=E2=80=99t kno= w what that =E2=80=9Cm=E2=80=9D means, but they told me to use HTTPS, so I = should use the one with =E2=80=9Ctls=E2=80=9D in its name, right?=

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still= get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces = them on everyone who supports mTLS. In contrast, the 307 redirect is only r= equired when an AS wants to support both, and is unambiguous in its behavio= r and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the= regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approa= ch deployed and working would be more complicated and error prone.=C2=A0=

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terri= bly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time. <= u>

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so mess= ages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000534537058111769b-- From nobody Mon Feb 4 05:29:12 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2309130E0A for ; Mon, 4 Feb 2019 05:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q85mwNh6RkVV for ; Mon, 4 Feb 2019 05:29:07 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FA9128CF3 for ; Mon, 4 Feb 2019 05:29:07 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id m62so20956866ith.5 for ; Mon, 04 Feb 2019 05:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MIcHnW4eJjUYwliG2wv5Pf49HTTVsk7PMsN+fiYMhWg=; b=oecvqhCUaRwfkbDLr0vqUFR8nf4TvcYAu0iG1YB6swnnTvaeJtfaylNhlIDci4NK3K RR6K+7cSiVtwm8jpxX0wM9lFHpFtTqImG/ce3LtZxwhsUWeH2FQDyyVxx5oU6/EU4ekI 6XYunZ6ZDUuKeC1LBozRhZbgsEcn521heeTUo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MIcHnW4eJjUYwliG2wv5Pf49HTTVsk7PMsN+fiYMhWg=; b=erg0iopn9KPQUtxQoFsgGWOCjx4GJngcrbXpfAkcdOFNQ0/N9ZzwAluuMBqE/GOdQm /VAhP6N3/qb0KhURQTCoNqwBv6XJib00/YiIqRt3PfhrkmyTuRK73Mg1jhzkrCovZuBJ gz50ODxgchp2vRBQgdN0evdg3QHkD3MZu3qh8RnejJRq6IZ5EeBeiJIkeURfzO7DxbQv MCMohl+xD0IvVUW7p38+hZkCD4Ge5I3m/KIhm0MIOEA0khghQwZSx9KiQpIVgdevGzxk V8rD2uhTDQ1gjGuWeHayHBEsUWZ65iKmXNXVfjY3cwlEDN4LZSukkxpUsI7FzJzBYgus Zlag== X-Gm-Message-State: AHQUAub29UUSPP+uQarYxop9MW78s+AQLkeP+Md9e6dbW4l2GcXQcbJC rB7mNy06DpXiWZT4hvHuaonaH1vuXZgzt41k31FaKbCDRX79TMC6x+/6MIw7ixeIxuIsTHl0wYM A6Nzno5oB0EhtHg== X-Google-Smtp-Source: AHgI3IZvFfGYviG4llz9+2Zrx6DpEmNTjHYPK3dhQWhKovm1u5ZHD2jyXUp8VUJOtPrkg+yLkB4h2QBq9EkP9QJj6UM= X-Received: by 2002:a24:8ac7:: with SMTP id v190mr8507142itd.174.1549286946284; Mon, 04 Feb 2019 05:29:06 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> In-Reply-To: <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> From: Brian Campbell Date: Mon, 4 Feb 2019 06:28:39 -0700 Message-ID: To: Neil Madden Cc: "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="00000000000016d45a0581117a80" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 13:29:10 -0000 --00000000000016d45a0581117a80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, probably. On Sat, Feb 2, 2019 at 12:39 AM Neil Madden wrote: > If we go down the 307 route, shouldn=E2=80=99t it rather be a 308 (perman= ent) > redirect? It seems unnecessary for the client to keep trying the original > endpoint or have to remember cache-control/expires timeouts. > > =E2=80=94 Neil > > On 2 Feb 2019, at 00:03, Richard Backman, Annabelle < > richanna=3D40amazon.com@dmarc.ietf.org> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Date: *Friday, February 1, 2019 at 3:17 PM > *To: *"Richard Backman, Annabelle" > *Cc: *George Fletcher , oauth > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher <40aol.com@dmarc...ietf.org>> > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf..org <40aol.com@dmarc.ietf.org>> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear.. > It'd be something to the effect of optional for the AS to include and > clients doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 [image: Ping Identity] Brian Campbell Distinguished Engineer bcampbell@pingidentity.com w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000016d45a0581117a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, probably.

On Sat, Feb 2, 2019 at 12:39 AM N= eil Madden <neil.madden@for= gerock.com> wrote:
If we = go down the 307 route, shouldn=E2=80=99t it rather be a 308 (permanent) red= irect? It seems unnecessary for the client to keep trying the original endp= oint or have to remember cache-control/expires timeouts.=C2=A0

=E2=80=94 Neil
<= br>On 2 Feb 2019, at 00:03, Richard Backman, Annabelle <richanna=3D40am= azon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to include both token_endpoint_u= ri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the e= mpty string?
  2. What if I only support mTLS for the= token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does= token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?=
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do= I include a mTLS-enabled device_authorization_endpoint under mtls_endpoint= s?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t k= now anything about mTLS, but the IT admins installed client certs in their = users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the m= TLS-only AS omitted token_endpoint_uri.
  3. My AS me= tadata parser crashed because it didn=E2=80=99t expect to encounter a JSON = object as a parameter value.
  4. The mTLS-only AS di= dn=E2=80=99t provide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, bu= t they told me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2= =80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still= get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces = them on everyone who supports mTLS. In contrast, the 307 redirect is only r= equired when an AS wants to support both, and is unambiguous in its behavio= r and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the= regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approa= ch deployed and working would be more complicated and error prone.=C2=A0=

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terri= bly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time. <= u>

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so mess= ages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear.. It'd be something to the effect of optional for = the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.

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

--

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000016d45a0581117a80-- From nobody Mon Feb 4 09:17:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8600D130EAB for ; Mon, 4 Feb 2019 09:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLMPlQk0EjSV for ; Mon, 4 Feb 2019 09:17:49 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 28428130E86 for ; Mon, 4 Feb 2019 09:17:48 -0800 (PST) Received: from [IPv6:2601:282:202:b210:b0d2:66e8:e5c0:c396] (unknown [IPv6:2601:282:202:b210:b0d2:66e8:e5c0:c396]) by alkaline-solutions.com (Postfix) with ESMTPSA id 62E043158E; Mon, 4 Feb 2019 17:17:47 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FF2F75B7-B2DD-473F-AD41-C0CDFEC77E26" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\)) Date: Mon, 4 Feb 2019 10:17:46 -0700 In-Reply-To: Cc: Neil Madden , oauth To: Brian Campbell References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> X-Mailer: Apple Mail (2.3445.104.1) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 17:17:50 -0000 --Apple-Mail=_FF2F75B7-B2DD-473F-AD41-C0CDFEC77E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My understanding is that a permanent redirect would be telling the = client (and any other clients getting cached results from an = intermediary) to now stop using the original endpoint in perpetuity for = all cases. I don=E2=80=99t think that is appropriate (in the general = case) for an endpoint with request processing business logic behind it, = since that logic may change over time. -DW > On Feb 4, 2019, at 6:28 AM, Brian Campbell = wrote: >=20 > Yeah, probably.=20 >=20 > On Sat, Feb 2, 2019 at 12:39 AM Neil Madden > wrote: > If we go down the 307 route, shouldn=E2=80=99t it rather be a 308 = (permanent) redirect? It seems unnecessary for the client to keep trying = the original endpoint or have to remember cache-control/expires = timeouts.=20 >=20 > =E2=80=94 Neil --Apple-Mail=_FF2F75B7-B2DD-473F-AD41-C0CDFEC77E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = understanding is that a permanent redirect would be telling the client = (and any other clients getting cached results from an intermediary) to = now stop using the original endpoint in perpetuity for all cases. I = don=E2=80=99t think that is appropriate (in the general case) for an = endpoint with request processing business logic behind it, since that = logic may change over time.

-DW

On Feb 4, 2019, at 6:28 AM, = Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

Yeah, probably. 

On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <neil.madden@forgerock.com> wrote:
If we go down the 307 route, shouldn=E2=80=99t it rather be = a 308 (permanent) redirect? It seems unnecessary for the client to keep = trying the original endpoint or have to remember cache-control/expires = timeouts. 

=E2=80=94 = Neil

= --Apple-Mail=_FF2F75B7-B2DD-473F-AD41-C0CDFEC77E26-- From nobody Tue Feb 5 07:22:50 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B46F128CF3 for ; Tue, 5 Feb 2019 07:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z26tCoFMSr9l for ; Tue, 5 Feb 2019 07:22:45 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760128.outbound.protection.outlook.com [40.107.76.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6AC124BF6 for ; Tue, 5 Feb 2019 07:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QJfHXFXb3RZXVh1hLXNl6IfWqFhYjsw+Sz6xkQOwxns=; b=Tm/nUFDB4o7BU79N0/s+B/dfJuY2DJAhrzeHutAht7Qrs7y0C0kIpZ6y7UMpiqsm3N1E3bgdTcgzLNkBHn3EKNL7ZhGmnhFum/xkhRaYLvQfBLZzarFoRlOA5rQNVQ+xySErJ/Uw8vrNfRhof/fecJDU0gcKEGKwXU3lGH45d8w= Received: from CY4PR01CA0007.prod.exchangelabs.com (2603:10b6:903:1f::17) by BN7PR01MB3843.prod.exchangelabs.com (2603:10b6:406:84::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Tue, 5 Feb 2019 15:22:43 +0000 Received: from BY2NAM03FT015.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::200) by CY4PR01CA0007.outlook.office365.com (2603:10b6:903:1f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.20 via Frontend Transport; Tue, 5 Feb 2019 15:22:43 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.59) smtp.mailfrom=mit.edu; alkaline-solutions.com; dkim=none (message not signed) header.d=none;alkaline-solutions.com; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.59 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.59; helo=outgoing-exchange-5.mit.edu; Received: from outgoing-exchange-5.mit.edu (18.9.28.59) by BY2NAM03FT015.mail.protection.outlook.com (10.152.84.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Tue, 5 Feb 2019 15:22:42 +0000 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x15FNBgt028334; Tue, 5 Feb 2019 10:23:18 -0500 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 5 Feb 2019 10:20:41 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 5 Feb 2019 10:21:15 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 5 Feb 2019 10:21:15 -0500 From: Justin Richer To: David Waite CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint Thread-Index: AQHUuoq/JxNvtNmWmkWyJyZ4NDNDkqXMc6OAgAOGLICAAEAEAIABccYA Date: Tue, 5 Feb 2019 15:21:15 +0000 Message-ID: <9864BB84-3987-4EF9-81C3-45B4387F0B1A@mit.edu> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_9864BB8439874EF981C345B4387F0B1Amitedu_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.59; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(39860400002)(376002)(2980300002)(189003)(199004)(236005)(84326002)(316002)(786003)(16586007)(336012)(83716004)(75432002)(6306002)(54896002)(3846002)(6246003)(6116002)(186003)(71190400001)(88552002)(33656002)(86362001)(106466001)(8676002)(966005)(356004)(36906005)(26826003)(26005)(4326008)(478600001)(8936002)(486006)(33964004)(14444005)(126002)(7696005)(476003)(66066001)(76176011)(36756003)(229853002)(6916009)(426003)(53546011)(106002)(82746002)(246002)(2906002)(102836004)(446003)(54906003)(7596002)(11346002)(2616005)(7736002)(93886005)(956004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR01MB3843; H:outgoing-exchange-5.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-exchange-5.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT015; 1:DwwYijD3OwwaG6oC4UWykNBUfN1myuyAeoAm4qJeskZWjyDWQLdSyi1jdLmF0EOSqPLPKACmRajVF/B8DhdncziZXa/q8yEO+B3uveECrVPTjcl1C68yhiHDWzV7t9Bu3BIh5CfeeVYlORS/yAe5EiUhT1kGMPqg+7E6cdOWWxs= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f105398c-d985-4511-ccb7-08d68b7dc614 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:BN7PR01MB3843; X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3843; 3:xRsyht9K/+BPSizHOSFNB+HifaLBwJOeE6lnJrlLNSSGLQhTd+SiYbkkIpU9XLEDvTkcDkJ9aI9enVzGRDCqEh+s1CksPJ6TkB8zNlQyR3OWUmmBNP4uHVLI4dZQfFHX/qbJ7OjT1SKDLTyPTbyOVQoB4ArnZ82iKyXmFVJcBvlIbLkoei93v0IfWPUYM8xid7dZhIrlLpwfHXU/ihQhoiY5jnB/WFQtps5Xfy4nyR7yXTvSX7qKNV9QSFG0LCBB7tufisDjxvH+LfgYNkFK5qmZgNU+ukjcizmPnZLQ8uhITQ2Igzz9IwLtzY9U5haF40SspJWmQssqwqyj/U1uQjFA+ChZOtkmiatQGQo04XZoVbfeVz0MzIRSSXteVcVk; 25:wIivHdcydgkT5+MoR3do07cQ6/d2aXxb6iJUKEJ/usq9Db6YSEfa8Lnh68tjRiyqAtFfNhwKeUjn0NcAFWxwB+HJzUe5w3pQ9JbF9DE06JwT/bne1z60w6s0Ec4gRlx4St1uB84sAJJ6RYJ/CGwvQlxZkyBJ00L7E8AdlwD3aecxg+0ppoW3wXM9FIBb6UrZsDcOelQIdG3jkNFUyDvhvaGpoJVUboUrkj0XrKaH1pm+fWJigulWnV7bsy/nW8Rr46Wa4/ZZErvI4QIznjJLdAReglojq4FJ0Y3iwGNC4Asp1lTWB53vydLBNw63PhnbGcbaeTYw7mZ9Qib242QUNw== X-MS-TrafficTypeDiagnostic: BN7PR01MB3843: X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3843; 31:aZKNhEm28+Qn5xLu/sa/pHtMQfvwIFoV9A10V66v1BZAoGn9e/yuVPWXjiAaTG9rkyPInibio9TjmqulqDa8g8k0VaiXcehc1rLsxdPsKoOt9R7NNvnxsDNTeM1QOVKxxpN86BsC3H0bbfYXhTczY4si9otcXd2C6nPOODxay1b7/4lEpifLO04Lgb1bKWsF92hKnuwxfLYmc64I1cnEl5QMjG8r6q8ayIrmdTBmiGs=; 20:QBaaLIhw2gWmvOl78gUmnMHlmTRSfq8nQQO8gkvAIHZNNEvssmiG6GIQD1hBt8TJUMjaz80w+El8CG2xBifBrituQUNZJtrbJDLfqWLorE71viSWukTm8rpJzvZPFBbPmQfWhLJzy4TDbgkYIgJvOiuxGNwZu08ecronOgpM1cLLXrk5hPM1hYJpvZ/UfS2aLiRaGNTF3TVxdkPeX75+6i/bu8186Hxi26CKio3Mm8pLfLhRd48LbVsroJSxU9MTAE8GFTVDSxOXDPfL4m9tXgn5ji21sI5mADaFc4/VWDleTgf62yH4Z5W9RQ9lgTLtHcSLN0hSamu+YVaaIrdIFaZQlf49Xmy2zEGjCuq4PHWWHX9f3MAC8iRsW7mddgjmMHywHj3R5b7DtzF22Bw+Uj9iyjYDL+HOMw4eIFo2aufc5MJjxIw5yoJ7CVvd8Fs52yHILVKBmu5zueAgBzb9aWHCj9e6qUzQjV25CVBMDkmaC3YTEyoizx53WiLlro+6D0hZkkpHer05pwS/lw10GK599cVoginFS8HxUdbTpByM3/HLjUsZlzzlS9O0QyRyTyNJLPbuAVtGc1O8R03yYQ1gGNKldy9SlC0hxGnUd6Y= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3843; 4:M7DTrYAIO3jQdhAzqn1dQRN1oOYH/8AmgfPr5OfMNOpUhS0ezNAAP/MORNZPSFmsZpXlASw7tfaIcoIi2ABawAK7GnDwqxn+BK3ljCtAgUig0XceHqljue/ARBkVym9x/JunRCKFOBIWWJX+1uymcQeZ9tE4TXcUtt1Tl/f1PwwY7FWF5G2g8+2nACUKq6qToX/QMLpviQ0rBDb7IGfkl+Fx5d8+QZueqCuiKhMX1xoQPTcu3Iz7YPVmDdLpoJ5h8y/04EODNHWtzAWaESt4bANnykbCOrfytRAUQCz0XTM= X-Forefront-PRVS: 0939529DE2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN7PR01MB3843; 23:d5g5liH2ChoOmrFlLnSvkAcS6XelMC3/2SNAl7Hu/?= =?us-ascii?Q?byxD2UnAG7VY0dT7VTQUcCHl1yLeMJRTqfFsAYFeY4IvRBucohsCp1688A2U?= =?us-ascii?Q?o9PUa0uzTEdVuyQ8IRHlocqYMoFaTDN9GHwdUFuU1BUEXdLeIL8MujR/FvAh?= =?us-ascii?Q?cfaDu8Fn8wcB97EdSztj3US5CSk25SPIaa6vlBOqaty7QOiOyCtHEuutbmh+?= =?us-ascii?Q?TTJTei0mv7RiKwpbd0n8MBp/BR1KjJnqIgnBX+zvhmQtTYNvYAkx9zhNJ79E?= =?us-ascii?Q?WfTBI9xl5MiEhtn6LTWrX330It/hJHN1Tyca3QJifROjxs+mUt9gRUGZU1cD?= =?us-ascii?Q?axe3HO60WvT+DdeaXtYFXxLrHtJ2OrcCJPPkbHC/bXT5fA0dLxha+V5FOdev?= =?us-ascii?Q?0xBTyh5NUz9TihYqB3BHYzkuibVUP78huacGmVBcmXPSFbvRip2xUQnLCsvM?= =?us-ascii?Q?UbA1+9TzRJfx5RsMWTavhmLpnx6y7KoiuU3n8SzMfWB01zctvnyUF2ZgZGiB?= =?us-ascii?Q?ozeAW+Ib0wdVmBHQIi5RugWOg41lVo4SXCaPDL5arL2QugvVAroP/t4pBn3z?= =?us-ascii?Q?bUSn07pI+5SF58JxAacJbFKdnyIetrwE72EPy5fTNg6HQrTAncO1MGcoNZt0?= =?us-ascii?Q?sFyh32mWLjwZHC6DAB2PWIgmVD1KCSv3PTX7i9MQqzAmiuNFMu9kHx5HzeET?= =?us-ascii?Q?GIKkoh3aDTC8nTC5Gg9HbycfPb38Nuc7BIINvHRYhxngQJ2HgYjrTafQnklN?= =?us-ascii?Q?SYQgPUDuEuAH/9s/MNLdPpjq3BdXU/w5iX7L1yA7fJlrWvN/BdTEUkAZx/K7?= =?us-ascii?Q?brggPixCFQb2WlftxDxZX4Mlizt+TsPIQTOsNyoGGD6LpBsTbDn0o5eCwBry?= =?us-ascii?Q?u/iIJ9f0CvqlGcOMzzCBShFXgH+MquAulBkRXt3cFZNPCdOvwlKO8N6Gxj5L?= =?us-ascii?Q?UjiMUV3MsnhLsMUCGFdjE8mmI1GnwzOhhTFhpzx6LhjkGS7KJCFTDvRKdINz?= =?us-ascii?Q?00P6fAb2vnToS6UskHF3f6TyPb68p9iEvonptlOPpxzX7wN0Bzgvql0FiQrC?= =?us-ascii?Q?i/PlcNpFbqFvZ7dFWOCpJZN7lxsvNs7PWJC6Hg2GoWW68RsOKA8XazirI7lF?= =?us-ascii?Q?C5N8LAXB+jsC7LFYimQN8LAAiUWkuY32T477NleZnBPrU5/nJdwj7DWHstB7?= =?us-ascii?Q?R+00bkTBBh5dptKiXKMS2qB/Lb0cPxYTKNT0YzunSh9YuBimzTymXq3P+LAk?= =?us-ascii?Q?pVa5W0FcM7SDmh+r6TJSBZlfHc+s30j6TpTPeYiObUbTdldFpv+U0JQyKOXV?= =?us-ascii?Q?O9OlQI6+CZ4aYlwsnZQYdTtM7vBw/HIblsfpZZsCsEz?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: y0Ze5xEhZOIUHZC1uOBanimnTNEPuh+FwFcEdjRf95zH2lfZnUmrP0+WWdAQoNQyA9ruq6V9bdH1yxiW4TzfzCCpTP7tk7W/7zNw+ZQXYiBeg53xTceWLucTWcZseCoT3fy0ICOCljgGhZ53CuwS3SBRV9Vj7PHu+duBWCrJSJM9mVJNky5cUAjo5Vjbkw8ko+NnO3ChRsg7AB6BjZZscPtDG/uFIWUBvlqeaZsraGYDWkBtBGVvPdvGEZL9NuTVVzjv/OV/Tgx/bupu02USUMiVre9oNGE3GX1W+extoAhFpGUTuNhy6/EK7s+pPa0iq70SiJKIrt0kKSlkFzYjhfQ8kK++LOklw1FdMhzFirpgdhabCaQkKoh+oSf/yCQJF+l6c0fsELXEGTwn73fNGHnUxrQndelGri+iLE8WBJA= X-Microsoft-Exchange-Diagnostics: 1; BN7PR01MB3843; 6:q8S3LgpHSHTxhTg2eU37hsUrdrLapeP3xbuG/Mj1MrAgwLzM5KMewnofWKFNUqqCZDFeK69u6R4WZ+2qv1kLzj791l2ryWS9EMCNtbofeGsjP0sQHQ4gl1V3m1x21ls1W1EMkdq+IN6RshnIXCdt6b7ihX5jVKLYnPYFNNkjtRCrBsH6/rhX3fWtR4YS/i1BCf/syITRX0+NEczCQgDnbuLzCcHE6L6J5UmhLGKr/lcl4IZWkddeqPCiaqymZnZtuUcKz8nmH3sOBAF8tiLfFR+YdICIZ2CTABNVe06qvoepJ0ZIgnuqeOlxaF6r0gSSHv0Agu7Ag/jzUmYGLsLyH0v+9O0em7W5X/1XKlublnE7AOcK9KpBpXByQpmV/OC3NsXktCZFXpeKaQtDAMuF7T+F312BE8rASKYQnnNzY0EYWR6eTcACj7hWrBXD2SppgYWwUO7+/rWcUui2POukUw==; 5:g5w0EXXI0ABrC8p/4+nmTVF/diubmDWEZaR2smpYQA4VHBdu1xvGP65UCMAeGk9ntniPzoJMrBi/sqLkpBgM7PvzmXlKO8918gC6PvhjdK3gloGLhpUJpZg6u14SQw8t9fRlQ7nRTrTon8uw+Qti2qP2q5pUP/RwRtmt2INhk1n4+MrkJYZoA8MbOI80NrT44A30AmarsJKb6k5B6UWXmQ==; 7:i1PNUY4yNlv+bu6eessbMsb4zZ8rExigA42OP3xyw09BhsqmHdwzPzpqPb6xDWPTENRL+Mv0HOqBT43awzN2vIYA7TGSSBqi94UTjVSnMoFqzb8UDIIw1X/UKNTzXVdOdflUpNPFcA+t2xRyTo4yMg== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Feb 2019 15:22:42.4864 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f105398c-d985-4511-ccb7-08d68b7dc614 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.59]; Helo=[outgoing-exchange-5.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR01MB3843 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 15:22:49 -0000 --_000_9864BB8439874EF981C345B4387F0B1Amitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gRGF2aWQuIElmIGl04oCZcyBhIHJlZGlyZWN0LCAzMDcgaXMgbW9yZSBhcHByb3ByaWF0 ZS4gSXTigJlzIHVwIHRvIHRoZSBBUyB0byBkZWNpZGUgaWYgdGhlIGNsaWVudCBzaG91bGQgZG8g TVRMUyBvciBub3QsIGlmIHRoZXJl4oCZcyBhbiBvcHRpb24uDQoNCuKAlCBKdXN0aW4NCg0KT24g RmViIDQsIDIwMTksIGF0IDEyOjE3IFBNLCBEYXZpZCBXYWl0ZSA8ZGF2aWRAYWxrYWxpbmUtc29s dXRpb25zLmNvbTxtYWlsdG86ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbT4+IHdyb3RlOg0K DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYSBwZXJtYW5lbnQgcmVkaXJlY3Qgd291bGQgYmUg dGVsbGluZyB0aGUgY2xpZW50IChhbmQgYW55IG90aGVyIGNsaWVudHMgZ2V0dGluZyBjYWNoZWQg cmVzdWx0cyBmcm9tIGFuIGludGVybWVkaWFyeSkgdG8gbm93IHN0b3AgdXNpbmcgdGhlIG9yaWdp bmFsIGVuZHBvaW50IGluIHBlcnBldHVpdHkgZm9yIGFsbCBjYXNlcy4gSSBkb27igJl0IHRoaW5r IHRoYXQgaXMgYXBwcm9wcmlhdGUgKGluIHRoZSBnZW5lcmFsIGNhc2UpIGZvciBhbiBlbmRwb2lu dCB3aXRoIHJlcXVlc3QgcHJvY2Vzc2luZyBidXNpbmVzcyBsb2dpYyBiZWhpbmQgaXQsIHNpbmNl IHRoYXQgbG9naWMgbWF5IGNoYW5nZSBvdmVyIHRpbWUuDQoNCi1EVw0KDQpPbiBGZWIgNCwgMjAx OSwgYXQgNjoyOCBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KWWVhaCwgcHJvYmFibHkuDQoNCk9uIFNhdCwgRmViIDIs IDIwMTkgYXQgMTI6MzkgQU0gTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208 bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiB3cm90ZToNCklmIHdlIGdvIGRvd24g dGhlIDMwNyByb3V0ZSwgc2hvdWxkbuKAmXQgaXQgcmF0aGVyIGJlIGEgMzA4IChwZXJtYW5lbnQp IHJlZGlyZWN0PyBJdCBzZWVtcyB1bm5lY2Vzc2FyeSBmb3IgdGhlIGNsaWVudCB0byBrZWVwIHRy eWluZyB0aGUgb3JpZ2luYWwgZW5kcG9pbnQgb3IgaGF2ZSB0byByZW1lbWJlciBjYWNoZS1jb250 cm9sL2V4cGlyZXMgdGltZW91dHMuDQoNCuKAlCBOZWlsDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_9864BB8439874EF981C345B4387F0B1Amitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <268C005AD9D38A46BA1F8C7DF7415E44@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCiYjNDM7MSB0byBEYXZpZC4gSWYgaXTigJlzIGEg cmVkaXJlY3QsIDMwNyBpcyBtb3JlIGFwcHJvcHJpYXRlLiBJdOKAmXMgdXAgdG8gdGhlIEFTIHRv IGRlY2lkZSBpZiB0aGUgY2xpZW50IHNob3VsZCBkbyBNVExTIG9yIG5vdCwgaWYgdGhlcmXigJlz IGFuIG9wdGlvbi4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iIj48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gRmViIDQsIDIwMTksIGF0IDEyOjE3IFBNLCBEYXZpZCBXYWl0ZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5jb20iIGNsYXNzPSIiPmRhdmlkQGFsa2Fs aW5lLXNvbHV0aW9ucy5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYSBw ZXJtYW5lbnQgcmVkaXJlY3Qgd291bGQgYmUgdGVsbGluZyB0aGUgY2xpZW50IChhbmQgYW55IG90 aGVyIGNsaWVudHMgZ2V0dGluZyBjYWNoZWQgcmVzdWx0cyBmcm9tIGFuIGludGVybWVkaWFyeSkg dG8gbm93IHN0b3AgdXNpbmcgdGhlIG9yaWdpbmFsIGVuZHBvaW50IGluIHBlcnBldHVpdHkgZm9y IGFsbCBjYXNlcy4gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgYXBwcm9wcmlhdGUgKGluIHRoZSBn ZW5lcmFsDQogY2FzZSkgZm9yIGFuIGVuZHBvaW50IHdpdGggcmVxdWVzdCBwcm9jZXNzaW5nIGJ1 c2luZXNzIGxvZ2ljIGJlaGluZCBpdCwgc2luY2UgdGhhdCBsb2dpYyBtYXkgY2hhbmdlIG92ZXIg dGltZS4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4tRFc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEZlYiA0 LCAyMDE5LCBhdCA2OjI4IEFNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJj YW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIGNsYXNzPSIiPmJjYW1w YmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5ZZWFoLCBwcm9iYWJseS48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iZ21haWxfYXR0ciI+T24gU2F0LCBGZWIgMiwgMjAxOSBhdCAxMjozOSBBTSBOZWlsIE1hZGRl biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20iIGNsYXNzPSIi Pm5laWwubWFkZGVuQGZvcmdlcm9jay5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4 IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxl OiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1s ZWZ0OiAxZXg7Ij4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSIiPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SWYgd2UgZ28gZG93biB0aGUg MzA3IHJvdXRlLCBzaG91bGRu4oCZdCBpdCByYXRoZXIgYmUgYSAzMDggKHBlcm1hbmVudCkgcmVk aXJlY3Q/IEl0IHNlZW1zIHVubmVjZXNzYXJ5IGZvciB0aGUgY2xpZW50IHRvIGtlZXAgdHJ5aW5n IHRoZSBvcmlnaW5hbCBlbmRwb2ludCBvciBoYXZlIHRvIHJlbWVtYmVyIGNhY2hlLWNvbnRyb2wv ZXhwaXJlcyB0aW1lb3V0cy4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+4oCUIE5laWw8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9864BB8439874EF981C345B4387F0B1Amitedu_-- From nobody Tue Feb 5 08:17:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F86130DE4 for ; Tue, 5 Feb 2019 08:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5wBEPb3oQw0 for ; Tue, 5 Feb 2019 08:17:26 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF9912008A for ; Tue, 5 Feb 2019 08:17:25 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id y8so4296211wmi.4 for ; Tue, 05 Feb 2019 08:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6vOfYQgmBj3Yx3p/fEO5aQtYY3kq6izQMNHLqvxs9GY=; b=Dn86cQKKwmYqx1c+PRe5OwG4udbI1v5DTNTWdiEgQWp0AYdg5sos4GES13T1E4PXOi VoICDn2Wj39fNMMM2LRnF/N5bbMEtDQCq1x8kgDNVNHHDP3uxumxaYiiMpGaPlsPEoUV A2i/RUFSwCJ86H+9XF/MtNYrk4En8kwchHGMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6vOfYQgmBj3Yx3p/fEO5aQtYY3kq6izQMNHLqvxs9GY=; b=AZy4UP8gkJYA0WSDyK1zC11N2XmJX6d4P3LaWwdhJMiANros7ulIIlLE+AGq/jmI9A H+PSnFv7KrURWJNMaeCvTd6qsXLJrvnzVhdQOb4yESdMmXuz5FzfOK4yhyB/LZeWqAky UJcnZOOqlvVWsUOf/FkoMLBFuVI4PDgTPImSA1UMgpkB56Zoqoi5kM/PRbMZ3QImC06x tAHFjajtG+9Ia5AELyEc4BIIbpRrEnImDTQb15LYxsEdHu207PTPUFkfKQFd37u5hnc0 em8CV0bAZh+H2xz2UtLY1a2YwDwt531gBvC2a9rcrfyusTf+5XzfNjvJ++wfO9j76WJw Jk9g== X-Gm-Message-State: AHQUAuacIHdrRCnbQtDiPmERmPZQvGSUFfEOS0/9ZK5J6+lGwd9Jy1Pk iGDJOkc2hmmYME9v5o9w2zJz9A== X-Google-Smtp-Source: AHgI3IZKImHV4tZuGJjfVN3g05D5O3ySVB8NUrrNQY1nhHu6E4dSbS3+droz1LoL1EpAINBfD6MldA== X-Received: by 2002:a1c:c707:: with SMTP id x7mr4262656wmf.120.1549383444159; Tue, 05 Feb 2019 08:17:24 -0800 (PST) Received: from guest2s-mbp.lan (173.132.93.209.dyn.plus.net. [209.93.132.173]) by smtp.gmail.com with ESMTPSA id x186sm27160043wmg.41.2019.02.05.08.17.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 08:17:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: <9864BB84-3987-4EF9-81C3-45B4387F0B1A@mit.edu> Date: Tue, 5 Feb 2019 16:17:21 +0000 Cc: David Waite , Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <761DA897-56F2-4201-81BA-04D894DE28BA@forgerock.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> <9864BB84-3987-4EF9-81C3-45B4387F0B1A@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 16:17:29 -0000 I=E2=80=99m less and less convinced that a redirect is the best way to = do this. I was reading the WHATWG Fetch spec yesterday, in particular the entries = about CORS, and realised that for cross-origin requests TLS client = certificates are treated as credentials just like cookies: = https://fetch.spec.whatwg.org/#credentials Credentials are HTTP cookies, TLS client certificates, and = authentication entries (for HTTP authentication) So assuming that web browser clients calling the token endpoint will = most likely be calling cross-origin, then it seems that client = certificates won=E2=80=99t be sent anyway unless = Access-Control-Allow-Credentials: true is returned from the preflight = request. Given that calls to the token endpoint shouldn=E2=80=99t = generally require cookies, then it seems likely that you can just *not* = allow credentials in the CORS response and therefore not have any = problem with prompting users for certificates. (Note that you can still = manually set the Authorization header without ACAC set to true, you just = have to whitelist that header in the AC-Allowed-Headers response). I haven=E2=80=99t got time to test it myself right now, but if so that = seems like it side-steps the issue pretty neatly. Configure the token = endpoint to ask for, but not require, client certs, and then make sure = you don=E2=80=99t return Access-Control-Allow-Credentials: true on CORS = preflight requests to that endpoint. =E2=80=94 Neil > On 5 Feb 2019, at 15:21, Justin Richer wrote: >=20 > +1 to David. If it=E2=80=99s a redirect, 307 is more appropriate. = It=E2=80=99s up to the AS to decide if the client should do MTLS or not, = if there=E2=80=99s an option. >=20 > =E2=80=94 Justin >=20 >> On Feb 4, 2019, at 12:17 PM, David Waite = wrote: >>=20 >> My understanding is that a permanent redirect would be telling the = client (and any other clients getting cached results from an = intermediary) to now stop using the original endpoint in perpetuity for = all cases. I don=E2=80=99t think that is appropriate (in the general = case) for an endpoint with request processing business logic behind it, = since that logic may change over time. >>=20 >> -DW >>=20 >>> On Feb 4, 2019, at 6:28 AM, Brian Campbell = wrote: >>>=20 >>> Yeah, probably.=20 >>>=20 >>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden = wrote: >>> If we go down the 307 route, shouldn=E2=80=99t it rather be a 308 = (permanent) redirect? It seems unnecessary for the client to keep trying = the original endpoint or have to remember cache-control/expires = timeouts.=20 >>>=20 >>> =E2=80=94 Neil >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Feb 5 12:42:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1513127B for ; Tue, 5 Feb 2019 12:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.352 X-Spam-Level: X-Spam-Status: No, score=-16.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxyQCsmFmm72 for ; Tue, 5 Feb 2019 12:42:32 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C618513126C for ; Tue, 5 Feb 2019 12:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1549399351; x=1580935351; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yljZlUpUoqWz697qC83ThG0d19blfQg6E3Fg89opwCc=; b=qFlK5k23eflFhAghNupsJsTCU6WYRyuH/YS02myG/YNFW5AKxLvYgaCq Q1tcwGQyejxpNI8M4nWSrzqoeYy0FGIWMb3g1/s+gYIP4JXvD/rhHjK4j n9U1uE0YgtTtT+UbzUK/d6WpKfziSbYcmxG8egic6ZPDPyo9C+rzP/Ote U=; X-IronPort-AV: E=Sophos;i="5.58,336,1544486400"; d="scan'208,217";a="781024371" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 05 Feb 2019 20:42:28 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (Postfix) with ESMTPS id 97AB0A020F; Tue, 5 Feb 2019 20:42:28 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Feb 2019 20:42:28 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Feb 2019 20:38:49 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Tue, 5 Feb 2019 20:38:49 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell , "Richard Backman, Annabelle" CC: oauth Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint Thread-Index: AQHUvI2LObcpr6zF5UKz57jceIw7rKXRJmGA Date: Tue, 5 Feb 2019 20:38:49 +0000 Message-ID: <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.164] Content-Type: multipart/alternative; boundary="_000_54A2B8BD279445B6969BE6155A1B7EBEamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 20:42:36 -0000 --_000_54A2B8BD279445B6969BE6155A1B7EBEamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KFRMO0RSOiBwdW50IEFTIG1ldGFkYXRhIHRvIGEgc2VwYXJhdGUgZHJhZnQpDQoNCkFTIHBvaW50 cyAjMS0zIGFyZSBhbGwgcXVlc3Rpb25zIEkgd291bGQgaGF2ZSBhcyBhbiBpbXBsZW1lbnRlcjoN Cg0KICAxLiAgU2VjdGlvbiAyIG9mIFJGQzg0MTQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzg0MTQjc2VjdGlvbi0yPiBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVu bGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hh dCBkb2VzIHRoZSBtVExTLW9ubHkgQVMgcHV0IGhlcmU/DQogIDIuICBUaGUgY2xhaW1zIGZvciB0 aGVzZSBvdGhlciBlbmRwb2ludHMgYXJlIE9QVElPTkFMLCBwb3RlbnRpYWxseSBsZWFkaW5nIHRv IGluY29uc2lzdGVuY3kgZGVwZW5kaW5nIG9uIGhvdyAjMSBnZXRzIGRlY2lkZWQuDQogIDMuICBU aGUgZXhhbXBsZSB1c2FnZSBvZiB0aGUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIHByb3Bl cnR5IGdpdmVuIGVhcmxpZXIgaXMgaW5jb21wYXRpYmxlIHdpdGggUkZDODQxNCwgc2luY2Ugc29t ZSBvZiBpdHMgY29udGVudHMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBub24tbVRMUyBlbmRwb2lu dHMsIGFuZCBvdGhlcnMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBtVExTIGVuZHBvaW50cy4gSGVu Y2UgdGhpcyBxdWVzdGlvbi4NCiAgNC4gIFRoaXMgaW50cm9kdWNlcyBhIG5ldyBtZXRhZGF0YSBw cm9wZXJ0eSB0aGF0IGNvdWxkIGltcGFjdCBob3cgb3RoZXIgc3BlY3Mgc2hvdWxkIGV4dGVuZCBB UyBtZXRhZGF0YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQuDQoNCkkgY291bGQgZ28gb24g Zm9yIGNsaWVudCBwb2ludHMgYnV0IHlvdSBhbHJlYWR5IGdldCB0aGUgcG9pbnQuIFRob3VnaCBJ 4oCZbGwgc2hhcmUgdGhhdCAjMyBpcyByZWFsIGFuZCBvbmNlIGZvcmNlZCBtZSB0byByb2xsIGJh Y2sgYW4gdXBkYXRlIHRvIHRoZSBMb2dpbiB3aXRoIEFtYXpvbiB1c2VyaW5mbyBlbmRwb2ludOKA pmdvb2QgdGltZXMuIPCfmIMNCg0KSSBkb27igJl0IG5lY2Vzc2FyaWx5IHRoaW5rIGFuIEFTIG1l dGFkYXRhIHByb3BlcnR5IGlzIHdyb25nIHBlciBzZSwgYnV0IHVuZGVyc3RhbmQgdGhhdCB5b3Xi gJlyZSBib2x0aW5nIGEgbGF5ZXIgb2YgZmxleGliaWxpdHkgb250byBhIHN0YW5kYXJkIHRoYXQg d2FzbuKAmXQgZGVzaWduZWQgZm9yIHRoYXQsIGFuZCBJIGRvbuKAmXQgdGhpbmsgdGhlIG1ldGFk YXRhIHByb3Bvc2FsIGFzIGl04oCZcyBiZWVuIGRpc2N1c3NlZCBoZXJlIHN1ZmZpY2llbnRseSBk ZWFscyB3aXRoIHRoZSBmYWxsb3V0IGZyb20gdGhhdC4gSW4gbXkgdmlldyB0aGlzIGlzIGEgY29t cGxleCBlbm91Z2ggaXNzdWUgYW5kIGl04oCZcyBmb3IgYSBudWFuY2VkIGVub3VnaCB1c2UgY2Fz ZSAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgZnJvbSBkaXNjdXNzaW9uPyBQbGVhc2UgY29ycmVjdCBt ZSBpZiBJ4oCZbSB3cm9uZykgdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFyYXRlIGRy YWZ0IChlLmcuLCDigJxBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSBFeHRlbnNpb25zIGZv ciBtVExTIEh5YnJpZHPigJ0pIGFuZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuDQoNCi0tDQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJl bGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogTW9uZGF5LCBGZWJy dWFyeSA0LCAyMDE5IGF0IDU6MjggQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUi IDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogb2F1dGggPG9hdXRo QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBS ZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0K DQpUaG9zZSBwb2ludHMgb2YgY29uZnVzaW9uIHN0cmlrZSBtZSBhcyBzb21ld2hhdCBoeXBvdGhl dGljYWwgb3IgaHlwZXJib2xpYy4gQnV0IHlvdXIgZ2VuZXJhbCBwb2ludCBpcyB0YWtlbiBhbmQg eW91ciBwb3NpdGlvbiBvZiBiZWluZyBhbnRpIGFkZGl0aW9uYWwgbWV0YWRhdGEgb24gdGhpcyBp c3N1ZSBpcyBub3RlZC4NCg0KQWxsIG9mIHdoaWNoIGxlYXZlcyBtZSBhIGJpdCB1bmNlcnRhaW4g YWJvdXQgaG93IHRvIHByb2NlZWQuIFRoZXJlIHNlZW0gdG8gYmUgYSByYW5nZSBvZiBvcGluaW9u cyBvbiB0aGlzIHBvaW50IGFuZCBnYXVnaW5nIGNvbnNlbnN1cyBpcyBwcm92aW5nIGVsdXNpdmUg Zm9yIG1lLiBUaGF0J3MgY29uZm91bmRlZCBieSBteSBvd24gb3BpbmlvbiBvbiBpdCBiZWluZyBz b21ld2hhdCBmbHVpZC4NCg0KQW5kIEknZCByZWFsbHkgbGlrZSB0byBwb3N0IGFuIHVwZGF0ZSB0 byB0aGlzIGRyYWZ0IGFib3V0IGEgbW9udGggb3IgdHdvIGFnby4NCg0KDQoNCg0KDQoNCk9uIEZy aSwgRmViIDEsIDIwMTkgYXQgNTowMyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmlj aGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1h cmMuaWV0Zi5vcmc+PiB3cm90ZToNCkNvbmZ1c2lvbiBmcm9tIHRoZSBBU+KAmXMgcGVyc3BlY3Rp dmU6DQoNCiAgMS4gIElmIEkgb25seSBzdXBwb3J0IG1UTFMsIGRvIEkgbmVlZCB0byBpbmNsdWRl IGJvdGggdG9rZW5fZW5kcG9pbnRfdXJpIGFuZCBtdGxzX2VuZHBvaW50cz8gU2hvdWxkIEkgb21p dCB0b2tlbl9lbmRwb2ludF91cmk/IE9yIHNldCBpdCB0byB0aGUgZW1wdHkgc3RyaW5nPw0KICAy LiAgV2hhdCBpZiBJIG9ubHkgc3VwcG9ydCBtVExTIGZvciB0aGUgdG9rZW4gZW5kcG9pbnQsIGJ1 dCBub3QgcmV2b2NhdGlvbiBvciB1c2VyIGluZm8/DQogIDMuICBIb3cgZG8gSSBzcGVjaWZ5IGF1 dGhlbnRpY2F0aW9uIG1ldGhvZHMgZm9yIHRoZSBtVExTIHRva2VuIGVuZHBvaW50PyBEb2VzIHRv a2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBhcHBseSB0byBib3RoIHRoZSBtVExTIGFuZCBub24t bVRMUyBlbmRwb2ludHM/DQogIDQuICBJ4oCZbSB1c2luZyB0aGUgT0F1dGggMi4wIERldmljZSBG bG93LiBEbyBJIGluY2x1ZGUgYSBtVExTLWVuYWJsZWQgZGV2aWNlX2F1dGhvcml6YXRpb25fZW5k cG9pbnQgdW5kZXIgbXRsc19lbmRwb2ludHM/DQoNCkNvbmZ1c2lvbiBmcm9tIHRoZSBjbGllbnTi gJlzIHBlcnNwZWN0aXZlOg0KDQogIDEuICBBcyBmYXIgYXMgSSBrbm93LCBJ4oCZbSBhIHB1Ymxp YyBjbGllbnQsIGFuZCBkb27igJl0IGtub3cgYW55dGhpbmcgYWJvdXQgbVRMUywgYnV0IHRoZSBJ VCBhZG1pbnMgaW5zdGFsbGVkIGNsaWVudCBjZXJ0cyBpbiB0aGVpciB1c2Vyc+KAmSBicm93c2Vy cyBhbmQgdGhlIEFTIGV4cGVjdHMgdG8gdXNlIHRoYXQgdG8gYXV0aGVudGljYXRlIG1lLg0KICAy LiAgTXkgQVMgbWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVjYXVzZSB0aGUgbVRMUy1vbmx5IEFT IG9taXR0ZWQgdG9rZW5fZW5kcG9pbnRfdXJpLg0KICAzLiAgTXkgQVMgbWV0YWRhdGEgcGFyc2Vy IGNyYXNoZWQgYmVjYXVzZSBpdCBkaWRu4oCZdCBleHBlY3QgdG8gZW5jb3VudGVyIGEgSlNPTiBv YmplY3QgYXMgYSBwYXJhbWV0ZXIgdmFsdWUuDQogIDQuICBUaGUgbVRMUy1vbmx5IEFTIGRpZG7i gJl0IHByb3ZpZGUgYSB2YWx1ZSBmb3IgbXRsc19lbmRwb2ludHMsIHdoYXQgZG8gSSBkbz8NCiAg NS4gIEkgZG9u4oCZdCBrbm93IHdoYXQgdGhhdCDigJxt4oCdIG1lYW5zLCBidXQgdGhleSB0b2xk IG1lIHRvIHVzZSBIVFRQUywgc28gSSBzaG91bGQgdXNlIHRoZSBvbmUgd2l0aCDigJx0bHPigJ0g aW4gaXRzIG5hbWUsIHJpZ2h0Pw0KDQpZZXMsIHlvdSBjYW4gd3JpdGUgbm9ybWF0aXZlIHRleHQg dGhhdCBhbnN3ZXJzIG1vc3Qgb2YgdGhlc2UuIEJ1dCB5b3XigJlsbCBoYXZlIHRvIGNsZWFybHkg Y292ZXIgYSBsb3Qgb2Ygc2ltaWxhci1idXQtc2xpZ2h0bHktZGlmZmVyZW50IHNjZW5hcmlvcyBh bmQgYmUgdmVyeSBleHBsaWNpdC4gQW5kIGltcGxlbWVudGVycyB3aWxsIHN0aWxsIGdldCBpdCB3 cm9uZy4gVGhlIG1ldGFkYXRhIGNoYW5nZSBpbnRyb2R1Y2VzIG9wcG9ydHVuaXRpZXMgZm9yIGNv bmZ1c2lvbiBhbmQgZmFpbHVyZSB0aGF0IGRvIG5vdCBleGlzdCBub3csIGFuZCBmb3JjZXMgdGhl bSBvbiBldmVyeW9uZSB3aG8gc3VwcG9ydHMgbVRMUy4gSW4gY29udHJhc3QsIHRoZSAzMDcgcmVk aXJlY3QgaXMgb25seSByZXF1aXJlZCB3aGVuIGFuIEFTIHdhbnRzIHRvIHN1cHBvcnQgYm90aCwg YW5kIGlzIHVuYW1iaWd1b3VzIGluIGl0cyBiZWhhdmlvciBhbmQgbWVhbmluZy4NCg0KLS0NCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IEJyaWFuIENh bXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogRnJpZGF5LCBGZWJy dWFyeSAxLCAyMDE5IGF0IDM6MTcgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUi IDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4NCkNjOiBH ZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb208bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+ Piwgb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIE1UTFMgYW5kIGluLWJyb3dzZXIg Y2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQNCg0KSXQgZG9lc24ndCBzZWVtIGxpa2Ug dGhhdCBjb25mdXNpbmcgb3IgbGFyZ2Ugb2YgYSBjaGFuZ2UgdG8gbWUgLSBpZiB0aGUgY2xpZW50 IGlzIGRvaW5nIE1UTFMgYW5kIHRoZSBnaXZlbiBlbmRwb2ludCBpcyBwcmVzZW50IGluIGBtdGxz X2VuZHBvaW50c2AsIHRoZW4gaXQgdXNlcyB0aGF0IG9uZS4gIE90aGVyd2lzZSBpdCB1c2VzIHRo ZSByZWd1bGFyIGVuZHBvaW50LiBJdCBnaXZlcyBhbiBBUyBhIGxvdCBvZiBmbGV4aWJpbGl0eSBp biBkZXBsb3ltZW50IG9wdGlvbnMuIEkgcGVyc29uYWxseSB0aGluayBnZXR0aW5nIGEgMzA3IGFw cHJvYWNoIGRlcGxveWVkIGFuZCB3b3JraW5nIHdvdWxkIGJlIG1vcmUgY29tcGxpY2F0ZWQgYW5k IGVycm9yIHByb25lLg0KDQpJdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNlIGF0IHRoZSBtb21lbnQg YnV0IHRoZXJlIGFyZSBmb3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVzaCBmb3IgaW5jcmVhc2Vk IHNlY3VyaXR5IGluIGdlbmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlwdCBjbGllbnRzIHVzZSB0 aGUgY29kZSBmbG93LCB0aGF0IHN1Z2dlc3QgaXQgd29uJ3QgYmUgdGVycmlibHkgdW51c3VhbCB0 byBzZWUgYW4gQVMgdGhhdCB3YW50cyB0byBzdXBwb3J0IE1UTFMgY2xpZW50cyBhbmQgamF2YXNj cmlwdC9zcGEgY2xpZW50cyBhdCB0aGUgc2FtZSB0aW1lLg0KDQpJJ3ZlIHBlcnNvbmFsbHkgd2F2 ZXJlZCBiYWNrIGFuZCBmb3J0aCBpbiB0aGlzIHRocmVhZCBvbiB3aGV0aGVyIG9yIG5vdCB0byBh ZGQgdGhlIG5ldyBtZXRhZGF0YSAob3Igc29tZXRoaW5nIGxpa2UgaXQpLiBXaXRoIG15IHJlYXNv bmluZyBlYWNoIHdheSBraW5kYSBleHBsYWluZWQgc29tZXdoZXJlIGJhY2sgaW4gdGhlIDQwIG9y IHNvIG1lc3NhZ2VzIHRoYXQgbWFrZSB1cCB0aGlzIHRocmVhZC4gIEJ1dCBpdCBzZWVtcyBsaWtl IHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhlIGdyb3VwIGhlcmUgaXMgaW4gZmF2b3Igb2YgaXQu DQoNCg0KDQoNCk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMzoxOCBQTSBSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNClRoaXMgc3RyaWtlcyBtZSBhcyBh IHZlcnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcgY2hhbmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVt cyB0byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ4oCZbSBnZXR0aW5nIGEgaGVhZGFjaGUganVz dCB0aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVkZWQgdG8gY2xhcmlmeSB3aGVuIHRoZSBBUyBz aG91bGQgcHJvdmlkZSBgbXRsc19lbmRwb2ludHNgIGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxk IHVzZSB0aGF0IHZlcnN1cyB1c2luZyBgdG9rZW5fZW5kcG9pbnQuYCBXaHkgaXMgdGhlIDMwNyBz dGF0dXMgY29kZSBpbnN1ZmZpY2llbnQgdG8gY292ZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUg QVMgc3VwcG9ydHMgYm90aCBtVExTIGFuZCBub24tbVRMUz8NCg0KLS0NCkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogRnJpZGF5 LCBGZWJydWFyeSAxLCAyMDE5IGF0IDE6MzEgUE0NClRvOiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxl dGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhb2wuY29tQGRtYXJjLi4uaWV0 Zi5vcmc+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVz aW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpZZXMsIHRoYXQgd291bGQgd29yay4NCg0KT24gRnJp LCBGZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wu Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90 ZToNCldoYXQgaWYgdGhlIEFTIHdhbnRzIHRvIE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rpb25z LiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRoZSBvcHRpb25hbCAibXRsc19lbmRwb2ludHMiIGFuZCBq dXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRhIHZhbHVlcz8NCk9uIDEvMTUvMTkgODo0OCBBTSwg QnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQpJdCB3b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFsLCBh cG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcgdG8g dGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMg ZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbiBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0KDQpP biBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9t ZW50dW1mdC5jby51azxtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3JvdGU6 DQpJJ20gaW4gZmF2b3VyIG9mIHRoZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRl ciAtIGFsdGhvdWdoIGl0IHNob3VsZCBiZSBvcHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZIE5P VElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQg bWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh dGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUt bWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9t IHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aD4NCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2Ug YW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K DQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRl bmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Ns b3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURF TlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQg cHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkg b3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFj aG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_54A2B8BD279445B6969BE6155A1B7EBEamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <59CF0F32D16AF24E81A7BB5351B36947@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2 IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIg NSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJ cGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFp bC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0 cGFyYWdyYXBoLCBsaS5nbWFpbC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0 NDU5MTI0Mjk4MTltc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbS00OTAyODIzNDYxODUzMjQz MDE4Z21haWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5 bGUtbmFtZTpnbWFpbC1tXy00OTAyODIzNDYxODUzMjQzMDE4Z21haWwtbV8tMTY2NjQ0NjQ0NTkx MjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUy ODEwMTgyOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDUzNzc2MDA0O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTEyNDc0MzQyOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyNjg3NTMxNzQgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTQ0MzQ5ODc3ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6OTg3MTM1NDYyO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDkN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTQ2 NzgyMTU2MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTczODM5ODIzOCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMzpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFRMO0RSOiBwdW50 IEFTIG1ldGFkYXRhIHRvIGEgc2VwYXJhdGUgZHJhZnQpPGJyPg0KPGJyPg0KQVMgcG9pbnRzICMx LTMgYXJlIGFsbCBxdWVzdGlvbnMgSSB3b3VsZCBoYXZlIGFzIGFuIGltcGxlbWVudGVyOjxvOnA+ PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwzIGxldmVsMSBsZm80Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjODQxNCNzZWN0aW9uLTIiPlNlY3Rpb24gMiBvZiBSRkM4NDE0PC9hPiBzYXlzIHRva2Vu X2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0 eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hhdCBkb2VzIHRoZQ0KIG1UTFMtb25seSBBUyBwdXQg aGVyZT88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm80Ij5UaGUgY2xhaW1zIGZvciB0 aGVzZSBvdGhlciBlbmRwb2ludHMgYXJlIE9QVElPTkFMLCBwb3RlbnRpYWxseSBsZWFkaW5nIHRv IGluY29uc2lzdGVuY3kgZGVwZW5kaW5nIG9uIGhvdyAjMSBnZXRzIGRlY2lkZWQuPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+VGhlIGV4YW1wbGUgdXNhZ2Ugb2YgdGhlIHRva2Vu X2VuZHBvaW50X2F1dGhfbWV0aG9kcyBwcm9wZXJ0eSBnaXZlbiBlYXJsaWVyIGlzIGluY29tcGF0 aWJsZSB3aXRoIFJGQzg0MTQsIHNpbmNlIHNvbWUgb2YgaXRzIGNvbnRlbnRzIGFyZSBvbmx5IHZh bGlkIGZvciB0aGUgbm9uLW1UTFMgZW5kcG9pbnRzLCBhbmQNCiBvdGhlcnMgYXJlIG9ubHkgdmFs aWQgZm9yIHRoZSBtVExTIGVuZHBvaW50cy4gSGVuY2UgdGhpcyBxdWVzdGlvbi48bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwzIGxldmVsMSBsZm80Ij5UaGlzIGludHJvZHVjZXMgYSBuZXcgbWV0YWRhdGEg cHJvcGVydHkgdGhhdCBjb3VsZCBpbXBhY3QgaG93IG90aGVyIHNwZWNzIHNob3VsZCBleHRlbmQg QVMgbWV0YWRhdGEuIFRoYXQgbmVlZHMgdG8gYmUgYWRkcmVzc2VkLjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGNvdWxkIGdvIG9uIGZvciBjbGllbnQgcG9pbnRzIGJ1dCB5b3UgYWxy ZWFkeSBnZXQgdGhlIHBvaW50LiBUaG91Z2ggSeKAmWxsIHNoYXJlIHRoYXQgIzMgaXMgcmVhbCBh bmQgb25jZSBmb3JjZWQgbWUgdG8gcm9sbCBiYWNrIGFuIHVwZGF0ZSB0byB0aGUgTG9naW4gd2l0 aCBBbWF6b24gdXNlcmluZm8gZW5kcG9pbnTigKZnb29kIHRpbWVzLg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij4mIzEyODUxNTs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBuZWNlc3NhcmlseSB0aGluayBhbiBB UyBtZXRhZGF0YSBwcm9wZXJ0eSBpcyB3cm9uZyBwZXIgc2UsIGJ1dCB1bmRlcnN0YW5kIHRoYXQg eW914oCZcmUgYm9sdGluZyBhIGxheWVyIG9mIGZsZXhpYmlsaXR5IG9udG8gYSBzdGFuZGFyZCB0 aGF0IHdhc27igJl0IGRlc2lnbmVkIGZvciB0aGF0LCBhbmQgSSBkb27igJl0IHRoaW5rIHRoZSBt ZXRhZGF0YSBwcm9wb3NhbCBhcyBpdOKAmXMgYmVlbiBkaXNjdXNzZWQgaGVyZQ0KIHN1ZmZpY2ll bnRseSBkZWFscyB3aXRoIHRoZSBmYWxsb3V0IGZyb20gdGhhdC4gSW4gbXkgdmlldyB0aGlzIGlz IGEgY29tcGxleCBlbm91Z2ggaXNzdWUgYW5kIGl04oCZcyBmb3IgYSBudWFuY2VkIGVub3VnaCB1 c2UgY2FzZSAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgZnJvbSBkaXNjdXNzaW9uPyBQbGVhc2UgY29y cmVjdCBtZSBpZiBJ4oCZbSB3cm9uZykgdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFy YXRlIGRyYWZ0IChlLmcuLCDigJxBdXRob3JpemF0aW9uDQogU2VydmVyIE1ldGFkYXRhIEV4dGVu c2lvbnMgZm9yIG1UTFMgSHlicmlkc+KAnSkgYW5kIGdldCBtVExTIG91dCB0aGUgZG9vci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsICZsdDtiY2Ft cGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5Nb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkgYXQgNToyOCBBTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPm9hdXRoICZsdDtvYXV0 aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gW1VOVkVS SUZJRUQgU0VOREVSXSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0 b2tlbiBlbmRwb2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3NlIHBvaW50 cyBvZiBjb25mdXNpb24gc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBoeXBl cmJvbGljLiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0aW9u IG9mIGJlaW5nIGFudGkgYWRkaXRpb25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzIG5vdGVk Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFsbCBvZiB3aGljaCBsZWF2ZXMgbWUgYSBiaXQgdW5jZXJ0YWluIGFib3V0IGhvdyB0byBwcm9j ZWVkLiBUaGVyZSBzZWVtIHRvIGJlIGEgcmFuZ2Ugb2Ygb3BpbmlvbnMgb24gdGhpcyBwb2ludCBh bmQgZ2F1Z2luZyBjb25zZW5zdXMgaXMgcHJvdmluZyBlbHVzaXZlIGZvciBtZS4gVGhhdCdzIGNv bmZvdW5kZWQgYnkgbXkgb3duIG9waW5pb24gb24gaXQgYmVpbmcgc29tZXdoYXQgZmx1aWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBJ J2QgcmVhbGx5IGxpa2UgdG8gcG9zdCBhbiB1cGRhdGUgdG8gdGhpcyBkcmFmdCBhYm91dCBhIG1v bnRoIG9yIHR3byBhZ28uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwg RmViIDEsIDIwMTkgYXQgNTowMyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmlj aGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBBU+KAmXMgcGVyc3BlY3RpdmU6PG86cD48 L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTQ5 MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWYgSSBvbmx5IHN1cHBvcnQg bVRMUywgZG8gSSBuZWVkIHRvIGluY2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91cmkgYW5kIG10 bHNfZW5kcG9pbnRzPyBTaG91bGQgSSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8gT3Igc2V0IGl0 IHRvIHRoZSBlbXB0eSBzdHJpbmc/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS00 OTAyODIzNDYxODUzMjQzMDE4Z21haWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCldoYXQgaWYgSSBvbmx5IHN1 cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQgbm90IHJldm9jYXRpb24gb3Ig dXNlciBpbmZvPzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0tNDkwMjgyMzQ2MTg1 MzI0MzAxOGdtYWlsLW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpIb3cgZG8gSSBzcGVjaWZ5IGF1dGhlbnRpY2F0 aW9uIG1ldGhvZHMgZm9yIHRoZSBtVExTIHRva2VuIGVuZHBvaW50PyBEb2VzIHRva2VuX2VuZHBv aW50X2F1dGhfbWV0aG9kcyBhcHBseSB0byBib3RoIHRoZSBtVExTIGFuZCBub24tbVRMUyBlbmRw b2ludHM/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS00OTAyODIzNDYxODUzMjQz MDE4Z21haWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCknigJltIHVzaW5nIHRoZSBPQXV0aCAyLjAgRGV2aWNl IEZsb3cuIERvIEkgaW5jbHVkZSBhIG1UTFMtZW5hYmxlZCBkZXZpY2VfYXV0aG9yaXphdGlvbl9l bmRwb2ludCB1bmRlciBtdGxzX2VuZHBvaW50cz88bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBjbGllbnTigJlzIHBlcnNwZWN0aXZlOjxvOnA+PC9v OnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iZ21haWwtbS00OTAy ODIzNDYxODUzMjQzMDE4Z21haWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFw aCIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8yIj4NCkFzIGZhciBhcyBJIGtub3csIEni gJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBtVExT LCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz 4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhhdCB0byBhdXRoZW50aWNh dGUgbWUuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS00OTAyODIzNDYxODUzMjQz MDE4Z21haWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1z by1saXN0OmwyIGxldmVsMSBsZm8yIj4NCk15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJl Y2F1c2UgdGhlIG1UTFMtb25seSBBUyBvbWl0dGVkIHRva2VuX2VuZHBvaW50X3VyaS48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2 NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzIiPg0KTXkgQVMgbWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVjYXVzZSBpdCBkaWRu 4oCZdCBleHBlY3QgdG8gZW5jb3VudGVyIGEgSlNPTiBvYmplY3QgYXMgYSBwYXJhbWV0ZXIgdmFs dWUuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS00OTAyODIzNDYxODUzMjQzMDE4 Z21haWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1s aXN0OmwyIGxldmVsMSBsZm8yIj4NClRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBh IHZhbHVlIGZvciBtdGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRvPzxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9ImdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0tMTY2NjQ0NjQ0NTkx MjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+ DQpJIGRvbuKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKAnSBtZWFucywgYnV0IHRoZXkgdG9sZCBt ZSB0byB1c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0aGUgb25lIHdpdGgg4oCcdGxz4oCdIGlu IGl0cyBuYW1lLCByaWdodD88bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywg eW91IGNhbiB3cml0ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4g QnV0IHlvdeKAmWxsIGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1z bGlnaHRseS1kaWZmZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1w bGVtZW50ZXJzDQogd2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2Ug aW50cm9kdWNlcyBvcHBvcnR1bml0aWVzIGZvciBjb25mdXNpb24gYW5kIGZhaWx1cmUgdGhhdCBk byBub3QgZXhpc3Qgbm93LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZlcnlvbmUgd2hvIHN1cHBvcnRz IG1UTFMuIEluIGNvbnRyYXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlzIG9ubHkgcmVxdWlyZWQgd2hl biBhbiBBUyB3YW50cyB0byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1bmFtYmlndW91cw0KIGluIGl0 cyBiZWhhdmlvciBhbmQgbWVhbmluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50 Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5CcmlhbiBDYW1wYmVsbCAmbHQ7 YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQ TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5HZW9yZ2UgRmxldGNo ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7LCBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5bVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIE1UTFMgYW5k IGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxhcmdlIG9m IGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0aGUgZ2l2 ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0IHVzZXMg dGhhdCBvbmUuJm5ic3A7IE90aGVyd2lzZQ0KIGl0IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9pbnQu IEl0IGdpdmVzIGFuIEFTIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQgb3B0aW9u cy4gSSBwZXJzb25hbGx5IHRoaW5rIGdldHRpbmcgYSAzMDcgYXBwcm9hY2ggZGVwbG95ZWQgYW5k IHdvcmtpbmcgd291bGQgYmUgbW9yZSBjb21wbGljYXRlZCBhbmQgZXJyb3IgcHJvbmUuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNlIGF0IHRoZSBtb21lbnQgYnV0IHRoZXJlIGFyZSBm b3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVzaCBmb3IgaW5jcmVhc2VkIHNlY3VyaXR5IGluIGdl bmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlwdCBjbGllbnRzIHVzZSB0aGUgY29kZSBmbG93LCB0 aGF0IHN1Z2dlc3QNCiBpdCB3b24ndCBiZSB0ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0 aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBjbGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGll bnRzIGF0IHRoZSBzYW1lIHRpbWUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUgcGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5k IGZvcnRoIGluIHRoaXMgdGhyZWFkIG9uIHdoZXRoZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1l dGFkYXRhIChvciBzb21ldGhpbmcgbGlrZSBpdCkuIFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5 IGtpbmRhIGV4cGxhaW5lZCBzb21ld2hlcmUgYmFjaw0KIGluIHRoZSA0MCBvciBzbyBtZXNzYWdl cyB0aGF0IG1ha2UgdXAgdGhpcyB0aHJlYWQuJm5ic3A7IEJ1dCBpdCBzZWVtcyBsaWtlIHRoZSBy b3VnaCBjb25zZW5zdXMgb2YgdGhlIGdyb3VwIGhlcmUgaXMgaW4gZmF2b3Igb2YgaXQuDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBGZWIgMSwgMjAxOSBhdCAzOjE4IFBNIFJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24u Y29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmll dGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJl bnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgc3RyaWtlcyBtZSBhcyBhIHZl cnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcgY2hhbmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVtcyB0 byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ4oCZbSBnZXR0aW5nIGEgaGVhZGFjaGUganVzdCB0 aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVkZWQgdG8gY2xhcmlmeSB3aGVuDQogdGhlIEFTIHNo b3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2AgYW5kIHdoZW4gdGhlIGNsaWVudCBzaG91bGQg dXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9lbmRwb2ludC5gIFdoeSBpcyB0aGUgMzA3IHN0 YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3ZlciB0aGUgY2FzZSB3aGVyZSBhIHNpbmdsZSBB UyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1tVExTPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0 eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZl YnJ1YXJ5IDEsIDIwMTkgYXQgMTozMSBQTTxicj4NCjxiPlRvOiA8L2I+R2VvcmdlIEZsZXRjaGVy ICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86NDBhb2wuY29tQGRtYXJjLi4uaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PkNjOiA8L2I+b2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBl bmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlllcywgdGhhdCB3b3VsZCB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDEsIDIwMTkg YXQgMjoyOCBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0 MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3Vy cmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh Ij5XaGF0IGlmIHRoZSBBUyB3YW50cyB0byBPTkxZIHN1cHBvcnQgTVRMUyBjb25uZWN0aW9ucy4g RG9lcyBpdCBub3Qgc3BlY2lmeSB0aGUgb3B0aW9uYWwgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVv dDsgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0YWRhdGEgdmFsdWVzPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEvMTUvMTkgODo0OCBB TSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCB3b3VsZCBkZWZpbml0ZWx5 IGJlIG9wdGlvbmFsLCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBi ZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1 ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbg0KIHByZXNlbnQgaW4g QVMgbWV0YWRhdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVHVlLCBKYW4gMTUsIDIwMTkgYXQgMjowNCBBTSBEYXZlIFRvbmdlICZsdDs8YSBo cmVmPSJtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+ ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oyxz YW5zLXNlcmlmIj5JJ20gaW4gZmF2b3VyIG9mIHRoZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRh IHBhcmFtZXRlciAtIGFsdGhvdWdoIGl0IHNob3VsZCBiZSBvcHRpb25hbC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlDQogcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj b21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+ DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N CjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlz dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu LiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBw dDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVz ZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZu YnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0 aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBU aGFuayB5b3UuPC9zcGFuPjwvaT48L2I+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_54A2B8BD279445B6969BE6155A1B7EBEamazoncom_-- From nobody Tue Feb 5 13:22:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C892C131271 for ; Tue, 5 Feb 2019 13:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgVT6-DQ8cZS for ; Tue, 5 Feb 2019 13:22:50 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643E1131268 for ; Tue, 5 Feb 2019 13:22:49 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id t27so5305354wra.6 for ; Tue, 05 Feb 2019 13:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=4UE9g9YQUigS64eMXnY5yP7FLU8VGCjNylTN+/Bq4qM=; b=kXmb/pk0fuMarIdNkyJrLXN2h+2zHjkfSes6RJ7Wp+t06Ajal4bWZ2sDf8RIPOejZH uqNq7ANWmbzbQ4IrST24A5hzQTNcvPHiKcewZGD7y51yK3+UQKFpOj07EyjVuV1djQSc DFYtzA1ke22qOmuJKouRTRxchaKsM3QIg11SjBgv5zF/X1JsJEiQRbeVbpskOIy/iwxs ItFczo5NWW5FoHbh2GqzRBY5CfGiZFpjShCA/jVRJ7/EfyffcYf9g8kyuzq7VruFC98o Bo/HRyFPGqeBv7VJvoBvwvOEQknQHdMlt/n14hBMdcnMIlpKCd/6ovByVjlA5YDPt6Sk KA4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=4UE9g9YQUigS64eMXnY5yP7FLU8VGCjNylTN+/Bq4qM=; b=RNkuWkmy+mLWPd9OhVBzGKGsZiX32v/vgBtRBbf7XP9ihnTHw/jT/TAtb2GPhzmsuv UaKbYdHnISuWk49SVT29j0ft10BsmX01FYpV3BMkQV1C4wZ4rex9xg8ZypM/4+xupoK7 ijLrd48+cqZ2nAwlgIRz5CUJ8f0YLjRkURD3g/Z95vYryZC4VuKGTjlUitTXvx3q8lNP 17rW4cpTl5pQz4UHq8Iop/m7Q/obQVne1fjhMIq5MDwZgoq4Fh0vC4P50K3O3KKmd1Nr 0VfQ8+9pV+FDoZ5BCm1rjAvzhXI7RPI75ietk3TqWcWGw0EcVi81OrJgpKNWyDbxuEqL CW6Q== X-Gm-Message-State: AHQUAuYvgub8G7eWlFMl/K1KEbSbD+27yRm6GAw6AcR0CxZ/CYQILkWk iRyiPMbpX6Dswt1xPTgCcRdA9iI= X-Google-Smtp-Source: AHgI3Ia+n+WgDRUZOCKeJNVoXem7URPIcK2ZFzlgOqqHpIdKEX3lBkpfqjaui6NLTf6D5JFqA7O9BQ== X-Received: by 2002:a5d:5649:: with SMTP id j9mr5117943wrw.256.1549401767320; Tue, 05 Feb 2019 13:22:47 -0800 (PST) Received: from [192.168.0.179] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id y145sm13542405wmd.30.2019.02.05.13.22.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 13:22:46 -0800 (PST) From: Filip Skokan Content-Type: multipart/alternative; boundary=Apple-Mail-B6446920-7F4F-4977-A2BA-5CDEDEC4D4A3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 5 Feb 2019 22:22:45 +0100 Message-Id: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> In-Reply-To: <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> To: oauth X-Mailer: iPhone Mail (16C101) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 21:22:53 -0000 --Apple-Mail-B6446920-7F4F-4977-A2BA-5CDEDEC4D4A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I for one believe the points are somewhat easily addressable, and fear that b= y just shoving mtls out the door and dealing with the browser UX caveats lat= er we=E2=80=99ll end up with a state where if an AS wants to have mtls enabl= ed without UX affected proprietary solutions will pop up, thus interoperabil= ity suffers. That being said it is clear that consensus is eluding us. However, just hosting the token endpoint on another host/port as the draft c= urrently mentions (which in itself acknowledges the issue) is no longer suff= icient (with the spa move to code flow) and doesn=E2=80=99t deal with userin= fo, introspection, revocation. Is there even enough substance/meat for a separate extension document? Best, Filip Odesl=C3=A1no z iPhonu 5. 2. 2019 v 21:38, Richard Backman, Annabelle : > (TL;DR: punt AS metadata to a separate draft) >=20 > AS points #1-3 are all questions I would have as an implementer: > Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only t= he implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS p= ut here? > The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided. > The example usage of the token_endpoint_auth_methods property given earlie= r is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints. H= ence this question. > This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed. > =20 > I could go on for client points but you already get the point. Though I=E2= =80=99ll share that #3 is real and once forced me to roll back an update to t= he Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > =20 > I don=E2=80=99t necessarily think an AS metadata property is wrong per se,= but understand that you=E2=80=99re bolting a layer of flexibility onto a st= andard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the m= etadata proposal as it=E2=80=99s been discussed here sufficiently deals with= the fallout from that. In my view this is a complex enough issue and it=E2=80= =99s for a nuanced enough use case (as far as I can tell from discussion? Pl= ease correct me if I=E2=80=99m wrong) that we should punt it to a separate d= raft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybri= ds=E2=80=9D) and get mTLS out the door. > =20 > --=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Brian Campbell > Date: Monday, February 4, 2019 at 5:28 AM > To: "Richard Backman, Annabelle" > Cc: oauth > Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser client= s using the token endpoint > =20 > Those points of confusion strike me as somewhat hypothetical or hyperbolic= . But your general point is taken and your position of being anti additional= metadata on this issue is noted. > =20 > All of which leaves me a bit uncertain about how to proceed. There seem to= be a range of opinions on this point and gauging consensus is proving elusi= ve for me. That's confounded by my own opinion on it being somewhat fluid. > =20 > And I'd really like to post an update to this draft about a month or two a= go. > =20 > =20 > =20 > =20 > =20 > =20 > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle wrote: > Confusion from the AS=E2=80=99s perspective: > If I only support mTLS, do I need to include both token_endpoint_uri and m= tls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng? > What if I only support mTLS for the token endpoint, but not revocation or u= ser info? > How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints? > I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled d= evice_authorization_endpoint under mtls_endpoints? > =20 > Confusion from the client=E2=80=99s perspective: > As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyt= hing about mTLS, but the IT admins installed client certs in their users=E2=80= =99 browsers and the AS expects to use that to authenticate me. > My AS metadata parser crashed because the mTLS-only AS omitted token_endpo= int_uri. > My AS metadata parser crashed because it didn=E2=80=99t expect to encounte= r a JSON object as a parameter value. > The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what d= o I do? > I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me= to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right? > =20 > Yes, you can write normative text that answers most of these. But you=E2=80= =99ll have to clearly cover a lot of similar-but-slightly-different scenario= s and be very explicit. And implementers will still get it wrong. The metada= ta change introduces opportunities for confusion and failure that do not exi= st now, and forces them on everyone who supports mTLS. In contrast, the 307 r= edirect is only required when an AS wants to support both, and is unambiguou= s in its behavior and meaning. > =20 > --=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Brian Campbell > Date: Friday, February 1, 2019 at 3:17 PM > To: "Richard Backman, Annabelle" > Cc: George Fletcher , oauth > Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients us= ing the token endpoint > =20 > It doesn't seem like that confusing or large of a change to me - if the cl= ient is doing MTLS and the given endpoint is present in `mtls_endpoints`, th= en it uses that one. Otherwise it uses the regular endpoint. It gives an AS= a lot of flexibility in deployment options. I personally think getting a 30= 7 approach deployed and working would be more complicated and error prone.=20= > =20 > It is a minority use case at the moment but there are forces in play, like= the push for increased security in general and to have javascript clients u= se the code flow, that suggest it won't be terribly unusual to see an AS tha= t wants to support MTLS clients and javascript/spa clients at the same time.= > =20 > I've personally wavered back and forth in this thread on whether or not to= add the new metadata (or something like it). With my reasoning each way kin= da explained somewhere back in the 40 or so messages that make up this threa= d. But it seems like the rough consensus of the group here is in favor of i= t. > =20 > =20 > =20 > =20 > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: > This strikes me as a very prominent and confusing change to support what s= eems to be a minority use case. I=E2=80=99m getting a headache just thinking= about the text needed to clarify when the AS should provide `mtls_endpoints= ` and when the client should use that versus using `token_endpoint.` Why is t= he 307 status code insufficient to cover the case where a single AS supports= both mTLS and non-mTLS? > =20 > --=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: OAuth on behalf of Brian Campbell > Date: Friday, February 1, 2019 at 1:31 PM > To: George Fletcher > Cc: oauth > Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoi= nt > =20 > Yes, that would work.=20 > =20 > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: > What if the AS wants to ONLY support MTLS connections. Does it not specify= the optional "mtls_endpoints" and just use the normal metadata values? >=20 > On 1/15/19 8:48 AM, Brian Campbell wrote: > It would definitely be optional, apologies if that wasn't made clear. It'd= be something to the effect of optional for the AS to include and clients do= ing MTLS would use it when present in AS metadata. > =20 > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge w= rote: > I'm in favour of the `mtls_endpoints` metadata parameter - although it sho= uld be optional. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf..org/mailman/listinfo/oauth > =20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-B6446920-7F4F-4977-A2BA-5CDEDEC4D4A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I for one believe the points are somewhat e= asily addressable, and fear that by just shoving mtls out the door and deali= ng with the browser UX caveats later we=E2=80=99ll end up with a state where= if an AS wants to have mtls enabled without UX affected proprietary solutio= ns will pop up, thus interoperability suffers.

That being= said it is clear that consensus is eluding us.

How= ever, just hosting the token endpoint on another host/port as the draft curr= ently mentions (which in itself acknowledges the issue) is no longer suffici= ent (with the spa move to code flow) and doesn=E2=80=99t deal with userinfo,= introspection, revocation.

Is there even enough su= bstance/meat for a separate extension document?

Best,
Filip

Od= esl=C3=A1no z iPhonu

5. 2. 2019 v 21:38,= Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>:

<= blockquote type=3D"cite">

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /p>

  1. Section 2 of R= FC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit= grant type is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoin= ts are OPTIONAL, potentially leading to inconsistency depending on how #1 ge= ts decided.
  3. The example usage of the token_endpoint_auth= _methods property given earlier is incompatible with RFC8414, since some of i= ts contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how ot= her specs should extend AS metadata. That needs to be addressed.<= /li>

 

I could go on for client points but you already get t= he point. Though I=E2=80=99ll share that #3 is real and once forced me to ro= ll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good ti= mes. =F0=9F=98=83

 

I don=E2=80=99t necessarily think an AS metadata prop= erty is wrong per se, but understand that you=E2=80=99re bolting a layer of f= lexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2= =80=99t think the metadata proposal as it=E2=80=99s been discussed here sufficiently deals with the fallout from that. In my view this is a complex= enough issue and it=E2=80=99s for a nuanced enough use case (as far as I ca= n tell from discussion? Please correct me if I=E2=80=99m wrong) that we shou= ld punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the d= oor.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From:= OAuth <oauth-bounces@ietf.org> on behalf of B= rian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
= Cc: oauth <oauth@ietf.org>= ;
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint

 

Those points of confusion strike me as somewhat hypot= hetical or hyperbolic. But your general point is taken and your position of b= eing anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to p= roceed. There seem to be a range of opinions on this point and gauging conse= nsus is proving elusive for me. That's confounded by my own opinion on it be= ing somewhat fluid.

 

And I'd really like to post an update to this draft a= bout a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annab= elle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtl= s_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string= ?
  2. What if I only support mTLS for the token endpoint, but not revocation or us= er info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does to= ken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled dev= ice_authorization_endpoint under mtls_endpoints?

 

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anythi= ng about mTLS, but the IT admins installed client certs in their users=E2=80= =99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoin= t_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a= JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I= do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me t= o use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name,= right?

 

Yes, you can write normative text that answers most of these. But yo= u=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different s= cenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for c= onfusion and failure that do not exist now, and forces them on everyone who s= upports mTLS. In contrast, the 307 redirect is only required when an AS want= s to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <b= campbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clien= ts using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if t= he client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deploy= ment options. I personally think getting a 307 approach deployed and working= would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play= , like the push for increased security in general and to have javascript cli= ents use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS client= s and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or n= ot to add the new metadata (or something like it). With my reasoning each wa= y kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like t= he rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richan= na=3D40amaz= on.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support w= hat seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that v= ersus using `token_endpoint.` Why is the 307 status code insufficient to cov= er the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.or= g>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token e= ndpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf= .org> wrote:

What if the AS wants to ONLY support= MTLS connections. Does it not specify the optional "mtls_endpoints" and jus= t use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear= . It'd be something to the effect of optional for the AS to include and clie= nts doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk&= gt; wrote:

I'm i= n favour of the `mtls_endpoints` metadata parameter - although it should be o= ptional.


CONFIDENTIALITY NOTICE: This email may c= ontain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is stri= ctly prohibited..  If you have received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you. 

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

 


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-B6446920-7F4F-4977-A2BA-5CDEDEC4D4A3-- From nobody Tue Feb 5 15:07:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8D12785F for ; Tue, 5 Feb 2019 15:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_rOCKa0iH_q for ; Tue, 5 Feb 2019 15:07:13 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DE31277CC for ; Tue, 5 Feb 2019 15:07:13 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id p197so1978910itp.0 for ; Tue, 05 Feb 2019 15:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WpJI/ITitEh7ArxaDwYOVWAG9gfeCzaFN7fr9CU+bSc=; b=QuYn5PqXq5BSbsf2p9LDePojanenIF6FTWrfzQl8BY1Js/Bqyt2o1GLVjeak2qKIo8 xGsDuK7JLJyrnpdtdkj9jnfVcXai1W6kFIF26UFk2lri8p6Np8Lc/ud/ZA8f67DLKXIY xmNeGNfHgBz2PUkvjnf2lBM4r0PUA7KGkF7FU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WpJI/ITitEh7ArxaDwYOVWAG9gfeCzaFN7fr9CU+bSc=; b=F3uszIIH867h87RRXdZ8H+6VycupoeJYFQHaHs08clgL9gn/wttJjALEfRcpWezqvN 8/ohl824wMOUT+CYsAHlXPptQbDYYXRy0hIZW9uJxrXuWY5t2+bWAVx3cZKEHfbJBzZQ x6juRkxsCq/f6HDEYknTD0a7uZOi2+kdULnB30zh5DQn/+wDu6vkQsTPIZ1OjZxmFAFg 53WtWaqhH8z5Apl1qqgvWX4mW5AbVRx4awgnfe6h1RpU9SBVrTWvTXb40i2hZjIsIaOW 70jrQimPW6WD1RGIsptvKGlVyhcetQR4UV7wjjBiBxltDVvhO7sieD5NuJ41q/d378cu GLGQ== X-Gm-Message-State: AHQUAuYUbji8Oz7yg//AhOz2fj15aCugdERRRtI79aHsbL+CcJPJBAYo 0fhEotJKYyKo5yvhXP6BuNdQaT/FCa56C6jVK6mfpVXoDByAy0vgYE7J1zosKSGy7LBmdHpedwG pCSaOaKpUtDVL2w== X-Google-Smtp-Source: AHgI3IbncPSKbXPIoI9UVgxTE2NZ9v2BZoWvyqMSR+gESSw+L3By5+PN9LquhVbLwk+xpeXVGqVyW7au1dn8lrJdTSs= X-Received: by 2002:a24:3644:: with SMTP id l65mr698538itl.124.1549408032272; Tue, 05 Feb 2019 15:07:12 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> <9864BB84-3987-4EF9-81C3-45B4387F0B1A@mit.edu> <761DA897-56F2-4201-81BA-04D894DE28BA@forgerock.com> In-Reply-To: <761DA897-56F2-4201-81BA-04D894DE28BA@forgerock.com> From: Brian Campbell Date: Tue, 5 Feb 2019 16:06:45 -0700 Message-ID: To: Neil Madden Cc: Justin Richer , David Waite , oauth Content-Type: multipart/alternative; boundary="0000000000006051e105812dab35" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 23:07:16 -0000 --0000000000006051e105812dab35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Filip did some testing along these lines awhile back. Although I think he was more focused on the other side of things by instructing the fetch/XHR request to omit sending credentials. The behavior he saw was that he wasn't able to suppress the certificate selection prompting as expected or hoped. But I don't think he'd say that the tests were exhaustive or conclusive (and again wasn't about the ACAC header so much as the request API). Also I wouldn't be surprised if browser implementations of a rather niche and software layer crossing part of a living standard aren't fully baked. I mean, I think the browser has to establish a TLS connection where it will be asked for client certs during the handshake in order to send the preflight request so as to get back (or not) the CORS Access-Control headers. So I guess it would have to ignore the CertificateRequest message in the handshake (and hope the server considers certs optional) and then, if the preflight response had ACAC:true, reestablish the TLS connection and do cert selection prompting before sending the actual request. Or if no ACAC:true header, then keep using the prior connection. Maybe I've gone off the rails there but I think the point was that it's complicated and so some rough edges on the implementations in the wild or misunderstanding of expected behavior aren't out of the question. Also I think you need something more on a POST request to the token endpoint, like some custom header, to trigger the whole preflight dance. A simple POST request is not preflighted so the ACAC isn't about sending credentials but about the browser rejecting a response that does not have the ACAC:true header and not making the response available to the invoking script. Anyway, with that rambling out of the way, I think that Neil's suggestion falls into the category of things (along with things like method/body preserving redirects, renegotiation, post-handshake client auth) that might be usable to suppress or avoid browser cert selection UX in the arguably not too common cases it happens. On Tue, Feb 5, 2019 at 9:17 AM Neil Madden wrote: > I=E2=80=99m less and less convinced that a redirect is the best way to do= this. > > I was reading the WHATWG Fetch spec yesterday, in particular the entries > about CORS, and realised that for cross-origin requests TLS client > certificates are treated as credentials just like cookies: > https://fetch.spec.whatwg.org/#credentials > > Credentials are HTTP cookies, TLS client certificates, and > authentication entries (for HTTP authentication) > > So assuming that web browser clients calling the token endpoint will most > likely be calling cross-origin, then it seems that client certificates > won=E2=80=99t be sent anyway unless Access-Control-Allow-Credentials: tru= e is > returned from the preflight request. Given that calls to the token endpoi= nt > shouldn=E2=80=99t generally require cookies, then it seems likely that yo= u can just > *not* allow credentials in the CORS response and therefore not have any > problem with prompting users for certificates. (Note that you can still > manually set the Authorization header without ACAC set to true, you just > have to whitelist that header in the AC-Allowed-Headers response). > > I haven=E2=80=99t got time to test it myself right now, but if so that se= ems like > it side-steps the issue pretty neatly. Configure the token endpoint to as= k > for, but not require, client certs, and then make sure you don=E2=80=99t = return > Access-Control-Allow-Credentials: true on CORS preflight requests to that > endpoint. > > =E2=80=94 Neil > > > On 5 Feb 2019, at 15:21, Justin Richer wrote: > > > > +1 to David. If it=E2=80=99s a redirect, 307 is more appropriate. It=E2= =80=99s up to the > AS to decide if the client should do MTLS or not, if there=E2=80=99s an o= ption. > > > > =E2=80=94 Justin > > > >> On Feb 4, 2019, at 12:17 PM, David Waite > wrote: > >> > >> My understanding is that a permanent redirect would be telling the > client (and any other clients getting cached results from an intermediary= ) > to now stop using the original endpoint in perpetuity for all cases. I > don=E2=80=99t think that is appropriate (in the general case) for an endp= oint with > request processing business logic behind it, since that logic may change > over time. > >> > >> -DW > >> > >>> On Feb 4, 2019, at 6:28 AM, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >>> > >>> Yeah, probably. > >>> > >>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden > wrote: > >>> If we go down the 307 route, shouldn=E2=80=99t it rather be a 308 (pe= rmanent) > redirect? It seems unnecessary for the client to keep trying the original > endpoint or have to remember cache-control/expires timeouts. > >>> > >>> =E2=80=94 Neil > >> > >> _______________________________________________ > >> OAuth mailing 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 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000006051e105812dab35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Filip did= some testing along these lines awhile back. Although I think he was more f= ocused on the other side of things by instructing the fetch/XHR request to = omit sending credentials. The behavior he saw was that he wasn't able t= o suppress the certificate selection prompting as expected or hoped. But I = don't think he'd say that the tests were exhaustive or conclusive (= and again wasn't about the ACAC header so much as the request API). Als= o I wouldn't be surprised if browser implementations of a rather niche = and software layer crossing part of a living standard aren't fully bake= d. I mean, I think the browser has to establish a TLS connection where it w= ill be asked for client certs during the handshake in order to send the pre= flight request so as to get back (or not) the CORS Access-Control headers. = So I guess it would have to ignore the CertificateRequest message in the ha= ndshake (and hope the server considers certs optional) and then, if the pre= flight response had ACAC:true, reestablish the TLS connection and do cert s= election prompting before sending the actual request. Or if no ACAC:true he= ader, then keep using the prior connection. Maybe I've gone off the rai= ls there but I think the point was that it's complicated and so some ro= ugh edges on the implementations in the wild or misunderstanding of expecte= d behavior aren't out of the question. Also I think you need something = more on a POST request to the token endpoint, like some custom header, to t= rigger the whole preflight dance. A simple POST request is not preflighted = so the ACAC isn't about sending credentials but about the browser rejec= ting a response that does not have the ACAC:true header and not making the = response available to the invoking script.

An= yway, with that rambling out of the way, I think that Neil's suggestion= falls into the category of things (along with things like method/body pres= erving redirects, renegotiation, post-handshake client auth) that might be = usable to suppress or avoid browser cert selection UX in the arguably not t= oo common cases it happens.=C2=A0



=
On Tue, Fe= b 5, 2019 at 9:17 AM Neil Madden <neil.madden@forgerock.com> wrote:
=
I=E2=80=99m less and less= convinced that a redirect is the best way to do this.

I was reading the WHATWG Fetch spec yesterday, in particular the entries ab= out CORS, and realised that for cross-origin requests TLS client certificat= es are treated as credentials just like cookies: https://f= etch.spec.whatwg.org/#credentials

=C2=A0 =C2=A0 Credentials are HTTP cookies, TLS client certificates, and au= thentication entries (for HTTP authentication)

So assuming that web browser clients calling the token endpoint will most l= ikely be calling cross-origin, then it seems that client certificates won= =E2=80=99t be sent anyway unless Access-Control-Allow-Credentials: true is = returned from the preflight request. Given that calls to the token endpoint= shouldn=E2=80=99t generally require cookies, then it seems likely that you= can just *not* allow credentials in the CORS response and therefore not ha= ve any problem with prompting users for certificates. (Note that you can st= ill manually set the Authorization header without ACAC set to true, you jus= t have to whitelist that header in the AC-Allowed-Headers response).

I haven=E2=80=99t got time to test it myself right now, but if so that seem= s like it side-steps the issue pretty neatly. Configure the token endpoint = to ask for, but not require, client certs, and then make sure you don=E2=80= =99t return Access-Control-Allow-Credentials: true on CORS preflight reques= ts to that endpoint.

=E2=80=94 Neil

> On 5 Feb 2019, at 15:21, Justin Richer <jricher@mit.edu> wrote:
>
> +1 to David. If it=E2=80=99s a redirect, 307 is more appropriate. It= =E2=80=99s up to the AS to decide if the client should do MTLS or not, if t= here=E2=80=99s an option.
>
> =E2=80=94 Justin
>
>> On Feb 4, 2019, at 12:17 PM, David Waite <david@alkaline-solutions.com> wrote:
>>
>> My understanding is that a permanent redirect would be telling the= client (and any other clients getting cached results from an intermediary)= to now stop using the original endpoint in perpetuity for all cases. I don= =E2=80=99t think that is appropriate (in the general case) for an endpoint = with request processing business logic behind it, since that logic may chan= ge over time.
>>
>> -DW
>>
>>> On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org> wrote:
>>>
>>> Yeah, probably.
>>>
>>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <neil.madden@forgerock.com<= /a>> wrote:
>>> If we go down the 307 route, shouldn=E2=80=99t it rather be a = 308 (permanent) redirect? It seems unnecessary for the client to keep tryin= g the original endpoint or have to remember cache-control/expires timeouts.=
>>>
>>> =E2=80=94 Neil
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000006051e105812dab35-- From nobody Tue Feb 5 15:36:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F368B131362 for ; Tue, 5 Feb 2019 15:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRJzMWGXyfqj for ; Tue, 5 Feb 2019 15:36:05 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA4C131354 for ; Tue, 5 Feb 2019 15:36:05 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id i145so1989818ita.4 for ; Tue, 05 Feb 2019 15:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+XIKGsUU+deXQwgJVdw3i7wpCiuFcheljDZpSGsKLcM=; b=VwOE+dicRYh2pSoBSsJr4ZwHRTKKbfzEeka+/4riHjuwojU8syThKNBvxHGirtEDHq evxALwNOuVN5pmECGCoWgkpKnNB9ijHawzfVN3UViItWwdIUBI0Rqh7RV3nrjQ/wtAGM tW/ETqTmOuabjDmbOtxg1WAs4BqfuzqmulH54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+XIKGsUU+deXQwgJVdw3i7wpCiuFcheljDZpSGsKLcM=; b=rPNJW6dHZQC8LM8d6xXD7nyawJCKYbzEJX/kTC6u890otNKmq1njAntvuhuU714h/C fsVtuBi/bjeaHH0Ka50bqSdGR0xJCCthoiE5FX8VOW/9uSrgMekHqQh2I1iNxIPdoAJF YiYGClW/8vh5wt32H6raF/O2Dcx1lGclPo9jd6j1ouxSfo3hVhezS2WPbMLTtqMMQZIk 3/ZndKUItxIcYoChrdrM3n8IVSw9/iIeN9rYCIUbvBJVV3j4t3TdMi0rN937BEXs6jUy kbh7cv61d/7b4pn7y1rllL7lfrdXdjfuGOhAnmypp/b+Ctnz12xPO8gIlzKkMKj6eaUR fJAA== X-Gm-Message-State: AHQUAuaGI0m9Y0LOR7U9s3snO3LhcgzKQAENzqnK2SKR01S2mgAI3wyb jHhxn5CwX6SlwPpvWEPunm/jsgo2V0HMa+tkuQ/jvZLaGrpALaBnRggxqzkzAAlerVIDG33RLql iPqj9bOOCW8nOhw== X-Google-Smtp-Source: AHgI3IZJSJ6T6jAFsKl6Od4MJpYlS7TzElI1E50oOh0ssK6NJcG62NOJQ08SbrzqdSSXweN/zynL2+eh08oEcgdWnrY= X-Received: by 2002:a6b:b408:: with SMTP id d8mr3618798iof.138.1549409764307; Tue, 05 Feb 2019 15:36:04 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> In-Reply-To: <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> From: Brian Campbell Date: Tue, 5 Feb 2019 16:35:37 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="0000000000009d13a105812e1212" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 23:36:11 -0000 --0000000000009d13a105812e1212 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic. The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though. On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle wrote: > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Monday, February 4, 2019 at 5:28 AM > *To: *"Richard Backman, Annabelle" > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Date: *Friday, February 1, 2019 at 3:17 PM > *To: *"Richard Backman, Annabelle" > *Cc: *George Fletcher , oauth > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher <40aol.com@dmarc...ietf.org>> > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000009d13a105812e1212 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It may well be due to my= own intellectual shortcomings but these issues/questions/confusion-points = are not resonating for me as being problematic.
=
The more general stance of "this isn't needed or wo= rth it in this document" (I think that's far?) is being heard thou= gh.



On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle &= lt;richanna=3D40amazon.com@d= marc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /u>

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIR= ED unless only the implicit grant type is supported.=E2=80=9D So what does = the mTLS-only AS put here?
  2. The claims for these oth= er endpoints are OPTIONAL, potentially leading to inconsistency depending o= n how #1 gets decided.
  3. The example usage of the = token_endpoint_auth_methods property given earlier is incompatible with RFC= 8414, since some of its contents are only valid for the non-mTLS endpoints,= and others are only valid for the mTLS endpoints. Hence this question.<= u>
  4. This introduces a new metadata property that could imp= act how other specs should extend AS metadata. That needs to be addressed.<= u>

=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good= times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I = don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed he= re sufficiently deals with the fallout from that. In my view this is a comple= x enough issue and it=E2=80=99s for a nuanced enough use case (as far as I = can tell from discussion? Please correct me if I=E2=80=99m wrong) that we s= hould punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the= door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion o= n it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000009d13a105812e1212-- From nobody Wed Feb 6 04:40:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735DE1292F1 for ; Wed, 6 Feb 2019 04:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk93nyJAA34X for ; Wed, 6 Feb 2019 04:40:01 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD63C128D09 for ; Wed, 6 Feb 2019 04:40:00 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id s16so2213697vsk.4 for ; Wed, 06 Feb 2019 04:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wGpMu3a/f/c6GiSXZaguqXHLsdG3+dRB75IHxTROMzI=; b=tRRSbqIkD1LkNh6b/Su+j3O5HOU8zT/u2O7tYTaW06hWR0tV52iMJKJwxCVHl6v8A7 nOyWwotyIfLXdcG1HUNh4/qwZpj+P5z9bGNbYBs4uLrMaARqnJddTdF74/yx8D4pMxnj +fony+VLmdGAhRK1gHoAhkyHvqWv9XHRBhwqGafffMopp44WHcl3jMu9YEgkffheFFSL HK15Ed1OuCltyBLO0Zo/j6yPCywr54aI3wAwkkwuGrx0wvO2Kk6rRkRL6+zCW0gMML+S pVRuj9/tXOjVJhqK0VCPJHikBr8FSZWv8/cVp0xFGeljUCqy4O5KEWG/nQK0usYheocq eOgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wGpMu3a/f/c6GiSXZaguqXHLsdG3+dRB75IHxTROMzI=; b=gtVTrlxIk9CTfBzxIdiRrIilrdRHA7hYcoJ3vmDGplY/NG4tnQ1oxtthXwXS2gtQBZ DqNKBCrxccsvpACazk80GRkin5X7LvJPP0qri3GSb8xSUAaa1kBiNuK4Mq/0fOIp43YH v/I6DNgI398I7r4mzXhyRayJKat5aQ+mtK0zrEufVxmBwAKe4RVCnLjxGoQeCq2uT6+P YOvHbcg+xcpl1/olp/F35x5qJJ1H0XzG8EdwALdPTv3Nq432Ziu3UR9rg9loAWdbLlS2 O/ZXA75sT2YSHi3JUH4C4mt9FD7hcjeP9l98kIAmzVeIbunqWz6FbORuIYGK5iBtogZB zI7A== X-Gm-Message-State: AHQUAub+7/Lc2c/BkYq8GlwOcTF681nNo3GK/p0eRNwWZNLodaIax4lj B9GVlm+Hq7oDi9D5+APg834KyKvEefx/950XY08bNeg= X-Google-Smtp-Source: AHgI3IarDoAQUJ3T+heK6Cb/6n9N8lTtMXmrdAKtdQZy6FDjt+FbrBj/PEEIBBlLH32m2mY9eraTekh/IFaGcRrbSOE= X-Received: by 2002:a67:99c2:: with SMTP id b185mr4124074vse.84.1549456799410; Wed, 06 Feb 2019 04:39:59 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a1f:95d4:0:0:0:0:0 with HTTP; Wed, 6 Feb 2019 04:39:58 -0800 (PST) In-Reply-To: References: From: Yong Ali Date: Wed, 6 Feb 2019 19:39:58 +0700 Message-ID: To: "oauth@ietf.org" , Yong Ali Iphone , Yong Ali Iphone Content-Type: multipart/alternative; boundary="0000000000001fb3a20581390619" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 124, Issue 18 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 12:40:02 -0000 --0000000000001fb3a20581390619 Content-Type: text/plain; charset="UTF-8" Pada Rabu, 06 Februari 2019, menulis: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > --0000000000001fb3a20581390619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Pada Rabu, 06 Februari 2019, <oauth-request@ietf.org> menulis:
Send OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.or= g

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth=
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth= -request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-o= wner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
--0000000000001fb3a20581390619-- From nobody Wed Feb 6 11:16:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D498130F36 for ; Wed, 6 Feb 2019 11:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pF-YxHiEALln for ; Wed, 6 Feb 2019 11:16:13 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9E312426A for ; Wed, 6 Feb 2019 11:16:13 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id z20so8802535itc.3 for ; Wed, 06 Feb 2019 11:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pk2YnXQ3sqI31S+Y5tZT1c75lZKX1VKATDuJwpoAr4M=; b=ZukrruSvlJjNOS6C/2XyLZPbC6SlPutohUTpb0IYbOeF3ib0zo5i5X7qqBs3Fh6IMp rgkzo5onJKtUQyyduVdKAvRw8Z9SVLE+65PF3q1cHKEAd5lPZgTagAKaowllW2gsAQjZ 9QWoB7PNMbr7jy+y0u+n1+Mf8g2VlXHfSNeGg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pk2YnXQ3sqI31S+Y5tZT1c75lZKX1VKATDuJwpoAr4M=; b=fqxObDWd6C12UM3WfcGf6KyQSlxVxXf5vXzpRoXTwRQJJQvA01SznGxOd1xhNs1Yff QbgcXfzU0jWp4/6kyfNpa+/GEMSmugc9UQ4phLjcJx1cDrQj0U7jAHk+3pE//yziYcES fBNrZfMPfITS0or+ekEpfGM8k4Td3DdYMOLjfpr0yv5Y04qoVjt/OS6ORCK9KHNwg87u 3NIhbWa3p7qGkbUpSSqdpzfEBVndPdrRyawuAs+FM1y//2RWBi6kP4q70AKBUrs0KMOE yccPj512FVSATCMOR0AVPvpIRE1f4U1OSUJ+OC7cbu+s52/4B0t5ZeUyM3g/0kAVW202 +LOg== X-Gm-Message-State: AHQUAuYGFu29Hb4z4XswSnjBSlA6NkVUSDU+EekIaq7YNu6mEDR2J/Qd RBJWS+yuDJdFsDTOL2QXoMS/bXDfa51H1cjLd1UaqDAfvNpIyO8I7+MXELwhgKP/f+EP1LM3aFV 5bEvszf2EL7qZKw== X-Google-Smtp-Source: AHgI3IabMEUF/icqn0LKNgtCL1XjZAcESmw3KhsGzUK7NyUsEoMwA+nQbAKiad5dEaXrd7yLtwM93UDSD0SbxcHUhCM= X-Received: by 2002:a24:3987:: with SMTP id l129mr2912494ita.45.1549480572283; Wed, 06 Feb 2019 11:16:12 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> In-Reply-To: From: Brian Campbell Date: Wed, 6 Feb 2019 12:15:45 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="00000000000019127305813e8ffe" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:16:18 -0000 --00000000000019127305813e8ffe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "far" should have said "fair" in the previous message On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> (TL;DR: punt AS metadata to a separate draft) >> >> AS points #1-3 are all questions I would have as an implementer: >> >> 1. Section 2 of RFC8414 >> says token_endpoint >> =E2=80=9Cis REQUIRED unless only the implicit grant type is supported= .=E2=80=9D So what >> does the mTLS-only AS put here? >> 2. The claims for these other endpoints are OPTIONAL, potentially >> leading to inconsistency depending on how #1 gets decided. >> 3. The example usage of the token_endpoint_auth_methods property >> given earlier is incompatible with RFC8414, since some of its content= s are >> only valid for the non-mTLS endpoints, and others are only valid for = the >> mTLS endpoints. Hence this question. >> 4. This introduces a new metadata property that could impact how >> other specs should extend AS metadata. That needs to be addressed. >> >> >> >> I could go on for client points but you already get the point. Though >> I=E2=80=99ll share that #3 is real and once forced me to roll back an up= date to the >> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >> >> >> >> I don=E2=80=99t necessarily think an AS metadata property is wrong per s= e, but >> understand that you=E2=80=99re bolting a layer of flexibility onto a sta= ndard that >> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata= proposal as it=E2=80=99s >> been discussed here sufficiently deals with the fallout from that. In my >> view this is a complex enough issue and it=E2=80=99s for a nuanced enoug= h use case >> (as far as I can tell from discussion? Please correct me if I=E2=80=99m = wrong) that >> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serv= er Metadata >> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Brian Campbell >> >> *Date: *Monday, February 4, 2019 at 5:28 AM >> *To: *"Richard Backman, Annabelle" >> *Cc: *oauth >> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> Those points of confusion strike me as somewhat hypothetical or >> hyperbolic. But your general point is taken and your position of being a= nti >> additional metadata on this issue is noted. >> >> >> >> All of which leaves me a bit uncertain about how to proceed. There seem >> to be a range of opinions on this point and gauging consensus is proving >> elusive for me. That's confounded by my own opinion on it being somewhat >> fluid. >> >> >> >> And I'd really like to post an update to this draft about a month or two >> ago. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote: >> >> Confusion from the AS=E2=80=99s perspective: >> >> 1. If I only support mTLS, do I need to include both >> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_u= ri? Or >> set it to the empty string? >> 2. What if I only support mTLS for the token endpoint, but not >> revocation or user info? >> 3. How do I specify authentication methods for the mTLS token >> endpoint? Does token_endpoint_auth_methods apply to both the mTLS and >> non-mTLS endpoints? >> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-e= nabled >> device_authorization_endpoint under mtls_endpoints? >> >> >> >> Confusion from the client=E2=80=99s perspective: >> >> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t k= now anything >> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >> browsers and the AS expects to use that to authenticate me. >> 2. My AS metadata parser crashed because the mTLS-only AS omitted >> token_endpoint_uri. >> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >> encounter a JSON object as a parameter value. >> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints= , what >> do I do? >> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they= told me to use HTTPS, >> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right= ? >> >> >> >> Yes, you can write normative text that answers most of these. But you=E2= =80=99ll >> have to clearly cover a lot of similar-but-slightly-different scenarios = and >> be very explicit. And implementers will still get it wrong. The metadata >> change introduces opportunities for confusion and failure that do not ex= ist >> now, and forces them on everyone who supports mTLS. In contrast, the 307 >> redirect is only required when an AS wants to support both, and is >> unambiguous in its behavior and meaning. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *Brian Campbell >> *Date: *Friday, February 1, 2019 at 3:17 PM >> *To: *"Richard Backman, Annabelle" >> *Cc: *George Fletcher , oauth >> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >> clients using the token endpoint >> >> >> >> It doesn't seem like that confusing or large of a change to me - if the >> client is doing MTLS and the given endpoint is present in `mtls_endpoint= s`, >> then it uses that one. Otherwise it uses the regular endpoint. It gives= an >> AS a lot of flexibility in deployment options. I personally think gettin= g a >> 307 approach deployed and working would be more complicated and error >> prone. >> >> >> >> It is a minority use case at the moment but there are forces in play, >> like the push for increased security in general and to have javascript >> clients use the code flow, that suggest it won't be terribly unusual to = see >> an AS that wants to support MTLS clients and javascript/spa clients at t= he >> same time. >> >> >> >> I've personally wavered back and forth in this thread on whether or not >> to add the new metadata (or something like it). With my reasoning each w= ay >> kinda explained somewhere back in the 40 or so messages that make up thi= s >> thread. But it seems like the rough consensus of the group here is in >> favor of it. >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote: >> >> This strikes me as a very prominent and confusing change to support what >> seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about >> the text needed to clarify when the AS should provide `mtls_endpoints` a= nd >> when the client should use that versus using `token_endpoint.` Why is th= e >> 307 status code insufficient to cover the case where a single AS support= s >> both mTLS and non-mTLS? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of Brian Campbell >> >> *Date: *Friday, February 1, 2019 at 1:31 PM >> *To: *George Fletcher > <40aol.com@dmarc...ietf.org>> >> *Cc: *oauth >> *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token >> endpoint >> >> >> >> Yes, that would work. >> >> >> >> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> What if the AS wants to ONLY support MTLS connections. Does it not >> specify the optional "mtls_endpoints" and just use the normal metadata >> values? >> >> On 1/15/19 8:48 AM, Brian Campbell wrote: >> >> It would definitely be optional, apologies if that wasn't made clear. >> It'd be something to the effect of optional for the AS to include and >> clients doing MTLS would use it when present in AS metadata. >> >> >> >> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >> wrote: >> >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000019127305813e8ffe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"far" should have said &qu= ot;fair" in the previous message





On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell= <bcampbell@pingidentity.c= om> wrote:
It may well be due to = my own intellectual shortcomings but these issues/questions/confusion-point= s are not resonating for me as being problematic.

The more general stance of "this isn't needed or = worth it in this document" (I think that's far?) is being heard th= ough.



On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle= <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /u>

  1. Section 2 of RFC8414 says token_e= ndpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is support= ed.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading = to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth= _methods property given earlier is incompatible with RFC8414, since some of= its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.<= u>
  4. This introduces a new metad= ata property that could impact how other specs should extend AS metadata. T= hat needs to be addressed.

=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good= times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I = don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed he= re sufficiently deals with the fallout from that. In my view this is a comple= x enough issue and it=E2=80=99s for a nuanced enough use case (as far as I = can tell from discussion? Please correct me if I=E2=80=99m wrong) that we s= hould punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the= door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion o= n it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000019127305813e8ffe-- From nobody Wed Feb 6 11:30:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0FD130F39 for ; Wed, 6 Feb 2019 11:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en9bWb_JQHyW for ; Wed, 6 Feb 2019 11:30:00 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A329D130F29 for ; Wed, 6 Feb 2019 11:30:00 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id m62so8786413ith.5 for ; Wed, 06 Feb 2019 11:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xiBfnTMcJVlrccUE0MZ2fiB8WlfCKW4GPoRZoThirhE=; b=WMY7orQmAg/E42J3aBsBrp0oRyfd3SBt5p2zeL/NxxmVi0IoouUN7QHU6jfuPt26E1 7SUCB+g1uHN3NVOaSok/0epKbMota4Kx8A2vz0Pm9YZv6TfXsXKkb9zTWD8MaPjdfG4v OJXJtkSwQptm+QywAeDGYGZKEev10lrgLuBmQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xiBfnTMcJVlrccUE0MZ2fiB8WlfCKW4GPoRZoThirhE=; b=WcR8Ib/zNPOR7BmDc3V3tKkOXe9EbmZdHH+7niFMjVlWqJQkN50VZigFA4onL8UNv+ hSfQgInSvJavviqv6NbZmGnt5LYvX8zcdPbv9A8vAbs2iyLMcoXaLM3pbVYNuty+uk0y 7IVND1XMWlyTcpKj4KbXibRlkaWt+GgR8yDaFsPmNtoS4+oab0dZaydhmEeU8nB9I1kO tTDYst+GN/tw7Tv+tt80oMw7JuG0ZITcg4J9M/O5uR4p53JqVIdQ2/k8Z63tUwP0X78i Ocv8STVXcnwrWHp9MI9iKxq8LTtcS5hj6eb0Dpb/gtC5B1h21J5YB7awd9zy81w7VmkO K0EQ== X-Gm-Message-State: AHQUAuYoL89GuvZGb9b364/vF+75goEsIQROxN/a6tCACPQYfj7TgwM9 SBtT3RH7gvZzm0ncCqaC5y0pWz9QVu0r5IAPCxYyrc/RyuLhejDa2b/VnEaZabBXYACJnBuYeHo mDv6XUwQpuR34zw== X-Google-Smtp-Source: AHgI3IbBo7Nnuk6arXCGdPp5r6O6z9rm24ki03PWGbo8YvHJJUaaSpExXZzm4k9P0ThstG4kH2YBmyr0PMEyTylNfbo= X-Received: by 2002:a5d:8597:: with SMTP id f23mr7220667ioj.238.1549481399686; Wed, 06 Feb 2019 11:29:59 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> In-Reply-To: From: Brian Campbell Date: Wed, 6 Feb 2019 12:29:33 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="0000000000006a375f05813ec016" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 19:30:07 -0000 --0000000000006a375f05813ec016 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more. On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell wrote: > "far" should have said "fair" in the previous message > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > >> It may well be due to my own intellectual shortcomings but these >> issues/questions/confusion-points are not resonating for me as being >> problematic. >> >> The more general stance of "this isn't needed or worth it in this >> document" (I think that's far?) is being heard though. >> >> >> >> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote: >> >>> (TL;DR: punt AS metadata to a separate draft) >>> >>> AS points #1-3 are all questions I would have as an implementer: >>> >>> 1. Section 2 of RFC8414 >>> says token_endpoint >>> =E2=80=9Cis REQUIRED unless only the implicit grant type is supporte= d.=E2=80=9D So what >>> does the mTLS-only AS put here? >>> 2. The claims for these other endpoints are OPTIONAL, potentially >>> leading to inconsistency depending on how #1 gets decided. >>> 3. The example usage of the token_endpoint_auth_methods property >>> given earlier is incompatible with RFC8414, since some of its conten= ts are >>> only valid for the non-mTLS endpoints, and others are only valid for= the >>> mTLS endpoints. Hence this question. >>> 4. This introduces a new metadata property that could impact how >>> other specs should extend AS metadata. That needs to be addressed. >>> >>> >>> >>> I could go on for client points but you already get the point. Though >>> I=E2=80=99ll share that #3 is real and once forced me to roll back an u= pdate to the >>> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>> >>> >>> >>> I don=E2=80=99t necessarily think an AS metadata property is wrong per = se, but >>> understand that you=E2=80=99re bolting a layer of flexibility onto a st= andard that >>> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadat= a proposal as it=E2=80=99s >>> been discussed here sufficiently deals with the fallout from that. In m= y >>> view this is a complex enough issue and it=E2=80=99s for a nuanced enou= gh use case >>> (as far as I can tell from discussion? Please correct me if I=E2=80=99m= wrong) that >>> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Ser= ver Metadata >>> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *OAuth on behalf of Brian Campbell >>> >>> *Date: *Monday, February 4, 2019 at 5:28 AM >>> *To: *"Richard Backman, Annabelle" >> > >>> *Cc: *oauth >>> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> Those points of confusion strike me as somewhat hypothetical or >>> hyperbolic. But your general point is taken and your position of being = anti >>> additional metadata on this issue is noted. >>> >>> >>> >>> All of which leaves me a bit uncertain about how to proceed. There seem >>> to be a range of opinions on this point and gauging consensus is provin= g >>> elusive for me. That's confounded by my own opinion on it being somewha= t >>> fluid. >>> >>> >>> >>> And I'd really like to post an update to this draft about a month or tw= o >>> ago. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org> wrote: >>> >>> Confusion from the AS=E2=80=99s perspective: >>> >>> 1. If I only support mTLS, do I need to include both >>> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_= uri? Or >>> set it to the empty string? >>> 2. What if I only support mTLS for the token endpoint, but not >>> revocation or user info? >>> 3. How do I specify authentication methods for the mTLS token >>> endpoint? Does token_endpoint_auth_methods apply to both the mTLS an= d >>> non-mTLS endpoints? >>> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-= enabled >>> device_authorization_endpoint under mtls_endpoints? >>> >>> >>> >>> Confusion from the client=E2=80=99s perspective: >>> >>> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t = know anything >>> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >>> browsers and the AS expects to use that to authenticate me. >>> 2. My AS metadata parser crashed because the mTLS-only AS omitted >>> token_endpoint_uri. >>> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >>> encounter a JSON object as a parameter value. >>> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoint= s, what >>> do I do? >>> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but the= y told me to use HTTPS, >>> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, righ= t? >>> >>> >>> >>> Yes, you can write normative text that answers most of these. But you= =E2=80=99ll >>> have to clearly cover a lot of similar-but-slightly-different scenarios= and >>> be very explicit. And implementers will still get it wrong. The metadat= a >>> change introduces opportunities for confusion and failure that do not e= xist >>> now, and forces them on everyone who supports mTLS. In contrast, the 30= 7 >>> redirect is only required when an AS wants to support both, and is >>> unambiguous in its behavior and meaning. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *Brian Campbell >>> *Date: *Friday, February 1, 2019 at 3:17 PM >>> *To: *"Richard Backman, Annabelle" >>> *Cc: *George Fletcher , oauth >>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> It doesn't seem like that confusing or large of a change to me - if the >>> client is doing MTLS and the given endpoint is present in `mtls_endpoin= ts`, >>> then it uses that one. Otherwise it uses the regular endpoint. It give= s an >>> AS a lot of flexibility in deployment options. I personally think getti= ng a >>> 307 approach deployed and working would be more complicated and error >>> prone. >>> >>> >>> >>> It is a minority use case at the moment but there are forces in play, >>> like the push for increased security in general and to have javascript >>> clients use the code flow, that suggest it won't be terribly unusual to= see >>> an AS that wants to support MTLS clients and javascript/spa clients at = the >>> same time. >>> >>> >>> >>> I've personally wavered back and forth in this thread on whether or not >>> to add the new metadata (or something like it). With my reasoning each = way >>> kinda explained somewhere back in the 40 or so messages that make up th= is >>> thread. But it seems like the rough consensus of the group here is in >>> favor of it. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org> wrote: >>> >>> This strikes me as a very prominent and confusing change to support wha= t >>> seems to be a minority use case. I=E2=80=99m getting a headache just th= inking about >>> the text needed to clarify when the AS should provide `mtls_endpoints` = and >>> when the client should use that versus using `token_endpoint.` Why is t= he >>> 307 status code insufficient to cover the case where a single AS suppor= ts >>> both mTLS and non-mTLS? >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *OAuth on behalf of Brian Campbell >>> >>> *Date: *Friday, February 1, 2019 at 1:31 PM >>> *To: *George Fletcher >> <40aol.com@dmarc...ietf.org>> >>> *Cc: *oauth >>> *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token >>> endpoint >>> >>> >>> >>> Yes, that would work. >>> >>> >>> >>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher >> 40aol.com@dmarc.ietf.org> wrote: >>> >>> What if the AS wants to ONLY support MTLS connections. Does it not >>> specify the optional "mtls_endpoints" and just use the normal metadata >>> values? >>> >>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>> >>> It would definitely be optional, apologies if that wasn't made clear. >>> It'd be something to the effect of optional for the AS to include and >>> clients doing MTLS would use it when present in AS metadata. >>> >>> >>> >>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >>> wrote: >>> >>> I'm in favour of the `mtls_endpoints` metadata parameter - although it >>> should be optional. >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >> --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000006a375f05813ec016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And I'm honestly really struggling to= see what could have gone wrong with or how token_endpoint_auth_methods bro= ke something with the user info endpoint. If you have the time and/or it= 9;d be informative to this here little discussion, please explain that one = a bit more.

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingiden= tity.com> wrote:
"far" should have = said "fair" in the previous message


=



On Tue, Feb 5, 2019 at 4:35 PM Brian Ca= mpbell <= bcampbell@pingidentity.com> wrote:
It may well be due to my own intellectual shortcomings but these issues/q= uestions/confusion-points are not resonating for me as being problematic. <= br>

The more general stance of "t= his isn't needed or worth it in this document" (I think that's= far?) is being heard though.



On Tue, Feb 5, 2019 at 1:42 PM Ri= chard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /u>

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIR= ED unless only the implicit grant type is supported.=E2=80=9D So what does = the mTLS-only AS put here?
  2. The claims for these o= ther endpoints are OPTIONAL, potentially leading to inconsistency depending= on how #1 gets decided.
  3. The example usage of = the token_endpoint_auth_methods property given earlier is incompatible with= RFC8414, since some of its contents are only valid for the non-mTLS endpoi= nts, and others are only valid for the mTLS endpoints. Hence this question.<= u>
  4. This introduces a new metadata property that could im= pact how other specs should extend AS metadata. That needs to be addressed.=

=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good= times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I = don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed he= re sufficiently deals with the fallout from that. In my view this is a comple= x enough issue and it=E2=80=99s for a nuanced enough use case (as far as I = can tell from discussion? Please correct me if I=E2=80=99m wrong) that we s= hould punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the= door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion o= n it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000006a375f05813ec016-- From nobody Thu Feb 7 07:15:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F01124C04; Thu, 7 Feb 2019 07:15:09 -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=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O2ezl2syi0r; Thu, 7 Feb 2019 07:15:07 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4806F1228B7; Thu, 7 Feb 2019 07:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dN078nYPpU+B5EQ2iGECjuOhYbd+tbcccW6j13IwS4g=; b=PelCxlEk67XgFdXtsPEOCXbCurZF+RiBUKATzcV/acCJQUJxuTzRhZfoAwdGig9lZMcQeN/4UnSuF+oKBfoRKsmqx8AkyMkF9/la7XIFI2IZTGRNNVa4bGiHePgUyUChiCqeG8mTtMBbT00xTcrkIlXxoEpCEcFxn8UqCWMq4Pw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1501.eurprd08.prod.outlook.com (10.167.210.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Thu, 7 Feb 2019 15:15:04 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1580.019; Thu, 7 Feb 2019 15:15:04 +0000 From: Hannes Tschofenig To: Ludwig Seitz , "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUt6gmW8ETQzXQdEeeWnvbq21Io6XUgBEQ Date: Thu, 7 Feb 2019 15:15:03 +0000 Message-ID: References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> In-Reply-To: <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1501; 6:ZLxyx6FwUcfin4hPeGCg7k/TtS8OIfRFBWPH6ISTTNRTUlx9gil46v6ReNmen34CIk9divVJf7gnM+/khW0eNKROgD870K8I93nC0bBmPjFaac2mAV1XpToSiTVUvbHwrd0YuXyGEbL53MMhjsUL0vajvULH2ULwodpgrYB2oAPowvBIS5pIPw0pWCWXpiLo8aBk2x/aAHqTzzgaxMdjl9AS0UUYXRp3n72iSKpRYdd4hecWq2xchZcjM/i+e/FzSl0x8ZTX8hbJk2D7N6NoUIsn+8AhzCOfTr0XZmvJZg9e3okTTN4b5y7ospifpZsWX63XuyjE9Rs3VWcSYtdX56cT7sG7iCJl9Y28MXOz5hdJK53jGrSEblIQwzujZCFXqRUu6Mn3BrjQ+3hgY04yMU+R2e/tc8axk4C2RxCXPDlXtOUwuzBUnsq/yJABGo2V+7HP0cGSh4GYJfe4qJ9hrg==; 5:ZbuW4038m9hqOHZFYp6ksTkNne32fIZWaxXwwHcMJCqcQ+N5keJB87fKet1As1LLyFYutVMKVX2B9gH5Fv2fVW4urHhkfI2EswWpUqV/6l0sxmsf/4UpIUq1oAbfuicaVndmlEd5Hr76lWNqFVTin7qdGTVVCccUWSVPwPigzfaa8JdEqStqXnTJTMTgxx9NZrPDw9NpwqKP9+yYQHctYQ==; 7:SLle2PwO26lfDVBClhKb+cyFFVcw7B6nh8u/VR2BLJSrSHlN4SjFGEnZO6XKiXJNGHEJTW5nLuxVDGChGFR5LtFuMQum11dO+Ez4AyV+ifLBBkItFnW8TWJ0dR78Yz7mVcabHWqi3UVQBongvprigw== x-ms-office365-filtering-correlation-id: a5bb6c7a-c552-43f1-9de2-08d68d0f0964 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1501; x-ms-traffictypediagnostic: VI1PR0801MB1501: x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(366004)(39860400002)(199004)(189003)(40434004)(13464003)(26005)(99286004)(66066001)(3846002)(6116002)(11346002)(446003)(14454004)(93886005)(25786009)(476003)(33656002)(71190400001)(478600001)(229853002)(72206003)(486006)(71200400001)(2501003)(102836004)(6246003)(256004)(5024004)(14444005)(2906002)(966005)(6436002)(8936002)(2201001)(316002)(7696005)(186003)(8676002)(53546011)(6506007)(55016002)(81156014)(81166006)(106356001)(53936002)(9686003)(97736004)(74316002)(7736002)(305945005)(86362001)(105586002)(110136005)(6306002)(68736007)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1501; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5rNLeTqTmgTpNnTxspUP65l5qqiflctw2/6Xn//Dlx49TgaoebkYj+xGg9r2QiIurOIz7jWzGl6GT1kdikwQY4CSY0PIodfvm2eEmCLYZuRVg6YWacfqUTfMu+5LLSnzPWp+EiUP4wm4N2Hj2PpA70TJcs0LL8O5F2VsTVy66nZXUris0deg5tzbwyBlm5y3rZwXONkNnQaC8JsqFb7CYjKrakU6TKkXo0eXm6dQE47N1aSLm70o8jg+/ABxkebOa2wDemB/M7UcM2QOKooZKC1XbAuf8A7LftqtZBoSI8eWyOhA0f40poFSOOewTcJ6R+esgTZaC8/OX55UISFEFP4uiGyxZQp9OyOHXgsYMvv9j5DmCHXFFbgihej8D4LrlH1MSemfxzbGXSeO8AEXTKslXJ1U52z9+LKSnvoDE2o= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5bb6c7a-c552-43f1-9de2-08d68d0f0964 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 15:15:03.9977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1501 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:15:09 -0000 Hi Ludwig, > My interpretation of this is that "resource" refers to a single resource No. Here is the text from token exchange (see last sentence): resource OPTIONAL. Indicates the location of the target service or resource where the client intends to use the requested security token. This enables the authorization server to apply policy as appropriate for the target, such as determining the type and content of the token to be issued or if and how the token is to be encrypted. In many cases, a client will not have knowledge of the logical organization of the systems with which it interacts and will only know the location of the service where it intends to use the token. The "resource" parameter allows the client to indicate to the authorization server where it intends to use the issued token by providing the location, typically as an https URL, in the token exchange request in the same form that will be used to access that resource. The authorization server will typically have the capability to map from a resource URI value to an appropriate policy. The value of the "resource" parameter MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], which MAY include a query component and MUST NOT include a fragment component. Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. Ciao Hannes -----Original Message----- From: OAuth On Behalf Of Ludwig Seitz Sent: Dienstag, 29. Januar 2019 08:56 To: ace@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resour= ce-indicators-01 On 28/01/2019 23:12, George Fletcher wrote: > I also don't know that this raises to the level of "concern" but I > find the parameter name of "req_aud" odd. Given that the parameter in > the resource-indicators spec is 'resource' why not use a parameter > name of 'audience'. That said, I have not read the thread on the ACE > working group list so there could be very good reasons for the chosen > name:) > > I do think that there is a lot of overlap (in most cases) between > 'resource' and 'audience' and having two parameters that cover a lot > of the same semantics is going to be confusing for developers. When > calling an API at a resource server, the 'audience' and the 'resource' > are pretty equivalent. Maybe in other use cases they are distinctly separ= ate? > To give you all the background of "req_aud" from ACE (sorry for the long text): Originally in ACE we had defined the "aud" parameter for requests to the to= ken endpoint with the semantics that the client was requesting a token for = a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token). We were then told that this collided with a use of "aud" in OAuth, that spe= cifies the intended audience of Authorization Servers (if I remember correc= tly), so we decided to rename our parameter to "req_aud" for "requested aud= ience". Mike Jones then made us aware of the work on resource indicators, but upon = closer examination I found the "resource" parameter to be more limited than= the "req_aud", since resource specifically states: "Its value MUST be an absolute URI ... the "resource" parameter URI value i= s an identifier representing the identity of the resource" My interpretation of this is that "resource" refers to a single resource, w= hich is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value. For example my intent was= to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-ke= y), which I cannot do with "resource". We therefore decided to keep the "r= eq_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly ov= erlaps with "resource". Any comments and suggestions about that line of reasoning (especially from = the OAuth point of view) are very welcome. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu Feb 7 07:16:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812361271FF; Thu, 7 Feb 2019 07:16: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=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVsEP2P38HJN; Thu, 7 Feb 2019 07:16:42 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9773F1228B7; Thu, 7 Feb 2019 07:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4x8Ooaa5se687DkFBVYr3HBkVACmJHm65msnZARDuK0=; b=F82auNrVVXYkMHyXdaeldpAF/ZzcogP7591aEVyw7y0p80YaACa48BiBX6TKdDJdqTsu2sBabef/8iIQ2up3wBLivv2nRXAeJotl1j4mFoE2GO2yLIKjuKvnzE0admDK4rNVNgLBoGlPj1XYpAzTTnJNZooIxXHzNtuLW0QrVCc= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1677.eurprd08.prod.outlook.com (10.168.66.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Thu, 7 Feb 2019 15:16:38 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1580.019; Thu, 7 Feb 2019 15:16:38 +0000 From: Hannes Tschofenig To: George Fletcher , Ludwig Seitz , "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUt9StSyg3OJ6I2kOpeSIpgZ6iyqXUgBoQ Date: Thu, 7 Feb 2019 15:16:38 +0000 Message-ID: References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1677; 6:3jKVusn2rlLKLtUh87FM5itJtmr3YOaHiNV81XiBLwt/JGdKcRb1O4Iu76wxqv9w/ftMa3BY0TXhzVM15ECb2TtWqxK7lHxzNhIX+82nt9dtOKrgVTXROmq4QJ3BP+eBOg4fKgLUkD3PlqozWbWnU+CCBTJx8dfmbK1DfGIpeOpArEGeg4qLxthZ6rf2NtowcjThXOAwADn6flt+5ESGVNVa/+xh6ACoZuju6t0n5ip6rOjP4ws86JVV4qmAUvauXFplydDROx+5OVHd0mXzzOXw8149qPWz8jxNsKTFAU7itFnjy9CAAvYFIvc+of2Ui3q40CZQFTDKqVN9Kjex44Cx/SSfBrAQeqcdgso01fjGkpwROjKzryZrNyCpnFTvAxV4HVUbf1GYqXEh1aMqq1I/FBkSkjIE4wBrxKjfn3f4u9PbAB31vKDR13kM82/gVBAV03wbILeUdvU7g/r8ZQ==; 5:ILF4tnPwCztQh9xB8ojBbq31cjxm8v5Wq8VcZLRZT/mhy02aHOTQA83tfK38wsGtAL+6cJDBami/OivB7+UA6L0PVal12524a2VA+f2LkwM5jaHq6QtsV2D5h0IMaT2ToMrWgBwhZHUa7O7hn3tLY7rOu1Lq/dvIin1abb5eWqcwi3gA9gMfq5Zh/ewCZgIGHEzOMX8E7sPy1SZnlWwJLg==; 7:A8x3qundsTpK9yTe1gE+thzjqBoWWFpDVggq3Fk0XKVhNRqLYXLH4uW32+ca95uXRIejL0PCmUOFKrpsPo6nuPDtgoyfh71iJqgHugR2mgO0sd0pcsmbz+j+hFMrIuMuZ3G70E1oq9inc2rL3nh0Pw== x-ms-office365-filtering-correlation-id: ed237e14-2b40-4b79-239c-08d68d0f41ab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1677; x-ms-traffictypediagnostic: VI1PR0801MB1677: x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(366004)(396003)(40434004)(199004)(189003)(2201001)(55016002)(486006)(9326002)(3846002)(97736004)(5024004)(81156014)(6506007)(11346002)(105586002)(53546011)(476003)(53376002)(6436002)(9686003)(478600001)(229853002)(54896002)(6306002)(14454004)(7736002)(71190400001)(606006)(71200400001)(33656002)(68736007)(6246003)(26005)(93886005)(7696005)(66066001)(106356001)(99286004)(72206003)(966005)(25786009)(74316002)(186003)(53936002)(76176011)(102836004)(8676002)(316002)(8936002)(86362001)(81166006)(790700001)(6116002)(110136005)(256004)(14444005)(446003)(236005)(2906002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1677; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1Sv5uYhhyMmJ7mEJBo1UBY0lhigsTCAn8mK9geZg4NLQuH8PVMCMg7S9QL/NMG1A1bcHrDhFwlCg89p+1dlN70NEB6hUmAT3eJmHwRFVsZbT/WMm0cCRhUMTsMk08mWBfoRNJAXYDb28KtdzG5XiaDJeFu/jWcoa5DlCHZHsCj0xF67qYa6Rt1SM6/aCTrlCxgThjpL9Zyt7Mc5ODDxU8/zeWIpa9DrNaGBBPgcTc042oVJr1myNXMZvyCg6XJcAWslYXaMvGnP4YHzVZbLR7uPJVLrkVkgWRWn2+TYrY4XZSDKOp0kIiVl4YoSXNjgAG8oKkdNHAQIZ566si9grRnteLg6bCdnTbkFjeDDdxsubKaX7BOrtoDX9garQAXroV80c0QZtGPxquvDHT21fDUoRh0K0h2rNHs+kpP4qno4= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112ABDD90AEB1208EC656CCFA680VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed237e14-2b40-4b79-239c-08d68d0f41ab X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 15:16:38.3583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1677 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:16:45 -0000 --_000_VI1PR0801MB2112ABDD90AEB1208EC656CCFA680VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2VvcmdlLA0KDQoNCiAgKiAgIEkgYmVsaWV2ZSB0aGF0IHNpbmNlIHRoZSBsYXRlc3QgZHJh ZnQgb2YgdGhlIHJlc291cmNlIGluZGljYXRvcnMgc3BlYyBbMV0gYWxsb3dzIGZvciBhYnN0cmFj dCBpZGVudGlmaWVycywgYW5kIHNpbmNlIGEgVVJOIGlzIGFsc28gYSBVUkksIHlvdSBjb3VsZCBl YXNpbHkgdXNlIGEgVVJOIHN5bnRheCB0byBhY2NvbXBsaXNoIHRoZSB1c2UgY2FzZSBvdXRsaW5l ZCBpbiB5b3VyIGVtYWlsLg0KDQpBZnRlciByZS1yZWFkaW5nIHRoZSB0b2tlbiBleGNoYW5nZSBk cmFmdCBJIHJlYWxpemVkIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IGRlZmluZWQgYSBzZXBhcmF0ZSBw YXJhbWV0ZXIgZm9yIOKAnGFic3RyYWN04oCdLCBvciBsb2dpY2FsLCBuYW1lcyB2aWEgdGhlIGF1 ZGllbmNlIHBhcmFtZXRlci4gSGVyZSBpcyB0aGUgZGVmaW5pdGlvbjoNCg0KICAgYXVkaWVuY2UN CiAgICAgIE9QVElPTkFMLiAgVGhlIGxvZ2ljYWwgbmFtZSBvZiB0aGUgdGFyZ2V0IHNlcnZpY2Ug d2hlcmUgdGhlIGNsaWVudA0KICAgICAgaW50ZW5kcyB0byB1c2UgdGhlIHJlcXVlc3RlZCBzZWN1 cml0eSB0b2tlbi4gIFRoaXMgc2VydmVzIGENCiAgICAgIHB1cnBvc2Ugc2ltaWxhciB0byB0aGUg InJlc291cmNlIiBwYXJhbWV0ZXIsIGJ1dCB3aXRoIHRoZSBjbGllbnQNCiAgICAgIHByb3ZpZGlu ZyBhIGxvZ2ljYWwgbmFtZSByYXRoZXIgdGhhbiBhIGxvY2F0aW9uLiAgSW50ZXJwcmV0YXRpb24N CiAgICAgIG9mIHRoZSBuYW1lIHJlcXVpcmVzIHRoYXQgdGhlIHZhbHVlIGJlIHNvbWV0aGluZyB0 aGF0IGJvdGggdGhlDQogICAgICBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB1 bmRlcnN0YW5kLiAgQW4gT0F1dGggY2xpZW50DQogICAgICBpZGVudGlmaWVyLCBhIFNBTUwgZW50 aXR5IGlkZW50aWZpZXIgW09BU0lTLnNhbWwtY29yZS0yLjAtb3M8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTYjcmVmLU9BU0lTLnNh bWwtY29yZS0yLjAtb3M+XSwgYW4NCiAgICAgIE9wZW5JRCBDb25uZWN0IElzc3VlciBJZGVudGlm aWVyIFtPcGVuSUQuQ29yZTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC10b2tlbi1leGNoYW5nZS0xNiNyZWYtT3BlbklELkNvcmU+XSwgb3IgYSBVUkkgYXJlDQog ICAgICBleGFtcGxlcyBvZiB0aGluZ3MgdGhhdCBtaWdodCBiZSB1c2VkIGFzICJhdWRpZW5jZSIg cGFyYW1ldGVyDQogICAgICB2YWx1ZXMuICBNdWx0aXBsZSAiYXVkaWVuY2UiIHBhcmFtZXRlcnMg bWF5IGJlIHVzZWQgdG8gaW5kaWNhdGUNCiAgICAgIHRoYXQgdGhlIGlzc3VlZCB0b2tlbiBpcyBp bnRlbmRlZCB0byBiZSB1c2VkIGF0IHRoZSBtdWx0aXBsZQ0KICAgICAgYXVkaWVuY2VzIGxpc3Rl ZC4gIFRoZSAiYXVkaWVuY2UiIGFuZCAicmVzb3VyY2UiIHBhcmFtZXRlcnMgbWF5IGJlDQogICAg ICB1c2VkIHRvZ2V0aGVyIHRvIGluZGljYXRlIG11bHRpcGxlIHRhcmdldCBzZXJ2aWNlcyB3aXRo IGEgbWl4IG9mDQogICAgICBsb2dpY2FsIG5hbWVzIGFuZCBsb2NhdGlvbnMuDQoNCkNpYW8NCkhh bm5lcw0KDQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBH ZW9yZ2UgRmxldGNoZXINClNlbnQ6IERpZW5zdGFnLCAyOS4gSmFudWFyIDIwMTkgMTQ6MTUNClRv OiBMdWR3aWcgU2VpdHogPGx1ZHdpZy5zZWl0ekByaS5zZT47IGFjZUBpZXRmLm9yZzsgb2F1dGhA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRlLXVw IGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDENCg0KVGhhbmsgeW91 IHNvIG11Y2ggZm9yIHRoZSBiYWNrZ3JvdW5kIQ0KDQpJIGJlbGlldmUgdGhhdCBzaW5jZSB0aGUg bGF0ZXN0IGRyYWZ0IG9mIHRoZSByZXNvdXJjZSBpbmRpY2F0b3JzIHNwZWMgWzFdIGFsbG93cyBm b3IgYWJzdHJhY3QgaWRlbnRpZmllcnMsIGFuZCBzaW5jZSBhIFVSTiBpcyBhbHNvIGEgVVJJLCB5 b3UgY291bGQgZWFzaWx5IHVzZSBhIFVSTiBzeW50YXggdG8gYWNjb21wbGlzaCB0aGUgdXNlIGNh c2Ugb3V0bGluZWQgaW4geW91ciBlbWFpbC4NCg0KcmVzb3VyY2U9dXJuOngtbXlkZXZpY2VzOnRl bXBlcmF0dXJlU2Vuc29yR3JvdXA0NzExDQoNClRoZSBzcGVjIGN1cnJlbnRseSBvdXRsaW5lcyBl eGFtcGxlcyB3aGVyZSB0aGUgInJlc291cmNlIGlkZW50aWZpZXIiIGlzIG5vdCBhICJzaW5nbGUg cmVzb3VyY2UiIGluIHRoZSBjb250ZXh0IG9mIGEgZnVsbHkgcXVhbGlmaWVkIEFQSSBlbmRwb2lu dC4NCg0KQW5vdGhlciBleGFtcGxlLCBmb3IgYW4gQVBJIGxpa2UgU0NJTSBbUkZDNzY0NDxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY0ND5dIHRoYXQgaGFzDQoNCiAgIG11bHRpcGxl IGVuZHBvaW50cyBzdWNoIGFzICJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9Vc2VycyI8 aHR0cHM6Ly9hcHBzLmV4YW1wbGUuY29tL3NjaW0vVXNlcnM+LA0KDQogICAiaHR0cHM6Ly9hcHBz LmV4YW1wbGUuY29tL3NjaW0vR3JvdXBzIjxodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9H cm91cHM+LCBhbmQNCg0KICAgImh0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltL1NjaGVtYXMi PGh0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltL1NjaGVtYXM+IFRoZSBjbGllbnQgd291bGQg dXNlDQoNCiAgICJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS8iPGh0dHBzOi8vYXBwcy5l eGFtcGxlLmNvbS9zY2ltLz4gYXMgdGhlIHJlc291cmNlIHNvIHRoYXQgdGhlIGlzc3VlZA0KDQog ICBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yIGFsbCB0aGUgZW5kcG9pbnRzIG9mIHRoZSBTQ0lN IEFQSS4NClVzaW5nICJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbSI8aHR0cHM6Ly9hcHBz LmV4YW1wbGUuY29tL3NjaW0+IGlzIHNlbWFudGljYWxseSBlcXVpdmFsZW50IHRvIHVzaW5nICJ0 ZW1wZXJhdHVyZVNlbnNvckdyb3VwNDcxMSIsIGF0IGxlYXN0IHRvIG1lOikNCg0KVGhhbmtzLA0K R2VvcmdlDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQpPbiAxLzI5LzE5IDI6NTYgQU0sIEx1ZHdpZyBTZWl0 eiB3cm90ZToNCk9uIDI4LzAxLzIwMTkgMjM6MTIsIEdlb3JnZSBGbGV0Y2hlciB3cm90ZToNCg0K SSBhbHNvIGRvbid0IGtub3cgdGhhdCB0aGlzIHJhaXNlcyB0byB0aGUgbGV2ZWwgb2YgImNvbmNl cm4iIGJ1dCBJIGZpbmQgdGhlIHBhcmFtZXRlciBuYW1lIG9mICJyZXFfYXVkIiBvZGQuIEdpdmVu IHRoYXQgdGhlIHBhcmFtZXRlciBpbiB0aGUgcmVzb3VyY2UtaW5kaWNhdG9ycyBzcGVjIGlzICdy ZXNvdXJjZScgd2h5IG5vdCB1c2UgYSBwYXJhbWV0ZXIgbmFtZSBvZiAnYXVkaWVuY2UnLiBUaGF0 IHNhaWQsIEkgaGF2ZSBub3QgcmVhZCB0aGUgdGhyZWFkIG9uIHRoZSBBQ0Ugd29ya2luZyBncm91 cCBsaXN0IHNvIHRoZXJlIGNvdWxkIGJlIHZlcnkgZ29vZCByZWFzb25zIGZvciB0aGUgY2hvc2Vu IG5hbWU6KQ0KDQpJIGRvIHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBsb3Qgb2Ygb3ZlcmxhcCAoaW4g bW9zdCBjYXNlcykgYmV0d2VlbiAncmVzb3VyY2UnIGFuZCAnYXVkaWVuY2UnIGFuZCBoYXZpbmcg dHdvIHBhcmFtZXRlcnMgdGhhdCBjb3ZlciBhIGxvdCBvZiB0aGUgc2FtZSBzZW1hbnRpY3MgaXMg Z29pbmcgdG8gYmUgY29uZnVzaW5nIGZvciBkZXZlbG9wZXJzLiBXaGVuIGNhbGxpbmcgYW4gQVBJ IGF0IGEgcmVzb3VyY2Ugc2VydmVyLCB0aGUgJ2F1ZGllbmNlJyBhbmQgdGhlICdyZXNvdXJjZScg YXJlIHByZXR0eSBlcXVpdmFsZW50LiBNYXliZSBpbiBvdGhlciB1c2UgY2FzZXMgdGhleSBhcmUg ZGlzdGluY3RseSBzZXBhcmF0ZT8NCg0KVG8gZ2l2ZSB5b3UgYWxsIHRoZSBiYWNrZ3JvdW5kIG9m ICJyZXFfYXVkIiBmcm9tIEFDRSAoc29ycnkgZm9yIHRoZSBsb25nIHRleHQpOg0KDQpPcmlnaW5h bGx5IGluIEFDRSB3ZSBoYWQgZGVmaW5lZCB0aGUgImF1ZCIgcGFyYW1ldGVyIGZvciByZXF1ZXN0 cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCB0aGUgc2VtYW50aWNzIHRoYXQgdGhlIGNsaWVu dCB3YXMgcmVxdWVzdGluZyBhIHRva2VuIGZvciBhIGNlcnRhaW4gYXVkaWVuY2UgKGkuZS4gcmVx dWVzdGluZyB0aGF0IHRoZSBBUyBjb3B5IHRoZSAiYXVkIiBwYXJhbWV0ZXIgdmFsdWUgaW50byB0 aGUgImF1ZCIgY2xhaW0gdmFsdWUgb2YgdGhlIHRva2VuKS4NCldlIHdlcmUgdGhlbiB0b2xkIHRo YXQgdGhpcyBjb2xsaWRlZCB3aXRoIGEgdXNlIG9mICJhdWQiIGluIE9BdXRoLCB0aGF0IHNwZWNp ZmllcyB0aGUgaW50ZW5kZWQgYXVkaWVuY2Ugb2YgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIChpZiBJ IHJlbWVtYmVyIGNvcnJlY3RseSksIHNvIHdlIGRlY2lkZWQgdG8gcmVuYW1lIG91ciBwYXJhbWV0 ZXIgdG8gInJlcV9hdWQiIGZvciAicmVxdWVzdGVkIGF1ZGllbmNlIi4NCk1pa2UgSm9uZXMgdGhl biBtYWRlIHVzIGF3YXJlIG9mIHRoZSB3b3JrIG9uIHJlc291cmNlIGluZGljYXRvcnMsIGJ1dCB1 cG9uIGNsb3NlciBleGFtaW5hdGlvbiBJIGZvdW5kIHRoZSAicmVzb3VyY2UiIHBhcmFtZXRlciB0 byBiZSBtb3JlIGxpbWl0ZWQgdGhhbiB0aGUgInJlcV9hdWQiLCBzaW5jZSByZXNvdXJjZSBzcGVj aWZpY2FsbHkgc3RhdGVzOg0KDQoiSXRzIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJIC4u LiB0aGUgInJlc291cmNlIiBwYXJhbWV0ZXIgVVJJIHZhbHVlIGlzIGFuIGlkZW50aWZpZXIgcmVw cmVzZW50aW5nIHRoZSBpZGVudGl0eSBvZiB0aGUgcmVzb3VyY2UiDQoNCk15IGludGVycHJldGF0 aW9uIG9mIHRoaXMgaXMgdGhhdCAicmVzb3VyY2UiIHJlZmVycyB0byBhIHNpbmdsZSByZXNvdXJj ZSwgd2hpY2ggaXMgbW9yZSBjb25zdHJhaW5lZCB0aGFuIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAi YXVkIiBjbGFpbSBmcm9tIDc1MTksIHdoaWNoIHVzZXMgYSBTdHJpbmdPclVSSSB2YWx1ZS4gIEZv ciBleGFtcGxlIG15IGludGVudCB3YXMgdG8gdXNlICJhdWQiIGFuZCAicmVxX2F1ZCIgZm9yIGdy b3VwIGlkZW50aWZpZXJzICgidGVtcGVyYXR1cmVTZW5zb3JHcm91cDQ3MTEiKSBhbmQgb3RoZXIg bm9uLXVyaSBzdHJpbmdzIChoYXNoLW9mLXB1YmxpYy1rZXkpLCB3aGljaCBJIGNhbm5vdCBkbyB3 aXRoICJyZXNvdXJjZSIuICBXZSB0aGVyZWZvcmUgZGVjaWRlZCB0byBrZWVwIHRoZSAicmVxX2F1 ZCIgcGFyYW1ldGVyIGluIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcywgZXZlbiB0aG91Z2gg aXMgY2xlYXJseSBvdmVybGFwcyB3aXRoICJyZXNvdXJjZSIuDQoNCkFueSBjb21tZW50cyBhbmQg c3VnZ2VzdGlvbnMgYWJvdXQgdGhhdCBsaW5lIG9mIHJlYXNvbmluZyAoZXNwZWNpYWxseSBmcm9t IHRoZSBPQXV0aCBwb2ludCBvZiB2aWV3KSBhcmUgdmVyeSB3ZWxjb21lLg0KDQovTHVkd2lnDQoN Cg0KDQoNCi0tDQoNCklkZW50aXR5IFN0YW5kYXJkcyBBcmNoaXRlY3QNCg0KVmVyaXpvbiBNZWRp YSAgICAgICAgICAgICAgICAgICAgIFdvcms6IGdlb3JnZS5mbGV0Y2hlckBvYXRoLmNvbTxtYWls dG86Z2VvcmdlLmZsZXRjaGVyQG9hdGguY29tPg0KDQpNb2JpbGU6ICsxLTcwMy00NjItMzQ5NCAg ICAgICAgICAgVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL2dmZmxldGNoDQoNCk9mZmljZTog KzEtNzAzLTI2NS0yNTQ0ICAgICAgICAgICBQaG90b3M6IGh0dHA6Ly9nZW9yZ2VmbGV0Y2hlci5w aG90b2dyYXBoeQ0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9y ZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112ABDD90AEB1208EC656CCFA680VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjc2NDE1MTAyNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6ODY0NTc1ODk0IC0zMDAzNzgxMTAgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMg MTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 RGVuZ1hpYW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDo5MDE4NjQ3ODI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi03NzgyNDcyNTYgMTIxNTYyMTYwNiAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEz NDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpEZW5nWGlhbjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgR2VvcmdlLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21h cmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkg YmVsaWV2ZSB0aGF0IHNpbmNlIHRoZSBsYXRlc3QgZHJhZnQgb2YgdGhlIHJlc291cmNlIGluZGlj YXRvcnMgc3BlYyBbMV0gYWxsb3dzIGZvciBhYnN0cmFjdCBpZGVudGlmaWVycywgYW5kIHNpbmNl IGEgVVJOIGlzIGFsc28gYSBVUkksIHlvdSBjb3VsZCBlYXNpbHkgdXNlIGEgVVJOIHN5bnRheCB0 byBhY2NvbXBsaXNoIHRoZSB1c2UgY2FzZQ0KIG91dGxpbmVkIGluIHlvdXIgZW1haWwuPGJyPg0K PGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QWZ0ZXIgcmUtcmVhZGluZyB0aGUgdG9rZW4gZXhjaGFuZ2UgZHJhZnQgSSByZWFsaXplZCB0aGF0 IHdlIGhhdmUgYWxyZWFkeSBkZWZpbmVkIGEgc2VwYXJhdGUgcGFyYW1ldGVyIGZvciDigJxhYnN0 cmFjdOKAnSwgb3IgbG9naWNhbCwgbmFtZXMgdmlhIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXIuIEhl cmUgaXMgdGhlIGRlZmluaXRpb246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgYXVkaWVuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElPTkFM LiZuYnNwOyBUaGUgbG9naWNhbCBuYW1lIG9mIHRoZSB0YXJnZXQgc2VydmljZSB3aGVyZSB0aGUg Y2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRlbmRzIHRvIHVzZSB0aGUgcmVx dWVzdGVkIHNlY3VyaXR5IHRva2VuLiZuYnNwOyBUaGlzIHNlcnZlcyBhPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBwdXJwb3NlIHNpbWlsYXIgdG8gdGhlICZxdW90O3Jlc291cmNlJnF1b3Q7 IHBhcmFtZXRlciwgYnV0IHdpdGggdGhlIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcHJvdmlkaW5nIGEgbG9naWNhbCBuYW1lIHJhdGhlciB0aGFuIGEgbG9jYXRpb24uJm5ic3A7 IEludGVycHJldGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiB0aGUgbmFtZSBy ZXF1aXJlcyB0aGF0IHRoZSB2YWx1ZSBiZSBzb21ldGhpbmcgdGhhdCBib3RoIHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg dW5kZXJzdGFuZC4mbmJzcDsgQW4gT0F1dGggY2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpZGVudGlmaWVyLCBhIFNBTUwgZW50aXR5IGlkZW50aWZpZXIgWzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTE2 I3JlZi1PQVNJUy5zYW1sLWNvcmUtMi4wLW9zIiB0aXRsZT0iJnF1b3Q7QXNzZXJ0aW9ucyBhbmQg UHJvdG9jb2wgZm9yIHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdl IChTQU1MKSBWMi4wJnF1b3Q7Ij5PQVNJUy5zYW1sLWNvcmUtMi4wLW9zPC9hPl0sDQogYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9wZW5JRCBDb25uZWN0IElzc3VlciBJZGVudGlmaWVy IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10 b2tlbi1leGNoYW5nZS0xNiNyZWYtT3BlbklELkNvcmUiIHRpdGxlPSImcXVvdDtPcGVuSUQgQ29u bmVjdCBDb3JlIDEuMCZxdW90OyI+T3BlbklELkNvcmU8L2E+XSwNCiBvciBhIFVSSSBhcmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4YW1wbGVzIG9mIHRoaW5ncyB0aGF0IG1pZ2h0IGJl IHVzZWQgYXMgJnF1b3Q7YXVkaWVuY2UmcXVvdDsgcGFyYW1ldGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB2YWx1ZXMuJm5ic3A7IE11bHRpcGxlICZxdW90O2F1ZGllbmNlJnF1b3Q7IHBh cmFtZXRlcnMgbWF5IGJlIHVzZWQgdG8gaW5kaWNhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoYXQgdGhlIGlzc3VlZCB0b2tlbiBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGF0IHRoZSBt dWx0aXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXVkaWVuY2VzIGxpc3RlZC4mbmJz cDsgVGhlICZxdW90O2F1ZGllbmNlJnF1b3Q7IGFuZCAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJh bWV0ZXJzIG1heSBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlZCB0b2dldGhlciB0 byBpbmRpY2F0ZSBtdWx0aXBsZSB0YXJnZXQgc2VydmljZXMgd2l0aCBhIG1peCBvZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbG9naWNhbCBuYW1lcyBhbmQgbG9jYXRpb25zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBBY2UgJmx0O2FjZS1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwv Yj5HZW9yZ2UgRmxldGNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gRGllbnN0YWcsIDI5LiBKYW51YXIg MjAxOSAxNDoxNTxicj4NCjxiPlRvOjwvYj4gTHVkd2lnIFNlaXR6ICZsdDtsdWR3aWcuc2VpdHpA cmkuc2UmZ3Q7OyBhY2VAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbQWNlXSBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1pZXRm LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rIHlvdSBzbyBtdWNoIGZvciB0aGUgYmFja2dyb3Vu ZCENCjxicj4NCjxicj4NCkkgYmVsaWV2ZSB0aGF0IHNpbmNlIHRoZSBsYXRlc3QgZHJhZnQgb2Yg dGhlIHJlc291cmNlIGluZGljYXRvcnMgc3BlYyBbMV0gYWxsb3dzIGZvciBhYnN0cmFjdCBpZGVu dGlmaWVycywgYW5kIHNpbmNlIGEgVVJOIGlzIGFsc28gYSBVUkksIHlvdSBjb3VsZCBlYXNpbHkg dXNlIGEgVVJOIHN5bnRheCB0byBhY2NvbXBsaXNoIHRoZSB1c2UgY2FzZSBvdXRsaW5lZCBpbiB5 b3VyIGVtYWlsLjxicj4NCjxicj4NCnJlc291cmNlPXVybjp4LW15ZGV2aWNlczp0ZW1wZXJhdHVy ZVNlbnNvckdyb3VwNDcxMTxicj4NCjxicj4NClRoZSBzcGVjIGN1cnJlbnRseSBvdXRsaW5lcyBl eGFtcGxlcyB3aGVyZSB0aGUgJnF1b3Q7cmVzb3VyY2UgaWRlbnRpZmllciZxdW90OyBpcyBub3Qg YSAmcXVvdDtzaW5nbGUgcmVzb3VyY2UmcXVvdDsgaW4gdGhlIGNvbnRleHQgb2YgYSBmdWxseSBx dWFsaWZpZWQgQVBJIGVuZHBvaW50Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkFu b3RoZXIgZXhhbXBsZSwgZm9yIGFuIEFQSSBsaWtlIFNDSU0gWzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjQ0IiB0aXRsZT0iJnF1b3Q7U3lzdGVtIGZvciBDcm9zcy1k b21haW4gSWRlbnRpdHkgTWFuYWdlbWVudDogUHJvdG9jb2wmcXVvdDsiPlJGQzc2NDQ8L2E+XSB0 aGF0IGhhczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtdWx0aXBsZSBlbmRw b2ludHMgc3VjaCBhcyA8YSBocmVmPSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9Vc2Vy cyI+JnF1b3Q7aHR0cHM6Ly9hcHBzLmV4YW1wbGUuY29tL3NjaW0vVXNlcnMmcXVvdDs8L2E+LDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2FwcHMu ZXhhbXBsZS5jb20vc2NpbS9Hcm91cHMiPiZxdW90O2h0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9z Y2ltL0dyb3VwcyZxdW90OzwvYT4sIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9TY2hlbWFzIj4mcXVv dDtodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9TY2hlbWFzJnF1b3Q7PC9hPiBUaGUgY2xp ZW50IHdvdWxkIHVzZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS8iPiZxdW90O2h0dHBzOi8vYXBwcy5leGFt cGxlLmNvbS9zY2ltLyZxdW90OzwvYT4gYXMgdGhlIHJlc291cmNlIHNvIHRoYXQgdGhlIGlzc3Vl ZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhY2Nlc3MgdG9rZW4gaXMgdmFs aWQgZm9yIGFsbCB0aGUgZW5kcG9pbnRzIG9mIHRoZSBTQ0lNIEFQSS48bzpwPjwvbzpwPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlVzaW5nDQo8YSBocmVmPSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2Np bSI+JnF1b3Q7aHR0cHM6Ly9hcHBzLmV4YW1wbGUuY29tL3NjaW0mcXVvdDs8L2E+IGlzIHNlbWFu dGljYWxseSBlcXVpdmFsZW50IHRvIHVzaW5nICZxdW90O3RlbXBlcmF0dXJlU2Vuc29yR3JvdXA0 NzExJnF1b3Q7LCBhdCBsZWFzdCB0byBtZTopPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdlb3Jn ZTxicj4NCjxicj4NClsxXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDI8L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMjkv MTkgMjo1NiBBTSwgTHVkd2lnIFNlaXR6IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI4LzAxLzIwMTkgMjM6MTIsIEdlb3JnZSBGbGV0Y2hl ciB3cm90ZTogPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBhbHNvIGRvbid0IGtub3cgdGhhdCB0 aGlzIHJhaXNlcyB0byB0aGUgbGV2ZWwgb2YgJnF1b3Q7Y29uY2VybiZxdW90OyBidXQgSSBmaW5k IHRoZSBwYXJhbWV0ZXIgbmFtZSBvZiAmcXVvdDtyZXFfYXVkJnF1b3Q7IG9kZC4gR2l2ZW4gdGhh dCB0aGUgcGFyYW1ldGVyIGluIHRoZSByZXNvdXJjZS1pbmRpY2F0b3JzIHNwZWMgaXMgJ3Jlc291 cmNlJyB3aHkgbm90IHVzZSBhIHBhcmFtZXRlciBuYW1lDQogb2YgJ2F1ZGllbmNlJy4gVGhhdCBz YWlkLCBJIGhhdmUgbm90IHJlYWQgdGhlIHRocmVhZCBvbiB0aGUgQUNFIHdvcmtpbmcgZ3JvdXAg bGlzdCBzbyB0aGVyZSBjb3VsZCBiZSB2ZXJ5IGdvb2QgcmVhc29ucyBmb3IgdGhlIGNob3NlbiBu YW1lOikNCjxicj4NCjxicj4NCkkgZG8gdGhpbmsgdGhhdCB0aGVyZSBpcyBhIGxvdCBvZiBvdmVy bGFwIChpbiBtb3N0IGNhc2VzKSBiZXR3ZWVuICdyZXNvdXJjZScgYW5kICdhdWRpZW5jZScgYW5k IGhhdmluZyB0d28gcGFyYW1ldGVycyB0aGF0IGNvdmVyIGEgbG90IG9mIHRoZSBzYW1lIHNlbWFu dGljcyBpcyBnb2luZyB0byBiZSBjb25mdXNpbmcgZm9yIGRldmVsb3BlcnMuIFdoZW4gY2FsbGlu ZyBhbiBBUEkgYXQgYSByZXNvdXJjZSBzZXJ2ZXIsIHRoZSAnYXVkaWVuY2UnIGFuZA0KIHRoZSAn cmVzb3VyY2UnIGFyZSBwcmV0dHkgZXF1aXZhbGVudC4gTWF5YmUgaW4gb3RoZXIgdXNlIGNhc2Vz IHRoZXkgYXJlIGRpc3RpbmN0bHkgc2VwYXJhdGU/DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KVG8gZ2l2ZSB5b3UgYWxsIHRoZSBiYWNrZ3JvdW5kIG9mICZxdW90O3JlcV9hdWQmcXVv dDsgZnJvbSBBQ0UgKHNvcnJ5IGZvciB0aGUgbG9uZyB0ZXh0KTogPGJyPg0KPGJyPg0KT3JpZ2lu YWxseSBpbiBBQ0Ugd2UgaGFkIGRlZmluZWQgdGhlICZxdW90O2F1ZCZxdW90OyBwYXJhbWV0ZXIg Zm9yIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIHRoZSBzZW1hbnRpY3MgdGhh dCB0aGUgY2xpZW50IHdhcyByZXF1ZXN0aW5nIGEgdG9rZW4gZm9yIGEgY2VydGFpbiBhdWRpZW5j ZSAoaS5lLiByZXF1ZXN0aW5nIHRoYXQgdGhlIEFTIGNvcHkgdGhlICZxdW90O2F1ZCZxdW90OyBw YXJhbWV0ZXIgdmFsdWUgaW50byB0aGUgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltIHZhbHVlIG9mDQog dGhlIHRva2VuKS4gPGJyPg0KV2Ugd2VyZSB0aGVuIHRvbGQgdGhhdCB0aGlzIGNvbGxpZGVkIHdp dGggYSB1c2Ugb2YgJnF1b3Q7YXVkJnF1b3Q7IGluIE9BdXRoLCB0aGF0IHNwZWNpZmllcyB0aGUg aW50ZW5kZWQgYXVkaWVuY2Ugb2YgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIChpZiBJIHJlbWVtYmVy IGNvcnJlY3RseSksIHNvIHdlIGRlY2lkZWQgdG8gcmVuYW1lIG91ciBwYXJhbWV0ZXIgdG8gJnF1 b3Q7cmVxX2F1ZCZxdW90OyBmb3IgJnF1b3Q7cmVxdWVzdGVkIGF1ZGllbmNlJnF1b3Q7Lg0KPGJy Pg0KTWlrZSBKb25lcyB0aGVuIG1hZGUgdXMgYXdhcmUgb2YgdGhlIHdvcmsgb24gcmVzb3VyY2Ug aW5kaWNhdG9ycywgYnV0IHVwb24gY2xvc2VyIGV4YW1pbmF0aW9uIEkgZm91bmQgdGhlICZxdW90 O3Jlc291cmNlJnF1b3Q7IHBhcmFtZXRlciB0byBiZSBtb3JlIGxpbWl0ZWQgdGhhbiB0aGUgJnF1 b3Q7cmVxX2F1ZCZxdW90Oywgc2luY2UgcmVzb3VyY2Ugc3BlY2lmaWNhbGx5IHN0YXRlczoNCjxi cj4NCjxicj4NCiZxdW90O0l0cyB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSSAuLi4gdGhl ICZxdW90O3Jlc291cmNlJnF1b3Q7IHBhcmFtZXRlciBVUkkgdmFsdWUgaXMgYW4gaWRlbnRpZmll ciByZXByZXNlbnRpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSByZXNvdXJjZSZxdW90Ow0KPGJyPg0K PGJyPg0KTXkgaW50ZXJwcmV0YXRpb24gb2YgdGhpcyBpcyB0aGF0ICZxdW90O3Jlc291cmNlJnF1 b3Q7IHJlZmVycyB0byBhIHNpbmdsZSByZXNvdXJjZSwgd2hpY2ggaXMgbW9yZSBjb25zdHJhaW5l ZCB0aGFuIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0gZnJvbSA3 NTE5LCB3aGljaCB1c2VzIGEgU3RyaW5nT3JVUkkgdmFsdWUuJm5ic3A7IEZvciBleGFtcGxlIG15 IGludGVudCB3YXMgdG8gdXNlICZxdW90O2F1ZCZxdW90OyBhbmQgJnF1b3Q7cmVxX2F1ZCZxdW90 OyBmb3IgZ3JvdXAgaWRlbnRpZmllcnMNCiAoJnF1b3Q7dGVtcGVyYXR1cmVTZW5zb3JHcm91cDQ3 MTEmcXVvdDspIGFuZCBvdGhlciBub24tdXJpIHN0cmluZ3MgKGhhc2gtb2YtcHVibGljLWtleSks IHdoaWNoIEkgY2Fubm90IGRvIHdpdGggJnF1b3Q7cmVzb3VyY2UmcXVvdDsuJm5ic3A7IFdlIHRo ZXJlZm9yZSBkZWNpZGVkIHRvIGtlZXAgdGhlICZxdW90O3JlcV9hdWQmcXVvdDsgcGFyYW1ldGVy IGluIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcywgZXZlbiB0aG91Z2ggaXMgY2xlYXJseSBv dmVybGFwcyB3aXRoICZxdW90O3Jlc291cmNlJnF1b3Q7Lg0KPGJyPg0KPGJyPg0KQW55IGNvbW1l bnRzIGFuZCBzdWdnZXN0aW9ucyBhYm91dCB0aGF0IGxpbmUgb2YgcmVhc29uaW5nIChlc3BlY2lh bGx5IGZyb20gdGhlIE9BdXRoIHBvaW50IG9mIHZpZXcpIGFyZSB2ZXJ5IHdlbGNvbWUuDQo8YnI+ DQo8YnI+DQovTHVkd2lnIDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJl Pi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklkZW50aXR5IFN0YW5kYXJkcyBBcmNoaXRlY3Q8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5WZXJpem9uIE1lZGlhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdvcms6IDxhIGhyZWY9 Im1haWx0bzpnZW9yZ2UuZmxldGNoZXJAb2F0aC5jb20iPmdlb3JnZS5mbGV0Y2hlckBvYXRoLmNv bTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Nb2JpbGU6ICYjNDM7MS03MDMtNDYyLTM0OTQm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVHdpdHRlcjogPGEgaHJlZj0iaHR0cDovL3R3aXR0ZXIuY29tL2dmZmxldGNoIj5odHRwOi8v dHdpdHRlci5jb20vZ2ZmbGV0Y2g8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+T2ZmaWNlOiAm IzQzOzEtNzAzLTI2NS0yNTQ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBob3RvczogPGEgaHJlZj0iaHR0cDovL2dlb3JnZWZsZXRj aGVyLnBob3RvZ3JhcGh5Ij5odHRwOi8vZ2VvcmdlZmxldGNoZXIucGhvdG9ncmFwaHk8L2E+PG86 cD48L286cD48L3ByZT4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFu ayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB2112ABDD90AEB1208EC656CCFA680VI1PR0801MB2112_-- From nobody Thu Feb 7 07:25:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF86130F08; Thu, 7 Feb 2019 07:24:50 -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=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZlKoFnIZcna; Thu, 7 Feb 2019 07:24:47 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on061c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::61c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774E1130E5B; Thu, 7 Feb 2019 07:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VmlMBfAg58vrkuAlDaHUvUwBry95RJCJZpn4Q+f2dDA=; b=d7/qipZxRurWXZjBKQbVBV8QQ5o+xKHVem1vrRRzWVPoa3d8TUOKkV1/+MsH6eUIL3BGyanQri7A9Xaw7s98mek3TEIsAHMwGC4fIb7wnQdU6f3x4H6GJhNS9Jtc0KqlrGuEHrkeXES/TgJdkN4QzSjtzLWlCR+q+tWL2tUzXMw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1728.eurprd08.prod.outlook.com (10.168.67.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Thu, 7 Feb 2019 15:24:43 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1580.019; Thu, 7 Feb 2019 15:24:43 +0000 From: Hannes Tschofenig To: "ace@ietf.org" CC: "oauth@ietf.org" Thread-Topic: Resource, Audience, and req_aud Thread-Index: AdS++E7Ly8Q8wLQXRVClxzlDwlE9TQ== Date: Thu, 7 Feb 2019 15:24:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1728; 6:nzd73LQR+GY7X+oW3D42HmKtcWenB5C7KomAyDdC9IbQTgCre6meoCJOA//e1prrfhL5ivFwEw8IfGsuigHA0t6jbVsY5D0gu1Pj7ZqIt/zMzhbWEwkHCgywOScpMUmKzH72mkJ+YHH5sBYbTzKdQeX+xqUsit5ZGNx1PShHifnqkpeurYQKX0LUDoKalFYY+v0ipft9YsRTMvX4NAWATtID0irPZKqlDIXWgzrkfftHkd7rOaa2E7S9cxtB6A+SVbhXdmctSttuU1YUdwOzGP7oaiuafMNwtcJEavkUgS+exJoFy2IdnkkK+VFj236VGINBqBCR4RP5oF+DDAlJ9KTVq3ynFMcQW4tjtjcvPbkZPeINu/DaOY2fHradzx5Yn0HE+uYB7pmck32uMgZIAePfp+xBHguR5HUAMG5D9PaJ95lCNzbScaGZYF59yeGNCpI1SfdVM0KX3ZYt0Y8dVg==; 5:Ga4ZANZBTjbDuqZmLz04aXaRukdZQe135Eun+iMELlai1JzNco9Eao5l53Va3HrmijvbPVUTOpB7YeRiYkvV35Dp7yFYZoaCSSnAfsMzLAaLptj/isyRZ43O+L/uIlcAOKNqtpe97XUtBKK1Dth66XhCfTFVG6dqr/5+EYglb+3UJC8iJPVs3kAgEgN3Z/yLgJRbl/OY6OsEaiRxqCZdvA==; 7:cIueBCmFNXmVqgpSIHrKqigQwSO4uOg1wZRg/l3/c5M9kScCwPYf9UMB/5O0qEt2dlfqJcpwYe/lCLYCyc0CM9p7ZxK5x65dtCekvT6Njot4kBK98YW9qwh015G5oLzVm7h60JIY9tI8ahHV+dk/VA== x-ms-office365-filtering-correlation-id: d58e71f8-ae4c-4e3b-25d2-08d68d1062d7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1728; x-ms-traffictypediagnostic: VI1PR0801MB1728: x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(39860400002)(136003)(346002)(40434004)(199004)(53754006)(189003)(25786009)(4326008)(450100002)(6436002)(53936002)(5640700003)(68736007)(6916009)(97736004)(55016002)(54896002)(256004)(1730700003)(81166006)(6306002)(186003)(5024004)(6506007)(2906002)(102836004)(26005)(9686003)(14444005)(81156014)(6116002)(3846002)(8676002)(790700001)(8936002)(99286004)(14454004)(71200400001)(71190400001)(33656002)(74316002)(478600001)(2351001)(2501003)(105586002)(7736002)(486006)(316002)(476003)(106356001)(66066001)(86362001)(7696005)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1728; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: n0oQ87laoQhPlMAhhUffCtBodvtUMd3WIotnYxTKvpMq5rMQVLg9ZdVeMdd8ek+3RHa5/Xlrvgs5MUoA0KVgpxw4wUZ4uC25RD61DGxOYI9rUYdM4KGfzna7XN89Mtl/VbkCaSpQKfYAf6miBSDLvyHj7umQ6+HZKLfSibw5jfpP9Ab2LxsXcCFUt7LqDkH1zfxz+xnhGTL8WFdg1tW6aKejuJNYCgjmefq8Uhhsh4L3dqytVl9rQur3NMEA3hFhlo4KZCEL/3VbPTlBxHgAEHXkrw93dVRhgMWFelMjZZwa6E9CFp6qV9RljdA4ZAeIMd/pR5iYDHZqPR+ez95eHzD8JHGDkCT0NB+nhv3Ep5xOevA/xPCyLGJuOaHg6rF06TJ0AOJGLYHUpvrTYu9mVha+qmewHRLaam1zyMkXhVU= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21126944E558E53992EB7FD3FA680VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d58e71f8-ae4c-4e3b-25d2-08d68d1062d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 15:24:43.5352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1728 Archived-At: Subject: [OAUTH-WG] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:24:53 -0000 --_000_VI1PR0801MB21126944E558E53992EB7FD3FA680VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, after re-reading token exchange, the resource indicator, and the ace-oauth-= params drafts I am wondering whether it is really necessary to have differe= nt functionality in ACE vs. in OAuth for basic parameters. Imagine I use an Authorization Server and I support devices that use CoAP a= nd HTTP. 1. If a device uses CoAP then it has to use the req_aud parameter to ind= icate to the authorization server that it wants to talk to a specific resou= rce server. It would either put a URI or a logical name there. 2. If a device uses HTTP then it has to use either the resource paramete= r to indicate to the authorization server that it wants to talk to a resour= ce server, which is identified using a URI, or the audience parameter, if i= t uses a logical name. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21126944E558E53992EB7FD3FA680VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

after re-reading token exchange= , the resource indicator, and the ace-oauth-params drafts I am wondering wh= ether it is really necessary to have different functionality in ACE vs. in = OAuth for basic parameters.

 

Imagine I use an Authorization = Server and I support devices that use CoAP and HTTP.

 

  1. If a device uses CoAP then it has to use the req= _aud parameter to indicate to the authorization server that it wants to tal= k to a specific resource server. It would either put a URI or a logical name there.
  2. If a device uses HTTP then it has to use either the resou= rce parameter to indicate to the authorization server that it wants to talk= to a resource server, which is identified using a URI, or the audience parameter, if it uses a logical= name.

 

Ciao
Hannes

 

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21126944E558E53992EB7FD3FA680VI1PR0801MB2112_-- From nobody Thu Feb 7 07:29:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620B5124C04; Thu, 7 Feb 2019 07:29:26 -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=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdQCDqiVM_kI; Thu, 7 Feb 2019 07:29:23 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB92912008F; Thu, 7 Feb 2019 07:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nxpc5HVOjuZv3ciduIOWD4+99P423G0p4AocwyDsy1g=; b=k5rGFttUqkSRVToukJMNciMGTXNkRdpmJsbfBI3btvHgf/uPkida+AJr6zKIg5Nn29a8Lh9++Jwb29pvjlo8neM9LvvJcUzHSVkJLP5BAPmLCxUZ4+fKu5msIZiV/JNH//y41BS+t+AYsPYieoHQyBUz6RsTmopB2QBANz/F4ng= Received: from HE1P18901CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::33) by VI1P189MB0336.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Thu, 7 Feb 2019 15:29:20 +0000 Received: from HE1EUR02FT017.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::204) by HE1P18901CA0023.outlook.office365.com (2603:10a6:3:8b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.19 via Frontend Transport; Thu, 7 Feb 2019 15:29:19 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT017.mail.protection.outlook.com (10.152.10.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1580.10 via Frontend Transport; Thu, 7 Feb 2019 15:29:19 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 7 Feb 2019 16:29:19 +0100 To: Hannes Tschofenig , "ace@ietf.org" , "oauth@ietf.org" References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> From: Ludwig Seitz Message-ID: <884da75e-8f45-7810-0563-8592d0298dd8@ri.se> Date: Thu, 7 Feb 2019 16:29:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000109090707080107020008" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(39860400002)(376002)(2980300002)(189003)(199004)(6246003)(81156014)(8676002)(316002)(81166006)(97736004)(508600001)(2616005)(486006)(336012)(11346002)(76176011)(69596002)(476003)(126002)(446003)(84326002)(36756003)(44832011)(33896004)(33964004)(53936002)(68736007)(31686004)(74482002)(356004)(7736002)(71190400001)(229853002)(305945005)(53546011)(386003)(40036005)(104016004)(22756006)(186003)(77096007)(106002)(26005)(65956001)(22746008)(235185005)(106466001)(16526019)(65806001)(93886005)(64126003)(568964002)(6116002)(31696002)(58126008)(3846002)(2201001)(65826007)(2906002)(16576012)(86362001)(8936002)(16586007)(110136005)(14444005)(5000100001)(5024004)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0336; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT017; 1:UnV/fIFlZDGKdRE5ejTBF86z7sVikAfPzAbyv1XEfKTHGGWz2CAbXbMmMwlGHqpWX0oP1L/2r0gKKv9oxGJyqgj7+Gsbx9n7THK9t9AHvIZrU09YKwuEN+RqtNhV/nmXPy22qxxIZaY17p1P/ny381wrKxJV2i/vx7cAT86jWcc= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f81ecf21-abff-4b2a-91b8-08d68d110754 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:VI1P189MB0336; X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0336; 3:WF2A3t8lL3G7btdH2I3ntDVkZXPwCck/eTPrmPCBsakdXqq2h99A9euxgS1AKanJvlvWY+pGdq4LHLdrp/VSErzj7kxGFx0PoSEeA5KdPAiKD8r4EfoD6ArpzCITWWcDl3QQTZXise0CxSe0zdg5uwNP1Nmru+c6N00PSw6UkLzD9mcNoDyv06SYgHSO2pYiVzW1yZNPTD7ST62+AAQ6PNgll6F3iny0Fyefzgw+iiJyDqtBOSo1dWIXeo6RUcjbY0mWu/rWQNqB2AsZdsrgDuKmYUFS4XYtoN/kN7m2LrWWjBa3nh5WrJAw0VHCPy27F0TXIKpAQMVStlNzb3T3MuyBElZOdactcI3YrijLb6E1NryOXH2nq607DvQbBOvd; 25:Q+1TCJC+DB9pL8cYRfOcI8Cjwn2bYCIPxuk1gdnzlmgoRgu1AA8xzO7hNKui2hzs6rk4Efl8pAJhNm3SzPPy7UiEUfHRuGk6fxCU2HSxyRHD3/Y3l9jBv7txCHaq7A2MhTJpMcR5RzEFOtpOUZsOgQ5CFdlYh7eVoR/3Iss9KnWPQn/wTIdVBv0ylVsI5B7IMY9NJJANTM/CslNxBuyu12O2WlK4jfflSeH9LHMAOwmEBVaz7vFxAdzN0JmZ2KoeE5bgFCmbSHRoyGtmCfqzFYozvL8gwRcEbpPDcI7KF4xogImKwJ6yr5NBXLf+MCTNneg3Hccs4qJZoKTFZPiH+Q== X-MS-TrafficTypeDiagnostic: VI1P189MB0336: X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0336; 31:GP6lsM3oLcAGq21mPL17KGM9zYKQZvBoJtWjANxwYEWzkuW2znCzflxPxXMQtiDjqZlB0rcCuk9EWw7vGLLWMk8whogFgKTqDn3lJ2r7BcLW7psMtJAHwgOSg6ZDukNQbv9W9E+Dp9XhKwZZVg+KzejlYu50MwhnntYu4qxK93+bq4CTJGQJzbWSzxQp+VClCyyqK3HhNxYs1Wwc4xgCpPqlsUpSeGM9b3gB785o9QQ=; 20:ShYZwGdSU400h+KO6zPbQg6lfb1cx7nQYChklL0SIYQev90cFexJhRK2iFJoW5uTK0Dyr/mXDYA0egjvqG21bcG9O6GQFzKXMwiR5r/mhttpJ0zIP6mW7c0Egd20Chmqiu88XGxoGCnx9+NJzJ6mqjewzObfmrNbb1G2VO/Ri5VjzAqPdC4JJFwq3UOt5d1ugVh7XQJsFqnmTJ+CQyd/ZRs4w7e6rrRrs5w5L2uUWU7XhFNPX37nXZKGbq5M11vB; 4:YO1Pw/3A1FsBVYTKAYMwrO9njiGCRrmR9kax7NyZTcrKu0hYBt8Fy2sPeZvI8RGeUNQrbhYqZimh/CDMXE5BfEKReJQy4ybpfowxe2aXi7VcsGHRVvHJVFgoa6km+9fF0lORGfW6+DrI7bbbCQOkBJZLvEuNkoZwed8zgAhZ2K28na044KPItzOueN03ErtZWecjZR0G0aIdIEdXauC6nkRq0SRXmrB8gFuCZJ18JUj/751ToRSQEvnIafC8zLFa8g75J+/mb8EVWrjk3mIE5C3CpqcgstGyw2zaSxyE32E= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0941B96580 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1P189MB0336; 23:pBQn6fq5m9HQICyMAkCHL30b+Sn0aQx+mbRdhvWSc?= =?us-ascii?Q?9vcgvPYqa+3IzdLDXr+7ReeM2HcKEUB34a9JIMo6OojZeTOvBouGr1eXg8Vp?= =?us-ascii?Q?SXrNAb9soS69ezz2aRZVzInds6XhUKO3ndXQXArrR7+s6uBUExF7FO2lVFIS?= =?us-ascii?Q?JKE7LCrdJ+SkJz6BTpTnKuFIpAzDFdxAQsuhEkmnqV0G/fRFKBTbK/7ap8px?= =?us-ascii?Q?4ra7Nqu5XzadhKSEa0FaVusc+jeeMVmdGfaCnADfA2mF0Nvl5Wf1KFDKOPG3?= =?us-ascii?Q?+NOA78Id2MT1lbtSz4Dj9/eKzHVmi3I9hu55+it0uT87PFygj1431thoFfKu?= =?us-ascii?Q?ENfH+yxE/ypPx8jz78hVctYyO7Xd7Iov7K+L6MrIwBnslA5B1L4E9IquipxR?= =?us-ascii?Q?DLXnRS3ju9uEX448bGb8et9Kl2cwyrklbRjZ/QSYBIsFta3GZZde3jYdJJCa?= =?us-ascii?Q?EwF+4kAkyw4wIM5+uOD1K6JyLVEomsSZ9AfjMACrbErsUzZP8jPkdSDx4Zha?= =?us-ascii?Q?aZZY0QxXqNT3ANTCeBUR7M+ZsohPgmP4aOVd8yzVr1e2Wf0HHpKtQaUGQds9?= =?us-ascii?Q?ZMGqEYuavWs2rCetWmvYjIICKnfhgqSbqbZeOu49dQxPE3JnUmqw39/Kgion?= =?us-ascii?Q?UnkoN1PyqfsGAwaDT8dgS1NMRzjG2h2G1pnqRtoOZiyMSBjxiqj9dhkVGrCN?= =?us-ascii?Q?XtjbG6/PdlJIRLZN1dqT2oz+zVaGV21zanlO0G+pcml+CSXoZ9WpK8WNUwuS?= =?us-ascii?Q?6JwEv2ScCSrKElOS+DqV3la87HCfUeAYII4zptygWYGl6ny2SCW8Fzuiip4D?= =?us-ascii?Q?Uq6YqfDxlww2ZzxyaTWw2+E0CtlXB+34KuANJKxtz0CTuiPdUUoQ8jsgoeS6?= =?us-ascii?Q?gowpGEzozcHhvu8eY141iigmgvvPA/X1rywlHSkPqym72HV/e03IOXfs06zi?= =?us-ascii?Q?j8a29PhyFH2pTr0G7+P8YNfzsx4dKVtZ+flrovX7EW6/mqAjgZERKIMrurDN?= =?us-ascii?Q?kGVrc3kmQ1QVVDRhCcPuBlhedUqmJsnsOH0JGVx+G0y4ypvYutd0DyRJMQOY?= =?us-ascii?Q?mbPIF4YPlZzV7OAdOcjs2Qf7mOlmLuDAbmwHmVLbABTyGx+pkg+aDc4zc9NY?= =?us-ascii?Q?Zon807Pk0aC898aVSZfaRk0OD6Dybe7x5RD0BQ1pnDBwAwijaROTmZ3hTVQi?= =?us-ascii?Q?8xdqetF9OsyvLJ/iebmQJMNs1nlBiaiHewSDNnfFp9Jqw0wPwkMP0ljk5MZK?= =?us-ascii?Q?2ibMQLE/SzUxGoqTazNlKej9n6jpY0wl1yqkiD4mMIObW8lD6Ao2s+5UYyOG?= =?us-ascii?Q?gzGDnI/CwNolAP572M7Nud5FCZ0qa6eH5kjeRkqMwVuAwYu2soSRJXu1UuaR?= =?us-ascii?Q?fjWQgHtDUtdoG2TKxaWptl238qXutuqdB+DH4PXBZMTDSMwGDVLvtgIya4Sd?= =?us-ascii?Q?KV19GmLX9x/m2irEYwIWUdj+6VYu/Gf84+3y4+OeVzOvXwoo0zWC3nW4Vr8G?= =?us-ascii?Q?5CrsVHl6RpNuE4hfTnTxTmyV5FxToWRmGeCSa5HqiOSnzaWLiW8u0nubQZp4?= =?us-ascii?Q?GRBmgxOly6FZ44rU9rystXgqIvYAyW0sGAGn50=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 1NQ3O6yVA21Waqqe0uRfmi+KHvVIOLHZzNMgEqTk5CxLOs2H0zcb7GhzPMYSXAugbPaNpcofqz0Hlwq5JRVJo1GALF8s0PiITYAg4IiZjV+alC3mKg99yQNZnzFKV4BuSrEa1CGKPFYao9YLzwlZ8mW3Ut+NCBsiC16tj8Z3HOqxtFvk4Y8IdODjknzSy0cQeSCv2qr1Ak5E/NPdh1BwCAIVEBcSa50NKdYhasPtCDZKS4Ytb1c9HvDUX2Ypt1mX5zpWVPHJK349AvSNzCu+4ZcKRKojTRQh01Z4SNVp3WBllIUFhbDYHRXH7Y4k5QiB+aIa9Zf7q08EoaUn7KwhrxDngTre5IQduCTKsWJ3U2gLqqGGUkIza9pdh+FkxaWk+2otT7G8gI6GSJ05F68dJAwylHjvbHnnWbkDW6R3aS8= X-Microsoft-Exchange-Diagnostics: 1; VI1P189MB0336; 6:SLhN8L3SOvJb8PKI3b4MfN1pYk66Ad2UhrUXcYmrlmRNYQnfP7zCSePgGQ75fPXDuG1gk0QcaBHQrNgE1/8ICzOykQ/Zs9N1FsJIOAAGY1NFtQT5pawJvHfh/tuTTreLoPtgZPTCoaQHRydOT0FoNKsOJfC4Gh4YnKYno1HPXNgFPGiwhdbHgcCmA3w2NhF2p8BYZZmOSyjbWRmpD1xB7mUuLrl2skznlXPx4TiHlXubgqjLsM51EG9FauJPYjkYF7VG7dXAmOexMDdc4xS/a2EmEL4mjx4CrZIVwo1DXVd/b3j6W66tXxxysYYRM1ykknW/RsW3Gcni0uZJXwVFG7P76oGiQffpC2nKst0iQ3EDQIqxYUS+5Wwl9OaH8GemLRq9uOyVU0O7sWz14FMWe/eupB/9cSkqH4zsWJ3tJIZRkNU1yviQv2DU6xAHUUa08rfJ7gTnepljPF9KI9bMtg==; 5:iEjoWrP6/qrI/mmc4WjLIdinrT2oXih3o8TUA1ZSZYnBHV8xMTbp7N6sKMcTP+/zVI3xRrjVQvhwhC3PlERSVFONcySXGkbl1khgamCiLGussDJYnocrqTxGroChbuNplAZLcT/Vx0h6nhasWtr/eEqHWps5YV5Zc0z944AZEqEyvrr5STQOpv4OGH2NGQy71QUewYD2JOFedl2pnfGytQ==; 7:3BHGY5FnQpm3qW0k5bbwZj+6MCSgc85kGN9HsOapMSwt9uVN2L29A9xxSZSS0mFITvuBD9hOodWf/NIHjodF4WNG+lwKzBAxP1fB+ACZNVA+T+2/5h75MFBsgBHcMiRULeA+6uNSbticTxy/3o1E4g== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2019 15:29:19.4775 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f81ecf21-abff-4b2a-91b8-08d68d110754 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0336 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:29:26 -0000 --------------ms000109090707080107020008 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/02/2019 16:15, Hannes Tschofenig wrote: > Hi Ludwig, >=20 >> My interpretation of this is that "resource" refers to a single resour= ce >=20 > No. Here is the text from token exchange (see last sentence): >=20 > resource [...] > Multiple "resource" parameters may be used to indicate > that the issued token is intended to be used at the multiple > resources listed. >=20 Enumerating the audience is not the same as addressing it by a group name= =2E I agree that without too much stretching of the definition of the=20 resource parameter I could use URIs as group identifiers, however the=20 audience claim is defined to be "StringOrURI" so if someone defines an=20 audience identified by a String that is not an URI how does a client ask = for that with the resource parameter? Or in short: Why don't you make your resource parameter mirror the "aud" = claim? /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms000109090707080107020008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIwNzE1 MjkxOFowLwYJKoZIhvcNAQkEMSIEICu23BXL0Pbv09NJBdMi7uNPltC1A2S2liq+/8LNiwVP MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAMj/ROXZfEbmRLb4spD74agUNhZOAOg+YmMHQ6wCZRaPO 6G1te4JrNQAtLLGcBvhkNJ5vHo79QxgjHG9byfrAuQFD56WxG8mE+bgtv3o7iIicztWgml11 tqajzgryexGeD2s0dbSP8nXaOKaAvaEWgSc+cRbA0WdWT+qTG3SVtzGul1O5EptgRDcic3DB C92mW5SuB19TaSY/uXox+dZcBawyNpmkW6JEnOC32u5wyUpkVYqDLFkNeEt6hJbDXp89NMpd 6TyVa/PWTmWtQPI59jhVhOcD07YwUIimU4duJidm4TrwAymd110YeDdGjpdiSADBgbem+lo9 QMGfPtCyVQAAAAAAAA== --------------ms000109090707080107020008-- From nobody Thu Feb 7 07:32:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0857012008F; Thu, 7 Feb 2019 07:32:41 -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=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XRJUCU5xNnG; Thu, 7 Feb 2019 07:32:38 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::611]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A42126D00; Thu, 7 Feb 2019 07:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3S/quHT7i3UbB1AjSNvzwePIOV99zb6Pgeh22v+N9nE=; b=QFsKjizF+qlB1RX2DgRVICJjp1h9k+J076HtZllnShxDwcRphr+6dXKGUekskP4MBjG0O6vELZXH5b47HGUjcAuxrjbDUX/7pNl6hOPfFKXu3fTVlN36pjYaRnAW7usd8Dj8796Z6Ag7ckCIwT56o0AremN+QAahkQQO2pFnjN8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1775.eurprd08.prod.outlook.com (10.168.67.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Thu, 7 Feb 2019 15:32:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1580.019; Thu, 7 Feb 2019 15:32:35 +0000 From: Hannes Tschofenig To: Ludwig Seitz , "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUt6gmW8ETQzXQdEeeWnvbq21Io6XUgBEQgAAEZgCAAAAfcA== Date: Thu, 7 Feb 2019 15:32:35 +0000 Message-ID: References: <4eb4ea45-c3f2-7991-9544-612d055809ba@ve7jtb.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> <884da75e-8f45-7810-0563-8592d0298dd8@ri.se> In-Reply-To: <884da75e-8f45-7810-0563-8592d0298dd8@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1775; 6:KvBSgtpDZFOL9/lkuJKL2JAb2aKetJzHPPcm8Z9gSxrbtVcUverR4oqst4DKQmAT7SWr793hSet7ShNk4WCTIJf1nfNiKagvJb+F3KJ9yNvyN/IgHv2fPaUhYlQcAjGyN5Cb83+/fjInuJ8+2QqUNW4/MADH5EfBcNnveoTNeAisaXX4ie2r2ajiADYi+2V2cn1QbfySYdXQNyvycQsWUw1ZgExDqecaNH3bfLg0bMCnTKGpooZdjLMZm6ujVr/yrj3Ci7T8liGi4wv0m5UaJik3UMc7uZsPM1y7RfnKl0qWm1/PaWHPxV0guj5lGV8IY6HqvZxWodEGfluCwlyc7NTl1KQ60iiJaBpBwYofuj6faGZYWhmcQC+7iUdjc5uy6glk9knMT6u+qYl+/jNH/PXobZORmVkLwsXVe0j0NQdfUTsjAQCzutBC8vq2Iz7/b0l0aW0e4IusbJ3k/We72Q==; 5:V2ABoPUbE1hRrCqkvhkGEP8lzWOVoeUgOt0Pe2ZMukZJiY9gyMkqKeDPRW9TBMCZ7kfm9l547rJ5k2joIDbOGYH/PgVwieF1Op0gHBHqx0lWA2tTVYQt8LtexBaa5c65B7BStXPPx2KdrYgzLjLzv8unxbbtn6YuCC1EyROFirg2P2IpnRQi+WP5k6YIoXBTbYWUqRqKzo5nf+1NtOFm1Q==; 7:pvJPlOFKzPDsTsr3G6wgF4Vs6fvZFj7mJKB+aIjfzYczEN/7hBH7abieuycj8OsAUC15rH5JnJ0p3BbLSjx2rojE2tCr63U+9Zr6VW4/WJ5yaj4v9ENSQwbbN4886ojlrPwysTU/x0zfkfbK8O0TmA== x-ms-office365-filtering-correlation-id: 45b513b8-a457-4a9f-9bf5-08d68d117c1d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1775; x-ms-traffictypediagnostic: VI1PR0801MB1775: x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(136003)(376002)(346002)(40434004)(189003)(13464003)(199004)(110136005)(6436002)(3846002)(76176011)(68736007)(7696005)(6116002)(71200400001)(6246003)(97736004)(478600001)(7736002)(14444005)(5024004)(316002)(256004)(2501003)(93886005)(99286004)(71190400001)(25786009)(2201001)(53546011)(102836004)(229853002)(2906002)(33656002)(105586002)(86362001)(6506007)(26005)(186003)(74316002)(66066001)(11346002)(14454004)(305945005)(72206003)(476003)(81166006)(486006)(9686003)(81156014)(53936002)(446003)(8676002)(55016002)(106356001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1775; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Y/WF8n2v8KezfAMWJWKTfC7IcKrGiCqKekGtrTJCsZhcOu0TfpXvqvRaKWHlHCRxKh3FSQR2O3B1hPvddbosTcnbWwASEL//kFGDs0JWQ7dNIpmy/Z/kCGZCxTHfMCZEZS7dJNThDSDtKLOYpqgCIAA1SezLrDaE6XgL9AQ+Q4MtAt5fmKJrYTAO/qW7ZCOQ/Hk4tG9OvWxv3/2VplvcLwYZCLs00PT2deDfD3nYxsLQ6arzhpyOraUOWuUJOZIhMrnw5QjFBi43XGPI1iY/ZxQbdyPQHSvwbuuKe7B8cUoqtngmB3S8Wlkfrv8GvvNS85ag5aNBuiBw4kkZ348lmCWGMk/jhJSh57IGZSunqrEH1IwyigQrQTwkl3gyP6SXowvdtp+tT1V6oF0Z32tA+etykL6No+NiG+DZFpjBj38= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45b513b8-a457-4a9f-9bf5-08d68d117c1d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 15:32:35.4488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1775 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:32:41 -0000 SGkgTHVkd2lnLA0KDQp0aGUgaXNzdWUgaXMgdGhhdCBmb2xrcyBpbiB0aGUgT0F1dGggZ3JvdXAg aGF2ZSBkZWZpbmVkIHR3byBwYXJhbWV0ZXJzLCBuYW1lbHkgcmVzb3VyY2UgKGZvciBVUklzKSBh bmQgYXVkaWVuY2UgKGZvciBsb2dpY2FsIG5hbWVzKSwgYW5kIGluIEFDRSB0aGVyZSBpcyBvbmx5 IG9uZSBkb2luZyBib3RoLg0KDQpUbyBtZSB0aGlzIGFwcGVhcnMgdG8gYmUgc3ViLW9wdGltYWwg dG8gaGF2ZSBkaWZmZXJlbnQgd2F5cyB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIGdvYWwganVzdCBi YXNlZCBvbiB0aGUgcHJvdG9jb2wgdGhlIGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdlZC4NCg0KV2hp Y2ggcm91dGUgaXMgYmV0dGVyPyBJIGRvbid0IGNhcmUuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNl aXR6QHJpLnNlPg0KU2VudDogRG9ubmVyc3RhZywgNy4gRmVicnVhciAyMDE5IDE2OjI5DQpUbzog SGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyBhY2VAaWV0Zi5v cmc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbQWNlXSBTaGVwaGVy ZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxDQoN Ck9uIDA3LzAyLzIwMTkgMTY6MTUsIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiBIaSBMdWR3 aWcsDQo+DQo+PiBNeSBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIGlzIHRoYXQgInJlc291cmNlIiBy ZWZlcnMgdG8gYSBzaW5nbGUgcmVzb3VyY2UNCj4NCj4gTm8uIEhlcmUgaXMgdGhlIHRleHQgZnJv bSB0b2tlbiBleGNoYW5nZSAoc2VlIGxhc3Qgc2VudGVuY2UpOg0KPg0KPiAgICAgcmVzb3VyY2UN ClsuLi5dDQo+IE11bHRpcGxlICJyZXNvdXJjZSIgcGFyYW1ldGVycyBtYXkgYmUgdXNlZCB0byBp bmRpY2F0ZQ0KPiAgICAgICAgdGhhdCB0aGUgaXNzdWVkIHRva2VuIGlzIGludGVuZGVkIHRvIGJl IHVzZWQgYXQgdGhlIG11bHRpcGxlDQo+ICAgICAgICByZXNvdXJjZXMgbGlzdGVkLg0KPg0KDQpF bnVtZXJhdGluZyB0aGUgYXVkaWVuY2UgaXMgbm90IHRoZSBzYW1lIGFzIGFkZHJlc3NpbmcgaXQg YnkgYSBncm91cCBuYW1lLg0KDQpJIGFncmVlIHRoYXQgd2l0aG91dCB0b28gbXVjaCBzdHJldGNo aW5nIG9mIHRoZSBkZWZpbml0aW9uIG9mIHRoZQ0KcmVzb3VyY2UgcGFyYW1ldGVyIEkgY291bGQg dXNlIFVSSXMgYXMgZ3JvdXAgaWRlbnRpZmllcnMsIGhvd2V2ZXIgdGhlDQphdWRpZW5jZSBjbGFp bSBpcyBkZWZpbmVkIHRvIGJlICJTdHJpbmdPclVSSSIgc28gaWYgc29tZW9uZSBkZWZpbmVzIGFu DQphdWRpZW5jZSBpZGVudGlmaWVkIGJ5IGEgU3RyaW5nIHRoYXQgaXMgbm90IGFuIFVSSSBob3cg ZG9lcyBhIGNsaWVudCBhc2sNCmZvciB0aGF0IHdpdGggdGhlIHJlc291cmNlIHBhcmFtZXRlcj8N Cg0KT3IgaW4gc2hvcnQ6IFdoeSBkb24ndCB5b3UgbWFrZSB5b3VyIHJlc291cmNlIHBhcmFtZXRl ciBtaXJyb3IgdGhlICJhdWQiDQpjbGFpbT8NCg0KL0x1ZHdpZw0KDQotLQ0KTHVkd2lnIFNlaXR6 LCBQaEQNClNlY3VyaXR5IExhYiwgUklTRQ0KUGhvbmUgKzQ2KDApNzAtMzQ5IDkyIDUxDQoNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Feb 7 07:38:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AC5128766; Thu, 7 Feb 2019 07:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RED2rnoSS4lW; Thu, 7 Feb 2019 07:38:05 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F9F1279E6; Thu, 7 Feb 2019 07:38:04 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id w25so361100otm.13; Thu, 07 Feb 2019 07:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jv7AeWKsTsLk9AACX5O1zx/tItWe6XDYXew3gdf/a5U=; b=o9RyO2eRZA/yg4jGCgknYcqKLC8bGhfD8+h15/uPL/5KS1xfk0NxjfOEeVcqgrGe1X JEn9qFMTfSeFf7quoGzGye99NJsJkRgNIDQrnZV5S9aIz4xmIto+JRIt1EWbQdDSVmy/ x8JdlJw0oitXZCksGcAVP5b+MWf3d0UInaJOfV0SlP81mfUgX0PAz6kzqMFyp4VRlTrL v2ztLZM+Uh2AzFbSHOMoPxBLtYrgziwDrMNmIeyNh4M8ZVXZ+WQWqHTEhpR4peEj/sCl /dske+/qd1q2QWlC/Bg18q73eICPY9gzmtmMrNDcFiDb9nxk/rF6B8SraYEaO2EovTsh qMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jv7AeWKsTsLk9AACX5O1zx/tItWe6XDYXew3gdf/a5U=; b=PHgKDfmNP6VwQXhYea1t/wBZsCvTIMeRWV0q/OsB2axQ79wWkKsCsEWW789gy1ezoR JmFed4IVpjQ+1y/xAyj7lxdqItCaKyNeoEfsviRhVIWoVUb3je1AdwiJzXsFPaVkPMvp 95V23j1s8zie6OtZMysf/FbTTFlmgktFmSTmiNXVn3OQWOyuXCNVjVMM92z287U6tTJH f5EMhaOdofuGGOXUkbkEhrX7EJPUv45KYllHQQa7AKabcs3yTkkEmQmXUdLyazHOnQLR 4mf+WqYzJ3hWQycOyTq2EWTmA510kTGbUvt3yMtIufMH0yVutuRCit6W3BiEXJTao9CY 1qgw== X-Gm-Message-State: AHQUAublGUHQodgVszgHq+eRr52tXVxsDpjmw/FTRri+P5DhzrQdjMz7 w3dvV2nTWErl2y7qbC9kbpsKu5iBd9J+ist71w== X-Google-Smtp-Source: AHgI3IYGMqfgH6vYPyb03T6K9AEJZzq5usvpkOWN7I/yj9cCwziLOs1H0eHDv6CcVL4PMTWpWrTruLc/K7exAnknpDo= X-Received: by 2002:a05:6808:6cf:: with SMTP id m15mr623471oih.13.1549553884144; Thu, 07 Feb 2019 07:38:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Thu, 7 Feb 2019 16:37:53 +0100 Message-ID: To: Hannes Tschofenig Cc: "ace@ietf.org" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d329e205814fa0b1" Archived-At: Subject: Re: [OAUTH-WG] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:38:07 -0000 --000000000000d329e205814fa0b1 Content-Type: text/plain; charset="UTF-8" To add to that, 3. If a device uses HTTP Token Exchange it can use both resource and audience parameters. With the recent discussion and changes to the language in the resource indicators draft, does the token exchange spec need a unique audience parameter? S pozdravem, *Filip Skokan* On Thu, 7 Feb 2019 at 16:25, Hannes Tschofenig wrote: > Hi all, > > > > after re-reading token exchange, the resource indicator, and the > ace-oauth-params drafts I am wondering whether it is really necessary to > have different functionality in ACE vs. in OAuth for basic parameters. > > > > Imagine I use an Authorization Server and I support devices that use CoAP > and HTTP. > > > > 1. If a device uses CoAP then it has to use the req_aud parameter to > indicate to the authorization server that it wants to talk to a specific > resource server. It would either put a URI or a logical name there. > 2. If a device uses HTTP then it has to use either the resource > parameter to indicate to the authorization server that it wants to talk to > a resource server, which is identified using a URI, or the audience > parameter, if it uses a logical name. > > > > Ciao > Hannes > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d329e205814fa0b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To add to that,

3. If a devi= ce uses HTTP Token Exchange it can use both resource and audience parameters.

With the recent discussion and chang= es to the language in the resource indicators draft, does the token exchang= e spec need a unique audience parameter?

S p= ozdravem,
Filip Skokan


On Thu, 7 Feb 2019 at 16:25= , Hannes Tschofenig <Hannes= .Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

after re-reading token exchange= , the resource indicator, and the ace-oauth-params drafts I am wondering wh= ether it is really necessary to have different functionality in ACE vs. in = OAuth for basic parameters.

=C2=A0

Imagine I use an Authorization = Server and I support devices that use CoAP and HTTP.

=C2=A0

  1. If a device uses CoAP then it has to use the = req_aud parameter to indicate to the authorization server that it wants to = talk to a specific resource server. It would either put a URI or a logical name there.
  2. If a device uses HTTP then it has to use either the= resource parameter to indicate to the authorization server that it wants t= o talk to a resource server, which is identified using a URI, or the audience parameter, if it uses a logical= name.

=C2=A0

Ciao
Hannes

=C2=A0

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d329e205814fa0b1-- From nobody Thu Feb 7 07:57:40 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF501292F1 for ; Thu, 7 Feb 2019 07:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.9 X-Spam-Level: X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-0mjBB78krP for ; Thu, 7 Feb 2019 07:57:34 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDB112008F for ; Thu, 7 Feb 2019 07:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1549555053; x=1581091053; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VmtcO4f+oYeR3QaJ9wpqAdO4Q8BQLIxb788HhLKXk28=; b=ifqkNyVju0x5sEAFsAyZXOUQEKcY8b8As+ciYmSbO42I/AG1qY13PxDN 5xdoutmpCbHi3DrFzouFNcy737nDtKzR+2cmwCV7QgF7ipi3LdJFvuf1B fA7X5h8Xqs3YOECczs+As9u3FIGSQiZstYm6tCX47ZxlvBFkthPmGPW4e 0=; X-IronPort-AV: E=Sophos;i="5.58,344,1544486400"; d="scan'208,217";a="781485535" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2b-55156cd4.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 07 Feb 2019 15:57:31 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2b-55156cd4.us-west-2.amazon.com (Postfix) with ESMTPS id 71893A1D83; Thu, 7 Feb 2019 15:57:29 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 7 Feb 2019 15:57:28 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 7 Feb 2019 15:57:28 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 7 Feb 2019 15:57:28 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell , "Richard Backman, Annabelle" CC: oauth Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint Thread-Index: AQHUvI2LObcpr6zF5UKz57jceIw7rKXRJmGAgAC3goCAAUm5gIAAA9uAgADQ+gA= Date: Thu, 7 Feb 2019 15:57:28 +0000 Message-ID: <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.36] Content-Type: multipart/alternative; boundary="_000_18CD2B6D5FA945B19334EB785F40A6A9amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:57:39 -0000 --_000_18CD2B6D5FA945B19334EB785F40A6A9amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNhc2UgSeKAmW0gcmVmZXJlbmNpbmcgZGlkbuKAmXQgc3BlY2lmaWNhbGx5IGludm9sdmUg QVMgbWV0YWRhdGEuIFdlIGhhZCBjbGllbnRzIGluIHRoZSB3aWxkIHRoYXQgYXNzdW1lZCB0aGF0 IGFsbCB0aGUgcHJvcGVydGllcyBpbiB0aGUgSlNPTiBvYmplY3QgcmV0dXJuZWQgZnJvbSBvdXIg dXNlcmluZm8gZW5kcG9pbnQgd2VyZSBzY2FsYXIgc3RyaW5ncy4gVGhpcyBicm9rZSB3aGVuIHdl IGludHJvZHVjZWQgYSBuZXcgcHJvcGVydHkgd2hvc2UgdmFsdWUgd2FzIGEgSlNPTiBvYmplY3Qu IEl0IHdhcyBhIGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBj aGFuZ2UgdGhhdCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGZvcmNlIG1vcmUg d29yayBvbiBjbGllbnRzIHRoYW4gd2UgZXhwZWN0Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQg QmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSA2LCAyMDE5IGF0 IDExOjMwIEFNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmE9NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93 c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNCkFuZCBJJ20gaG9uZXN0bHkg cmVhbGx5IHN0cnVnZ2xpbmcgdG8gc2VlIHdoYXQgY291bGQgaGF2ZSBnb25lIHdyb25nIHdpdGgg b3IgaG93IHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBicm9rZSBzb21ldGhpbmcgd2l0aCB0 aGUgdXNlciBpbmZvIGVuZHBvaW50LiBJZiB5b3UgaGF2ZSB0aGUgdGltZSBhbmQvb3IgaXQnZCBi ZSBpbmZvcm1hdGl2ZSB0byB0aGlzIGhlcmUgbGl0dGxlIGRpc2N1c3Npb24sIHBsZWFzZSBleHBs YWluIHRoYXQgb25lIGEgYml0IG1vcmUuDQoNCk9uIFdlZCwgRmViIDYsIDIwMTkgYXQgMTI6MTUg UE0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KImZhciIgc2hvdWxkIGhhdmUgc2FpZCAi ZmFpciIgaW4gdGhlIHByZXZpb3VzIG1lc3NhZ2UNCg0KDQoNCg0KDQpPbiBUdWUsIEZlYiA1LCAy MDE5IGF0IDQ6MzUgUE0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KSXQgbWF5IHdlbGwg YmUgZHVlIHRvIG15IG93biBpbnRlbGxlY3R1YWwgc2hvcnRjb21pbmdzIGJ1dCB0aGVzZSBpc3N1 ZXMvcXVlc3Rpb25zL2NvbmZ1c2lvbi1wb2ludHMgYXJlIG5vdCByZXNvbmF0aW5nIGZvciBtZSBh cyBiZWluZyBwcm9ibGVtYXRpYy4NCg0KVGhlIG1vcmUgZ2VuZXJhbCBzdGFuY2Ugb2YgInRoaXMg aXNuJ3QgbmVlZGVkIG9yIHdvcnRoIGl0IGluIHRoaXMgZG9jdW1lbnQiIChJIHRoaW5rIHRoYXQn cyBmYXI/KSBpcyBiZWluZyBoZWFyZCB0aG91Z2guDQoNCg0KDQpPbiBUdWUsIEZlYiA1LCAyMDE5 IGF0IDE6NDIgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4g d3JvdGU6DQooVEw7RFI6IHB1bnQgQVMgbWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCkNCg0K QVMgcG9pbnRzICMxLTMgYXJlIGFsbCBxdWVzdGlvbnMgSSB3b3VsZCBoYXZlIGFzIGFuIGltcGxl bWVudGVyOg0KDQogIDEuICBTZWN0aW9uIDIgb2YgUkZDODQxNDxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODQxNCNzZWN0aW9uLTI+IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVR VUlSRUQgdW5sZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKA nSBTbyB3aGF0IGRvZXMgdGhlIG1UTFMtb25seSBBUyBwdXQgaGVyZT8NCiAgMi4gIFRoZSBjbGFp bXMgZm9yIHRoZXNlIG90aGVyIGVuZHBvaW50cyBhcmUgT1BUSU9OQUwsIHBvdGVudGlhbGx5IGxl YWRpbmcgdG8gaW5jb25zaXN0ZW5jeSBkZXBlbmRpbmcgb24gaG93ICMxIGdldHMgZGVjaWRlZC4N CiAgMy4gIFRoZSBleGFtcGxlIHVzYWdlIG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhv ZHMgcHJvcGVydHkgZ2l2ZW4gZWFybGllciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0LCBz aW5jZSBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1tVExT IGVuZHBvaW50cywgYW5kIG90aGVycyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5kcG9p bnRzLiBIZW5jZSB0aGlzIHF1ZXN0aW9uLg0KICA0LiAgVGhpcyBpbnRyb2R1Y2VzIGEgbmV3IG1l dGFkYXRhIHByb3BlcnR5IHRoYXQgY291bGQgaW1wYWN0IGhvdyBvdGhlciBzcGVjcyBzaG91bGQg ZXh0ZW5kIEFTIG1ldGFkYXRhLiBUaGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4NCg0KSSBjb3Vs ZCBnbyBvbiBmb3IgY2xpZW50IHBvaW50cyBidXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4g VGhvdWdoIEnigJlsbCBzaGFyZSB0aGF0ICMzIGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRv IHJvbGwgYmFjayBhbiB1cGRhdGUgdG8gdGhlIExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVu ZHBvaW504oCmZ29vZCB0aW1lcy4g8J+Ygw0KDQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsg YW4gQVMgbWV0YWRhdGEgcHJvcGVydHkgaXMgd3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0 aGF0IHlvdeKAmXJlIGJvbHRpbmcgYSBsYXllciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRh cmQgdGhhdCB3YXNu4oCZdCBkZXNpZ25lZCBmb3IgdGhhdCwgYW5kIEkgZG9u4oCZdCB0aGluayB0 aGUgbWV0YWRhdGEgcHJvcG9zYWwgYXMgaXTigJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc3VmZmlj aWVudGx5IGRlYWxzIHdpdGggdGhlIGZhbGxvdXQgZnJvbSB0aGF0LiBJbiBteSB2aWV3IHRoaXMg aXMgYSBjb21wbGV4IGVub3VnaCBpc3N1ZSBhbmQgaXTigJlzIGZvciBhIG51YW5jZWQgZW5vdWdo IHVzZSBjYXNlIChhcyBmYXIgYXMgSSBjYW4gdGVsbCBmcm9tIGRpc2N1c3Npb24/IFBsZWFzZSBj b3JyZWN0IG1lIGlmIEnigJltIHdyb25nKSB0aGF0IHdlIHNob3VsZCBwdW50IGl0IHRvIGEgc2Vw YXJhdGUgZHJhZnQgKGUuZy4sIOKAnEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIEV4dGVu c2lvbnMgZm9yIG1UTFMgSHlicmlkc+KAnSkgYW5kIGdldCBtVExTIG91dCB0aGUgZG9vci4NCg0K LS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9B dXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn Pj4gb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHku Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmc+Pg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5IGF0IDU6MjggQU0NClRvOiAiUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMg dXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNClRob3NlIHBvaW50cyBvZiBjb25mdXNpb24gc3Ry aWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQgeW91ciBn ZW5lcmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFudGkgYWRk aXRpb25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzIG5vdGVkLg0KDQpBbGwgb2Ygd2hpY2gg bGVhdmVzIG1lIGEgYml0IHVuY2VydGFpbiBhYm91dCBob3cgdG8gcHJvY2VlZC4gVGhlcmUgc2Vl bSB0byBiZSBhIHJhbmdlIG9mIG9waW5pb25zIG9uIHRoaXMgcG9pbnQgYW5kIGdhdWdpbmcgY29u c2Vuc3VzIGlzIHByb3ZpbmcgZWx1c2l2ZSBmb3IgbWUuIFRoYXQncyBjb25mb3VuZGVkIGJ5IG15 IG93biBvcGluaW9uIG9uIGl0IGJlaW5nIHNvbWV3aGF0IGZsdWlkLg0KDQpBbmQgSSdkIHJlYWxs eSBsaWtlIHRvIHBvc3QgYW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYWJvdXQgYSBtb250aCBvciB0 d28gYWdvLg0KDQoNCg0KDQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCA1OjAzIFBNIFJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KQ29uZnVzaW9u IGZyb20gdGhlIEFT4oCZcyBwZXJzcGVjdGl2ZToNCg0KICAxLiAgSWYgSSBvbmx5IHN1cHBvcnQg bVRMUywgZG8gSSBuZWVkIHRvIGluY2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91cmkgYW5kIG10 bHNfZW5kcG9pbnRzPyBTaG91bGQgSSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8gT3Igc2V0IGl0 IHRvIHRoZSBlbXB0eSBzdHJpbmc/DQogIDIuICBXaGF0IGlmIEkgb25seSBzdXBwb3J0IG1UTFMg Zm9yIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IG5vdCByZXZvY2F0aW9uIG9yIHVzZXIgaW5mbz8N CiAgMy4gIEhvdyBkbyBJIHNwZWNpZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1U TFMgdG9rZW4gZW5kcG9pbnQ/IERvZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5 IHRvIGJvdGggdGhlIG1UTFMgYW5kIG5vbi1tVExTIGVuZHBvaW50cz8NCiAgNC4gIEnigJltIHVz aW5nIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cuIERvIEkgaW5jbHVkZSBhIG1UTFMtZW5hYmxl ZCBkZXZpY2VfYXV0aG9yaXphdGlvbl9lbmRwb2ludCB1bmRlciBtdGxzX2VuZHBvaW50cz8NCg0K Q29uZnVzaW9uIGZyb20gdGhlIGNsaWVudOKAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIEFzIGZh ciBhcyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0 aGluZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRz IGluIHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhh dCB0byBhdXRoZW50aWNhdGUgbWUuDQogIDIuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hl ZCBiZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuDQog IDMuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIGl0IGRpZG7igJl0IGV4 cGVjdCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBhcyBhIHBhcmFtZXRlciB2YWx1ZS4NCiAg NC4gIFRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZvciBtdGxzX2Vu ZHBvaW50cywgd2hhdCBkbyBJIGRvPw0KICA1LiAgSSBkb27igJl0IGtub3cgd2hhdCB0aGF0IOKA nG3igJ0gbWVhbnMsIGJ1dCB0aGV5IHRvbGQgbWUgdG8gdXNlIEhUVFBTLCBzbyBJIHNob3VsZCB1 c2UgdGhlIG9uZSB3aXRoIOKAnHRsc+KAnSBpbiBpdHMgbmFtZSwgcmlnaHQ/DQoNClllcywgeW91 IGNhbiB3cml0ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4gQnV0 IHlvdeKAmWxsIGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1zbGln aHRseS1kaWZmZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1wbGVt ZW50ZXJzIHdpbGwgc3RpbGwgZ2V0IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hhbmdlIGludHJv ZHVjZXMgb3Bwb3J0dW5pdGllcyBmb3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRoYXQgZG8gbm90 IGV4aXN0IG5vdywgYW5kIGZvcmNlcyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBwb3J0cyBtVExT LiBJbiBjb250cmFzdCwgdGhlIDMwNyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYW4g QVMgd2FudHMgdG8gc3VwcG9ydCBib3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMgaW4gaXRzIGJlaGF2 aW9yIGFuZCBtZWFuaW5nLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElk ZW50aXR5DQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0 eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRm Lm9yZz4+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQTQ0KVG86ICJS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+Pg0KQ2M6IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNv bTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVU SC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2lu dA0KDQpJdCBkb2Vzbid0IHNlZW0gbGlrZSB0aGF0IGNvbmZ1c2luZyBvciBsYXJnZSBvZiBhIGNo YW5nZSB0byBtZSAtIGlmIHRoZSBjbGllbnQgaXMgZG9pbmcgTVRMUyBhbmQgdGhlIGdpdmVuIGVu ZHBvaW50IGlzIHByZXNlbnQgaW4gYG10bHNfZW5kcG9pbnRzYCwgdGhlbiBpdCB1c2VzIHRoYXQg b25lLiAgT3RoZXJ3aXNlIGl0IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9pbnQuIEl0IGdpdmVzIGFu IEFTIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQgb3B0aW9ucy4gSSBwZXJzb25h bGx5IHRoaW5rIGdldHRpbmcgYSAzMDcgYXBwcm9hY2ggZGVwbG95ZWQgYW5kIHdvcmtpbmcgd291 bGQgYmUgbW9yZSBjb21wbGljYXRlZCBhbmQgZXJyb3IgcHJvbmUuDQoNCkl0IGlzIGEgbWlub3Jp dHkgdXNlIGNhc2UgYXQgdGhlIG1vbWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBs aWtlIHRoZSBwdXNoIGZvciBpbmNyZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2 ZSBqYXZhc2NyaXB0IGNsaWVudHMgdXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdCBpdCB3 b24ndCBiZSB0ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBv cnQgTVRMUyBjbGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRp bWUuDQoNCkkndmUgcGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhy ZWFkIG9uIHdoZXRoZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhp bmcgbGlrZSBpdCkuIFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBz b21ld2hlcmUgYmFjayBpbiB0aGUgNDAgb3Igc28gbWVzc2FnZXMgdGhhdCBtYWtlIHVwIHRoaXMg dGhyZWFkLiAgQnV0IGl0IHNlZW1zIGxpa2UgdGhlIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgZ3Jv dXAgaGVyZSBpcyBpbiBmYXZvciBvZiBpdC4NCg0KDQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBh dCAzOjE4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdy b3RlOg0KVGhpcyBzdHJpa2VzIG1lIGFzIGEgdmVyeSBwcm9taW5lbnQgYW5kIGNvbmZ1c2luZyBj aGFuZ2UgdG8gc3VwcG9ydCB3aGF0IHNlZW1zIHRvIGJlIGEgbWlub3JpdHkgdXNlIGNhc2UuIEni gJltIGdldHRpbmcgYSBoZWFkYWNoZSBqdXN0IHRoaW5raW5nIGFib3V0IHRoZSB0ZXh0IG5lZWRl ZCB0byBjbGFyaWZ5IHdoZW4gdGhlIEFTIHNob3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2Ag YW5kIHdoZW4gdGhlIGNsaWVudCBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9l bmRwb2ludC5gIFdoeSBpcyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3Zl ciB0aGUgY2FzZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1t VExTPw0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0K RnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFy Yy5pZXRmLm9yZz4+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMTozMSBQTQ0K VG86IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGFvbC5jb21AZG1hcmMuLi5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYu b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNVExT IGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNClllcywg dGhhdCB3b3VsZCB3b3JrLg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDI6MjggUE0gR2Vvcmdl IEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW9s LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2hhdCBpZiB0aGUgQVMgd2FudHMgdG8gT05M WSBzdXBwb3J0IE1UTFMgY29ubmVjdGlvbnMuIERvZXMgaXQgbm90IHNwZWNpZnkgdGhlIG9wdGlv bmFsICJtdGxzX2VuZHBvaW50cyIgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0YWRhdGEgdmFs dWVzPw0KT24gMS8xNS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCkl0IHdvdWxk IGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0IHdhc24ndCBtYWRlIGNs ZWFyLiBJdCdkIGJlIHNvbWV0aGluZyB0byB0aGUgZWZmZWN0IG9mIG9wdGlvbmFsIGZvciB0aGUg QVMgdG8gaW5jbHVkZSBhbmQgY2xpZW50cyBkb2luZyBNVExTIHdvdWxkIHVzZSBpdCB3aGVuIHBy ZXNlbnQgaW4gQVMgbWV0YWRhdGEuDQoNCk9uIFR1ZSwgSmFuIDE1LCAyMDE5IGF0IDI6MDQgQU0g RGF2ZSBUb25nZSA8ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPG1haWx0bzpkYXZlLnRvbmdl QG1vbWVudHVtZnQuY28udWs+PiB3cm90ZToNCkknbSBpbiBmYXZvdXIgb2YgdGhlIGBtdGxzX2Vu ZHBvaW50c2AgbWV0YWRhdGEgcGFyYW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxkIGJlIG9wdGlv bmFsLg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9y IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5k IGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBt YWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMg ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0 cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4u ICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUg bWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFu ayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24g b3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFu ZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_18CD2B6D5FA945B19334EB785F40A6A9amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <469B7697F75D3E44A1D979386C17908D@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIg MTEgNiAzIDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw Lm0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwtbS0z NzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4NjJtc29saXN0cGFyYWdy YXBoLCBsaS5tLTg1NjMzMDgyMjY1NDUwODA5NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdt YWlsLW0tMzc1MDE4MzE5MzYzNDQxOTIwNWdtYWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYybXNvbGlz dHBhcmFncmFwaCwgZGl2Lm0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2Mzkw Mjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4 NjJtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTg1NjMzMDgyMjY1NDUwODA5 NjJnbWFpbC1tXzY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tXy0zNzUwMTgzMTkzNjM0NDE5MjA1 Z21haWwtbV8yNzIyMDE4MDg2NjgxMTU1ODYybXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwt bTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcy MjAxODA4NjY4MTE1NTg2MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0tMTY2NjQ0 NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tODU2MzMwODIyNjU0NTA4MDk2Mmdt YWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwt bTI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2 NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdyYXBoLCBkaXYubS04NTYzMzA4MjI2NTQ1MDgw OTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVn bWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWls LW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6 bV8tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW1fNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW1f LTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tXzI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1tLTQ5 MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NDUwMTY0OTY7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0yMDM5NzI3MDAwO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjg2MTc0 OTIyOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA1Mzk3MTI3MDt9DQpAbGlzdCBsMg0KCXtt c28tbGlzdC1pZDoxOTI0MjIxOTY3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzkwNjA2Mjky O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGNhc2UgSeKAmW0gcmVmZXJlbmNpbmcgZGlkbuKAmXQgc3BlY2lmaWNhbGx5IGlu dm9sdmUgQVMgbWV0YWRhdGEuIFdlIGhhZCBjbGllbnRzIGluIHRoZSB3aWxkIHRoYXQgYXNzdW1l ZCB0aGF0IGFsbCB0aGUgcHJvcGVydGllcyBpbiB0aGUgSlNPTiBvYmplY3QgcmV0dXJuZWQgZnJv bSBvdXIgdXNlcmluZm8gZW5kcG9pbnQgd2VyZSBzY2FsYXIgc3RyaW5ncy4gVGhpcyBicm9rZSB3 aGVuIHdlIGludHJvZHVjZWQNCiBhIG5ldyBwcm9wZXJ0eSB3aG9zZSB2YWx1ZSB3YXMgYSBKU09O IG9iamVjdC4gSXQgd2FzIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5u b2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gZm9y Y2UgbW9yZSB3b3JrIG9uIGNsaWVudHMgdGhhbiB3ZSBleHBlY3QuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEZlYnJ1YXJ5 IDYsIDIwMTkgYXQgMTE6MzAgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZx dW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDssIG9hdXRoICZsdDtvYXV0aEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VO REVSXSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRw b2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFuZCBJJ20gaG9uZXN0bHkgcmVhbGx5IHN0cnVnZ2xpbmcgdG8gc2Vl IHdoYXQgY291bGQgaGF2ZSBnb25lIHdyb25nIHdpdGggb3IgaG93IHRva2VuX2VuZHBvaW50X2F1 dGhfbWV0aG9kcyBicm9rZSBzb21ldGhpbmcgd2l0aCB0aGUgdXNlciBpbmZvIGVuZHBvaW50LiBJ ZiB5b3UgaGF2ZSB0aGUgdGltZSBhbmQvb3IgaXQnZCBiZSBpbmZvcm1hdGl2ZSB0byB0aGlzIGhl cmUgbGl0dGxlIGRpc2N1c3Npb24sIHBsZWFzZQ0KIGV4cGxhaW4gdGhhdCBvbmUgYSBiaXQgbW9y ZS4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IEZlYiA2LCAyMDE5IGF0IDEyOjE1IFBNIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1 b3Q7ZmFyJnF1b3Q7IHNob3VsZCBoYXZlIHNhaWQgJnF1b3Q7ZmFpciZxdW90OyBpbiB0aGUgcHJl dmlvdXMgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgNDozNSBQTSBCcmlhbiBD YW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1heSB3ZWxsIGJlIGR1ZSB0byBteSBvd24gaW50ZWxs ZWN0dWFsIHNob3J0Y29taW5ncyBidXQgdGhlc2UgaXNzdWVzL3F1ZXN0aW9ucy9jb25mdXNpb24t cG9pbnRzIGFyZSBub3QgcmVzb25hdGluZyBmb3IgbWUgYXMgYmVpbmcgcHJvYmxlbWF0aWMuDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IG1vcmUgZ2VuZXJhbCBzdGFuY2Ugb2YgJnF1b3Q7dGhpcyBpc24ndCBuZWVkZWQgb3Igd29ydGgg aXQgaW4gdGhpcyBkb2N1bWVudCZxdW90OyAoSSB0aGluayB0aGF0J3MgZmFyPykgaXMgYmVpbmcg aGVhcmQgdGhvdWdoLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDE6 NDIgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1h aWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpv bi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oVEw7 RFI6IHB1bnQgQVMgbWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCk8YnI+DQo8YnI+DQpBUyBw b2ludHMgIzEtMyBhcmUgYWxsIHF1ZXN0aW9ucyBJIHdvdWxkIGhhdmUgYXMgYW4gaW1wbGVtZW50 ZXI6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJt LTg1NjMzMDgyMjY1NDUwODA5NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1 MDE4MzE5MzYzNDQxOTIwNWdtYWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYybXNvbGlzdHBhcmFncmFw aCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDE0I3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rp b24gMiBvZiBSRkM4NDE0PC9hPiBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVu bGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hh dCBkb2VzIHRoZSBtVExTLW9ubHkgQVMgcHV0IGhlcmU/PG86cD48L286cD48L2xpPjxsaSBjbGFz cz0ibS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1t LTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2Mm1zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpUaGUgY2xhaW1zIGZvciB0 aGVzZSBvdGhlciBlbmRwb2ludHMgYXJlIE9QVElPTkFMLCBwb3RlbnRpYWxseSBsZWFkaW5nIHRv IGluY29uc2lzdGVuY3kgZGVwZW5kaW5nIG9uIGhvdyAjMSBnZXRzIGRlY2lkZWQuPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0ibS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYz OTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1 NTg2Mm1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpU aGUgZXhhbXBsZSB1c2FnZSBvZiB0aGUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIHByb3Bl cnR5IGdpdmVuIGVhcmxpZXIgaXMgaW5jb21wYXRpYmxlIHdpdGggUkZDODQxNCwgc2luY2Ugc29t ZSBvZiBpdHMgY29udGVudHMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBub24tbVRMUyBlbmRwb2lu dHMsIGFuZCBvdGhlcnMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBtVExTIGVuZHBvaW50cy4gSGVu Y2UgdGhpcyBxdWVzdGlvbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJtLTg1NjMzMDgyMjY1 NDUwODA5NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1MDE4MzE5MzYzNDQx OTIwNWdtYWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYybXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1z by1saXN0OmwxIGxldmVsMSBsZm8xIj4NClRoaXMgaW50cm9kdWNlcyBhIG5ldyBtZXRhZGF0YSBw cm9wZXJ0eSB0aGF0IGNvdWxkIGltcGFjdCBob3cgb3RoZXIgc3BlY3Mgc2hvdWxkIGV4dGVuZCBB UyBtZXRhZGF0YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQuPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JIGNvdWxkIGdvIG9uIGZvciBjbGllbnQgcG9pbnRzIGJ1dCB5b3Ug YWxyZWFkeSBnZXQgdGhlIHBvaW50LiBUaG91Z2ggSeKAmWxsIHNoYXJlIHRoYXQgIzMgaXMgcmVh bCBhbmQgb25jZSBmb3JjZWQgbWUgdG8gcm9sbCBiYWNrIGFuIHVwZGF0ZSB0byB0aGUgTG9naW4g d2l0aCBBbWF6b24gdXNlcmluZm8gZW5kcG9pbnTigKZnb29kDQogdGltZXMuIDxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OyI+JiMxMjg1MTU7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb27igJl0IG5lY2Vzc2FyaWx5IHRo aW5rIGFuIEFTIG1ldGFkYXRhIHByb3BlcnR5IGlzIHdyb25nIHBlciBzZSwgYnV0IHVuZGVyc3Rh bmQgdGhhdCB5b3XigJlyZSBib2x0aW5nIGEgbGF5ZXIgb2YgZmxleGliaWxpdHkgb250byBhIHN0 YW5kYXJkIHRoYXQgd2FzbuKAmXQgZGVzaWduZWQgZm9yIHRoYXQsIGFuZCBJDQogZG9u4oCZdCB0 aGluayB0aGUgbWV0YWRhdGEgcHJvcG9zYWwgYXMgaXTigJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUg c3VmZmljaWVudGx5IGRlYWxzIHdpdGggdGhlIGZhbGxvdXQgZnJvbSB0aGF0LiBJbiBteSB2aWV3 IHRoaXMgaXMgYSBjb21wbGV4IGVub3VnaCBpc3N1ZSBhbmQgaXTigJlzIGZvciBhIG51YW5jZWQg ZW5vdWdoIHVzZSBjYXNlIChhcyBmYXIgYXMgSSBjYW4gdGVsbCBmcm9tIGRpc2N1c3Npb24/IFBs ZWFzZSBjb3JyZWN0IG1lIGlmIEnigJltIHdyb25nKQ0KIHRoYXQgd2Ugc2hvdWxkIHB1bnQgaXQg dG8gYSBzZXBhcmF0ZSBkcmFmdCAoZS5nLiwg4oCcQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRh dGEgRXh0ZW5zaW9ucyBmb3IgbVRMUyBIeWJyaWRz4oCdKSBhbmQgZ2V0IG1UTFMgb3V0IHRoZSBk b29yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5B V1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNv bG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZs dDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJl bGwgJmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5IGF0 IDU6MjggQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl JnF1b3Q7ICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5DYzogPC9iPm9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IE1UTFMgYW5kIGlu LWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhvc2UgcG9pbnRzIG9mIGNvbmZ1c2lvbiBzdHJpa2UgbWUg YXMgc29tZXdoYXQgaHlwb3RoZXRpY2FsIG9yIGh5cGVyYm9saWMuIEJ1dCB5b3VyIGdlbmVyYWwg cG9pbnQgaXMgdGFrZW4gYW5kIHlvdXIgcG9zaXRpb24gb2YgYmVpbmcgYW50aSBhZGRpdGlvbmFs IG1ldGFkYXRhIG9uIHRoaXMgaXNzdWUgaXMNCiBub3RlZC4gPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGwgb2Ygd2hpY2ggbGVhdmVz IG1lIGEgYml0IHVuY2VydGFpbiBhYm91dCBob3cgdG8gcHJvY2VlZC4gVGhlcmUgc2VlbSB0byBi ZSBhIHJhbmdlIG9mIG9waW5pb25zIG9uIHRoaXMgcG9pbnQgYW5kIGdhdWdpbmcgY29uc2Vuc3Vz IGlzIHByb3ZpbmcgZWx1c2l2ZSBmb3IgbWUuIFRoYXQncyBjb25mb3VuZGVkDQogYnkgbXkgb3du IG9waW5pb24gb24gaXQgYmVpbmcgc29tZXdoYXQgZmx1aWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgSSdkIHJlYWxseSBsaWtl IHRvIHBvc3QgYW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYWJvdXQgYSBtb250aCBvciB0d28gYWdv Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwg RmViIDEsIDIwMTkgYXQgNTowMyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmlj aGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJl bnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Db25mdXNpb24gZnJvbSB0aGUgQVPigJlzIHBlcnNwZWN0aXZlOjxvOnA+PC9vOnA+ PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0ibS04NTYzMzA4MjI2NTQ1 MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTky MDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdt YWlsLW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQpJZiBJIG9ubHkgc3VwcG9ydCBtVExTLCBkbyBJIG5lZWQgdG8g aW5jbHVkZSBib3RoIHRva2VuX2VuZHBvaW50X3VyaSBhbmQgbXRsc19lbmRwb2ludHM/IFNob3Vs ZCBJIG9taXQgdG9rZW5fZW5kcG9pbnRfdXJpPyBPciBzZXQgaXQgdG8gdGhlIGVtcHR5IHN0cmlu Zz88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJtLTg1NjMzMDgyMjY1NDUwODA5NjJnbWFpbC1t NjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1MDE4MzE5MzYzNDQxOTIwNWdtYWlsLW0yNzIy MDE4MDg2NjgxMTU1ODYyZ21haWwtbS00OTAyODIzNDYxODUzMjQzMDE4Z21haWwtbS0xNjY2NDQ2 NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCldoYXQgaWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50 LCBidXQgbm90IHJldm9jYXRpb24gb3IgdXNlciBpbmZvPzxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Im0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwt bS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1tLTQ5 MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KSG93IGRvIEkgc3BlY2lmeSBh dXRoZW50aWNhdGlvbiBtZXRob2RzIGZvciB0aGUgbVRMUyB0b2tlbiBlbmRwb2ludD8gRG9lcyB0 b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYXBwbHkgdG8gYm90aCB0aGUgbVRMUyBhbmQgbm9u LW1UTFMgZW5kcG9pbnRzPzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Im0tODU2MzMwODIyNjU0 NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5 MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThn bWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPg0KSeKAmW0gdXNpbmcgdGhlIE9BdXRoIDIuMCBEZXZpY2UgRmxv dy4gRG8gSSBpbmNsdWRlIGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRob3JpemF0aW9uX2VuZHBv aW50IHVuZGVyIG10bHNfZW5kcG9pbnRzPzxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Q29uZnVzaW9uIGZyb20gdGhlIGNsaWVudOKAmXMgcGVyc3BlY3RpdmU6PG86cD48L286cD48 L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJtLTg1NjMzMDgyMjY1NDUw ODA5NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1MDE4MzE5MzYzNDQxOTIw NWdtYWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYyZ21haWwtbS00OTAyODIzNDYxODUzMjQzMDE4Z21h aWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0 OmwyIGxldmVsMSBsZm8zIj4NCkFzIGZhciBhcyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVu dCwgYW5kIGRvbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlu cyBpbnN0YWxsZWQgY2xpZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0 aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhhdCB0byBhdXRoZW50aWNhdGUgbWUuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0ibS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYzOTAy OTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2 MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+DQpNeSBBUyBt ZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0 b2tlbl9lbmRwb2ludF91cmkuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0ibS04NTYzMzA4MjI2 NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0 MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAx OGdtYWlsLW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28t bGlzdDpsMiBsZXZlbDEgbGZvMyI+DQpNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNh dXNlIGl0IGRpZG7igJl0IGV4cGVjdCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBhcyBhIHBh cmFtZXRlciB2YWx1ZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJtLTg1NjMzMDgyMjY1NDUw ODA5NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1MDE4MzE5MzYzNDQxOTIw NWdtYWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYyZ21haWwtbS00OTAyODIzNDYxODUzMjQzMDE4Z21h aWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0 OmwyIGxldmVsMSBsZm8zIj4NClRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZh bHVlIGZvciBtdGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRvPzxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Im0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21h aWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1t LTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFy YWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KSSBkb27igJl0IGtub3cg d2hhdCB0aGF0IOKAnG3igJ0gbWVhbnMsIGJ1dCB0aGV5IHRvbGQgbWUgdG8gdXNlIEhUVFBTLCBz byBJIHNob3VsZCB1c2UgdGhlIG9uZSB3aXRoIOKAnHRsc+KAnSBpbiBpdHMgbmFtZSwgcmlnaHQ/ PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHlvdSBjYW4gd3JpdGUgbm9y bWF0aXZlIHRleHQgdGhhdCBhbnN3ZXJzIG1vc3Qgb2YgdGhlc2UuIEJ1dCB5b3XigJlsbCBoYXZl IHRvIGNsZWFybHkgY292ZXIgYSBsb3Qgb2Ygc2ltaWxhci1idXQtc2xpZ2h0bHktZGlmZmVyZW50 IHNjZW5hcmlvcyBhbmQgYmUgdmVyeSBleHBsaWNpdC4gQW5kIGltcGxlbWVudGVycw0KIHdpbGwg c3RpbGwgZ2V0IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hhbmdlIGludHJvZHVjZXMgb3Bwb3J0 dW5pdGllcyBmb3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRoYXQgZG8gbm90IGV4aXN0IG5vdywg YW5kIGZvcmNlcyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBwb3J0cyBtVExTLiBJbiBjb250cmFz dCwgdGhlIDMwNyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYW4gQVMgd2FudHMgdG8g c3VwcG9ydCBib3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMNCiBpbiBpdHMgYmVoYXZpb3IgYW5kIG1l YW5pbmcuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5CcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBp bmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVu dGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXks IEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5HZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRj aEBhb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7LCBvYXV0 aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1 dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bVU5WRVJJRklFRCBTRU5E RVJdIFJlOiBbT0FVVEgtV0ddIE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUg dG9rZW4gZW5kcG9pbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGRvZXNuJ3Qgc2VlbSBsaWtl IHRoYXQgY29uZnVzaW5nIG9yIGxhcmdlIG9mIGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVu dCBpcyBkb2luZyBNVExTIGFuZCB0aGUgZ2l2ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRs c19lbmRwb2ludHNgLCB0aGVuIGl0IHVzZXMgdGhhdCBvbmUuJm5ic3A7IE90aGVyd2lzZQ0KIGl0 IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9pbnQuIEl0IGdpdmVzIGFuIEFTIGEgbG90IG9mIGZsZXhp YmlsaXR5IGluIGRlcGxveW1lbnQgb3B0aW9ucy4gSSBwZXJzb25hbGx5IHRoaW5rIGdldHRpbmcg YSAzMDcgYXBwcm9hY2ggZGVwbG95ZWQgYW5kIHdvcmtpbmcgd291bGQgYmUgbW9yZSBjb21wbGlj YXRlZCBhbmQgZXJyb3IgcHJvbmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNlIGF0 IHRoZSBtb21lbnQgYnV0IHRoZXJlIGFyZSBmb3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVzaCBm b3IgaW5jcmVhc2VkIHNlY3VyaXR5IGluIGdlbmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlwdCBj bGllbnRzIHVzZSB0aGUgY29kZSBmbG93LCB0aGF0IHN1Z2dlc3QNCiBpdCB3b24ndCBiZSB0ZXJy aWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBjbGll bnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuDQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUg cGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhyZWFkIG9uIHdoZXRo ZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhpbmcgbGlrZSBpdCku IFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBzb21ld2hlcmUgYmFj aw0KIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0aHJlYWQuJm5i c3A7IEJ1dCBpdCBzZWVtcyBsaWtlIHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhlIGdyb3VwIGhl cmUgaXMgaW4gZmF2b3Igb2YgaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBGZWIg MSwgMjAxOSBhdCAzOjE4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5u YT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNv bG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoaXMgc3RyaWtlcyBtZSBhcyBhIHZlcnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcgY2hh bmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVtcyB0byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ4oCZ bSBnZXR0aW5nIGEgaGVhZGFjaGUganVzdCB0aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVkZWQg dG8gY2xhcmlmeSB3aGVuDQogdGhlIEFTIHNob3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2Ag YW5kIHdoZW4gdGhlIGNsaWVudCBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9l bmRwb2ludC5gIFdoeSBpcyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3Zl ciB0aGUgY2FzZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1t VExTPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5B V1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNv bG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBi ZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMTozMSBQTTxicj4N CjxiPlRvOiA8L2I+R2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86 NDBhb2wuY29tQGRtYXJjLi4uaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0OzxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3Nl ciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgdGhhdCB3b3Vs ZCB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0 O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50 Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5XaGF0IGlmIHRoZSBBUyB3YW50cyB0byBPTkxZ IHN1cHBvcnQgTVRMUyBjb25uZWN0aW9ucy4gRG9lcyBpdCBub3Qgc3BlY2lmeSB0aGUgb3B0aW9u YWwgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0 YWRhdGEgdmFsdWVzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIDEvMTUvMTkgODo0OCBBTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JdCB3b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFsLCBhcG9sb2dpZXMgaWYgdGhh dCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBv cHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3Vs ZCB1c2UgaXQgd2hlbg0KIHByZXNlbnQgaW4gQVMgbWV0YWRhdGEuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBKYW4gMTUsIDIwMTkgYXQg MjowNCBBTSBEYXZlIFRvbmdlICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1 bWZ0LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5JJ20gaW4gZmF2b3VyIG9mIHRo ZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhvdWdoIGl0IHNob3Vs ZCBiZSBvcHRpb25hbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlDQogcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1 NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElB TElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2 aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiM1NTU1 NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFM SVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3Ro ZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0 YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1NTU1 NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJ VFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls ZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQo cykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhl cnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRh Y2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1 cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9p PjwvYj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_18CD2B6D5FA945B19334EB785F40A6A9amazoncom_-- From nobody Thu Feb 7 07:58:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44B21311A2 for ; Thu, 7 Feb 2019 07:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUiIoHf_qIVL for ; Thu, 7 Feb 2019 07:58:03 -0800 (PST) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7575130F18 for ; Thu, 7 Feb 2019 07:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1549555069; bh=JeMoRh77apIQtkd38g9aiTattnhUku2msau3wYalA/Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ELt7AfvkWfjvYLEBa2PsJUFRjwPufZOU1/TKYxC7BryFncpk6tHITgGKS8ZkKpsokIqySqIVqEj0zCvKvyGnmY5Jk/Dtwnw9gxX1GUd01LpPaIPVwNaTdSyEfzXLdQ7cQnp/8Czm8w0ZEibn2OeONOF/pQ7l7mT48IDFdZGM0m/wCzsixPafdvXJlBE20cSl4eAMHiN0gGhNy4xnbouitbZIizdltgzAaGBHFUCJyHsRluFibzozOJRZJlGSxapCZYau+TCR/tid5RNr+vwcpjPbOwg3tl/HRYvHNFzBVF/fDnNqpxZdxUHm3/mvtPrSFpeZRKqo45XvK3Van6RVgw== X-YMail-OSG: w8w7N8gVM1mdgys_w.SrUdK58Ub6qUSgig1AWH2MdvnnbzGmxzCX_0ss7_.a8rz Kesj6VTog38i025BanG2UYcH6nGUCnrwGcXMWbEcyEPJfyh2mKG7NonqU6BTxvHvaCql5xn1dAzi fPZgQNgU83piU4_me3YKdAMP1.8RJMivLxKLJRlq5BtmLekLE3se8ReLdhVPHnQybmJo0M.SFtz4 mR9erUp8rbvel_.hc2K36micBDcJxHNeJzga.IiSAXLjsfhzZoo0AUB0AJ0Hx_kpI7jQMZhNnJVg 3IULkIn_3AUVF2_zH1rYr9I75.QKTC8olwmlMStk8bSjvrK3UMCekQ7f5TMG.BXTPsRbx5tBhY3S iC8kk6ixqY7hhn6_4LSsJul0uSXbH04Alus1NcSPh2Q3pVb0UVCeDhUKNFCXD8JG.p3mhSG.jnki 8G0eN5fduyCyldOmxuqehYiDmrUEDTApW_85s.90u1UR_sYollMQtIPbElpE11fa7BROqk3ZpcSR 5qT90XKqJ7SoRYJWSj_5xCGDu3AN5l1odSE6E4ru7b6CUDhEewwwrjL9S3Qnl76KyEHVCHBht.HN nnfTKiytYymN5yLdM2VsoD1qJJg._O9E5IR4dcKkf62PRR4Gq7I5ei9mhYgqzpPSF_LJx.kghctd ._LKa5OU56LO5Ak0RLOQjHSiASDypV8ia0WejTgOSJe8FvMuMHS0620K64mpzhLneA61cWDVKO9S 8zcCGXklq2X49_G_v.b._fvauknaKz6JRzDTUWYbxBsWGm_Kuh8H9CQC4sp4TbUfuSZ7srVZNZTf JWIyf6fwihlI9_do1klD0jo5jccP4f6MSrbXIPN7jvMQCyvfux2J13bwEXK.gW3QDYJesnRmWgyg QHFqydz.ZSwxOaWifoV1w1qEEN83vGyWrC1Rr5lmB2aEZ1DoErEWaqR4_CvGk_JJeRBUtO.Qcoxz aBAZ9Q_BKv1px4zYejjIHyk_pEoty5aF06wP4jFyr2KNrdkuHJkojEEHvIW34QW1d4Nb8eB0TzTL KipYT2i.Br.VX3ztM4bhWFJuyoaAYkMstN8im.5z_A_FiFF926D2Jm_dNqqxYYjCZh9o0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 Feb 2019 15:57:49 +0000 Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [10.89.92.247]) ([184.165.8.99]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ce9e0489898e3cbc8124c4c1b32d8800; Thu, 07 Feb 2019 15:57:48 +0000 (UTC) To: Hannes Tschofenig , "ace@ietf.org" Cc: "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: <0ce67b13-b22c-bd7e-dda5-e30f6b074d79@aol.com> Date: Thu, 7 Feb 2019 10:57:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------93FF2A76804F6D717C6B7398" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:58:07 -0000 This is a multi-part message in MIME format. --------------93FF2A76804F6D717C6B7398 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 for rationalizing this! :) On 2/7/19 10:24 AM, Hannes Tschofenig wrote: > > Hi all, > > after re-reading token exchange, the resource indicator, and the > ace-oauth-params drafts I am wondering whether it is really necessary > to have different functionality in ACE vs. in OAuth for basic parameters. > > Imagine I use an Authorization Server and I support devices that use > CoAP and HTTP. > > 1. If a device uses CoAP then it has to use the req_aud parameter to > indicate to the authorization server that it wants to talk to a > specific resource server. It would either put a URI or a logical > name there. > 2. If a device uses HTTP then it has to use either the resource > parameter to indicate to the authorization server that it wants to > talk to a resource server, which is identified using a URI, or the > audience parameter, if it uses a logical name. > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------93FF2A76804F6D717C6B7398 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1 for rationalizing this! :)

On 2/7/19 10:24 AM, Hannes Tschofenig wrote:

Hi all,

�

after re-reading token exchange, the resource indicator, and the ace-oauth-params drafts I am wondering whether it is really necessary to have different functionality in ACE vs. in OAuth for basic parameters.

�

Imagine I use an Authorization Server and I support devices that use CoAP and HTTP.

�

  1. If a device uses CoAP then it has to use the req_aud parameter to indicate to the authorization server that it wants to talk to a specific resource server. It would either put a URI or a logical name there.
  2. If a device uses HTTP then it has to use either the resource parameter to indicate to the authorization server that it wants to talk to a resource server, which is identified using a URI, or the audience parameter, if it uses a logical name.

�

Ciao
Hannes

�

�

�

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--------------93FF2A76804F6D717C6B7398-- From nobody Thu Feb 7 08:03:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F35128B33 for ; Thu, 7 Feb 2019 08:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pmixHpp4cPH for ; Thu, 7 Feb 2019 08:02:58 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60A6128766 for ; Thu, 7 Feb 2019 08:02:57 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id l9so334935wrt.13 for ; Thu, 07 Feb 2019 08:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=DvLhS9VsSeZVGmUkt+r0x7hN/tDjTtkObY1LSSeGJDA=; b=MtKoBA+AWMm3wUaRrOB5FYEu6dWkDu8YugFqWdUvWTIypUXK4Swy/rnwnvk7BUamU8 NIvK9EseFE1tSuHOC09RYsB51w/wLpEwX1LZyU/fyGX0jaYAyv46e7qKwxZvb2+x1CIH b7KpI1/0YrxdCRX1PxsOPu9XDkLVPNzs4br7EAwVWlNI3dI2ulC1IjVVfSd3r4P4PY6i Zle2Odci8b+gSjU0P+5TIo+DU68H5p8tgpZNUiixOsA1yufPkTxyRshHSJ9bx50gFh4v jlxiWkIdDluPraV1bpZMFfx8XqW0yzTxoiKBwlfvXllR2pdYknvkLf+amrASb/LONbLp 2mPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=DvLhS9VsSeZVGmUkt+r0x7hN/tDjTtkObY1LSSeGJDA=; b=KnoM18Y+vtFYn/PYRZzVrVK0Z258N2nZIDHQ8WmDYZDDlOva1p+pM8ATBOfzrIaAyc oISmGG3X65yoeRD5bvR0+UuhAmjgk37PpkXEqOxeygK0ubTvBu21+VsjZqgDHWB0gJPS CKbh7OUSDtgRcAfMwZfRT25wrfxanVLzStxaOcKIcKJddt/G87xfsQcZTEW4FKNqfkZ1 xG1EoDtE9qXmrO9s66sjZz4t81fRbUewAsf2wsbdIn5g2zPtO5NppXIJccEcHMt03v0x YOeA90lnQmeh96tlYgf8GNf1wIDjsZ1PM9TY7AMoDlAk2RgIEuDjP11dE9q80/fx4pVo GLZg== X-Gm-Message-State: AHQUAuY71MFXOnYZZLYSO3bvWOZ55q+SPnS5l9mGU+G98N4dRKFF004N hsnvG++2S5KggA4r54ewzm7pZGywfG4= X-Google-Smtp-Source: AHgI3IZ44Agoj5Datoph9sqjZxRPD1xiPHwXjzwswykOwixtZFj61irlZ3pwjGVEq5wAy8wQNR6VEA== X-Received: by 2002:adf:8224:: with SMTP id 33mr1127494wrb.264.1549555375666; Thu, 07 Feb 2019 08:02:55 -0800 (PST) Received: from ?IPv6:2003:c1:4f41:8e00:34fe:248a:6492:fc0f? (p200300C14F418E0034FE248A6492FC0F.dip0.t-ipconnect.de. [2003:c1:4f41:8e00:34fe:248a:6492:fc0f]) by smtp.gmail.com with ESMTPSA id i20sm1010484wmb.15.2019.02.07.08.02.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 08:02:54 -0800 (PST) To: "oauth@ietf.org" From: Daniel Fett Message-ID: Date: Thu, 7 Feb 2019 17:02:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4B075A8A74F65BDC6E4415BC" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] 4th OAuth Security Workshop - Registration now open! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:03:05 -0000 This is a multi-part message in MIME format. --------------4B075A8A74F65BDC6E4415BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit All, The registration for the 4th OAuth Security Workshop (March 20-22, Stuttgart) is now open. As usual, the workshop will feature interesting talks and discussions around OAuth, OpenID Connect, and related standards and technologies. This time, we also aim to offer tutorials on the morning of the first day and an unconference-style second day. Please register at https://sec.uni-stuttgart.de/events/osw2019 - early bird pricing is available until March 5. Please also consider submitting a proposal for a session (talk/discussion/...) or tutorial until February 18 (see link above). -Daniel --------------4B075A8A74F65BDC6E4415BC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

All,

The registration for the 4th OAuth Security Workshop (March 20-22, Stuttgart) is now open.

As usual, the workshop will feature interesting talks and discussions around OAuth, OpenID Connect, and related standards and technologies. This time, we also aim to offer tutorials on the morning of the first day and an unconference-style second day.

Please register at https://sec.uni-stuttgart.de/events/osw2019 - early bird pricing is available until March 5.

Please also consider submitting a proposal for a session (talk/discussion/...) or tutorial until February 18 (see link above).

-Daniel

--------------4B075A8A74F65BDC6E4415BC-- From nobody Thu Feb 7 08:05:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B598126D00; Thu, 7 Feb 2019 08:05: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=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN7sDJPhljPH; Thu, 7 Feb 2019 08:05:23 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50041.outbound.protection.outlook.com [40.107.5.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2123B12008F; Thu, 7 Feb 2019 08:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0+37Ytd0Kdz6A1NaT323fj49zs3Hxf3hCsW/9N5c960=; b=Jsoi8TJQtfTo0ZMwx5r9tMuP+/mti1YK+KsXg4wlyFvKOvoiQbYhu++Dd6mLHNxVSeInSbnrUxHUwqhhfZZse2THKgb4KE9tCaEdoe93CFkJ4cHyQPvQjJc39OitCx02oszZXy9Qog8NGK4F9HShsgD1dFO0OSRDxZyR/rKs3Ck= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1774.eurprd08.prod.outlook.com (10.168.67.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Thu, 7 Feb 2019 16:05:20 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1580.019; Thu, 7 Feb 2019 16:05:20 +0000 From: Hannes Tschofenig To: Filip Skokan CC: "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Resource, Audience, and req_aud Thread-Index: AdS++E7Ly8Q8wLQXRVClxzlDwlE9TQAAsgOAAADi1lA= Date: Thu, 7 Feb 2019 16:05:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1774; 6:aphtQthjYKzn56gTae2XFbP5lgtOSPLG5fLE+RAlSchs4ANcNS3bFJ4rwFYrLEdX3bZ9smhAw3Ul/PYVeiBkNXlJjMZXpua+lLhkhyL1kWFRGYbefLAXIMP9mW0forKH6cT0KdL7fH3W3/16nS2eeZ0Rl2gYcfJuS7EJBxVMTbk0uHuQzfxOTfKed7uALHaaIDw3NwBWSK1qKvtpafL1q3MtAU78v1vc9GjHZitziF21IERAczo+mipnTleomM3REPX4dCNYij+9oc4EhzFelpYUkP0Ab4sowcpuaGH+9MIKBNFKah7RKEVGbCWLcK9Cy95fepZgWxkBfeam44Kb9Kjl6i1MTT2KQYfaN1mQzUvObp9XkviWILoTH/GuWRqX4Xso+ny6oe9DBYVnMDIWH9+Fzihr4hWwuplCppLPbCPCuXHsCcAPow7pqbIU2bClfzuMyp9JAuO37S/WktXtVA==; 5:eF29SS/CM5XjdsWfNLo8XrTiTZR4TDorzGEiaaWidrOlas3PZbMneu2vwfL6EdKwA4rh7KufbyoVuHsaipBTpZQstf+C9rxqsi4pRNHqwjFFyhDqwxo2SaUepU1ZaMMsfsH+/EEDLJKaOqymzc/yJj/sQSBs580YGL8GWY9q4z1MRb6lNzY0WInq7QMs48zXjA5wgbbcNcAnUpsPeHoV6Q==; 7:S6hMySohFg+0vOPL++lWqiGT5leN33JxJ7klAhbIQysCwCymXAL5goUSrkERC7xX9jo5cd4oYuPVyUbCksLi8hovxpOaiD5+w27fVGCKJZA+roh3lOdFYQCTrOAuw81mCgAXoPd5rkxhNI16onB0Hg== x-ms-office365-filtering-correlation-id: e868a82e-8461-4a68-9316-08d68d160f23 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1774; x-ms-traffictypediagnostic: VI1PR0801MB1774: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(136003)(376002)(39860400002)(189003)(199004)(53754006)(40434004)(186003)(229853002)(7736002)(5070765005)(14444005)(6116002)(53546011)(5024004)(102836004)(256004)(99286004)(81166006)(53936002)(54906003)(6506007)(26005)(316002)(3846002)(54896002)(76176011)(236005)(6306002)(606006)(25786009)(86362001)(8936002)(8676002)(74316002)(4326008)(66066001)(6436002)(81156014)(97736004)(55016002)(71190400001)(6246003)(7696005)(105586002)(106356001)(71200400001)(790700001)(9686003)(33656002)(486006)(68736007)(14454004)(966005)(2906002)(72206003)(478600001)(6916009)(446003)(11346002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1774; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Kq3NSyZ+1K18Giaj6VIVJCwJzvAM+U7YcF2CaH12Foy4zDqF9pCZ71j4D309E8VQ3L3InqR7WmIqnCkf5yfHAIE51unXOBl2ESnpK6b3flGlEWXYZJiQD/LLAFPIuMHn90J0tazz0LjgkItrFhNF9jqh2dvm9EuHsQgYJ7MZZ0HId7l7FEnIzE3+/fCoykeDJhd1E7iWBAcRSp54JD8iaij4+m5DyPHP6C+rYgA4e1qIhz3UxVvQhQtQaJgbY5HwjRa14irhSMx9Z67jnLfqnrnI0jsvQffaqSOl94kCqxDSjXhERV/l4H29AoP8/lS3p18DJjbR+xf30whu6EhN1st8wMqXdy5r0sM4Ftu4fmG2w+t3Qg9bTUtbHbozsk/JWtwrNd/EMXFIoCicq3F1fTjWInI0vD7by7ryWcPVKmM= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122AAF0736E7BBD9A0524BFA680VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e868a82e-8461-4a68-9316-08d68d160f23 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 16:05:20.1519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1774 Archived-At: Subject: Re: [OAUTH-WG] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:05:27 -0000 --_000_VI1PR0801MB21122AAF0736E7BBD9A0524BFA680VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgdGhlIGF1dGhvcnMgb2YgdGhlIHRva2VuIGV4Y2hhbmdlIGRyYWZ0IGhhdmUgYXNrZWQg SUFOQSBmb3IgYW4gZWFybHkgcmVnaXN0cmF0aW9uIG9mIHRoZSBwYXJhbWV0ZXJzIEkgZ2V0IHRo ZSBpbXByZXNzaW9uIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIG1vcmUg4oCcIGRvZXMgdGhlIHJlc291 cmNlIGluZGljYXRvciBzcGVjIG5lZWQgdG8gZGVmaW5lIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIg KG9yIHJhdGhlciByZWZlcmVuY2UgdGhlIHJlc291cmNlIGFuZCBhdWRpZW5jZSBwYXJhbWV0ZXJz IGZyb20gdGhlIHRva2VuIGV4Y2hhbmdlIHNwZWMp4oCdPw0KDQpGcm9tOiBGaWxpcCBTa29rYW4g PHBhbnZhLmlwQGdtYWlsLmNvbT4NClNlbnQ6IERvbm5lcnN0YWcsIDcuIEZlYnJ1YXIgMjAxOSAx NjozOA0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPg0K Q2M6IGFjZUBpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IFJlc291cmNlLCBBdWRpZW5jZSwgYW5kIHJlcV9hdWQNCg0KVG8gYWRkIHRvIHRoYXQsDQoNCjMu IElmIGEgZGV2aWNlIHVzZXMgSFRUUCBUb2tlbiBFeGNoYW5nZSBpdCBjYW4gdXNlIGJvdGggcmVz b3VyY2UgYW5kIGF1ZGllbmNlIHBhcmFtZXRlcnMuDQoNCldpdGggdGhlIHJlY2VudCBkaXNjdXNz aW9uIGFuZCBjaGFuZ2VzIHRvIHRoZSBsYW5ndWFnZSBpbiB0aGUgcmVzb3VyY2UgaW5kaWNhdG9y cyBkcmFmdCwgZG9lcyB0aGUgdG9rZW4gZXhjaGFuZ2Ugc3BlYyBuZWVkIGEgdW5pcXVlIGF1ZGll bmNlIHBhcmFtZXRlcj8NCg0KUyBwb3pkcmF2ZW0sDQpGaWxpcCBTa29rYW4NCg0KDQpPbiBUaHUs IDcgRmViIDIwMTkgYXQgMTY6MjUsIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpIaSBh bGwsDQoNCmFmdGVyIHJlLXJlYWRpbmcgdG9rZW4gZXhjaGFuZ2UsIHRoZSByZXNvdXJjZSBpbmRp Y2F0b3IsIGFuZCB0aGUgYWNlLW9hdXRoLXBhcmFtcyBkcmFmdHMgSSBhbSB3b25kZXJpbmcgd2hl dGhlciBpdCBpcyByZWFsbHkgbmVjZXNzYXJ5IHRvIGhhdmUgZGlmZmVyZW50IGZ1bmN0aW9uYWxp dHkgaW4gQUNFIHZzLiBpbiBPQXV0aCBmb3IgYmFzaWMgcGFyYW1ldGVycy4NCg0KSW1hZ2luZSBJ IHVzZSBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgSSBzdXBwb3J0IGRldmljZXMgdGhhdCB1 c2UgQ29BUCBhbmQgSFRUUC4NCg0KDQogIDEuICBJZiBhIGRldmljZSB1c2VzIENvQVAgdGhlbiBp dCBoYXMgdG8gdXNlIHRoZSByZXFfYXVkIHBhcmFtZXRlciB0byBpbmRpY2F0ZSB0byB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgdGhhdCBpdCB3YW50cyB0byB0YWxrIHRvIGEgc3BlY2lmaWMgcmVz b3VyY2Ugc2VydmVyLiBJdCB3b3VsZCBlaXRoZXIgcHV0IGEgVVJJIG9yIGEgbG9naWNhbCBuYW1l IHRoZXJlLg0KICAyLiAgSWYgYSBkZXZpY2UgdXNlcyBIVFRQIHRoZW4gaXQgaGFzIHRvIHVzZSBl aXRoZXIgdGhlIHJlc291cmNlIHBhcmFtZXRlciB0byBpbmRpY2F0ZSB0byB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdGhhdCBpdCB3YW50cyB0byB0YWxrIHRvIGEgcmVzb3VyY2Ugc2VydmVyLCB3 aGljaCBpcyBpZGVudGlmaWVkIHVzaW5nIGEgVVJJLCBvciB0aGUgYXVkaWVuY2UgcGFyYW1ldGVy LCBpZiBpdCB1c2VzIGEgbG9naWNhbCBuYW1lLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQoNCklNUE9S VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y bWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB21122AAF0736E7BBD9A0524BFA680VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnAuZ21haWwtbTgxNTY1NjEyMjE5MzQxNDA5OTBtc29saXN0cGFyYWdyYXBoLCBsaS5n bWFpbC1tODE1NjU2MTIyMTkzNDE0MDk5MG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tODE1 NjU2MTIyMTkzNDE0MDk5MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwt bV84MTU2NTYxMjIxOTM0MTQwOTkwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQxODU1NTQxNjsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NDk5NTU1ODE4O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TaW5jZSB0aGUgYXV0aG9ycyBvZiB0aGUgdG9rZW4gZXhjaGFuZ2UgZHJhZnQg aGF2ZSBhc2tlZCBJQU5BIGZvciBhbiBlYXJseSByZWdpc3RyYXRpb24gb2YgdGhlIHBhcmFtZXRl cnMgSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgcXVlc3Rpb24gaXMgbW9yZSDigJwgZG9l cyB0aGUgcmVzb3VyY2UgaW5kaWNhdG9yIHNwZWMgbmVlZCB0byBkZWZpbmUgdGhlIHJlc291cmNl IHBhcmFtZXRlciAob3IgcmF0aGVyDQogcmVmZXJlbmNlIHRoZSByZXNvdXJjZSBhbmQgYXVkaWVu Y2UgcGFyYW1ldGVycyBmcm9tIHRoZSB0b2tlbiBleGNoYW5nZSBzcGVjKeKAnT8gPG86cD4NCjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+IEZpbGlwIFNrb2thbiAmbHQ7cGFudmEuaXBAZ21haWwuY29tJmd0 Ow0KPGJyPg0KPGI+U2VudDo8L2I+IERvbm5lcnN0YWcsIDcuIEZlYnJ1YXIgMjAxOSAxNjozODxi cj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBhY2VAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlc291cmNlLCBBdWRpZW5jZSwgYW5k IHJlcV9hdWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8g YWRkIHRvIHRoYXQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjMuIElmIGEgZGV2aWNlIHVzZXMgSFRUUCBUb2tlbiBFeGNoYW5nZSBpdCBjYW4g dXNlIGJvdGggPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4NCnJlc291cmNlPC9zcGFuPiBhbmQgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5hdWRpZW5jZTwvc3Bhbj4gcGFyYW1ldGVycy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCB0aGUgcmVjZW50 IGRpc2N1c3Npb24gYW5kIGNoYW5nZXMgdG8gdGhlIGxhbmd1YWdlIGluIHRoZSByZXNvdXJjZSBp bmRpY2F0b3JzIGRyYWZ0LCBkb2VzIHRoZSB0b2tlbiBleGNoYW5nZSBzcGVjIG5lZWQgYSB1bmlx dWUgYXVkaWVuY2UgcGFyYW1ldGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UyBwb3pkcmF2ZW0sPGJyPg0KPGI+RmlsaXAgU2tva2Fu PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VGh1LCA3IEZlYiAyMDE5IGF0IDE2OjI1LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkg YWxsLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+YWZ0ZXIgcmUtcmVhZGluZyB0b2tlbiBleGNo YW5nZSwgdGhlIHJlc291cmNlIGluZGljYXRvciwgYW5kIHRoZSBhY2Utb2F1dGgtcGFyYW1zIGRy YWZ0cyBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIGl0IGlzIHJlYWxseSBuZWNlc3NhcnkgdG8gaGF2 ZSBkaWZmZXJlbnQgZnVuY3Rpb25hbGl0eQ0KIGluIEFDRSB2cy4gaW4gT0F1dGggZm9yIGJhc2lj IHBhcmFtZXRlcnMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkltYWdpbmUgSSB1c2UgYW4gQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIEkgc3VwcG9ydCBkZXZpY2VzIHRoYXQgdXNlIENvQVAgYW5k IEhUVFAuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9 IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJnbWFpbC1tODE1NjU2MTIyMTkzNDE0MDk5MG1zb2xp c3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+SWYgYSBkZXZpY2UgdXNlcyBDb0FQIHRoZW4gaXQgaGFzIHRvIHVzZSB0aGUgcmVx X2F1ZCBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRo YXQgaXQgd2FudHMgdG8gdGFsayB0byBhIHNwZWNpZmljIHJlc291cmNlIHNlcnZlci4gSXQgd291 bGQgZWl0aGVyIHB1dCBhIFVSSSBvciBhIGxvZ2ljYWwgbmFtZSB0aGVyZS4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tODE1NjU2MTIyMTkzNDE0MDk5MG1zb2xpc3Rw YXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+SWYgYSBkZXZpY2UgdXNlcyBIVFRQIHRoZW4gaXQgaGFzIHRvIHVzZSBlaXRoZXIgdGhl IHJlc291cmNlIHBhcmFtZXRlciB0byBpbmRpY2F0ZSB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdGhhdCBpdCB3YW50cyB0byB0YWxrIHRvIGEgcmVzb3VyY2Ugc2VydmVyLCB3aGljaCBpcyBp ZGVudGlmaWVkIHVzaW5nIGEgVVJJLCBvciB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyLCBpZiBpdCB1 c2VzIGEgbG9naWNhbCBuYW1lLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2lhbzxi cj4NCkhhbm5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwNCiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB21122AAF0736E7BBD9A0524BFA680VI1PR0801MB2112_-- From nobody Thu Feb 7 08:05:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF98F12F1A2 for ; Thu, 7 Feb 2019 08:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX9PN84qGIh8 for ; Thu, 7 Feb 2019 08:05:45 -0800 (PST) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD57130F3B for ; Thu, 7 Feb 2019 08:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1549555542; bh=xUSK28T0q+SQ8IwDt7wC5xD7R1Xy9IPs39OALqCzkAo=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ZYDNJCJVDFWDVlBybTu7KYVhbWvsXRvnoZuZH8ZlAzwJZrf05cnPyO0YeoGWgmz9xyFNjTWpIgZrt+tLWuIhxnVTib6ziI6yg5ammVL7eOfO5zibnlk8ADZbfVv2YK7gWCNBXwSWtUKBZwYDDh11LDPH+DWdhl12VTS2ttfumNl1Rh/lod5y+lW4R/wm13cUsUxzYz/EhSRUTLwyqZtIVLTzRUUMX3RNOw9aA07cSbP6q35FxLTLYbkwzkMid5vZ2EZHOQw59um1pZ0lr2kNS3p2v6RICRsH0N5pfgTjqXEOAwrAaq89QJiDjJW6zoxPyMHLuEIPEHhodnZY87ftEg== X-YMail-OSG: s29ItuEVM1kz6xW0gkS1ricGDd2y.afhLkACLAJpf9EPNZW8YN49nSazeLOdnnE xh7OL8AdjWWLDetPF3JgiMLNJLofGzrCqX9EwiK72TxRpZloSQ5ABxZRE2JvHVSeHardlzHn_eMh Z2D58WXsvrApl8ydHKzapuFFwnfQueCDVf4C7QaKiaPeJn2zZn8evww84U3d70DxGta1PQIAwP4R u5atYGUEql_pterd67vpm._Kt5rL4Vs4iEzh2NvecI3gvi5rQkJlfih.by4XYESGGaT3e7oVmZLs IWCUhRoNoJiJoCKJbqZ.8TgKeBG6hgsjGAJEDF4F5YTEZWidHBCMP3MXB3okN9RLW0695i.NR8zI OFpJfGdaZ5YAMaXtmxYxsVFEdRyODoe4rCZarvvWCJ7XGVGK67.NRCyJxK7IegPUtcWHlvzBVpZr EvgQIF3u6KBfu0pAwDXD4nwx.XveUnM6cfoVsjbN_bemcXT5NlOGgh.rZFAzYtSZo70zLFfBlL0o zQyYaXPx.FYJOyAgdZMR9_MlLSosmzUd0kBdh7eVQj7vEgLRcpijLvvzyixprT0tQMp3ISj_IZ9v 0F9E15__r9pkRX1vgeMIJUi0qBneUJjdLw7QfvH_Dir3mna3M76hDnhq3q5qjkC1ZdMPDyK4EIli ._qt0H2qP0.zXfRxtG98J7WxaG73shT_EgpA27Kr5izBiM4OAd52x8db0._HvoW5hbGWD7Vd0Yi1 7z43hq6dzQL7hK6MsWWb8U4oEzcMlkxmACTwlpsXHPDji_5nKV.pgdYuEGJR2Yh600NQYAnQhZHu AXjPx5xMmeUkRPfEIrpNW7X.tnvx7h4VoTCMG_m6bqGsgZb7Urn9HNCB0DmkiMXrix1lvWsXqz.j V030438hYXYFjw2.fgOdFSdUFm9__HFzxKjoEyF92oTn4jimhP75efAGHBTfiHlEAQ9cCw4FQy0x wvI1H57lVQx9ZUIacfptKMrq8s3h.sUGivthDcO8K6aVSklNtW1P2RHlr1LWrh_QO3Mckct33YSQ onTMN4.NaxmgClqQQWleLomW0qzwz8cXigzNaSS2PGg5eIDmkmvNYJVvbzj1kTOPX Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 Feb 2019 16:05:42 +0000 Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [10.89.92.247]) ([184.165.8.99]) by smtp414.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 483a52b58039239bac8fef3b4f174921; Thu, 07 Feb 2019 16:05:39 +0000 (UTC) To: Hannes Tschofenig , Ludwig Seitz , "ace@ietf.org" , "oauth@ietf.org" References: <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 7 Feb 2019 11:05:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9ED1AE8C0B808192A81FAB79" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:05:51 -0000 This is a multi-part message in MIME format. --------------9ED1AE8C0B808192A81FAB79 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is true... however, to my knowledge there is no support for this parameter outside of the token-exchange spec. Just because it is documented as an OAuth parameter I don't consider it usable in other contexts unless spec'd to do so. If we want to use 'audience' for logical audience names when binding audiences to tokens, then we need a spec for that (or add it to the resource-indicators spec). Personally, I see a lot of overlap even between the 'audience' and 'resource' parameters. I'd really prefer we just have one parameter that can be either logical or specific. As outlined in this thread, 'https://api.exampl.com' to me is a logical representation of the resource if the "real" endpoint(s) are "https://api.example.com/mail/user/inbox", ... Thanks, George On 2/7/19 10:16 AM, Hannes Tschofenig wrote: > > Hi George, > > * I believe that since the latest draft of the resource indicators > spec [1] allows for abstract identifiers, and since a URN is also > a URI, you could easily use a URN syntax to accomplish the use > case outlined in your email. > > After re-reading the token exchange draft I realized that we have > already defined a separate parameter for “abstract”, or logical, names > via the audience parameter. Here is the definition: > > audience > > OPTIONAL.  The logical name of the target service where the client > > intends to use the requested security token.  This serves a > > purpose similar to the "resource" parameter, but with the client > > providing a logical name rather than a location. Interpretation > > of the name requires that the value be something that both the > > client and the authorization server understand.  An OAuth client > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os > ], > an > > OpenID Connect Issuer Identifier [OpenID.Core > ], > or a URI are > > examples of things that might be used as "audience" parameter > > values.  Multiple "audience" parameters may be used to indicate > > that the issued token is intended to be used at the multiple > > audiences listed.  The "audience" and "resource" parameters may be > > used together to indicate multiple target services with a mix of > > logical names and locations. > > Ciao > > Hannes > > *From:*Ace *On Behalf Of *George Fletcher > *Sent:* Dienstag, 29. Januar 2019 14:15 > *To:* Ludwig Seitz ; ace@ietf.org; oauth@ietf.org > *Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > Thank you so much for the background! > > I believe that since the latest draft of the resource indicators spec > [1] allows for abstract identifiers, and since a URN is also a URI, > you could easily use a URN syntax to accomplish the use case outlined > in your email. > > resource=urn:x-mydevices:temperatureSensorGroup4711 > > The spec currently outlines examples where the "resource identifier" > is not a "single resource" in the context of a fully qualified API > endpoint. > > Another example, for an API like SCIM [RFC7644 ] that has > >    multiple endpoints such as"https://apps.example.com/scim/Users" , > > "https://apps.example.com/scim/Groups" , and > > "https://apps.example.com/scim/Schemas" The client would use > > "https://apps.example.com/scim/" as the resource so that the issued > >    access token is valid for all the endpoints of the SCIM API. > > Using "https://apps.example.com/scim" > is semantically equivalent to using "temperatureSensorGroup4711", at > least to me:) > > Thanks, > George > > [1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 > > On 1/29/19 2:56 AM, Ludwig Seitz wrote: > > On 28/01/2019 23:12, George Fletcher wrote: > > I also don't know that this raises to the level of "concern" > but I find the parameter name of "req_aud" odd. Given that the > parameter in the resource-indicators spec is 'resource' why > not use a parameter name of 'audience'. That said, I have not > read the thread on the ACE working group list so there could > be very good reasons for the chosen name:) > > I do think that there is a lot of overlap (in most cases) > between 'resource' and 'audience' and having two parameters > that cover a lot of the same semantics is going to be > confusing for developers. When calling an API at a resource > server, the 'audience' and the 'resource' are pretty > equivalent. Maybe in other use cases they are distinctly > separate? > > > To give you all the background of "req_aud" from ACE (sorry for > the long text): > > Originally in ACE we had defined the "aud" parameter for requests > to the token endpoint with the semantics that the client was > requesting a token for a certain audience (i.e. requesting that > the AS copy the "aud" parameter value into the "aud" claim value > of the token). > We were then told that this collided with a use of "aud" in OAuth, > that specifies the intended audience of Authorization Servers (if > I remember correctly), so we decided to rename our parameter to > "req_aud" for "requested audience". > Mike Jones then made us aware of the work on resource indicators, > but upon closer examination I found the "resource" parameter to be > more limited than the "req_aud", since resource specifically states: > > "Its value MUST be an absolute URI ... the "resource" parameter > URI value is an identifier representing the identity of the resource" > > My interpretation of this is that "resource" refers to a single > resource, which is more constrained than the definition of the > "aud" claim from 7519, which uses a StringOrURI value.  For > example my intent was to use "aud" and "req_aud" for group > identifiers ("temperatureSensorGroup4711") and other non-uri > strings (hash-of-public-key), which I cannot do with "resource".  > We therefore decided to keep the "req_aud" parameter in > draft-ietf-ace-oauth-params, even though is clearly overlaps with > "resource". > > Any comments and suggestions about that line of reasoning > (especially from the OAuth point of view) are very welcome. > > /Ludwig > --------------9ED1AE8C0B808192A81FAB79 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This is true... however, to my knowledge there is no support for this parameter outside of the token-exchange spec. Just because it is documented as an OAuth parameter I don't consider it usable in other contexts unless spec'd to do so. If we want to use 'audience' for logical audience names when binding audiences to tokens, then we need a spec for that (or add it to the resource-indicators spec).

Personally, I see a lot of overlap even between the 'audience' and 'resource' parameters. I'd really prefer we just have one parameter that can be either logical or specific. As outlined in this thread, 'https://api.exampl.com' to me is a logical representation of the resource if the "real" endpoint(s) are "https://api.example.com/mail/user/inbox", ...

Thanks,
George
On 2/7/19 10:16 AM, Hannes Tschofenig wrote:

Hi George,

 

  • I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email.

After re-reading the token exchange draft I realized that we have already defined a separate parameter for “abstract”, or logical, names via the audience parameter. Here is the definition:

 

   audience

      OPTIONAL.  The logical name of the target service where the client

      intends to use the requested security token.  This serves a

      purpose similar to the "resource" parameter, but with the client

      providing a logical name rather than a location.  Interpretation

      of the name requires that the value be something that both the

      client and the authorization server understand.  An OAuth client

      identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an

      OpenID Connect Issuer Identifier [OpenID.Core], or a URI are

      examples of things that might be used as "audience" parameter

      values.  Multiple "audience" parameters may be used to indicate

      that the issued token is intended to be used at the multiple

      audiences listed.  The "audience" and "resource" parameters may be

      used together to indicate multiple target services with a mix of

      logical names and locations.

 

Ciao

Hannes

 

 

From: Ace <ace-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org; oauth@ietf.org
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is not a "single resource" in the context of a fully qualified API endpoint. 

Another example, for an API like SCIM [RFC7644] that has
   multiple endpoints such as "https://apps.example.com/scim/Users",
   "https://apps.example.com/scim/Groups", and
   "https://apps.example.com/scim/Schemas" The client would use
   "https://apps.example.com/scim/" as the resource so that the issued
   access token is valid for all the endpoints of the SCIM API.

Using "https://apps.example.com/scim" is semantically equivalent to using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

On 1/29/19 2:56 AM, Ludwig Seitz wrote:

On 28/01/2019 23:12, George Fletcher wrote:

I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate?


To give you all the background of "req_aud" from ACE (sorry for the long text):

Originally in ACE we had defined the "aud" parameter for requests to the token endpoint with the semantics that the client was requesting a token for a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that specifies the intended audience of Authorization Servers (if I remember correctly), so we decided to rename our parameter to "req_aud" for "requested audience".
Mike Jones then made us aware of the work on resource indicators, but upon closer examination I found the "resource" parameter to be more limited than the "req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI value is an identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single resource, which is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value.  For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource".  We therefore decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with "resource".

Any comments and suggestions about that line of reasoning (especially from the OAuth point of view) are very welcome.

/Ludwig


--------------9ED1AE8C0B808192A81FAB79-- From nobody Thu Feb 7 08:26:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3A1289FA; Thu, 7 Feb 2019 08:26:50 -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=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHqYa-Mb6sRq; Thu, 7 Feb 2019 08:26:47 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20050.outbound.protection.outlook.com [40.107.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947C81271FF; Thu, 7 Feb 2019 08:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k+g+ZHYq3mmspbsH7xwIKl642TywmpGjbse/jagsVHM=; b=pmlqrJ4TtmwBBG1PrFGGHduFOpC2xyCsjcJRPidyCclwYdNQlARKCBn+vSndv8yjIBFKYW9FGX60zisrwsi/MFnPo9KOyNFJju5xbkS4j8OGpk142PHfu5VRm81x3tTWgFYwNyR+9YtAHp60c25MK5Nw07/0oTEpwlMglGaKvFg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1742.eurprd08.prod.outlook.com (10.168.67.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Thu, 7 Feb 2019 16:26:43 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1580.019; Thu, 7 Feb 2019 16:26:43 +0000 From: Hannes Tschofenig To: George Fletcher , Ludwig Seitz , "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 Thread-Index: AQHUt9StSyg3OJ6I2kOpeSIpgZ6iyqXUgBoQgAAOKYCAAAUdcA== Date: Thu, 7 Feb 2019 16:26:42 +0000 Message-ID: References: <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1742; 6:IbnMhoroBCCZ4mRDP8oymHxMdoo1ug/1tyKmBVxgoAgveRWFPtSsujfSjKX2ebltON0ixh/idtGqYdC7GGlNx7MbWXjCTmnAFHqIx+fg9NlZaJOMBi8OZksueVY3DY2Js/0rPorlZJNKmJpdZ0HGD4IsE+65sO19fOQZXdlKWnhL/AuFEQgzyAeeEidu0kdi61CB16FFfl9ohp+on3rrb9GfyDTmWvuubgIfdm6uvjj9+69tTPQUE6cxKTqGbcDZ7nwWFOguF+FLOibG/g65sjX7Ka3LAN09+6Vi0iiB01NChcKGyuNoDyyfv7h7kkE63EJZkaF7Vb65pHEEINMm6QZbUwLuW3Ttq9iiG4gcU6tnjOHLpyJ2eCe/G1Lujndh5m+c3emOhxRkdNPgqBiN+IgdVLs80yX1Ipt8FUAIV36UYtBrB9WFCemnPvMQHSo6YXX8gPqr3SvP205M0c2yHg==; 5:dFUx782wGabtoPi5uKDBwP63DofUADv6U+kK3if2rkng3Xz8AMq6Q1iCaAqD+FGw8n4wCkRy6ARZdaDjuRaXZHYomhlP/Kow/EeakCLkHrDqAZ96pFZlf6N7ssv7F75JHBzV3Dyeu+psYySEo+ZLutn3iCmHq4354hxkV4mxeHDTeLvJDpP7wwPZpQ00q0tWveRSBV9c4C/PCIXj5l0jWA==; 7:WTCMnljlVYlQPTaMVZcYcz+9ytxn7B1X2PVQjvWS3qEGt0G8ngiN9kTW0ilhMI92Y8z7EhlioyEPYIzv9MDpn/7fJOFOUzOsq+59L2PmLYsyz8UXl1/oqQzIBIGrHj2tCiIexsZDkwNH5sEa7467Fg== x-ms-office365-filtering-correlation-id: 24d45253-1cb3-4e97-88a4-08d68d190bce x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1742; x-ms-traffictypediagnostic: VI1PR0801MB1742: x-ms-exchange-purlcount: 11 x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(136003)(366004)(39860400002)(199004)(189003)(40434004)(6436002)(55016002)(7696005)(229853002)(76176011)(2201001)(478600001)(2501003)(110136005)(2906002)(966005)(14454004)(316002)(11346002)(790700001)(72206003)(476003)(86362001)(6246003)(33656002)(8936002)(6506007)(53546011)(102836004)(25786009)(81156014)(8676002)(81166006)(7736002)(71190400001)(74316002)(71200400001)(9686003)(99286004)(66066001)(6306002)(106356001)(6116002)(26005)(68736007)(186003)(3846002)(236005)(9326002)(54896002)(53936002)(486006)(446003)(105586002)(14444005)(256004)(5024004)(97736004)(93886005)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1742; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AZX/pdNMKh5lN0el6vbVSyaDS6lmWzEEvhOzpgSxqy6v+fduoQuMpsMcF+pXs85Dnzo8VpmwF83555pcwna9Cy5RZVLBZ0wFOmHWs0r1oN1PnE2asBDcqmyw3W6ScztTMt/HQyggXT1ifsstc2HQlYTqSgAU0w1PUd3KrQbzo+bSmUd8gvT11iHv1JDuaRdiU1eRmZkOJUMsK0W7UYqjS3vy3660+nu3W65l3Co96o4yu36/6bvCKYmElRJqhOec1PJw5lsydxWJ2ylHG2/2qaboe1M1h9DDYXiBbNl6XgB98+WuQFIypgiPO1iq3ZlJU4ahU0Hvut7X/eqEUJq7vdDXdjV1FN/+HngNDj4SugAeX9Z3O+hcJ8H27rkS9li0w0ltmJ+hucHZZtMr+wmNkA95aB4G4+e8rkMevMbrsXA= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122F4357775349577965E6FA680VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24d45253-1cb3-4e97-88a4-08d68d190bce X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 16:26:42.9545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1742 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:26:50 -0000 --_000_VI1PR0801MB21122F4357775349577965E6FA680VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2VvcmdlLA0KDQpUaGUgSUFOQSByZWdpc3RyeSBkb2VzIG5vdCBpbmRpY2F0ZSBpbiB3aGF0 IGNvbnRleHQgdGhlc2UgcGFyYW1ldGVycyBhcmUgc3VwcG9zZWQgdG8gYmUgdXNlZC4gVG8gbWUg aXQgZmVlbHMgdG90YWxseSBub3JtYWwgdG8gdXNlIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXIgaW5z dGVhZCBvZiB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIHdoZW4gSSBoYXZlIGEgbG9naWNhbCBuYW1l Lg0KDQpTdHVmZmluZyBldmVyeXRoaW5nIGludG8gYSBVUkkgaXMgcG9zc2libGUgYnV0IGluIGNl cnRhaW4gc2NlbmFyaW9zIG1heSBmZWVsIHF1aXRlIHVubmF0dXJhbC4gSXQgbXVzdCBoYXZlIGZl bHQgdW5uYXR1cmFsIGFscmVhZHkgdG8gdGhlIGdyb3VwIHdoZW4gd29ya2luZyBvbiB0aGUgdG9r ZW4gZXhjaGFuZ2Ugc3BlY+KApg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogR2VvcmdlIEZsZXRj aGVyIDxnZmZsZXRjaEBhb2wuY29tPg0KU2VudDogRG9ubmVyc3RhZywgNy4gRmVicnVhciAyMDE5 IDE3OjA2DQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+ OyBMdWR3aWcgU2VpdHogPGx1ZHdpZy5zZWl0ekByaS5zZT47IGFjZUBpZXRmLm9yZzsgb2F1dGhA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBbT0FVVEgtV0ddIFNoZXBoZXJkIHdyaXRlLXVw IGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDENCg0KVGhpcyBpcyB0 cnVlLi4uIGhvd2V2ZXIsIHRvIG15IGtub3dsZWRnZSB0aGVyZSBpcyBubyBzdXBwb3J0IGZvciB0 aGlzIHBhcmFtZXRlciBvdXRzaWRlIG9mIHRoZSB0b2tlbi1leGNoYW5nZSBzcGVjLiBKdXN0IGJl Y2F1c2UgaXQgaXMgZG9jdW1lbnRlZCBhcyBhbiBPQXV0aCBwYXJhbWV0ZXIgSSBkb24ndCBjb25z aWRlciBpdCB1c2FibGUgaW4gb3RoZXIgY29udGV4dHMgdW5sZXNzIHNwZWMnZCB0byBkbyBzby4g SWYgd2Ugd2FudCB0byB1c2UgJ2F1ZGllbmNlJyBmb3IgbG9naWNhbCBhdWRpZW5jZSBuYW1lcyB3 aGVuIGJpbmRpbmcgYXVkaWVuY2VzIHRvIHRva2VucywgdGhlbiB3ZSBuZWVkIGEgc3BlYyBmb3Ig dGhhdCAob3IgYWRkIGl0IHRvIHRoZSByZXNvdXJjZS1pbmRpY2F0b3JzIHNwZWMpLg0KDQpQZXJz b25hbGx5LCBJIHNlZSBhIGxvdCBvZiBvdmVybGFwIGV2ZW4gYmV0d2VlbiB0aGUgJ2F1ZGllbmNl JyBhbmQgJ3Jlc291cmNlJyBwYXJhbWV0ZXJzLiBJJ2QgcmVhbGx5IHByZWZlciB3ZSBqdXN0IGhh dmUgb25lIHBhcmFtZXRlciB0aGF0IGNhbiBiZSBlaXRoZXIgbG9naWNhbCBvciBzcGVjaWZpYy4g QXMgb3V0bGluZWQgaW4gdGhpcyB0aHJlYWQsICdodHRwczovL2FwaS5leGFtcGwuY29tJyB0byBt ZSBpcyBhIGxvZ2ljYWwgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlIGlmIHRoZSAicmVh bCIgZW5kcG9pbnQocykgYXJlICJodHRwczovL2FwaS5leGFtcGxlLmNvbS9tYWlsL3VzZXIvaW5i b3giPGh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL21haWwvdXNlci9pbmJveD4sIC4uLg0KDQpUaGFu a3MsDQpHZW9yZ2UNCk9uIDIvNy8xOSAxMDoxNiBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6 DQpIaSBHZW9yZ2UsDQoNCg0KICAqICAgSSBiZWxpZXZlIHRoYXQgc2luY2UgdGhlIGxhdGVzdCBk cmFmdCBvZiB0aGUgcmVzb3VyY2UgaW5kaWNhdG9ycyBzcGVjIFsxXSBhbGxvd3MgZm9yIGFic3Ry YWN0IGlkZW50aWZpZXJzLCBhbmQgc2luY2UgYSBVUk4gaXMgYWxzbyBhIFVSSSwgeW91IGNvdWxk IGVhc2lseSB1c2UgYSBVUk4gc3ludGF4IHRvIGFjY29tcGxpc2ggdGhlIHVzZSBjYXNlIG91dGxp bmVkIGluIHlvdXIgZW1haWwuDQoNCg0KQWZ0ZXIgcmUtcmVhZGluZyB0aGUgdG9rZW4gZXhjaGFu Z2UgZHJhZnQgSSByZWFsaXplZCB0aGF0IHdlIGhhdmUgYWxyZWFkeSBkZWZpbmVkIGEgc2VwYXJh dGUgcGFyYW1ldGVyIGZvciDigJxhYnN0cmFjdOKAnSwgb3IgbG9naWNhbCwgbmFtZXMgdmlhIHRo ZSBhdWRpZW5jZSBwYXJhbWV0ZXIuIEhlcmUgaXMgdGhlIGRlZmluaXRpb246DQoNCiAgIGF1ZGll bmNlDQogICAgICBPUFRJT05BTC4gIFRoZSBsb2dpY2FsIG5hbWUgb2YgdGhlIHRhcmdldCBzZXJ2 aWNlIHdoZXJlIHRoZSBjbGllbnQNCiAgICAgIGludGVuZHMgdG8gdXNlIHRoZSByZXF1ZXN0ZWQg c2VjdXJpdHkgdG9rZW4uICBUaGlzIHNlcnZlcyBhDQogICAgICBwdXJwb3NlIHNpbWlsYXIgdG8g dGhlICJyZXNvdXJjZSIgcGFyYW1ldGVyLCBidXQgd2l0aCB0aGUgY2xpZW50DQogICAgICBwcm92 aWRpbmcgYSBsb2dpY2FsIG5hbWUgcmF0aGVyIHRoYW4gYSBsb2NhdGlvbi4gIEludGVycHJldGF0 aW9uDQogICAgICBvZiB0aGUgbmFtZSByZXF1aXJlcyB0aGF0IHRoZSB2YWx1ZSBiZSBzb21ldGhp bmcgdGhhdCBib3RoIHRoZQ0KICAgICAgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdW5kZXJzdGFuZC4gIEFuIE9BdXRoIGNsaWVudA0KICAgICAgaWRlbnRpZmllciwgYSBTQU1M IGVudGl0eSBpZGVudGlmaWVyIFtPQVNJUy5zYW1sLWNvcmUtMi4wLW9zPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTE2I3JlZi1PQVNJ Uy5zYW1sLWNvcmUtMi4wLW9zPl0sIGFuDQogICAgICBPcGVuSUQgQ29ubmVjdCBJc3N1ZXIgSWRl bnRpZmllciBbT3BlbklELkNvcmU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTYjcmVmLU9wZW5JRC5Db3JlPl0sIG9yIGEgVVJJIGFy ZQ0KICAgICAgZXhhbXBsZXMgb2YgdGhpbmdzIHRoYXQgbWlnaHQgYmUgdXNlZCBhcyAiYXVkaWVu Y2UiIHBhcmFtZXRlcg0KICAgICAgdmFsdWVzLiAgTXVsdGlwbGUgImF1ZGllbmNlIiBwYXJhbWV0 ZXJzIG1heSBiZSB1c2VkIHRvIGluZGljYXRlDQogICAgICB0aGF0IHRoZSBpc3N1ZWQgdG9rZW4g aXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhdCB0aGUgbXVsdGlwbGUNCiAgICAgIGF1ZGllbmNlcyBs aXN0ZWQuICBUaGUgImF1ZGllbmNlIiBhbmQgInJlc291cmNlIiBwYXJhbWV0ZXJzIG1heSBiZQ0K ICAgICAgdXNlZCB0b2dldGhlciB0byBpbmRpY2F0ZSBtdWx0aXBsZSB0YXJnZXQgc2VydmljZXMg d2l0aCBhIG1peCBvZg0KICAgICAgbG9naWNhbCBuYW1lcyBhbmQgbG9jYXRpb25zLg0KDQpDaWFv DQpIYW5uZXMNCg0KDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86YWNl LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHZW9yZ2UgRmxldGNoZXINClNlbnQ6IERp ZW5zdGFnLCAyOS4gSmFudWFyIDIwMTkgMTQ6MTUNClRvOiBMdWR3aWcgU2VpdHogPGx1ZHdpZy5z ZWl0ekByaS5zZT48bWFpbHRvOmx1ZHdpZy5zZWl0ekByaS5zZT47IGFjZUBpZXRmLm9yZzxtYWls dG86YWNlQGlldGYub3JnPjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtBY2VdIFtPQVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAgZm9yIGRyYWZ0 LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMQ0KDQpUaGFuayB5b3Ugc28gbXVjaCBm b3IgdGhlIGJhY2tncm91bmQhDQoNCkkgYmVsaWV2ZSB0aGF0IHNpbmNlIHRoZSBsYXRlc3QgZHJh ZnQgb2YgdGhlIHJlc291cmNlIGluZGljYXRvcnMgc3BlYyBbMV0gYWxsb3dzIGZvciBhYnN0cmFj dCBpZGVudGlmaWVycywgYW5kIHNpbmNlIGEgVVJOIGlzIGFsc28gYSBVUkksIHlvdSBjb3VsZCBl YXNpbHkgdXNlIGEgVVJOIHN5bnRheCB0byBhY2NvbXBsaXNoIHRoZSB1c2UgY2FzZSBvdXRsaW5l ZCBpbiB5b3VyIGVtYWlsLg0KDQpyZXNvdXJjZT11cm46eC1teWRldmljZXM6dGVtcGVyYXR1cmVT ZW5zb3JHcm91cDQ3MTENCg0KVGhlIHNwZWMgY3VycmVudGx5IG91dGxpbmVzIGV4YW1wbGVzIHdo ZXJlIHRoZSAicmVzb3VyY2UgaWRlbnRpZmllciIgaXMgbm90IGEgInNpbmdsZSByZXNvdXJjZSIg aW4gdGhlIGNvbnRleHQgb2YgYSBmdWxseSBxdWFsaWZpZWQgQVBJIGVuZHBvaW50Lg0KDQpBbm90 aGVyIGV4YW1wbGUsIGZvciBhbiBBUEkgbGlrZSBTQ0lNIFtSRkM3NjQ0PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3NjQ0Pl0gdGhhdCBoYXMNCg0KICAgbXVsdGlwbGUgZW5kcG9pbnRz IHN1Y2ggYXMgImh0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltL1VzZXJzIjxodHRwczovL2Fw cHMuZXhhbXBsZS5jb20vc2NpbS9Vc2Vycz4sDQoNCiAgICJodHRwczovL2FwcHMuZXhhbXBsZS5j b20vc2NpbS9Hcm91cHMiPGh0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltL0dyb3Vwcz4sIGFu ZA0KDQogICAiaHR0cHM6Ly9hcHBzLmV4YW1wbGUuY29tL3NjaW0vU2NoZW1hcyI8aHR0cHM6Ly9h cHBzLmV4YW1wbGUuY29tL3NjaW0vU2NoZW1hcz4gVGhlIGNsaWVudCB3b3VsZCB1c2UNCg0KICAg Imh0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltLyI8aHR0cHM6Ly9hcHBzLmV4YW1wbGUuY29t L3NjaW0vPiBhcyB0aGUgcmVzb3VyY2Ugc28gdGhhdCB0aGUgaXNzdWVkDQoNCiAgIGFjY2VzcyB0 b2tlbiBpcyB2YWxpZCBmb3IgYWxsIHRoZSBlbmRwb2ludHMgb2YgdGhlIFNDSU0gQVBJLg0KVXNp bmcgImh0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltIjxodHRwczovL2FwcHMuZXhhbXBsZS5j b20vc2NpbT4gaXMgc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQgdG8gdXNpbmcgInRlbXBlcmF0dXJl U2Vuc29yR3JvdXA0NzExIiwgYXQgbGVhc3QgdG8gbWU6KQ0KDQpUaGFua3MsDQpHZW9yZ2UNCg0K WzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXJlc291cmNl LWluZGljYXRvcnMtMDINCk9uIDEvMjkvMTkgMjo1NiBBTSwgTHVkd2lnIFNlaXR6IHdyb3RlOg0K T24gMjgvMDEvMjAxOSAyMzoxMiwgR2VvcmdlIEZsZXRjaGVyIHdyb3RlOg0KDQoNCkkgYWxzbyBk b24ndCBrbm93IHRoYXQgdGhpcyByYWlzZXMgdG8gdGhlIGxldmVsIG9mICJjb25jZXJuIiBidXQg SSBmaW5kIHRoZSBwYXJhbWV0ZXIgbmFtZSBvZiAicmVxX2F1ZCIgb2RkLiBHaXZlbiB0aGF0IHRo ZSBwYXJhbWV0ZXIgaW4gdGhlIHJlc291cmNlLWluZGljYXRvcnMgc3BlYyBpcyAncmVzb3VyY2Un IHdoeSBub3QgdXNlIGEgcGFyYW1ldGVyIG5hbWUgb2YgJ2F1ZGllbmNlJy4gVGhhdCBzYWlkLCBJ IGhhdmUgbm90IHJlYWQgdGhlIHRocmVhZCBvbiB0aGUgQUNFIHdvcmtpbmcgZ3JvdXAgbGlzdCBz byB0aGVyZSBjb3VsZCBiZSB2ZXJ5IGdvb2QgcmVhc29ucyBmb3IgdGhlIGNob3NlbiBuYW1lOikN Cg0KSSBkbyB0aGluayB0aGF0IHRoZXJlIGlzIGEgbG90IG9mIG92ZXJsYXAgKGluIG1vc3QgY2Fz ZXMpIGJldHdlZW4gJ3Jlc291cmNlJyBhbmQgJ2F1ZGllbmNlJyBhbmQgaGF2aW5nIHR3byBwYXJh bWV0ZXJzIHRoYXQgY292ZXIgYSBsb3Qgb2YgdGhlIHNhbWUgc2VtYW50aWNzIGlzIGdvaW5nIHRv IGJlIGNvbmZ1c2luZyBmb3IgZGV2ZWxvcGVycy4gV2hlbiBjYWxsaW5nIGFuIEFQSSBhdCBhIHJl c291cmNlIHNlcnZlciwgdGhlICdhdWRpZW5jZScgYW5kIHRoZSAncmVzb3VyY2UnIGFyZSBwcmV0 dHkgZXF1aXZhbGVudC4gTWF5YmUgaW4gb3RoZXIgdXNlIGNhc2VzIHRoZXkgYXJlIGRpc3RpbmN0 bHkgc2VwYXJhdGU/DQoNClRvIGdpdmUgeW91IGFsbCB0aGUgYmFja2dyb3VuZCBvZiAicmVxX2F1 ZCIgZnJvbSBBQ0UgKHNvcnJ5IGZvciB0aGUgbG9uZyB0ZXh0KToNCg0KT3JpZ2luYWxseSBpbiBB Q0Ugd2UgaGFkIGRlZmluZWQgdGhlICJhdWQiIHBhcmFtZXRlciBmb3IgcmVxdWVzdHMgdG8gdGhl IHRva2VuIGVuZHBvaW50IHdpdGggdGhlIHNlbWFudGljcyB0aGF0IHRoZSBjbGllbnQgd2FzIHJl cXVlc3RpbmcgYSB0b2tlbiBmb3IgYSBjZXJ0YWluIGF1ZGllbmNlIChpLmUuIHJlcXVlc3Rpbmcg dGhhdCB0aGUgQVMgY29weSB0aGUgImF1ZCIgcGFyYW1ldGVyIHZhbHVlIGludG8gdGhlICJhdWQi IGNsYWltIHZhbHVlIG9mIHRoZSB0b2tlbikuDQpXZSB3ZXJlIHRoZW4gdG9sZCB0aGF0IHRoaXMg Y29sbGlkZWQgd2l0aCBhIHVzZSBvZiAiYXVkIiBpbiBPQXV0aCwgdGhhdCBzcGVjaWZpZXMgdGhl IGludGVuZGVkIGF1ZGllbmNlIG9mIEF1dGhvcml6YXRpb24gU2VydmVycyAoaWYgSSByZW1lbWJl ciBjb3JyZWN0bHkpLCBzbyB3ZSBkZWNpZGVkIHRvIHJlbmFtZSBvdXIgcGFyYW1ldGVyIHRvICJy ZXFfYXVkIiBmb3IgInJlcXVlc3RlZCBhdWRpZW5jZSIuDQpNaWtlIEpvbmVzIHRoZW4gbWFkZSB1 cyBhd2FyZSBvZiB0aGUgd29yayBvbiByZXNvdXJjZSBpbmRpY2F0b3JzLCBidXQgdXBvbiBjbG9z ZXIgZXhhbWluYXRpb24gSSBmb3VuZCB0aGUgInJlc291cmNlIiBwYXJhbWV0ZXIgdG8gYmUgbW9y ZSBsaW1pdGVkIHRoYW4gdGhlICJyZXFfYXVkIiwgc2luY2UgcmVzb3VyY2Ugc3BlY2lmaWNhbGx5 IHN0YXRlczoNCg0KIkl0cyB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSSAuLi4gdGhlICJy ZXNvdXJjZSIgcGFyYW1ldGVyIFVSSSB2YWx1ZSBpcyBhbiBpZGVudGlmaWVyIHJlcHJlc2VudGlu ZyB0aGUgaWRlbnRpdHkgb2YgdGhlIHJlc291cmNlIg0KDQpNeSBpbnRlcnByZXRhdGlvbiBvZiB0 aGlzIGlzIHRoYXQgInJlc291cmNlIiByZWZlcnMgdG8gYSBzaW5nbGUgcmVzb3VyY2UsIHdoaWNo IGlzIG1vcmUgY29uc3RyYWluZWQgdGhhbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgImF1ZCIgY2xh aW0gZnJvbSA3NTE5LCB3aGljaCB1c2VzIGEgU3RyaW5nT3JVUkkgdmFsdWUuICBGb3IgZXhhbXBs ZSBteSBpbnRlbnQgd2FzIHRvIHVzZSAiYXVkIiBhbmQgInJlcV9hdWQiIGZvciBncm91cCBpZGVu dGlmaWVycyAoInRlbXBlcmF0dXJlU2Vuc29yR3JvdXA0NzExIikgYW5kIG90aGVyIG5vbi11cmkg c3RyaW5ncyAoaGFzaC1vZi1wdWJsaWMta2V5KSwgd2hpY2ggSSBjYW5ub3QgZG8gd2l0aCAicmVz b3VyY2UiLiAgV2UgdGhlcmVmb3JlIGRlY2lkZWQgdG8ga2VlcCB0aGUgInJlcV9hdWQiIHBhcmFt ZXRlciBpbiBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMsIGV2ZW4gdGhvdWdoIGlzIGNsZWFy bHkgb3ZlcmxhcHMgd2l0aCAicmVzb3VyY2UiLg0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zIGFib3V0IHRoYXQgbGluZSBvZiByZWFzb25pbmcgKGVzcGVjaWFsbHkgZnJvbSB0aGUgT0F1 dGggcG9pbnQgb2YgdmlldykgYXJlIHZlcnkgd2VsY29tZS4NCg0KL0x1ZHdpZw0KDQoNCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_VI1PR0801MB21122F4357775349577965E6FA680VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc2NDE1MTAyNjsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODY0NTc1ODk0IC0zMDAzNzgxMTAgMTM0 ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMg MTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNjE3MzY1MDUzOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoyMDc2MDkxMzM2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIEdlb3JnZSwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBJ QU5BIHJlZ2lzdHJ5IGRvZXMgbm90IGluZGljYXRlIGluIHdoYXQgY29udGV4dCB0aGVzZSBwYXJh bWV0ZXJzIGFyZSBzdXBwb3NlZCB0byBiZSB1c2VkLiBUbyBtZSBpdCBmZWVscyB0b3RhbGx5IG5v cm1hbCB0byB1c2UgdGhlIGF1ZGllbmNlIHBhcmFtZXRlciBpbnN0ZWFkIG9mIHRoZSByZXNvdXJj ZSBwYXJhbWV0ZXIgd2hlbiBJIGhhdmUgYSBsb2dpY2FsIG5hbWUuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U3R1ZmZpbmcgZXZlcnl0aGluZyBpbnRvIGEgVVJJIGlzIHBvc3NpYmxlIGJ1dCBp biBjZXJ0YWluIHNjZW5hcmlvcyBtYXkgZmVlbCBxdWl0ZSB1bm5hdHVyYWwuIEl0IG11c3QgaGF2 ZSBmZWx0IHVubmF0dXJhbCBhbHJlYWR5IHRvIHRoZSBncm91cCB3aGVuIHdvcmtpbmcgb24gdGhl IHRva2VuIGV4Y2hhbmdlIHNwZWPigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gR2VvcmdlIEZsZXRjaGVy ICZsdDtnZmZsZXRjaEBhb2wuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IERvbm5lcnN0YWcs IDcuIEZlYnJ1YXIgMjAxOSAxNzowNjxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcg Jmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20mZ3Q7OyBMdWR3aWcgU2VpdHogJmx0O2x1ZHdp Zy5zZWl0ekByaS5zZSZndDs7IGFjZUBpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtBY2VdIFtPQVVUSC1XR10gU2hlcGhlcmQgd3JpdGUtdXAgZm9yIGRy YWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5UaGlzIGlzIHRydWUuLi4gaG93ZXZlciwgdG8gbXkga25vd2xlZGdlIHRoZXJlIGlzIG5vIHN1 cHBvcnQgZm9yIHRoaXMgcGFyYW1ldGVyIG91dHNpZGUgb2YgdGhlIHRva2VuLWV4Y2hhbmdlIHNw ZWMuIEp1c3QgYmVjYXVzZSBpdCBpcyBkb2N1bWVudGVkIGFzIGFuIE9BdXRoDQogcGFyYW1ldGVy IEkgZG9uJ3QgY29uc2lkZXIgaXQgdXNhYmxlIGluIG90aGVyIGNvbnRleHRzIHVubGVzcyBzcGVj J2QgdG8gZG8gc28uIElmIHdlIHdhbnQgdG8gdXNlICdhdWRpZW5jZScgZm9yIGxvZ2ljYWwgYXVk aWVuY2UgbmFtZXMgd2hlbiBiaW5kaW5nIGF1ZGllbmNlcyB0byB0b2tlbnMsIHRoZW4gd2UgbmVl ZCBhIHNwZWMgZm9yIHRoYXQgKG9yIGFkZCBpdCB0byB0aGUgcmVzb3VyY2UtaW5kaWNhdG9ycyBz cGVjKS48YnI+DQo8YnI+DQpQZXJzb25hbGx5LCBJIHNlZSBhIGxvdCBvZiBvdmVybGFwIGV2ZW4g YmV0d2VlbiB0aGUgJ2F1ZGllbmNlJyBhbmQgJ3Jlc291cmNlJyBwYXJhbWV0ZXJzLiBJJ2QgcmVh bGx5IHByZWZlciB3ZSBqdXN0IGhhdmUgb25lIHBhcmFtZXRlciB0aGF0IGNhbiBiZSBlaXRoZXIg bG9naWNhbCBvciBzcGVjaWZpYy4gQXMgb3V0bGluZWQgaW4gdGhpcyB0aHJlYWQsICc8YSBocmVm PSJodHRwczovL2FwaS5leGFtcGwuY29tIj5odHRwczovL2FwaS5leGFtcGwuY29tPC9hPicNCiB0 byBtZSBpcyBhIGxvZ2ljYWwgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlIGlmIHRoZSAm cXVvdDtyZWFsJnF1b3Q7IGVuZHBvaW50KHMpIGFyZSA8YSBocmVmPSJodHRwczovL2FwaS5leGFt cGxlLmNvbS9tYWlsL3VzZXIvaW5ib3giPg0KJnF1b3Q7aHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20v bWFpbC91c2VyL2luYm94JnF1b3Q7PC9hPiwgLi4uPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdl b3JnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biAyLzcvMTkgMTA6MTYgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdlb3JnZSwgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGJlbGlldmUgdGhhdCBzaW5jZSB0aGUgbGF0 ZXN0IGRyYWZ0IG9mIHRoZSByZXNvdXJjZSBpbmRpY2F0b3JzIHNwZWMgWzFdIGFsbG93cyBmb3Ig YWJzdHJhY3QgaWRlbnRpZmllcnMsIGFuZCBzaW5jZSBhIFVSTiBpcyBhbHNvIGEgVVJJLCB5b3Ug Y291bGQgZWFzaWx5IHVzZSBhIFVSTiBzeW50YXggdG8gYWNjb21wbGlzaCB0aGUgdXNlIGNhc2UN CiBvdXRsaW5lZCBpbiB5b3VyIGVtYWlsLjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIHJlLXJlYWRpbmcgdGhl IHRva2VuIGV4Y2hhbmdlIGRyYWZ0IEkgcmVhbGl6ZWQgdGhhdCB3ZSBoYXZlIGFscmVhZHkgZGVm aW5lZCBhIHNlcGFyYXRlIHBhcmFtZXRlciBmb3Ig4oCcYWJzdHJhY3TigJ0sIG9yIGxvZ2ljYWws IG5hbWVzIHZpYSB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyLiBIZXJlIGlzIHRoZSBkZWZpbml0aW9u OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGF1ZGllbmNl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05BTC4mbmJzcDsgVGhlIGxvZ2ljYWwg bmFtZSBvZiB0aGUgdGFyZ2V0IHNlcnZpY2Ugd2hlcmUgdGhlIGNsaWVudDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaW50ZW5kcyB0byB1c2UgdGhlIHJlcXVlc3RlZCBzZWN1cml0eSB0b2tl bi4mbmJzcDsgVGhpcyBzZXJ2ZXMgYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHVycG9z ZSBzaW1pbGFyIHRvIHRoZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJhbWV0ZXIsIGJ1dCB3aXRo IHRoZSBjbGllbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3ZpZGluZyBhIGxvZ2lj YWwgbmFtZSByYXRoZXIgdGhhbiBhIGxvY2F0aW9uLiZuYnNwOyBJbnRlcnByZXRhdGlvbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhlIG5hbWUgcmVxdWlyZXMgdGhhdCB0aGUgdmFs dWUgYmUgc29tZXRoaW5nIHRoYXQgYm90aCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVuZGVyc3RhbmQuJm5ic3A7IEFu IE9BdXRoIGNsaWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpZmllciwgYSBT QU1MIGVudGl0eSBpZGVudGlmaWVyIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xNiNyZWYtT0FTSVMuc2FtbC1jb3Jl LTIuMC1vcyIgdGl0bGU9IiZxdW90O0Fzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FT SVMNCiAgICAgICAgICAgICAgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FN TCkgVjIuMCZxdW90OyI+T0FTSVMuc2FtbC1jb3JlLTIuMC1vczwvYT5dLA0KIGFuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPcGVuSUQgQ29ubmVjdCBJc3N1ZXIgSWRlbnRpZmllciBbPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMTYjcmVmLU9wZW5JRC5Db3JlIiB0aXRsZT0iJnF1b3Q7T3BlbklEIENvbm5lY3Qg Q29yZSAxLjAmcXVvdDsiPk9wZW5JRC5Db3JlPC9hPl0sDQogb3IgYSBVUkkgYXJlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBleGFtcGxlcyBvZiB0aGluZ3MgdGhhdCBtaWdodCBiZSB1c2Vk IGFzICZxdW90O2F1ZGllbmNlJnF1b3Q7IHBhcmFtZXRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdmFsdWVzLiZuYnNwOyBNdWx0aXBsZSAmcXVvdDthdWRpZW5jZSZxdW90OyBwYXJhbWV0 ZXJzIG1heSBiZSB1c2VkIHRvIGluZGljYXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGF0IHRoZSBpc3N1ZWQgdG9rZW4gaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhdCB0aGUgbXVsdGlw bGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1ZGllbmNlcyBsaXN0ZWQuJm5ic3A7IFRo ZSAmcXVvdDthdWRpZW5jZSZxdW90OyBhbmQgJnF1b3Q7cmVzb3VyY2UmcXVvdDsgcGFyYW1ldGVy cyBtYXkgYmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZWQgdG9nZXRoZXIgdG8gaW5k aWNhdGUgbXVsdGlwbGUgdGFyZ2V0IHNlcnZpY2VzIHdpdGggYSBtaXggb2Y8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGxvZ2ljYWwgbmFtZXMgYW5kIGxvY2F0aW9ucy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g QWNlDQo8YSBocmVmPSJtYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmciPiZsdDthY2UtYm91bmNl c0BpZXRmLm9yZyZndDs8L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpHZW9yZ2UgRmxldGNoZXI8 YnI+DQo8Yj5TZW50OjwvYj4gRGllbnN0YWcsIDI5LiBKYW51YXIgMjAxOSAxNDoxNTxicj4NCjxi PlRvOjwvYj4gTHVkd2lnIFNlaXR6IDxhIGhyZWY9Im1haWx0bzpsdWR3aWcuc2VpdHpAcmkuc2Ui PiZsdDtsdWR3aWcuc2VpdHpAcmkuc2UmZ3Q7PC9hPjsNCjxhIGhyZWY9Im1haWx0bzphY2VAaWV0 Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+ b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQWNlXSBbT0FVVEgt V0ddIFNoZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMtMDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlRoYW5rIHlvdSBzbyBtdWNoIGZvciB0aGUgYmFja2dyb3VuZCENCjxicj4NCjxicj4NCkkgYmVs aWV2ZSB0aGF0IHNpbmNlIHRoZSBsYXRlc3QgZHJhZnQgb2YgdGhlIHJlc291cmNlIGluZGljYXRv cnMgc3BlYyBbMV0gYWxsb3dzIGZvciBhYnN0cmFjdCBpZGVudGlmaWVycywgYW5kIHNpbmNlIGEg VVJOIGlzIGFsc28gYSBVUkksIHlvdSBjb3VsZCBlYXNpbHkgdXNlIGEgVVJOIHN5bnRheCB0byBh Y2NvbXBsaXNoIHRoZSB1c2UgY2FzZSBvdXRsaW5lZCBpbiB5b3VyIGVtYWlsLjxicj4NCjxicj4N CnJlc291cmNlPXVybjp4LW15ZGV2aWNlczp0ZW1wZXJhdHVyZVNlbnNvckdyb3VwNDcxMTxicj4N Cjxicj4NClRoZSBzcGVjIGN1cnJlbnRseSBvdXRsaW5lcyBleGFtcGxlcyB3aGVyZSB0aGUgJnF1 b3Q7cmVzb3VyY2UgaWRlbnRpZmllciZxdW90OyBpcyBub3QgYSAmcXVvdDtzaW5nbGUgcmVzb3Vy Y2UmcXVvdDsgaW4gdGhlIGNvbnRleHQgb2YgYSBmdWxseSBxdWFsaWZpZWQgQVBJIGVuZHBvaW50 Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkFub3RoZXIgZXhhbXBsZSwgZm9yIGFu IEFQSSBsaWtlIFNDSU0gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 NjQ0IiB0aXRsZT0iJnF1b3Q7U3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdl bWVudDogUHJvdG9jb2wmcXVvdDsiPlJGQzc2NDQ8L2E+XSB0aGF0IGhhczxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtdWx0aXBsZSBlbmRwb2ludHMgc3VjaCBhcyA8YSBocmVm PSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9Vc2VycyI+JnF1b3Q7aHR0cHM6Ly9hcHBz LmV4YW1wbGUuY29tL3NjaW0vVXNlcnMmcXVvdDs8L2E+LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbS9Hcm91 cHMiPiZxdW90O2h0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltL0dyb3VwcyZxdW90OzwvYT4s IGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L2FwcHMuZXhhbXBsZS5jb20vc2NpbS9TY2hlbWFzIj4mcXVvdDtodHRwczovL2FwcHMuZXhhbXBs ZS5jb20vc2NpbS9TY2hlbWFzJnF1b3Q7PC9hPiBUaGUgY2xpZW50IHdvdWxkIHVzZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2FwcHMuZXhhbXBs ZS5jb20vc2NpbS8iPiZxdW90O2h0dHBzOi8vYXBwcy5leGFtcGxlLmNvbS9zY2ltLyZxdW90Ozwv YT4gYXMgdGhlIHJlc291cmNlIHNvIHRoYXQgdGhlIGlzc3VlZDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yIGFsbCB0aGUgZW5kcG9p bnRzIG9mIHRoZSBTQ0lNIEFQSS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlVzaW5nDQo8 YSBocmVmPSJodHRwczovL2FwcHMuZXhhbXBsZS5jb20vc2NpbSI+JnF1b3Q7aHR0cHM6Ly9hcHBz LmV4YW1wbGUuY29tL3NjaW0mcXVvdDs8L2E+IGlzIHNlbWFudGljYWxseSBlcXVpdmFsZW50IHRv IHVzaW5nICZxdW90O3RlbXBlcmF0dXJlU2Vuc29yR3JvdXA0NzExJnF1b3Q7LCBhdCBsZWFzdCB0 byBtZTopPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTxicj4NCjxicj4NClsxXSA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTAyIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMjkvMTkgMjo1NiBBTSwgTHVkd2lnIFNl aXR6IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDI4LzAxLzIwMTkgMjM6MTIsIEdlb3JnZSBGbGV0Y2hlciB3cm90ZTogPGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SSBhbHNvIGRvbid0IGtub3cgdGhhdCB0aGlzIHJhaXNlcyB0byB0 aGUgbGV2ZWwgb2YgJnF1b3Q7Y29uY2VybiZxdW90OyBidXQgSSBmaW5kIHRoZSBwYXJhbWV0ZXIg bmFtZSBvZiAmcXVvdDtyZXFfYXVkJnF1b3Q7IG9kZC4gR2l2ZW4gdGhhdCB0aGUgcGFyYW1ldGVy IGluIHRoZSByZXNvdXJjZS1pbmRpY2F0b3JzIHNwZWMgaXMgJ3Jlc291cmNlJyB3aHkgbm90IHVz ZSBhIHBhcmFtZXRlciBuYW1lDQogb2YgJ2F1ZGllbmNlJy4gVGhhdCBzYWlkLCBJIGhhdmUgbm90 IHJlYWQgdGhlIHRocmVhZCBvbiB0aGUgQUNFIHdvcmtpbmcgZ3JvdXAgbGlzdCBzbyB0aGVyZSBj b3VsZCBiZSB2ZXJ5IGdvb2QgcmVhc29ucyBmb3IgdGhlIGNob3NlbiBuYW1lOikNCjxicj4NCjxi cj4NCkkgZG8gdGhpbmsgdGhhdCB0aGVyZSBpcyBhIGxvdCBvZiBvdmVybGFwIChpbiBtb3N0IGNh c2VzKSBiZXR3ZWVuICdyZXNvdXJjZScgYW5kICdhdWRpZW5jZScgYW5kIGhhdmluZyB0d28gcGFy YW1ldGVycyB0aGF0IGNvdmVyIGEgbG90IG9mIHRoZSBzYW1lIHNlbWFudGljcyBpcyBnb2luZyB0 byBiZSBjb25mdXNpbmcgZm9yIGRldmVsb3BlcnMuIFdoZW4gY2FsbGluZyBhbiBBUEkgYXQgYSBy ZXNvdXJjZSBzZXJ2ZXIsIHRoZSAnYXVkaWVuY2UnIGFuZA0KIHRoZSAncmVzb3VyY2UnIGFyZSBw cmV0dHkgZXF1aXZhbGVudC4gTWF5YmUgaW4gb3RoZXIgdXNlIGNhc2VzIHRoZXkgYXJlIGRpc3Rp bmN0bHkgc2VwYXJhdGU/DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KVG8gZ2l2ZSB5 b3UgYWxsIHRoZSBiYWNrZ3JvdW5kIG9mICZxdW90O3JlcV9hdWQmcXVvdDsgZnJvbSBBQ0UgKHNv cnJ5IGZvciB0aGUgbG9uZyB0ZXh0KTogPGJyPg0KPGJyPg0KT3JpZ2luYWxseSBpbiBBQ0Ugd2Ug aGFkIGRlZmluZWQgdGhlICZxdW90O2F1ZCZxdW90OyBwYXJhbWV0ZXIgZm9yIHJlcXVlc3RzIHRv IHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIHRoZSBzZW1hbnRpY3MgdGhhdCB0aGUgY2xpZW50IHdh cyByZXF1ZXN0aW5nIGEgdG9rZW4gZm9yIGEgY2VydGFpbiBhdWRpZW5jZSAoaS5lLiByZXF1ZXN0 aW5nIHRoYXQgdGhlIEFTIGNvcHkgdGhlICZxdW90O2F1ZCZxdW90OyBwYXJhbWV0ZXIgdmFsdWUg aW50byB0aGUgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltIHZhbHVlIG9mDQogdGhlIHRva2VuKS4gPGJy Pg0KV2Ugd2VyZSB0aGVuIHRvbGQgdGhhdCB0aGlzIGNvbGxpZGVkIHdpdGggYSB1c2Ugb2YgJnF1 b3Q7YXVkJnF1b3Q7IGluIE9BdXRoLCB0aGF0IHNwZWNpZmllcyB0aGUgaW50ZW5kZWQgYXVkaWVu Y2Ugb2YgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIChpZiBJIHJlbWVtYmVyIGNvcnJlY3RseSksIHNv IHdlIGRlY2lkZWQgdG8gcmVuYW1lIG91ciBwYXJhbWV0ZXIgdG8gJnF1b3Q7cmVxX2F1ZCZxdW90 OyBmb3IgJnF1b3Q7cmVxdWVzdGVkIGF1ZGllbmNlJnF1b3Q7Lg0KPGJyPg0KTWlrZSBKb25lcyB0 aGVuIG1hZGUgdXMgYXdhcmUgb2YgdGhlIHdvcmsgb24gcmVzb3VyY2UgaW5kaWNhdG9ycywgYnV0 IHVwb24gY2xvc2VyIGV4YW1pbmF0aW9uIEkgZm91bmQgdGhlICZxdW90O3Jlc291cmNlJnF1b3Q7 IHBhcmFtZXRlciB0byBiZSBtb3JlIGxpbWl0ZWQgdGhhbiB0aGUgJnF1b3Q7cmVxX2F1ZCZxdW90 Oywgc2luY2UgcmVzb3VyY2Ugc3BlY2lmaWNhbGx5IHN0YXRlczoNCjxicj4NCjxicj4NCiZxdW90 O0l0cyB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSSAuLi4gdGhlICZxdW90O3Jlc291cmNl JnF1b3Q7IHBhcmFtZXRlciBVUkkgdmFsdWUgaXMgYW4gaWRlbnRpZmllciByZXByZXNlbnRpbmcg dGhlIGlkZW50aXR5IG9mIHRoZSByZXNvdXJjZSZxdW90Ow0KPGJyPg0KPGJyPg0KTXkgaW50ZXJw cmV0YXRpb24gb2YgdGhpcyBpcyB0aGF0ICZxdW90O3Jlc291cmNlJnF1b3Q7IHJlZmVycyB0byBh IHNpbmdsZSByZXNvdXJjZSwgd2hpY2ggaXMgbW9yZSBjb25zdHJhaW5lZCB0aGFuIHRoZSBkZWZp bml0aW9uIG9mIHRoZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0gZnJvbSA3NTE5LCB3aGljaCB1c2Vz IGEgU3RyaW5nT3JVUkkgdmFsdWUuJm5ic3A7IEZvciBleGFtcGxlIG15IGludGVudCB3YXMgdG8g dXNlICZxdW90O2F1ZCZxdW90OyBhbmQgJnF1b3Q7cmVxX2F1ZCZxdW90OyBmb3IgZ3JvdXAgaWRl bnRpZmllcnMNCiAoJnF1b3Q7dGVtcGVyYXR1cmVTZW5zb3JHcm91cDQ3MTEmcXVvdDspIGFuZCBv dGhlciBub24tdXJpIHN0cmluZ3MgKGhhc2gtb2YtcHVibGljLWtleSksIHdoaWNoIEkgY2Fubm90 IGRvIHdpdGggJnF1b3Q7cmVzb3VyY2UmcXVvdDsuJm5ic3A7IFdlIHRoZXJlZm9yZSBkZWNpZGVk IHRvIGtlZXAgdGhlICZxdW90O3JlcV9hdWQmcXVvdDsgcGFyYW1ldGVyIGluIGRyYWZ0LWlldGYt YWNlLW9hdXRoLXBhcmFtcywgZXZlbiB0aG91Z2ggaXMgY2xlYXJseSBvdmVybGFwcyB3aXRoICZx dW90O3Jlc291cmNlJnF1b3Q7Lg0KPGJyPg0KPGJyPg0KQW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0 aW9ucyBhYm91dCB0aGF0IGxpbmUgb2YgcmVhc29uaW5nIChlc3BlY2lhbGx5IGZyb20gdGhlIE9B dXRoIHBvaW50IG9mIHZpZXcpIGFyZSB2ZXJ5IHdlbGNvbWUuDQo8YnI+DQo8YnI+DQovTHVkd2ln IDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_VI1PR0801MB21122F4357775349577965E6FA680VI1PR0801MB2112_-- From nobody Thu Feb 7 08:47:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335A41271FF for ; Thu, 7 Feb 2019 08:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAQzri1w_Riu for ; Thu, 7 Feb 2019 08:47:26 -0800 (PST) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91D6124BF6 for ; Thu, 7 Feb 2019 08:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1549558044; bh=Pt/qGn07qbI8rDxfxj6SZveM6EaqafY5Edsrn8t/LeA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=sblqlDNYmSsdQZuJ4SLIiV3CxGdwwsNxrHG8cJO+Uk2CtNhLZ62kHMqBCC4Nky/uVVxKxzVuQOFrSvPxAMP6EqwS2/w9W5OMvT0b3APDoHNbZrAhvodTc1pcaYWgD+yM1OfBQm7oTAqliw9H4gRyqpmt8qhbbuIgiEj4DseNdSZaaKF/8s0l7/UboXF8dNnYP7FSbzxAL72KOJqqhn68m4r83It0jn1ZIY8wbNxjtoDM/nm3410HTUcSmhdb3EO3AL9hYg9/GZrhUiiuyI8GWmy7p1SRkF13b4aiPFIN4kLSpa9b9c6erZE7GjVQ3fDIKSZNjP6cUhoTrZ0F1mMysw== X-YMail-OSG: PcXimEYVM1mg.v6SSUpAlOs4weV2aMaoxC9bMKM96OiRU_2WX7Ac8rvzQx9gDq3 YFMPh6Gata06uJPowWOTgKcDiC7bz.6.PAALqkLaEQRo3Erfphq3MjLRlAv_1gYoikoAJZloNGLw N.vooiw8hJw4LBig36lA5ul6pp5FEfCIZ8r.Rvc.mbnAZdCFMdyHvuPRuKaBmUPmT8Zlsc12wfQ0 tz9YcHlqvduSgnQpE_.hFILs.3wItpcASPdDp4mVFTB55hws5LyUNgBsnpPQv04RZpGDgC9QVFBK AFp_i8SH8so3nr61m1yCp.pgLsCriSa1ScuQlg6hxX7D_3TppIhrqoWc7eo5ODoC4rehbweDJC5f x_2B6K27uz6AlTL9vOkWtq91ag34ivWCX2b6sowCrXNOd30F.YMGkLm.r2HF2jPM8_3xcvqgyzhY XTQ6UPzIkJQ0pDwNTmuXrjVkljvQBT._jLwd6hQDAEvfrLN_gZW0qyRpa2PNy97WXo9pdyDARlvV eF81ICMIS3c.NLJRhi2PWju275Gz_37gzLaMNlPu6BMoFbBhZtba3GsB_h.1CtNY7Ffif4EO5a39 IsWLZ.3MN7zGxKs9XjJVQlSg3kyu9ep.qKtkpzpP82ILJ7pU35lUIfPXMtnfk2tP5_.N7yeypA9g .YvbnVAVGy1yHbRqEwmkF7vIO.8Syc9SkGyXCDmRWSKpE5QyWyjtzFiRiF2sdS.UhJq8Ho6VbAND 1FN306ZqsJTV9HKOjt9sDiumGaxiNu1D47J_K1Ut3MoDevFfjeK3GTv0_zTBKr9jm2Ffpw3Ihki2 c9m5.jiCacU5Bm2pTn4AvEZSSuq6FdN495kA3X.IDsfwzop6uLb_9cC7VkTMKxgUEjenRThiOfnF UmcEGAfJrmzI0.gSwQLcsOF5aJtvTxpVepOSjGq_LLOa.HjCkncIfxIsH0iV_bGP2C.pc0GsoENV e_SkVqT9jgL2EhL3NJ.lPiJ.Wamr5.S0PzsffcYPpjsMmWeHvUge5d0NC2lnbJNJ1Hqo.tLp_pkv Lm3isuqcDjSeH.o4lGWcxpjgiat67ed9pbf_vYUlI4IlPPsiM6JImzWuxLkMyRodvin_O Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 Feb 2019 16:47:24 +0000 Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [10.89.92.247]) ([184.165.8.99]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 529dbd89a71b4f4c15f45e060ceb9676; Thu, 07 Feb 2019 16:47:20 +0000 (UTC) To: Hannes Tschofenig , Ludwig Seitz , "ace@ietf.org" , "oauth@ietf.org" References: <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 7 Feb 2019 11:47:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------14B335B4606FD30721E12CF0" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:47:30 -0000 This is a multi-part message in MIME format. --------------14B335B4606FD30721E12CF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Then I think we have a bigger issue:( To me the point of the "resource-indicators" spec is to define semantics around how a client can request that tokens be "constrained" in where they can be used. If it is not going to define the actual 'resource' parameter and rather use the registered value from the token-exchange spec, then it seems like the resource-indicators spec has the wrong title. Instead it should be about "constraining where a token can be used" and in that view should describe how to use either the 'audience' or 'resource' parameter. I believe we need clear guidance for when to use one over the other (if possible). It is then left up to the AS to determine whether it is going to support just 'audience', just 'resource' or both when constraining tokens. We should also provide some "best practice" guidance on how resource servers can ensure these tokens are for them. In a wide eco-system deployment where a resource server is supporting multiple authorization servers, this could get complicated for the resource server. The resource-indicators spec implies that the AS should use the resource parameter to set the 'audience' of the returned access_token. There is no guidance for what a AS should return from the /introspection endpoint in regards to the "constrained" token. Do both 'resource' and 'audience' values get returned in the "aud" claim? Thanks, George On 2/7/19 11:26 AM, Hannes Tschofenig wrote: > > Hi George, > > The IANA registry does not indicate in what context these parameters > are supposed to be used. To me it feels totally normal to use the > audience parameter instead of the resource parameter when I have a > logical name. > > Stuffing everything into a URI is possible but in certain scenarios > may feel quite unnatural. It must have felt unnatural already to the > group when working on the token exchange spec… > > Ciao > > Hannes > > *From:*George Fletcher > *Sent:* Donnerstag, 7. Februar 2019 17:06 > *To:* Hannes Tschofenig ; Ludwig Seitz > ; ace@ietf.org; oauth@ietf.org > *Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > This is true... however, to my knowledge there is no support for this > parameter outside of the token-exchange spec. Just because it is > documented as an OAuth parameter I don't consider it usable in other > contexts unless spec'd to do so. If we want to use 'audience' for > logical audience names when binding audiences to tokens, then we need > a spec for that (or add it to the resource-indicators spec). > > Personally, I see a lot of overlap even between the 'audience' and > 'resource' parameters. I'd really prefer we just have one parameter > that can be either logical or specific. As outlined in this thread, > 'https://api.exampl.com' to me is a logical representation of the > resource if the "real" endpoint(s) are > "https://api.example.com/mail/user/inbox" > , ... > > Thanks, > George > > On 2/7/19 10:16 AM, Hannes Tschofenig wrote: > > Hi George, > > * I believe that since the latest draft of the resource > indicators spec [1] allows for abstract identifiers, and since > a URN is also a URI, you could easily use a URN syntax to > accomplish the use case outlined in your email. > > > After re-reading the token exchange draft I realized that we have > already defined a separate parameter for “abstract”, or logical, > names via the audience parameter. Here is the definition: > >    audience > >       OPTIONAL.  The logical name of the target service where the > client > >       intends to use the requested security token.  This serves a > >       purpose similar to the "resource" parameter, but with the client > >       providing a logical name rather than a location.  Interpretation > >       of the name requires that the value be something that both the > >       client and the authorization server understand.  An OAuth client > >       identifier, a SAML entity identifier [OASIS.saml-core-2.0-os > ], > an > >       OpenID Connect Issuer Identifier [OpenID.Core > ], > or a URI are > >       examples of things that might be used as "audience" parameter > >       values.  Multiple "audience" parameters may be used to indicate > >       that the issued token is intended to be used at the multiple > >       audiences listed.  The "audience" and "resource" parameters > may be > >       used together to indicate multiple target services with a mix of > >       logical names and locations. > > Ciao > > Hannes > > *From:*Ace > *On Behalf Of * George Fletcher > *Sent:* Dienstag, 29. Januar 2019 14:15 > *To:* Ludwig Seitz > ; ace@ietf.org ; > oauth@ietf.org > *Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > > Thank you so much for the background! > > I believe that since the latest draft of the resource indicators > spec [1] allows for abstract identifiers, and since a URN is also > a URI, you could easily use a URN syntax to accomplish the use > case outlined in your email. > > resource=urn:x-mydevices:temperatureSensorGroup4711 > > The spec currently outlines examples where the "resource > identifier" is not a "single resource" in the context of a fully > qualified API endpoint. > > Another example, for an API like SCIM [RFC7644 ] that has > >    multiple endpoints such as"https://apps.example.com/scim/Users" , > > "https://apps.example.com/scim/Groups" , and > > "https://apps.example.com/scim/Schemas" The client would use > > "https://apps.example.com/scim/" as the resource so that the issued > >    access token is valid for all the endpoints of the SCIM API. > > Using "https://apps.example.com/scim" > is semantically equivalent to > using "temperatureSensorGroup4711", at least to me:) > > Thanks, > George > > [1] > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 > > On 1/29/19 2:56 AM, Ludwig Seitz wrote: > > On 28/01/2019 23:12, George Fletcher wrote: > > > I also don't know that this raises to the level of > "concern" but I find the parameter name of "req_aud" odd. > Given that the parameter in the resource-indicators spec > is 'resource' why not use a parameter name of 'audience'. > That said, I have not read the thread on the ACE working > group list so there could be very good reasons for the > chosen name:) > > I do think that there is a lot of overlap (in most cases) > between 'resource' and 'audience' and having two > parameters that cover a lot of the same semantics is going > to be confusing for developers. When calling an API at a > resource server, the 'audience' and the 'resource' are > pretty equivalent. Maybe in other use cases they are > distinctly separate? > > > To give you all the background of "req_aud" from ACE (sorry > for the long text): > > Originally in ACE we had defined the "aud" parameter for > requests to the token endpoint with the semantics that the > client was requesting a token for a certain audience (i.e. > requesting that the AS copy the "aud" parameter value into the > "aud" claim value of the token). > We were then told that this collided with a use of "aud" in > OAuth, that specifies the intended audience of Authorization > Servers (if I remember correctly), so we decided to rename our > parameter to "req_aud" for "requested audience". > Mike Jones then made us aware of the work on resource > indicators, but upon closer examination I found the "resource" > parameter to be more limited than the "req_aud", since > resource specifically states: > > "Its value MUST be an absolute URI ... the "resource" > parameter URI value is an identifier representing the identity > of the resource" > > My interpretation of this is that "resource" refers to a > single resource, which is more constrained than the definition > of the "aud" claim from 7519, which uses a StringOrURI value.  > For example my intent was to use "aud" and "req_aud" for group > identifiers ("temperatureSensorGroup4711") and other non-uri > strings (hash-of-public-key), which I cannot do with > "resource". We therefore decided to keep the "req_aud" > parameter in draft-ietf-ace-oauth-params, even though is > clearly overlaps with "resource". > > Any comments and suggestions about that line of reasoning > (especially from the OAuth point of view) are very welcome. > > /Ludwig > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. --------------14B335B4606FD30721E12CF0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Then I think we have a bigger issue:(

To me the point of the "resource-indicators" spec is to define semantics around how a client can request that tokens be "constrained" in where they can be used. If it is not going to define the actual 'resource' parameter and rather use the registered value from the token-exchange spec, then it seems like the resource-indicators spec has the wrong title. Instead it should be about "constraining where a token can be used" and in that view should describe how to use either the 'audience' or 'resource' parameter. I believe we need clear guidance for when to use one over the other (if possible).

It is then left up to the AS to determine whether it is going to support just 'audience', just 'resource' or both when constraining tokens.

We should also provide some "best practice" guidance on how resource servers can ensure these tokens are for them. In a wide eco-system deployment where a resource server is supporting multiple authorization servers, this could get complicated for the resource server. The resource-indicators spec implies that the AS should use the resource parameter to set the 'audience' of the returned access_token. There is no guidance for what a AS should return from the /introspection endpoint in regards to the "constrained" token. Do both 'resource' and 'audience' values get returned in the "aud" claim?

Thanks,
George

On 2/7/19 11:26 AM, Hannes Tschofenig wrote:

Hi George,

 

The IANA registry does not indicate in what context these parameters are supposed to be used. To me it feels totally normal to use the audience parameter instead of the resource parameter when I have a logical name.

 

Stuffing everything into a URI is possible but in certain scenarios may feel quite unnatural. It must have felt unnatural already to the group when working on the token exchange spec…

 

Ciao

Hannes

 

From: George Fletcher <gffletch@aol.com>
Sent: Donnerstag, 7. Februar 2019 17:06
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org; oauth@ietf.org
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

This is true... however, to my knowledge there is no support for this parameter outside of the token-exchange spec. Just because it is documented as an OAuth parameter I don't consider it usable in other contexts unless spec'd to do so. If we want to use 'audience' for logical audience names when binding audiences to tokens, then we need a spec for that (or add it to the resource-indicators spec).

Personally, I see a lot of overlap even between the 'audience' and 'resource' parameters. I'd really prefer we just have one parameter that can be either logical or specific. As outlined in this thread, 'https://api.exampl.com' to me is a logical representation of the resource if the "real" endpoint(s) are "https://api.example.com/mail/user/inbox", ...

Thanks,
George

On 2/7/19 10:16 AM, Hannes Tschofenig wrote:

Hi George,

 

  • I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email.


After re-reading the token exchange draft I realized that we have already defined a separate parameter for “abstract”, or logical, names via the audience parameter. Here is the definition:

 

   audience

      OPTIONAL.  The logical name of the target service where the client

      intends to use the requested security token.  This serves a

      purpose similar to the "resource" parameter, but with the client

      providing a logical name rather than a location.  Interpretation

      of the name requires that the value be something that both the

      client and the authorization server understand.  An OAuth client

      identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an

      OpenID Connect Issuer Identifier [OpenID.Core], or a URI are

      examples of things that might be used as "audience" parameter

      values.  Multiple "audience" parameters may be used to indicate

      that the issued token is intended to be used at the multiple

      audiences listed.  The "audience" and "resource" parameters may be

      used together to indicate multiple target services with a mix of

      logical names and locations.

 

Ciao

Hannes

 

 

From: Ace <ace-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org; oauth@ietf.org
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

 

Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is not a "single resource" in the context of a fully qualified API endpoint. 

Another example, for an API like SCIM [RFC7644] that has
   multiple endpoints such as "https://apps.example.com/scim/Users",
   "https://apps.example.com/scim/Groups", and
   "https://apps.example.com/scim/Schemas" The client would use
   "https://apps.example.com/scim/" as the resource so that the issued
   access token is valid for all the endpoints of the SCIM API.

Using "https://apps.example.com/scim" is semantically equivalent to using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

On 1/29/19 2:56 AM, Ludwig Seitz wrote:

On 28/01/2019 23:12, George Fletcher wrote:


I also don't know that this raises to the level of "concern" but I find the parameter name of "req_aud" odd. Given that the parameter in the resource-indicators spec is 'resource' why not use a parameter name of 'audience'. That said, I have not read the thread on the ACE working group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' and 'audience' and having two parameters that cover a lot of the same semantics is going to be confusing for developers. When calling an API at a resource server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other use cases they are distinctly separate?


To give you all the background of "req_aud" from ACE (sorry for the long text):

Originally in ACE we had defined the "aud" parameter for requests to the token endpoint with the semantics that the client was requesting a token for a certain audience (i.e. requesting that the AS copy the "aud" parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that specifies the intended audience of Authorization Servers (if I remember correctly), so we decided to rename our parameter to "req_aud" for "requested audience".
Mike Jones then made us aware of the work on resource indicators, but upon closer examination I found the "resource" parameter to be more limited than the "req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI value is an identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single resource, which is more constrained than the definition of the "aud" claim from 7519, which uses a StringOrURI value.  For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource".  We therefore decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with "resource".

Any comments and suggestions about that line of reasoning (especially from the OAuth point of view) are very welcome.

/Ludwig


 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--------------14B335B4606FD30721E12CF0-- From nobody Thu Feb 7 13:28:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F889129A87 for ; Thu, 7 Feb 2019 13:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0mITmMfSM-a for ; Thu, 7 Feb 2019 13:28:30 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79565129A85 for ; Thu, 7 Feb 2019 13:28:30 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id z7so3749721iti.0 for ; Thu, 07 Feb 2019 13:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9JgyolgrytpShL8YvUvaBeFAg8iNTemmVj5Cl16YTfk=; b=QGxwj9zfAOUH9ObSOtc5pTch/2VTQ1tovlv/wPI1/m5u1WFwwEiWOH1JHFnusRHfNd prnIJWtL8QZroitAoxloWzWZueQ/t+yNRenUf/wigZXcTr4GvekOhvppi5oYcztDP8/D 35fe/r39B9ZemJJXuhOPKnrUwcszD6h0sHVFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9JgyolgrytpShL8YvUvaBeFAg8iNTemmVj5Cl16YTfk=; b=m5Vm2rYDQ6tOyGB/KMDVDzQlpwoeeFduOiZ+GdneWtsj79JSB2rAiMZ76LU58lGE8P 2IWnrVlXju5YEtvHGzAm1SfGvH3EGskySv5ioT2UciiasmhP3v0j19zLPV4qL6uAGgB8 8LV0Dg4wK7QHKE3zmKC+kRj3PeWjtVwpzI9v7NzeyDFjWfNPOCj+NzDuPsC1HIgR9GHc Ray7V5EhgGzw8W8huKJ7dkNXzRnuORQ2sUbxr3ZObV947POTN/z+DE5WKZUsUGT/aKkc O9xNSSnTLUNV3drOv81CVuXAAfzUqDaJAACwfoe5WXjVtCUShbLyoCtzzfC/YtUGXtVU Vf3Q== X-Gm-Message-State: AHQUAub5N9JqZtAcF3ciaMERnMcxvw5RqGn03Wz9swGhBx9ZFh5+4dR9 d3UN+Dd2jKXHRLe8LMXME5wk/b1Q/aDtXEXHrGA1SMuexnhqeGHHq/3RBTbEz80J+N0lUdmyO5s hm8TUqm4NgwL5Zg== X-Google-Smtp-Source: AHgI3IYWmN9ZwU61nwa81ZQiTIDr8ryzhLXrlDVsxwBfS5uDyREq6VDd60T9c0Va9d+EHtXvlZloA41ByQY0gGUTXv4= X-Received: by 2002:a5d:8597:: with SMTP id f23mr10866259ioj.238.1549574909542; Thu, 07 Feb 2019 13:28:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Thu, 7 Feb 2019 14:28:02 -0700 Message-ID: To: Filip Skokan , Benjamin Kaduk , Eric Rescorla Cc: Hannes Tschofenig , "oauth@ietf.org" , "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000096edf05815486ca" Archived-At: Subject: Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 21:28:34 -0000 --000000000000096edf05815486ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For better or worse there is a long and winding road that has led to where we are now with these parameters. And there has been plenty of misunderstanding, miscommunication, dysfunction, questionable decisions, and general SDO process along the way that/'s helped get to this point. I've certainly been a party to much of that so I'm not trying to point fingers here. And I'm not going to try and recount all that's happened - just the parts that (I think) are useful or relvent at this point. And really I'm just wanting to say that it has been pretty messy getting to the mess we have now. The token-exchange draft defines both the "resource" and "audience" parameters for use in the context of a "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to the token endpoint. There is a lot of overlap between "resource" and "audience" and I'm not sure there was necessarily a good reason to have the two but it just kind of unfolded that way (the use of a client ID as an audience is one case that's mentioned that isn't a URI). That document is in IESG evaluation (which is towards the end of the RFC process) and had a few DISCUSS ballot positions raised against it. Resulting from one of those DISCUSSes, which was unrelated to "resource"/"audience" but rather because of the OAuth URIs as far as I understand, one of the IESG members steered us in the direction of, and facilitated, the early registration requests. So token-exchange is currently requesting registration of (among other things) the "resource" and "audience" parameters at the token endpoint and the document describes their use only in the context of a token request with a "urn:ietf:params:oauth:grant-type:token-exchange" grant type. I strongly disagree with the idea, in theory or practice, that a parameter suddenly becomes meaningful and usable outside the context of its definition just by showing up in the registry. While the idea has been floating around for a long time, the actual resource-indicators draft as a WG item is considerably more recent than token-exchange. The resource-indicators draft defines the "resource" parameter as generally applicable for all requests to the token endpoint and the authorization endpoint. The meaning of "resource" in resource-indicators is consistent/compatible with the meaning in token-exchange but resource-indicators defines a broader more generalized usage of it. There's some TODO text in the IANA section that tries to capture that situation https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section= -4.1 and I was hopeful that the actual registration could be handled/updated to reflect the situation in a sane way. Recently the language in the resource-indicators draft was changed/softened a bit to clarify that the value of the "resource" parameter is a URI which can be an abstract identifier for the target resource and doesn't necessarily have to correspond to a network addressable location. I believe that's still very much compatible with it's usage and definition in token-exchange but it does, to Filip's point, shine some light on the question of the value of, or need for, the separate "audience" parameter at all. I'm less familiar with the happenings in ACE but there seems to have been some desire for a parameter that is somewhat similar. As far as I can tell, the intended usage has been for the token endpoint only. I believe it had the name "aud" at one point. It was pointed out that OAuth ran into conceptual problems with "aud" as a parameter name at the authorization endpoint because of a name conflict when used in conjunction with signed authorization requests made via redirection though the browser to the authorization endpoint with the likes of https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17 or https://openid.net/specs/openid-connect-core-1_0.html#RequestObject. Although the ACE "aud" parameter wasn't defined for the authorization endpoint AFAIK the name was changed to "req_aud" to avoid potential future collision and/or confusion (I think anyway). That's the state of things right now as best I understand and can articulate. So where does that leave us? My preference (I think anyway after thinking about it for hours while writing this email) would be to remove the "audience" parameter from token-exchange. And to have token-exchange defer to resource-indicators for the core definition and registration of the "resource" parameter while just having text describing how it's used in the token-exchange context for ease of reading and understanding. A URN scheme could be prescribed in token-exchange for how to convey a client ID in a URI (something like "urn:ietf:params:oauth:client_id:" using the subnamespace procured by RFC 6755). ACE could also reference resource-indicators and utilize the "resource" parameter rather than "req_aud" - to do so it seems it would also need to provide guidance or definition on how to place arbitrary string values into a URI. Regardless of keeping the "audience" parameter or not, it would seem to make some sense to have token-exchange defer to resource-indicators for the core definition and registration of the "resource" parameter. But the drafts are at different stages in the process (in the wrong order) and I'm way out of my depth in understanding what can and can't be done with references to documents that aren't as far along towards being RFC. I'm not even sure how much change is possible/allowed to token-exchange at this point, given that it's almost done. An alternative is to leave "resource" and "audience" in token-exchange and have it do the registrations. Then have resource-indicators expand the "resource" registration to add "authorization request" as a usage location (and maybe update the additional context of use too). ACE could use "audience" rather than "req_aud" and further define it for general use and do a similar kind of expanded registration request for "audience" to account for its more generalized definition. There are, of course, other alternatives too. But that's more than enough typing from me for the time being. On Thu, Feb 7, 2019 at 8:38 AM Filip Skokan wrote: > To add to that, > > 3. If a device uses HTTP Token Exchange it can use both resource and > audience parameters. > > With the recent discussion and changes to the language in the resource > indicators draft, does the token exchange spec need a unique audience > parameter? > > S pozdravem, > *Filip Skokan* > > > On Thu, 7 Feb 2019 at 16:25, Hannes Tschofenig > wrote: > >> Hi all, >> >> >> >> after re-reading token exchange, the resource indicator, and the >> ace-oauth-params drafts I am wondering whether it is really necessary to >> have different functionality in ACE vs. in OAuth for basic parameters. >> >> >> >> Imagine I use an Authorization Server and I support devices that use CoA= P >> and HTTP. >> >> >> >> 1. If a device uses CoAP then it has to use the req_aud parameter to >> indicate to the authorization server that it wants to talk to a speci= fic >> resource server. It would either put a URI or a logical name there. >> 2. If a device uses HTTP then it has to use either the resource >> parameter to indicate to the authorization server that it wants to ta= lk to >> a resource server, which is identified using a URI, or the audience >> parameter, if it uses a logical name. >> >> >> >> Ciao >> Hannes >> >> >> >> >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy t= he >> information in any medium. Thank you. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000096edf05815486ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
For better or worse there is a long a= nd winding road that has led to where we are now with these parameters. And= there has been plenty of misunderstanding, miscommunication, dysfunction, = questionable decisions, and general SDO process along the way that/'s h= elped get to this point. I've certainly been a party to much of that so= I'm not trying to point fingers here. And I'm not going to try and= recount all that's happened - just the parts that (I think) are useful= or relvent at this point. And really I'm just wanting to say that it h= as been pretty messy getting to the mess we have now.

The token-exchange draft defines both the "resource" and= "audience" parameters for use in the context of a "urn:ietf= :params:oauth:grant-type:token-exchange" grant type request to the tok= en endpoint. There is a lot of overlap between "resource" and &qu= ot;audience" and I'm not sure there was necessarily a good reason = to have the two but it just kind of unfolded that way (the use of a client = ID as an audience is one case that's mentioned that isn't a URI).= =C2=A0 That document is in IESG evaluation (which is towards the end of the= RFC process) and had a few DISCUSS ballot positions raised against it. Res= ulting from one of those DISCUSSes, which was unrelated to "resource&q= uot;/"audience" but rather because of the OAuth URIs as far as I = understand, one of the IESG members steered us in the direction of, and fac= ilitated, the early registration requests.

So= token-exchange is currently requesting registration of (among other things= ) the "resource" and "audience" parameters at the token= endpoint and the document describes their use only in the context of a tok= en request with a=C2=A0 "urn:ietf:params:oauth:grant-type:token-exchan= ge" grant type. I strongly disagree with the idea, in theory or practi= ce, that a parameter suddenly becomes meaningful and usable outside the con= text of its definition just by showing up in the registry.
<= br>
While the idea has been floating around for a long time, the = actual resource-indicators draft as a WG item is considerably more recent t= han token-exchange. The resource-indicators draft defines the "resourc= e" parameter as generally applicable for all requests to the token end= point and the authorization endpoint. The meaning of "resource" i= n resource-indicators is consistent/compatible with the meaning in token-ex= change but resource-indicators defines a broader more generalized usage of = it. There's some TODO text in the IANA section that tries to capture th= at situation https://tools.ietf.org/html= /draft-ietf-oauth-resource-indicators-02#section-4.1 and I was hopeful = that the actual registration could be handled/updated to reflect the situat= ion in a sane way.

Recently the language in t= he resource-indicators draft was changed/softened a bit to clarify that the= value of the "resource" parameter is a URI which can be an abstr= act identifier for the target resource and doesn't necessarily have to = correspond to a network addressable location. I believe that's still ve= ry much compatible with it's usage and definition in token-exchange but= it does, to Filip's point, shine some light on the question of the val= ue of, or need for, the separate "audience" parameter at all.
=

I'm less familiar with the happenings in ACE = but there seems to have been some desire for a parameter that is somewhat s= imilar. As far as I can tell, the intended usage has been for the token end= point only. I believe it had the name "aud" at one point. It was = pointed out that OAuth ran into conceptual problems with "aud" as= a parameter name at the authorization endpoint because of a name conflict = when used in conjunction with signed authorization requests made via redire= ction though the browser to the authorization endpoint with the likes of https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17 or https://openid.net/specs/openid-connect-core-1_0.html#Req= uestObject. Although the ACE "aud" parameter wasn't defin= ed for the authorization endpoint AFAIK the name was changed to "req_a= ud" to avoid potential future collision and/or confusion (I think anyw= ay).

That's the state of things right now= as best I understand and can articulate. So where does that leave us?

My preference (I think anyway after thinking about it for h= ours while writing this email) would be to remove the "audience" = parameter from token-exchange. And to have token-exchange defer to resource= -indicators for the core definition and registration of the "resource&= quot; parameter while just having text describing how it's used in the = token-exchange context for ease of reading and understanding. A URN scheme = could be prescribed in token-exchange for how to convey a client ID in a UR= I (something like "urn:ietf:params:oauth:client_id:<value>"= using the subnamespace procured by RFC 6755). ACE could also reference res= ource-indicators and utilize the "resource" parameter rather than= "req_aud" - to do so it seems it would also need to provide guid= ance or definition on how to place arbitrary string values into a URI.
=

Regardless of keeping the "audie= nce" parameter or not, it would seem to make some sense to have token-= exchange defer to resource-indicators for the core definition and registrat= ion of the "resource" parameter. But the drafts are at different = stages in the process (in the wrong order) and I'm way out of my depth= in understanding what can and can't be done with references to documen= ts that aren't as far along towards being RFC.

I'm not even sure how much change is possible/allowed to token-ex= change at this point, given that it's almost done.=C2=A0

An alternative is to leave "resource" and= "audience" in token-exchange and have it do the registrations. T= hen have resource-indicators expand the "resource" registration t= o add "authorization request" as a usage location (and maybe upda= te the additional context of use too).=C2=A0 ACE could use "audience&q= uot; rather than "req_aud" and further define it for general use = and do a similar kind of expanded registration request for "audience&q= uot; to account for its more generalized definition.

There are, of course, other alternatives too. But = that's more than enough typing from me for the time being.





=

On Thu, Feb 7, 2019 at 8:38 AM Filip Sk= okan <panva.ip@g= mail.com> wrote:
To add to that,

3. I= f a device uses HTTP Token Exchange it can use both resource and audien= ce parameters.

With the recent discussion a= nd changes to the language in the resource indicators draft, does the token= exchange spec need a unique audience parameter?

S pozdravem,
Filip Skokan
=


On Thu, 7 Feb 2019 at 16:25, Hannes Tschofenig <Hannes..Tschofenig@arm.com= > wrote:

Hi all,

=C2=A0

after re-reading token exchange= , the resource indicator, and the ace-oauth-params drafts I am wondering wh= ether it is really necessary to have different functionality in ACE vs. in = OAuth for basic parameters.

=C2=A0

Imagine I use an Authorization = Server and I support devices that use CoAP and HTTP.

=C2=A0

  1. If a device uses CoAP then it has to use the req_aud par= ameter to indicate to the authorization server that it wants to talk to a s= pecific resource server. It would either put a URI or a logical name there.
  2. If a device uses HTTP then it has to use either the resource p= arameter to indicate to the authorization server that it wants to talk to a= resource server, which is identified using a URI, or the audience parameter, if it uses a logical= name.

=C2=A0

Ciao
Hannes

=C2=A0

=C2=A0

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000096edf05815486ca-- From nobody Thu Feb 7 13:36:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9957C12D4EC for ; Thu, 7 Feb 2019 13:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_Ztn93hwm7x for ; Thu, 7 Feb 2019 13:36:37 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B092D129A87 for ; Thu, 7 Feb 2019 13:36:36 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id d11so3763702itf.2 for ; Thu, 07 Feb 2019 13:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eP6vEfE9Nk3n4I9FdP6zrrxd3zQ57PHmVzkLQrV1edI=; b=nTUtWvKxihasydIT8+9Wzq6CkH/aGKh6wmabQW94r9rm/YodLZFzgRIjhIRyDLwAhP islHuOzs0M1pqRMBSuq5USPjgtpy4jnBs/i2yL2VONLsO7rIECaxHfO6EZ+mT7HvXdwU TqjNU0cGfhmrlH8o8M+MdY9qnm0YnHfDLeFdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eP6vEfE9Nk3n4I9FdP6zrrxd3zQ57PHmVzkLQrV1edI=; b=YQh+yBHbbruwVYPyaeqEkTJC4AuBS1sYsPMWjvf/n1q0VVEYOivb+KMETgEXgXPHw2 enK0Svf6C6DFNvIgfpDXLTZ+q0XmFVOtNilh+NOeHaa5zd1Nmw3gOW8JBfafmxntUJd4 14vsG8AmMu3b09jMEy5Zdx+/JaYuAJGUc0/BMBvNvUM6OoTDm7G256i79fBg3fgC0Ia5 TMWZ3ODkXyN+1/AqyKuIaU8vv2keRyoNVxvbft5sOnlT4PgL/DeI139V1E2rSWI2l3Iw K8F3nkl1sujxfP58FMoMhy8GLwMoFfAYEn55Xh7+U6BT1eAiUxFl0LXvKgYSUXXPQvmK mVVQ== X-Gm-Message-State: AHQUAuaKKA3ezoRXL2XjNpkuCCIhEdsJBpNekovrSK3FKK7cbR+YfF0l 0fZ59phtSCCetU8S+Xqb8jJPMBZfx1Ot++Hm3H2WM/JLe+bzSdFzaXhplb9nJUrQZzg1SrEQZA/ vcME44UL/3F5zSpcbfKg= X-Google-Smtp-Source: AHgI3IYIA/5u0k2Nf96YLpkLAm/NgA1r4KV7AEAjKVvYXF0d7Waf+29xjw5ZWB1pmOllOy8UtexPVIRY2l80CF56HIc= X-Received: by 2002:a24:3987:: with SMTP id l129mr6213722ita.45.1549575395452; Thu, 07 Feb 2019 13:36:35 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> From: Brian Campbell Date: Thu, 7 Feb 2019 14:36:08 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="000000000000ffca2c058154a2b7" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 21:36:42 -0000 --000000000000ffca2c058154a2b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly. On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: > The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had > clients in the wild that assumed that all the properties in the JSON obje= ct > returned from our userinfo endpoint were scalar strings. This broke when = we > introduced a new property whose value was a JSON object. It was a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Date: *Wednesday, February 6, 2019 at 11:30 AM > *To: *"Richard Backman, Annabelle" > *Cc: *"Richard Backman, Annabelle" , oauth < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > And I'm honestly really struggling to see what could have gone wrong with > or how token_endpoint_auth_methods broke something with the user info > endpoint. If you have the time and/or it'd be informative to this here > little discussion, please explain that one a bit more. > > > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > wrote: > > "far" should have said "fair" in the previous message > > > > > > > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Monday, February 4, 2019 at 5:28 AM > *To: *"Richard Backman, Annabelle" > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell > *Date: *Friday, February 1, 2019 at 3:17 PM > *To: *"Richard Backman, Annabelle" > *Cc: *George Fletcher , oauth > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher <40aol.com@dmarc...ietf.org>> > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ffca2c058154a2b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000002d019d05817345c2-- From nobody Sat Feb 9 14:31:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7DC130E09; Sat, 9 Feb 2019 14:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTjqrpmRIR6w; Sat, 9 Feb 2019 14:31:41 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790139.outbound.protection.outlook.com [40.107.79.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4CB130DC8; Sat, 9 Feb 2019 14:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pM33reUN/XxMLhTQVn//SrvSvrhDTpQRGDgFCV7kMSo=; b=I7KzZ05zkGdzK5ph8v6uVk+v/j8/Kn9PVwE6rrs64Vvsf69Ul4DaczMWco++hBLo7ilqcrDUKPqnOrGssG3Ev/LFeKpfknUSIk5q4EUvt6Jfm0mkNqFWp6ut+TLPPB6cYNcrVFGzniVn9CLNBQmu9zQsaYkDiqLz/xq21wVG1fc= Received: from CY4PR0101CA0021.prod.exchangelabs.com (2603:10b6:910:3c::34) by SN6PR01MB3760.prod.exchangelabs.com (2603:10b6:805:17::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Sat, 9 Feb 2019 22:31:38 +0000 Received: from CO1NAM03FT055.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::201) by CY4PR0101CA0021.outlook.office365.com (2603:10b6:910:3c::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17 via Frontend Transport; Sat, 9 Feb 2019 22:31:38 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT055.mail.protection.outlook.com (10.152.81.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Sat, 9 Feb 2019 22:31:37 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x19MVXhQ011772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 Feb 2019 17:31:35 -0500 Date: Sat, 9 Feb 2019 16:31:33 -0600 From: Benjamin Kaduk To: Brian Campbell CC: Filip Skokan , Eric Rescorla , Hannes Tschofenig , "oauth@ietf.org" , "ace@ietf.org" Message-ID: <20190209223132.GB23225@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(189003)(199004)(76176011)(486006)(26826003)(476003)(126002)(14444005)(88552002)(336012)(86362001)(97756001)(4326008)(305945005)(2906002)(246002)(8676002)(7696005)(50466002)(53416004)(47776003)(478600001)(426003)(55016002)(956004)(1076003)(11346002)(446003)(106466001)(75432002)(54906003)(229853002)(26005)(106002)(316002)(16586007)(6246003)(8936002)(104016004)(186003)(36906005)(356004)(786003)(46406003)(23726003)(33656002)(58126008)(6916009)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3760; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT055; 1:gslkPoeMcM+vroMgnYtrX5eA4WJI5JnzzsCUwK5nLva96D8MrL8pzcT8rFtZPWlTvyHlBKxG9i9H9W3Q8N5ECsPU4tTrKOeXzpZQCKhOSWYDTeEP0XgzyIcwT0rmc2xilW+8Uwfj0+07twbY6CWwqJRxhG4gW57ArJkXl7VRnD4= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c2aafd70-4646-4d2c-c4e5-08d68ede5ae7 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB3760; X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3760; 3:QpDiLzptppwdOh1AFd//vpwSHNzM3zi1Oz7EVdZq8Qzw35BzWsPKww5SnVvelx6SZjC8Z9reSLYalPK/nGMBLXjGTwpM8geQfxe3qRpW8l+im450ovgkIEKI7bbIpVo0Mr0kURrWYF8kgaBmfDAj5AI1bP03IzTwPLghjh8XKVZuxWWzQzViixOM7nbo1Almh7xhrTTFBWQgXTeJrpbgNhl0P/vPfOIdpySvMhFMEAUZUPo7PlIN6v+Gn57iP2HyXDPWWCVTDrxH3BN9hwCXWRxGE3pto8dRu1dlTDyu+QMTqMkUj7hwoOn1xITzBjKG6ON2WZ5AgoC+5Z0SvMvDxwSD0Qj9hx/ZH9ifbT6j9lbk2PvU+hQw+x1nGWpe0CbB; 25:D28RiH06dyhqpZtzxOfPblVMHnxhgxpKezuispB2EOsdo4xFYs8LdRCausvZG+HgvyxYe+NRAeTq26Jnzsgf4vJblxWajogdYMKglmPBag3ELboP8Twh80DfI+B4puv/qVjtdTje6X9bwWmOgB3qHM5Z2Ab8VBwcXK2hXBzniKnYFqlmY49HN+C8rPTsSP8xiKw0dS8ItJd6d1ekMqhqhgf9YlOvlx6iT8oToqMURwvgq/cfifXce42k/iaxBu8b9BXhdXmEHFeBNg/ICL8JdGvShPWXDsqhU85wthk7/lVAbXPEDZkWZUj8eRMSdsyHDAXFVAmVr/w+uW5OHdg2Ag== X-MS-TrafficTypeDiagnostic: SN6PR01MB3760: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3760; 31:oar2NNh50t3hf88BeFbPa1j+vuoYKEHDe9t38Swcj1UGofbZH4XkT7JRmlkK/I6EfGdg9ysgGqZ6EwojdjkipUB3px5qiB287mSE0OKHY+ZOH2DkcYvyOBSg8UQ9FtxYjk53r0m83mnlQWilOoJvfzXdigHMor86KgKmusblx+XewiCL+UOG3BSJGmnTeTEm/owQSan5WUJ9PASo8sK2PhriHQbi5dhJ18AHnUk/3N0=; 20:hucQfnK6IKs4DHcYcF8SST8zomcoHMG2MBKZZlicFb0aOy/4w0Zl3rV8UlFYL60xHnsPDpJ3wCTnCSzVa9iYrAqfwCU0YnF5OAyMZfrIcqfbkb/rwNp40Lo4TKA7v8XY1dgKZZhCbxWD0+E8iDlm1zy5/To3YLQv5hyxhtu+11VC6V10fGVt9IbzFeUXCw6xJRXGnow2tbEefQy5Ebf7cx+vmA+5sLbG2obTve+F3E7vjo1DWcAlFc1NLOJP/3vYHBBdzCv2apNmRt7FXwvOaPQFErfshAE9K/K3tgK0PnTnlvI6L9etq/fCScth3RKkNuvVc9OmxXtSb3o0yFkY8Bb13umyGSsSkdloIeJ9LOhGVBZn8uJOfOsznjwc1yew2LE5C5xgnvYkKpvyHxl5fHH6suB9r6Zw6q//N5Ucmbe/6/UWqWyB924MHc0uouDvYQtdtYAj6wD1A2OlT4zTuJAgCg+jZGl5dNGTRboGlegtQP5ZrbXXlHuJUX2/YaJM//bmCGCDh0ARrVEvYgQF2KUgmR6lmfkOzP8lbM3qbcT0+7JQq1GIIj4nP3oQlBypjfQ7JFK2Zh6fRAca1XivYhk0g2aSoMOCeHJ8URRqofw= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3760; 4:7IJVGr595dfZl1jdCFQ3AHsMlx9e92cEXF4K2X+RBS2+o403jZvhyyVqnwelWlxNpuexTrAbT4fQRBXsVqEv3gTKoQmog8n6vTrBjVlCuTCeMFpGTNlloFYeVqIb+HuPyqvYzWXnozl+0flW7X5T6zlLD4xY/57WdOeMBXrpqzTrsAX+wTrUnra435Ea1iUscDqlx+BQBvXQKU7KfnT/yrFjhHk7a/0TBMVugjCEgYsbpHhxNy6GOcFAeRJf8+dqCKMq/qN2iagGmjzYssflJ7AnRJVG4Ytc0nxn/5EieyF6ggENxWW8AB6E9xvOyAhw X-Forefront-PRVS: 09435FCA72 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB3760; 23:4A+b+/vp/cn8I1ngJ5TufTKRn6A9sODHmVBEXOgxn?= =?us-ascii?Q?qLafP8Sx3VJEg9pfb1Qd6klpZOIvEwGgSqWDLeRgiMMVSewvaQsDh9nrdCpQ?= =?us-ascii?Q?XCRSvUBXu2ZWhHZrVY/KIPoDu79iNmY22+awW1f8LajZonCXxmEfhoKHJYzw?= =?us-ascii?Q?Wu6Jk/naMh/ItwToMqygPP9J8JfivIHT7aASMJxyPdBEmdD0brdHd4b1PtIK?= =?us-ascii?Q?rtrsEM2V199tuE4t2WLPNg/Vj4+rtaxvrFZm898XF9ETzaOQBKduCDdbmSbu?= =?us-ascii?Q?eGxBivP3pgKkMKw2xj0SgUWNwWPmQAPty/DeCYgr8Zsq0cttALlCn/M8hHGM?= =?us-ascii?Q?7VYOPS9WUth0MR/mfGjUHBTL2dc8DBmFQcsQ7E/ICY3OLIrIObiQ+2q3OF/y?= =?us-ascii?Q?I7RQFcl1nZzO/JSY36j6MlKlfAKKcvxzmReOiQRUfLp4Adm1W8gFUtC7Wrmt?= =?us-ascii?Q?9BWQcmIbuIVj7ktDStbtjHKmW7EyJbDVHngs1wrvuv2o9BwOzLP4Hy0BGyqB?= =?us-ascii?Q?0moGY9i2GqIbTEO27gNN8hELI6q3FamEjss8Q6jIMAIMQ8iUxKHrYc+eIJsF?= =?us-ascii?Q?eqvbFeNHnf++ruX/QxucPIbpWh9zcQmH+AAomiOCv423/EEa+oStIbT0QH6P?= =?us-ascii?Q?Pn7WL1+1TA4JsDvL5RyDBxo87uuMKQYS99p8imm/5LmSXjF22FoTr6nKlRAD?= =?us-ascii?Q?kC4og0eiM6Ui87rhNBd/lNYN2tJ5e/6iBvARvDewbUl3CHQZVb0KtsDfTkgV?= =?us-ascii?Q?Gx1fZxfZa6b0ZndfGIXrM5Gy4bNLkfvA5tYaKAsHxXoD/WyQVZNNGf9lDV10?= =?us-ascii?Q?ZDKDuzlThrpuNNQjWDkVxEF2pqV4ly0zkuqy9b0K9C3uRC+foXUr+0UG9Fk/?= =?us-ascii?Q?+Dx72qNWW59Uo0gI7cDUAB6GkVTespoOY03vommj6ZiGtwVd7Qx703uxjPY4?= =?us-ascii?Q?Uif6p+Y4hPfpAfwKFF44QjfyOmLRRueCgAaKpV4z0hN4eDJijmmPZ9LyzLb9?= =?us-ascii?Q?a7thMghUKm/JPBFQKAmg26dVzr2QAmTuhC9d2dadYwg1P2u6H98yr0qcDH0g?= =?us-ascii?Q?tOpzPhxEHLqeOHZ6p3befZ2EQpk7pveKOqQxCs6cKLEED+HOxU3kob1Pfr0z?= =?us-ascii?Q?jIsbAk7cZCReDurpfYT2SXIZI344Ng6e+CwJ1jdnVz5NQ88SJHQMDU9vFVOy?= =?us-ascii?Q?m9IzQd0GkgeJt1nBN21XBruE+748ZpOmQMD?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: YYzKO0qni+lEiltWYwSM2/HoUGawcEGq8+zsgPh6SvqPqJUkiGSMKDdrAwrZQ54FfuP2/bRbk8JCLvP3miH+bLNcVvdtWuaRZDZ5nkVYeS9Gi4LEjilxiKz4MxL2OXHGPt84TW4WSFCUHMEu4YoEGKKKE4BUYPN+bqwU9Q0UMyVixHBNKw4JeU6U+nKiQxosY6udDa0TtLwJmnllbWI3ABmwdLUNgB99qcmWKgjWeVmhJ2ARadGjrdXAAKCHwCfzBpC8+Wijryxs9PptegkmDUsfR9tKQrNcr5QwF7pe/G1evxKspcjuFhr13lUncHxJLRcAZiHUeoUb0vuYWu5swsJbLzyacXqpYkBs5ZI/+TV2HLenDah280phVqMsE8pSv75jZbZuRODkrwSE+ZmUpTpBT4Ct6DEg2M4Hi5+jNXQ= X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3760; 6:wmZlgMyT+In1scteVX34BBMvfR3HjY6Du8HMmwC4FhSCfaaAu7dKbzMIkLJ3CuQqlJPVbMI2MuvFUfxbe4E5hpA/Yg/vNsjMU1sMD20w2DXnrquzo4lVWO+VvaxK8uYGWhqzDbENm+1yMhPFcC2ChWDtEEPQKN7TzysCK+XSOQ2wrHD36cUPwvB3MkJWAGTzr0+vSlqd9mOF982hrl5BehXsTPRCb7v86JGRJ1Uz+YF7X3/slUQjmlL0MRRBI8ch3cHafuGNlBGDsu3P+1kVhiQrY9kAxuXI4YReW5EEayhovCQFiv9jwKI0gc+sz2iBTXtTCk91P1scwMjL80S02VYDtZ8Fk5gMpM0+pdf9uDgX80PrcdkpyYgLpnSqcFZj6urUCYqXutgnHD6A/LA1MoGXTdCz5VYDV8wuuW5V7iUEQk8armOMiwgrsPBkpCMzpLANDy167D5MIwVmXXtopA==; 5:aUe5sM/pazzq0aAVGCjRRs2r8sdIAVVBbm18ArHJg6syEHybKsIWuu0w5s39fhHVjs7AICscF3PaKxInE9sW60C0DMtAsHgTsOROHFHHNdq9qxgEps2iUe5Ru8FHvkd3XnkfPoCqNT3fPxs0b5ub+lOulJWWY/WXuqHPUTrnkWXgAoji/7t/gx8sOKlHrOLToN1DDi965JVTHHpU2igEUw==; 7:5/ZQlFcFX4YD8TH+j3ejHJYPNRb46jXVRVv2gsdu+VNcm7CkjiqiJDLlqnnXxuPmVYG9f4KfPdpK+rO33esHr/SlUWDEHIy0KjrN+DO1xPkdSUKFV4gcB01ukDnOEUHRAsFLDFhqtCNbNhOuq0LxGQ== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2019 22:31:37.5261 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c2aafd70-4646-4d2c-c4e5-08d68ede5ae7 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3760 Archived-At: Subject: Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 22:31:44 -0000 On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > The token-exchange draft defines both the "resource" and "audience" > parameters for use in the context of a > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to the > token endpoint. There is a lot of overlap between "resource" and "audience" > and I'm not sure there was necessarily a good reason to have the two but it > just kind of unfolded that way (the use of a client ID as an audience is > one case that's mentioned that isn't a URI). That document is in IESG > evaluation (which is towards the end of the RFC process) and had a few > DISCUSS ballot positions raised against it. Resulting from one of those > DISCUSSes, which was unrelated to "resource"/"audience" but rather because > of the OAuth URIs as far as I understand, one of the IESG members steered > us in the direction of, and facilitated, the early registration requests. That was me. The conclusion to go for early registration was not (AFAICT) out of a desire to get the actual value registered more quickly than it would have been otherwise (which should be pretty fast, since IANA generally makes the live registries reflect changes shortly after IESG approval, not even waiting for AUTH48 or final RFC publication), but just from it seeming to be the least-effort way to approve and publish the document while still following the required process. (Basically, the I-D sent to the IESG was "codepoint squatting", having text in the document that claims that a specific URI value will be used, but with no guarantee from IANA that that specific value will end up being the one registered. I didn't think the IESG should grant its seal of approval to a document that was jumping the process in that way, and the other options we could think of would require fairly invasive changes to the text that would just have to be undone by the RFC Editor.) -Ben From nobody Mon Feb 11 04:26:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE56130E8A for ; Mon, 11 Feb 2019 04:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKsv61VjU8Vx for ; Mon, 11 Feb 2019 04:26:37 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EC11286D8 for ; Mon, 11 Feb 2019 04:26:37 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id v72so790142itc.0 for ; Mon, 11 Feb 2019 04:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iy9/9HzxeZE00NgaWh7rrk1O35NH28tR9rp+dgQfEGw=; b=oOnIpcDCf2hBAU9sDi5gFm14IeAjXiJWxMIzZ/cQ4Nm1xmTZBJgk9UaZAdAi2N7OcU D3IBaXZ6BLwe+YhiIZ2wQU0xRFl9Y8TzVbMEbkJEMzq7J19LpisJWtvVrvTYeL5BdvW3 aKEMnOECUirdQoBLRSK+uVtZPHPK/2Gt/uP8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iy9/9HzxeZE00NgaWh7rrk1O35NH28tR9rp+dgQfEGw=; b=Cl+lkmmjt+86muB10QiOanLOUeX7YBmdcAOJupFWMyB5NkKnhrwfyOc21RDRSVhLQ1 ETvEZs+5LLNCrHIiPJ306rKhyCvILDBOHgsE67kGpXojV2EASsBa9OuDaBJBXaz/dqU/ wsWtDsjk4O7RR5sfZ/4fypqeXgSn7rn+wQh3UEINN4e8Ooa2ZYiEoSpK2/5l+ZybyKc1 8J6M8fWYzj/fFElDqekM6lvzwt/Af41IaiBoDOwgIJ8b/6dEShk9I9jsmBLFgsaDIBgZ bOB21uExJ13qiepayrvjjqJMMf4SPRCULJfS1YtRCQS8d7DD5MtQDz0LJMISyFZhwngI 8CcQ== X-Gm-Message-State: AHQUAuYFm44OkobdtEfKVC4i8OFcOLiO9dsTrhTfCCf5qmVFX8j9eB8e R+PmxGzk8w2B52W03S6m2khu0Y/xdneMNpz/Gp38Cuupn/a4REcQngfKUsFYphIc5F+zux4Hm/Z gW9DTwNT+Xa/qDQ== X-Google-Smtp-Source: AHgI3IawiwA52wQoi+pbg2xM+TZcdQiX+zBdzNKpOmxB4UC4oRpRUjnDjKQz6+i3Z4qBP+GRRYW3oINsNDFyVEB83v8= X-Received: by 2002:a6b:b408:: with SMTP id d8mr16257593iof.138.1549887996389; Mon, 11 Feb 2019 04:26:36 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: From: Brian Campbell Date: Mon, 11 Feb 2019 05:26:09 -0700 Message-ID: To: Dominick Baier Cc: oauth Content-Type: multipart/alternative; boundary="00000000000077886d05819d6bfb" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 12:26:42 -0000 --00000000000077886d05819d6bfb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So, at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints. A straw-man example might look like this { "issuer":"https://server.example.com", "authorization_endpoint":"https://server.example.com/authz", "token_endpoint":"https://server.example.com/token", "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_client_auth", "none"], "userinfo_endpoint":"https://server.example.com/userinfo", "revocation_endpoint":"https://server.example.com/revo", "jwks_uri":"https://server.example.com/jwks.json", * "mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token ", "userinfo_endpoint":"https://mtls.example.com/userinfo ", "revocation_endpoint":"https://mtls.example.com/revo " }* } A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints". The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user. I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: > We are currently implementing MTLS in IdentityServer. > > Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. > > Thanks > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS = metadata. We had >> clients in the wild that assumed that all the properties in the JSON obj= ect >> returned from our userinfo endpoint were scalar strings. This broke when= we >> introduced a new property whose value was a JSON object. It was a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can force more work on clients than we expect. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Wednesday, February 6, 2019 at 11:30 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* "Richard Backman, Annabelle" , oauth < >> oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> And I'm honestly really struggling to see what could have gone wrong wit= h >> or how token_endpoint_auth_methods broke something with the user info >> endpoint. If you have the time and/or it'd be informative to this here >> little discussion, please explain that one a bit more. >> >> >> >> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> "far" should have said "fair" in the previous message >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell >> wrote: >> >> It may well be due to my own intellectual shortcomings but these >> issues/questions/confusion-points are not resonating for me as being >> problematic. >> >> >> >> The more general stance of "this isn't needed or worth it in this >> document" (I think that's far?) is being heard though. >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> (TL;DR: punt AS metadata to a separate draft) >> >> AS points #1-3 are all questions I would have as an implementer: >> >> 1. Section 2 of RFC8414 >> says token_endpoint >> =E2=80=9Cis REQUIRED unless only the implicit grant type is supported= .=E2=80=9D So what >> does the mTLS-only AS put here? >> 2. The claims for these other endpoints are OPTIONAL, potentially >> leading to inconsistency depending on how #1 gets decided. >> 3. The example usage of the token_endpoint_auth_methods property >> given earlier is incompatible with RFC8414, since some of its content= s are >> only valid for the non-mTLS endpoints, and others are only valid for = the >> mTLS endpoints. Hence this question. >> 4. This introduces a new metadata property that could impact how >> other specs should extend AS metadata. That needs to be addressed. >> >> >> >> I could go on for client points but you already get the point. Though >> I=E2=80=99ll share that #3 is real and once forced me to roll back an up= date to the >> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >> >> >> >> I don=E2=80=99t necessarily think an AS metadata property is wrong per s= e, but >> understand that you=E2=80=99re bolting a layer of flexibility onto a sta= ndard that >> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata= proposal as it=E2=80=99s >> been discussed here sufficiently deals with the fallout from that. In my >> view this is a complex enough issue and it=E2=80=99s for a nuanced enoug= h use case >> (as far as I can tell from discussion? Please correct me if I=E2=80=99m = wrong) that >> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serv= er Metadata >> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Monday, February 4, 2019 at 5:28 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> Those points of confusion strike me as somewhat hypothetical or >> hyperbolic. But your general point is taken and your position of being a= nti >> additional metadata on this issue is noted. >> >> >> >> All of which leaves me a bit uncertain about how to proceed. There seem >> to be a range of opinions on this point and gauging consensus is proving >> elusive for me. That's confounded by my own opinion on it being somewhat >> fluid. >> >> >> >> And I'd really like to post an update to this draft about a month or two >> ago. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> Confusion from the AS=E2=80=99s perspective: >> >> 1. If I only support mTLS, do I need to include both >> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_u= ri? Or >> set it to the empty string? >> 2. What if I only support mTLS for the token endpoint, but not >> revocation or user info? >> 3. How do I specify authentication methods for the mTLS token >> endpoint? Does token_endpoint_auth_methods apply to both the mTLS and >> non-mTLS endpoints? >> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-e= nabled >> device_authorization_endpoint under mtls_endpoints? >> >> >> >> Confusion from the client=E2=80=99s perspective: >> >> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t k= now anything >> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >> browsers and the AS expects to use that to authenticate me. >> 2. My AS metadata parser crashed because the mTLS-only AS omitted >> token_endpoint_uri. >> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >> encounter a JSON object as a parameter value. >> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints= , what >> do I do? >> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they= told me to use HTTPS, >> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right= ? >> >> >> >> Yes, you can write normative text that answers most of these. But you=E2= =80=99ll >> have to clearly cover a lot of similar-but-slightly-different scenarios = and >> be very explicit. And implementers will still get it wrong. The metadata >> change introduces opportunities for confusion and failure that do not ex= ist >> now, and forces them on everyone who supports mTLS. In contrast, the 307 >> redirect is only required when an AS wants to support both, and is >> unambiguous in its behavior and meaning. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Friday, February 1, 2019 at 3:17 PM >> *To:* "Richard Backman, Annabelle" >> *Cc:* George Fletcher , oauth >> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >> clients using the token endpoint >> >> >> >> It doesn't seem like that confusing or large of a change to me - if the >> client is doing MTLS and the given endpoint is present in `mtls_endpoint= s`, >> then it uses that one. Otherwise it uses the regular endpoint. It gives= an >> AS a lot of flexibility in deployment options. I personally think gettin= g a >> 307 approach deployed and working would be more complicated and error >> prone. >> >> >> >> It is a minority use case at the moment but there are forces in play, >> like the push for increased security in general and to have javascript >> clients use the code flow, that suggest it won't be terribly unusual to = see >> an AS that wants to support MTLS clients and javascript/spa clients at t= he >> same time. >> >> >> >> I've personally wavered back and forth in this thread on whether or not >> to add the new metadata (or something like it). With my reasoning each w= ay >> kinda explained somewhere back in the 40 or so messages that make up thi= s >> thread. But it seems like the rough consensus of the group here is in >> favor of it. >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> This strikes me as a very prominent and confusing change to support what >> seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about >> the text needed to clarify when the AS should provide `mtls_endpoints` a= nd >> when the client should use that versus using `token_endpoint.` Why is th= e >> 307 status code insufficient to cover the case where a single AS support= s >> both mTLS and non-mTLS? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Friday, February 1, 2019 at 1:31 PM >> *To:* George Fletcher > <40aol.com@dmarc.....ietf.org>> >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >> endpoint >> >> >> >> Yes, that would work. >> >> >> >> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> What if the AS wants to ONLY support MTLS connections. Does it not >> specify the optional "mtls_endpoints" and just use the normal metadata >> values? >> >> On 1/15/19 8:48 AM, Brian Campbell wrote: >> >> It would definitely be optional, apologies if that wasn't made clear. >> It'd be something to the effect of optional for the AS to include and >> clients doing MTLS would use it when present in AS metadata. >> >> >> >> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >> wrote: >> >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000077886d05819d6bfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's been pointed out that = the potential issue is not isolated to the just token endpoint but that rev= ocation, introspection, etc. could be impacted as well. So,=C2=A0 at this p= oint, the proposal on the table is to add a new optional AS metadata parame= ter named 'mtls_endpoints' that's value we be a JSON object whi= ch itself contains endpoints that, when present, a client doing MTLS would = use rather than the regular endpoints.=C2=A0 A straw-man example might look= like this

{
=C2=A0 "issuer":"https://server.example.co= m",
=C2=A0 "authorization_endpoint":"https://server.example.= com/authz",
=C2=A0 "token_endpoint":"https://server.example.= com/token",
=C2=A0 "token_endpoint_auth_methods_supported&= quot;:[ =C2=A0"client_secret_basic","tls_client_auth", = "none"],
=C2=A0 "userinfo_endpoint":"https://server.exam= ple.com/userinfo",
=C2=A0 "revocation_endpoint":"= ;https://serv= er.example.com/revo",
=C2=A0 "jwks_uri":"https://server.= example.com/jwks.json",
=C2=A0 "mtls_endpoints":{<= br>=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token"= ;,
=C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/useri= nfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example= .com/revo"
=C2=A0 }
}

A client doing MTLS would look for and give precedence = to an endpoint under "mtls_endpoints" while falling back to use t= he normal endpoint from the top level of metadata when/if its not in "= mtls_endpoints".

The idea being that "r= egular" clients (those not doing MTLS) will use the regular endpoints.= And only the host/port of the endpoints listed in mtls_endpoints will be s= et up to request TLS client certificates during handshake. Thus any potenti= al impact of the CertificateRequest message being sent in the TLS handshake= can be avoided for all the other regular clients that are not going to do = MTLS - including and most importantly in-browser javascript clients where t= here can be less than desirable UI presented to the end-user.

I'm struggling, however, to adequately gauge wh= ether or not there's sufficient consensus to go ahead with the update. = There's been some support for it voiced. As well as talk of other appro= aches that could be alternatives or additional measures. And also some voca= l opposition to it.=C2=A0

=
On Sat= , Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:
We are currently implementing = MTLS in IdentityServer.

Our approach will be that we=E2=80=99ll offer a separate token endpoin= t that supports client certs. Are you planning on adding an official endpoi= nt name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint= =E2=80=9D.
<= br>
Thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick

= On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

<= div>
Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..





On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pin= gidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discus= sed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" an= d just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.t= onge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000077886d05819d6bfb-- From nobody Mon Feb 11 05:07:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFE812E7C1 for ; Mon, 11 Feb 2019 05:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn3pnsFdEQoP for ; Mon, 11 Feb 2019 05:07:31 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0149712008A for ; Mon, 11 Feb 2019 05:07:30 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id v72so1074501itc.0 for ; Mon, 11 Feb 2019 05:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QJ2GrJjjYSfM9gElfYNOVxVZ+ew9YkHHvxBFwZOKeJM=; b=kTj3SWb2alxG3jWwKh55yxaSAh3pXnOdrSDqgT1Wm306RKUqUOH0LWVSmowEwTzFu8 uPMgeceq3fznPlziBhSX7dkHKXi6gsGhbcWyfkE1Wn+gb5AaPRlEMJLfMvcVd5G28OyG ezBcZ7TwdwNy8EdwwRmhoU7FbaO2AanqTcLuM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QJ2GrJjjYSfM9gElfYNOVxVZ+ew9YkHHvxBFwZOKeJM=; b=F5BHQOzkqSxLvlinDhEJPl96K9BJO+E7EJy+qwwOCUS1w3e2aDtaZiUPUUgIkXXLGO BGUfDPEkHF2dYflbWxRN2bmY8JuwLfg4/agpUp22jARzcx66Cz1Re8ea5HUKaqKtYxUr prjFCJkAIFIvuH+cyvEY8w5ZkcvE9F1CXyyQXPiKRJDIxntz2RS/b5ZUSpRv6yI/RpDl rPXc+G5tk8w9fYkQKk+xvElITNXE8PY/mfrDWFYLvHiuVaEcMQYVXvzxZs/LP+uVhr2m 2j5psWCpzEtZ+owa8/b20bYFFAbrXCzR8uF7XaqfKINg2tFx03b3So0FFjUYd0spdIjh k2TQ== X-Gm-Message-State: AHQUAuajzv6ksc+vHtNGfepiZ0cCo3aiLOwjBoL1sIQ6PfjNQ52f/89O 6Yv8xS9ziqkKS6lGs6PHkzuU/7xZaXwKtv8XT4bjRXAZFlTjW+nwYBjGsDGcsX6ZJAMTjzWctEO eKddThayjHFzvfg== X-Google-Smtp-Source: AHgI3IZCQpgnXp7rvLmyh4G0Se8WPqy7hLzv2vUsGxE3q6v3kHILeBV9eP8gL7Hh8ivdRSspBxKFwfQzaqaDRoKpKn4= X-Received: by 2002:a02:946e:: with SMTP id a101mr19058985jai.90.1549890450117; Mon, 11 Feb 2019 05:07:30 -0800 (PST) MIME-Version: 1.0 References: <20190209223132.GB23225@kduck.mit.edu> In-Reply-To: <20190209223132.GB23225@kduck.mit.edu> From: Brian Campbell Date: Mon, 11 Feb 2019 06:07:03 -0700 Message-ID: To: Benjamin Kaduk Cc: Filip Skokan , Eric Rescorla , Hannes Tschofenig , "oauth@ietf.org" , "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b8768b05819dfd41" Archived-At: Subject: Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 13:07:33 -0000 --000000000000b8768b05819dfd41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right, I was just trying to recount what had happened and say that it was my understanding that the URI registrations were the ones you'd expressed concern with and moved to early registration while the topic of this thread was about parameter names. I guess it doesn't really matter but it seemed like a distinction worth making when I wrote that last week. On Sat, Feb 9, 2019 at 3:31 PM Benjamin Kaduk wrote: > On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > > > The token-exchange draft defines both the "resource" and "audience" > > parameters for use in the context of a > > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to > the > > token endpoint. There is a lot of overlap between "resource" and > "audience" > > and I'm not sure there was necessarily a good reason to have the two bu= t > it > > just kind of unfolded that way (the use of a client ID as an audience i= s > > one case that's mentioned that isn't a URI). That document is in IESG > > evaluation (which is towards the end of the RFC process) and had a few > > DISCUSS ballot positions raised against it. Resulting from one of those > > DISCUSSes, which was unrelated to "resource"/"audience" but rather > because > > of the OAuth URIs as far as I understand, one of the IESG members steer= ed > > us in the direction of, and facilitated, the early registration request= s. > > That was me. The conclusion to go for early registration was not (AFAICT= ) > out of a desire to get the actual value registered more quickly than it > would have been otherwise (which should be pretty fast, since IANA > generally makes the live registries reflect changes shortly after IESG > approval, not even waiting for AUTH48 or final RFC publication), but just > from it seeming to be the least-effort way to approve and publish the > document while still following the required process. (Basically, the I-D > sent to the IESG was "codepoint squatting", having text in the document > that claims that a specific URI value will be used, but with no guarantee > from IANA that that specific value will end up being the one registered. > I didn't think the IESG should grant its seal of approval to a document > that was jumping the process in that way, and the other options we could > think of would require fairly invasive changes to the text that would > just have to be undone by the RFC Editor.) > > -Ben > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b8768b05819dfd41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, I was just trying to recount what had happened and = say that it was my understanding that the URI registrations were the ones y= ou'd expressed concern with and moved to early registration while the t= opic of this thread was about parameter names. I guess it doesn't reall= y matter but it seemed like a distinction worth making when I wrote that la= st week.

On Sat, Feb 9, 2019 at 3:31 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Thu, Feb 07, 2019 at 02:28:02PM -0700,= Brian Campbell wrote:
>
> The token-exchange draft defines both the "resource" and &qu= ot;audience"
> parameters for use in the context of a
> "urn:ietf:params:oauth:grant-type:token-exchange" grant type= request to the
> token endpoint. There is a lot of overlap between "resource"= and "audience"
> and I'm not sure there was necessarily a good reason to have the t= wo but it
> just kind of unfolded that way (the use of a client ID as an audience = is
> one case that's mentioned that isn't a URI).=C2=A0 That docume= nt is in IESG
> evaluation (which is towards the end of the RFC process) and had a few=
> DISCUSS ballot positions raised against it. Resulting from one of thos= e
> DISCUSSes, which was unrelated to "resource"/"audience&= quot; but rather because
> of the OAuth URIs as far as I understand, one of the IESG members stee= red
> us in the direction of, and facilitated, the early registration reques= ts.

That was me.=C2=A0 The conclusion to go for early registration was not (AFA= ICT)
out of a desire to get the actual value registered more quickly than it
would have been otherwise (which should be pretty fast, since IANA
generally makes the live registries reflect changes shortly after IESG
approval, not even waiting for AUTH48 or final RFC publication), but just from it seeming to be the least-effort way to approve and publish the
document while still following the required process.=C2=A0 (Basically, the = I-D
sent to the IESG was "codepoint squatting", having text in the do= cument
that claims that a specific URI value will be used, but with no guarantee from IANA that that specific value will end up being the one registered. I didn't think the IESG should grant its seal of approval to a document=
that was jumping the process in that way, and the other options we could think of would require fairly invasive changes to the text that would
just have to be undone by the RFC Editor.)

-Ben

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000b8768b05819dfd41-- From nobody Mon Feb 11 06:53:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BC0130E95 for ; Mon, 11 Feb 2019 06:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyeS-ZvHpExF for ; Mon, 11 Feb 2019 06:53:30 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE86130E8A for ; Mon, 11 Feb 2019 06:53:30 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id f18so15855511itb.5 for ; Mon, 11 Feb 2019 06:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1SVxKt/+iVX0QIvPz2PUQ1krQxI2IbxuRa+kfx47+mw=; b=G1V2ov9CQ38yNAq5UaqFO1JQA0mT24hlTyOlv8pdNjOK4Q2j/xxpNFfmbUvWbrcxOl 2Fj+mzawNdQ3duFtyRr8oMkDQfBhlY7qKpptG+3Q1PgBldjOEllk3hnvpaISXjf5EPuN eZ8eUs9jZ0w6u0IrTAty9u/hSn5eyFjxZtznkIqHzukXud6FiHKCZO/cYG7K9v3lCCLl kd3oVaGwguWQulmVSKvLF/mLJUhqq6mNKYWXusL/zSDTRsMjWm4Ah3x3opmfq7U2bQHT zdMmaP1RJEuY9NSxgskPcUQtA3TzOja/l+zAQUp39TGnLdSBeTGjNDlaPgMgowud3Tif HvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1SVxKt/+iVX0QIvPz2PUQ1krQxI2IbxuRa+kfx47+mw=; b=H55/ltj9fqqJmoRobRdQtSmuBlHcrED7ECB3gRTfrm8rde/wXWVrWDm3eMVOaZr8bz dWHr+UsIE8jHsSDMGHkptPvS3BR9wGV3u/W/aqhadHsF530S2L76vgen0xSXblVREDWe 0NTdmSy7qnei6zBKVaO+ztfvoDHQ/m7eUa57Cqi7rBq6SaMHqgLNuT7jLW2qUC64gqkX pHVK82nCa9WGnj8Y83SLBK33sQoKBTttZpG/rK7Xw1t7jBDA4YXuDBni3yjnPli6ZQCs wp3eHRVdWW3nmGV6A8kfsQ3weTwNjA/09q5YF9N/DZPgy0lOpWiy90hco/IQiBoZw9Yw tgyw== X-Gm-Message-State: AHQUAubVm6F0926SbL96Zf+vVWOvaz5SHCGM9G/1tF30JCL4GfkBu/wx qn4Egchjjvqrn0yAJXMJRRlIv58C9p/0kIgZ5d756KnX X-Google-Smtp-Source: AHgI3IYuib1y9xX+PR7gwL45/Ym9ZhE6RKw/8oCYCANMVWyAjy1zikuLpCmSlABEU8Ehm7OXupXCz23/nDPHTDnbo7E= X-Received: by 2002:a5d:8489:: with SMTP id t9mr3071076iom.0.1549896809378; Mon, 11 Feb 2019 06:53:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 11 Feb 2019 09:53:18 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c2fa1005819f7870" Archived-At: Subject: Re: [OAUTH-WG] Fixed "OAuth WG Virtual Office Hours" Conference Bridge X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 14:53:32 -0000 --000000000000c2fa1005819f7870 Content-Type: text/plain; charset="UTF-8" All, Unfortunately, Hannes and I cannot attend this meeting today, so we are canceling the meeting for this week. Regards, Rifaat On Wed, Jan 16, 2019 at 10:19 AM Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Rifaat noticed that the distributed Outlook calendar invite was incorrect. > Here is the corrected version. > > Ciao > Hannes > > -----Original Message----- > From: Hannes Tschofenig > Sent: Montag, 14. Januar 2019 18:24 > To: oauth > Subject: Updated "OAuth WG Virtual Office Hours" Conference Bridge > > Hi all, > > Please update your meeting invite for the "OAuth WG Virtual Office Hours" > conference call. > > Ciao > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000c2fa1005819f7870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Unfortunately, Hannes and I cannot= attend this meeting today, so we are canceling the meeting for this week.<= /div>

Regards,
=C2=A0Rifaat


On Wed, Jan 16, 2019 at 10:19 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Rifaat noticed that the= distributed Outlook calendar invite was incorrect.
Here is the corrected version.

Ciao
Hannes

-----Original Message-----
From: Hannes Tschofenig
Sent: Montag, 14. Januar 2019 18:24
To: oauth <oauth@iet= f.org>
Subject: Updated "OAuth WG Virtual Office Hours" Conference Bridg= e

Hi all,

Please update your meeting invite for the "OAuth WG Virtual Office Hou= rs" conference call.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c2fa1005819f7870-- From nobody Mon Feb 11 08:36:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE7131074 for ; Mon, 11 Feb 2019 08:36:41 -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=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nykf7ElVNgO for ; Mon, 11 Feb 2019 08:36:38 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30074.outbound.protection.outlook.com [40.107.3.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD8A12008A for ; Mon, 11 Feb 2019 08:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MI+Bux/3f4td82Aj7s08JibUo72WCSCK3et8noZ69Ko=; b=PeYkFkQu3K8b5FZ5J1oBwnZq1/SlQyU+Sy0JNmb3IsPKyEejvZHhi4QqHPS87B6X9Vl+fjXAtQiee9gpXVQ9W5VDykSlyAbop74MRPSCG5tEQtfdK+0OciR1O2wSjlJfDCEvBVvNOvC/2kNDQ1mGMYxmyNyeke3/fIvIALyYa9s= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1264.eurprd08.prod.outlook.com (10.167.197.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Mon, 11 Feb 2019 16:36:34 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1601.023; Mon, 11 Feb 2019 16:36:34 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: OAuth call today cancelled Thread-Index: AdTCJ6QNK6OfLZrVR7i07k2PTX62Xg== Date: Mon, 11 Feb 2019 16:36:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [130.88.240.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1264; 20:IivlSgHyGnzGd8K+kHdZyAVgREyMjc9jUVRpGU3NhFBBIR7DZT3C4M2qMenZnuoS/aH0us1GjpxfTTCQSxhwsV8gaOGDCSqa8DAiWmp9j06BK9c0WVOywQFnL0zvggd1LGPrnIENFT3eo6jWukNRN3BVzoKiJDKJ9DT84GJ5EQU= x-ms-office365-filtering-correlation-id: ef9c4539-0bf0-4795-2cf8-08d6903f15f2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1264; x-ms-traffictypediagnostic: VI1PR0801MB1264: x-microsoft-antispam-prvs: x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(346002)(376002)(136003)(40434004)(38314003)(53754006)(189003)(199004)(106356001)(2351001)(99286004)(53936002)(105586002)(5640700003)(6506007)(7736002)(6436002)(74316002)(97736004)(55016002)(478600001)(68736007)(316002)(8676002)(1730700003)(4743002)(14444005)(256004)(5024004)(8936002)(86362001)(81156014)(81166006)(33656002)(71200400001)(3846002)(72206003)(26005)(25786009)(790700001)(2906002)(186003)(102836004)(66066001)(71190400001)(6916009)(6116002)(486006)(476003)(54896002)(9686003)(7696005)(6306002)(14454004)(3480700005)(2501003)(4744005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1264; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +iSC53dG9gfw04fCiJzXzIKmRgfuFNWXyhVfDxYKmSj8LI47VKz0Y/nyB/h51n6CBvN+pupXbrnPsSRpeoqniIjk8Fl6V7oL6SNc9UqUZTkDFlOBkXyGQixrbKGBdKiBd1ML96LUgifZqa4/jCa9qUsxbzj7ChwipaLuGxTut6d/ZoGPfTjhtyuybBNsWCo1y3sid9r9iugBjSe1eO8mpx0l8G+qUB6wThg/dB5eEFTUsGNwXN5hwksvbpREgy0pEYmIKdeUoH9ifFwQMhiJ54Jnv5oCjtMrN2jg1g92lEyxI+xpBa+VwE9sHVRJgrMIdK5u/e3ayP9r/DursWnrQ5duJ/5ppHf6aAruBJ4njAmOk1Lj4ue91wa6+hPU4+UucJMVMu4P4633lJr+w0WEmYBKVCVi9FzDNgy0PO+bzos= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112D4D8FE01603984C82769FA640VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef9c4539-0bf0-4795-2cf8-08d6903f15f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 16:36:34.3885 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1264 Archived-At: Subject: [OAUTH-WG] OAuth call today cancelled X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:36:41 -0000 --_000_VI1PR0801MB2112D4D8FE01603984C82769FA640VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Since neither Rifaat nor I are available for the "OAuth WG Virtual Office H= ours" we unfortunately have to cancel the call. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112D4D8FE01603984C82769FA640VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Since neither Rifaat nor I are = available for the “OAuth WG Virtual Office Hours” we unfortunat= ely have to cancel the call.

 

Ciao

Hannes & Rifaat<= /span>

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112D4D8FE01603984C82769FA640VI1PR0801MB2112_-- From nobody Mon Feb 11 22:01:12 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C0112D84D for ; Mon, 11 Feb 2019 22:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG1xnxz4av12 for ; Mon, 11 Feb 2019 22:01:07 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88EA12D861 for ; Mon, 11 Feb 2019 22:01:06 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id b8so1647213qtr.9 for ; Mon, 11 Feb 2019 22:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=znpCzZOQLebhGZDExdZMlmziI7Y54BO7uTcus/N0Ygw=; b=pbM3Mc6uKkk4vRU+elmBMPhVsliqd63W5bl/ifxERln7UwMwv3lDjWW5yL+BP71d+3 +DKS6sI8xAHJf5D++qgPgL0UTgN4O/9TXnwHCPEfH9q2dM6ULnRXuQx+SGknSrSWf+gh vRl5ba6IMsyCU4h1csO38i4SZVuCW5iX5bfxGG3bpHJgtJtgtyGf8cRNMKjYTlJo5lbH BCavmwRmS5JcfkHZLmEwERy58D+obyCkqnr4hl99PGPNdKWfBxu67yC5D3Lec6VUc6jS WHrFpQy5dgFlHXFZV6YHAAqRmHm84SnQOodP3ruvhqgH1ef0u53yto66EkRIF23aA2o7 M/4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=znpCzZOQLebhGZDExdZMlmziI7Y54BO7uTcus/N0Ygw=; b=DZ9HG38zTgL1Mv6Aoeqk8BVSttPS7iefKWueJLfhUCqpU0zq4nrtmOsSL3GqYCnYy7 ELBmEyxUtIhSNV2ExxcN7Iu9AlmnI8NR1RDc/7NdOSCNJyCI3POLgB8mPDXc88RYRJq4 X2417bgv7hBYG+amNPMx030qACFXbTYR1rSRFjs3VKPBIUoVP3PjUM85mMOXEiElH20c r9wwUSrRNAV3yjnMcG1Jz9+s0q+jI1umT/SepyLEbAJ6zzT+Q2U4kP60ZCjEArU/ztk0 EzMYaN0CPisPEHUTyG8Br0QwGB4sJ0f0jamcUdP3aUuz0CDwHp44K9kU5JEz2wMpF2PZ jXCw== X-Gm-Message-State: AHQUAuYePC7hngWowBBVRF0S9IcCkIVAU3F3/CKiY8lLXjdCHyZMHcVw q1EaXJGpiy+XxjZZyl8w9/E9PEOdejTv7weir1DE X-Google-Smtp-Source: AHgI3IYdFvfkVBKkTbeetbjYFa/jDNDkBUqcAdOpsLFKK2EYcco0m4I0dS3QbJLMO9kiiy4ZBvz8rYcwEtOLivb26xg= X-Received: by 2002:a0c:b024:: with SMTP id k33mr1406426qvc.204.1549951265575; Mon, 11 Feb 2019 22:01:05 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 Feb 2019 22:01:04 -0800 From: Dominick Baier In-Reply-To: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> MIME-Version: 1.0 Date: Mon, 11 Feb 2019 22:01:04 -0800 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009ac0e20581ac262b" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 06:01:10 -0000 --0000000000009ac0e20581ac262b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMHO that=E2=80=99s a reasonable and pragmatic option. Thanks =E2=80=94=E2=80=94=E2=80=94 Dominick On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.co= m) wrote: It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So, at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints. A straw-man example might look like this { "issuer":"https://server.example.com", "authorization_endpoint":"https://server.example.com/authz", "token_endpoint":"https://server.example.com/token", "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_client_auth", "none"], "userinfo_endpoint":"https://server.example.com/userinfo", "revocation_endpoint":"https://server.example.com/revo", "jwks_uri":"https://server.example.com/jwks.json", *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token ", "userinfo_endpoint":"https://mtls.example.com/userinfo ", "revocation_endpoint":"https://mtls.example.com/revo " }* } A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints". The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user. I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: > We are currently implementing MTLS in IdentityServer. > > Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. > > Thanks > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS = metadata. We had >> clients in the wild that assumed that all the properties in the JSON obj= ect >> returned from our userinfo endpoint were scalar strings. This broke when= we >> introduced a new property whose value was a JSON object. It was a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can force more work on clients than we expect. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Wednesday, February 6, 2019 at 11:30 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* "Richard Backman, Annabelle" , oauth < >> oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> And I'm honestly really struggling to see what could have gone wrong wit= h >> or how token_endpoint_auth_methods broke something with the user info >> endpoint. If you have the time and/or it'd be informative to this here >> little discussion, please explain that one a bit more. >> >> >> >> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> "far" should have said "fair" in the previous message >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell >> wrote: >> >> It may well be due to my own intellectual shortcomings but these >> issues/questions/confusion-points are not resonating for me as being >> problematic. >> >> >> >> The more general stance of "this isn't needed or worth it in this >> document" (I think that's far?) is being heard though. >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> (TL;DR: punt AS metadata to a separate draft) >> >> AS points #1-3 are all questions I would have as an implementer: >> >> 1. Section 2 of RFC8414 >> says token_endpoint >> =E2=80=9Cis REQUIRED unless only the implicit grant type is supported= .=E2=80=9D So what >> does the mTLS-only AS put here? >> 2. The claims for these other endpoints are OPTIONAL, potentially >> leading to inconsistency depending on how #1 gets decided. >> 3. The example usage of the token_endpoint_auth_methods property >> given earlier is incompatible with RFC8414, since some of its content= s are >> only valid for the non-mTLS endpoints, and others are only valid for = the >> mTLS endpoints. Hence this question. >> 4. This introduces a new metadata property that could impact how >> other specs should extend AS metadata. That needs to be addressed. >> >> >> >> I could go on for client points but you already get the point. Though >> I=E2=80=99ll share that #3 is real and once forced me to roll back an up= date to the >> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >> >> >> >> I don=E2=80=99t necessarily think an AS metadata property is wrong per s= e, but >> understand that you=E2=80=99re bolting a layer of flexibility onto a sta= ndard that >> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata= proposal as it=E2=80=99s >> been discussed here sufficiently deals with the fallout from that. In my >> view this is a complex enough issue and it=E2=80=99s for a nuanced enoug= h use case >> (as far as I can tell from discussion? Please correct me if I=E2=80=99m = wrong) that >> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serv= er Metadata >> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Monday, February 4, 2019 at 5:28 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> Those points of confusion strike me as somewhat hypothetical or >> hyperbolic. But your general point is taken and your position of being a= nti >> additional metadata on this issue is noted. >> >> >> >> All of which leaves me a bit uncertain about how to proceed. There seem >> to be a range of opinions on this point and gauging consensus is proving >> elusive for me. That's confounded by my own opinion on it being somewhat >> fluid. >> >> >> >> And I'd really like to post an update to this draft about a month or two >> ago. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> Confusion from the AS=E2=80=99s perspective: >> >> 1. If I only support mTLS, do I need to include both >> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_u= ri? Or >> set it to the empty string? >> 2. What if I only support mTLS for the token endpoint, but not >> revocation or user info? >> 3. How do I specify authentication methods for the mTLS token >> endpoint? Does token_endpoint_auth_methods apply to both the mTLS and >> non-mTLS endpoints? >> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-e= nabled >> device_authorization_endpoint under mtls_endpoints? >> >> >> >> Confusion from the client=E2=80=99s perspective: >> >> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t k= now anything >> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >> browsers and the AS expects to use that to authenticate me. >> 2. My AS metadata parser crashed because the mTLS-only AS omitted >> token_endpoint_uri. >> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >> encounter a JSON object as a parameter value. >> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints= , what >> do I do? >> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they= told me to use HTTPS, >> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right= ? >> >> >> >> Yes, you can write normative text that answers most of these. But you=E2= =80=99ll >> have to clearly cover a lot of similar-but-slightly-different scenarios = and >> be very explicit. And implementers will still get it wrong. The metadata >> change introduces opportunities for confusion and failure that do not ex= ist >> now, and forces them on everyone who supports mTLS. In contrast, the 307 >> redirect is only required when an AS wants to support both, and is >> unambiguous in its behavior and meaning. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Friday, February 1, 2019 at 3:17 PM >> *To:* "Richard Backman, Annabelle" >> *Cc:* George Fletcher , oauth >> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >> clients using the token endpoint >> >> >> >> It doesn't seem like that confusing or large of a change to me - if the >> client is doing MTLS and the given endpoint is present in `mtls_endpoint= s`, >> then it uses that one. Otherwise it uses the regular endpoint. It gives= an >> AS a lot of flexibility in deployment options. I personally think gettin= g a >> 307 approach deployed and working would be more complicated and error >> prone. >> >> >> >> It is a minority use case at the moment but there are forces in play, >> like the push for increased security in general and to have javascript >> clients use the code flow, that suggest it won't be terribly unusual to = see >> an AS that wants to support MTLS clients and javascript/spa clients at t= he >> same time. >> >> >> >> I've personally wavered back and forth in this thread on whether or not >> to add the new metadata (or something like it). With my reasoning each w= ay >> kinda explained somewhere back in the 40 or so messages that make up thi= s >> thread. But it seems like the rough consensus of the group here is in >> favor of it. >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> This strikes me as a very prominent and confusing change to support what >> seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about >> the text needed to clarify when the AS should provide `mtls_endpoints` a= nd >> when the client should use that versus using `token_endpoint.` Why is th= e >> 307 status code insufficient to cover the case where a single AS support= s >> both mTLS and non-mTLS? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Friday, February 1, 2019 at 1:31 PM >> *To:* George Fletcher > <40aol.com@dmarc.....ietf.org>> >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >> endpoint >> >> >> >> Yes, that would work. >> >> >> >> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> What if the AS wants to ONLY support MTLS connections. Does it not >> specify the optional "mtls_endpoints" and just use the normal metadata >> values? >> >> On 1/15/19 8:48 AM, Brian Campbell wrote: >> >> It would definitely be optional, apologies if that wasn't made clear. >> It'd be something to the effect of optional for the AS to include and >> clients doing MTLS would use it when present in AS metadata. >> >> >> >> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >> wrote: >> >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* ______________________________________________= _ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > * CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --0000000000009ac0e20581ac262b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
IMHO= that=E2=80=99s a reasonable and pragmatic option.

Thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,=C2=A0 at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a = JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"http= s://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz",
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"client_secret_basic","tls_client_auth", "no= ne"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo",
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",
=C2=A0 "jwks_uri":"https://server.example.com/jwks.json",
=C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",
=C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo"
=C2=A0 }
}

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".

The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it.=C2=A0


On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leas= tprivilege.com> wrote:
We are currently implementing MTLS in IdentityServer.

Our approach will be that we=E2=80=99ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D.

Thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingidentity.com@dmarc= .ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..
On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <ri= channa@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99= t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pingidentity.com&= gt;
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org> Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.co= m> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.co= m> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8= 414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discus= sed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on behalf of = Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org> Cc: oauth <oauth@ietf.org&g= t;
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bc= ampbell=3D40pingidenti= ty.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch= @aol.com>, oauth <oauth@ietf.or= g>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on behalf of = Brian Campbell <bcampbell=3D40ping= identity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org&g= t;
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.= ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" an= d just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co= .uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
--0000000000009ac0e20581ac262b-- From nobody Tue Feb 12 07:50:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B92212D827 for ; Tue, 12 Feb 2019 07:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzXI-Wo-DfTH for ; Tue, 12 Feb 2019 07:50:03 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770108.outbound.protection.outlook.com [40.107.77.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C854130EAB for ; Tue, 12 Feb 2019 07:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DDw6jdVbTs9qbnTTjBi152qyvzcbBV+rTW/yoDmayhI=; b=WLXJO0Vu5h5T8v25qTeALKaWnjvSeQRz7oVGjo0GKXqdMbS911boR+/w9C6nfFSKcT/CkseP3slmhVn/sgUWtqFl/SXLTaWwzEWft+9oCUJg0GXZa2w0ZQ3pPG1sJN+GAZVpi0fhNIB3VN6Dr6BG7QJ8uI+CriOKXt5YgTlC9Dc= Received: from BN6PR0101CA0035.prod.exchangelabs.com (2603:10b6:405:2a::48) by SN6PR01MB4990.prod.exchangelabs.com (2603:10b6:805:c8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Tue, 12 Feb 2019 15:49:59 +0000 Received: from BY2NAM03FT020.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::206) by BN6PR0101CA0035.outlook.office365.com (2603:10b6:405:2a::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1601.19 via Frontend Transport; Tue, 12 Feb 2019 15:49:59 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.15) smtp.mailfrom=mit.edu; dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.15 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.15; helo=outgoing-exchange-1.mit.edu; Received: from outgoing-exchange-1.mit.edu (18.9.28.15) by BY2NAM03FT020.mail.protection.outlook.com (10.152.84.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Tue, 12 Feb 2019 15:49:58 +0000 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x1CFnaFe027317; Tue, 12 Feb 2019 10:49:57 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 12 Feb 2019 10:49:26 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 12 Feb 2019 10:49:52 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 12 Feb 2019 10:49:52 -0500 From: Justin Richer To: Brian Campbell CC: Dominick Baier , oauth Thread-Topic: [OAUTH-WG] MTLS token endoint & discovery Thread-Index: AQHUwF+R+S8P+Onl5kOpyXoHXgpqsaXa3QGAgAHLP4A= Date: Tue, 12 Feb 2019 15:49:52 +0000 Message-ID: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_BBFD924FBBB34CF88EDA0BC739C2220Amitedu_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.15; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(136003)(2980300002)(199004)(51444003)(189003)(606006)(7596002)(186003)(83716004)(2906002)(30864003)(93886005)(5070765005)(561944003)(316002)(356004)(26005)(66066001)(71190400001)(33656002)(7736002)(82746002)(4326008)(26826003)(478600001)(36756003)(75432002)(88552002)(6246003)(966005)(66574012)(786003)(426003)(6306002)(236005)(86362001)(336012)(446003)(76176011)(5024004)(106002)(7696005)(54896002)(11346002)(14444005)(126002)(956004)(2616005)(476003)(53946003)(6116002)(3846002)(33964004)(84326002)(486006)(8936002)(106466001)(53546011)(54906003)(36906005)(102836004)(16586007)(229853002)(8676002)(246002)(559001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4990; H:outgoing-exchange-1.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-exchange-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT020; 1:QYLwzwgpB1KzcMTrzbpFNKwgI2WSIwHzWIhu1I4mpcVqQWGIcoLM+4ApLI4IOc565PiDXTwOx7Sw9O45RH9aKO8/LmTV72mL7kD0CnsBMgMEJ/Ui9ZlbIM8jXYS5vFe41unD67kLIy4NQDj40UYe+g== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 09b05025-83da-4c37-8a76-08d69101be0a X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:SN6PR01MB4990; X-MS-TrafficTypeDiagnostic: SN6PR01MB4990: X-MS-Exchange-PUrlCount: 11 X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4990; 20:TUzKT/xlCpG/UT0tPYNKawPt2CDv+RC6j7SYHabQb18mbfTGPmYXzeowR0eNATx8eQDntv+VqpRK3fKwb4rdTXu3IKlEVPj6o+q+qjPWTu06BB4iWOr7AgBbeIbP9sAOqu/1z8dyqVvyvGgGKAqt1pjdnrI0F+QNoI6KWsRFZ5NuTWXmriMpOM6Q4P955GgRz5WGtW6XhY2/B+QDp2AVDaLKl+XjHeHU6DvfBHSxqqMLi31uhH3fXsmOIcu0nfvqew869KXGaHrW6/dkagLZfGO+M2iSZb4dGTJ9zW32JDtMhT/rsM+xz60kXhbYcv+V+0G4WXdtGrzUW9RNmKFzSdGBYl/2fq8Pk9g+dKHQCkCmN54IlPGqx8ki1nHuQ1kpdV0DAGQvGEOEoOAoADLyzuusvxFJ0TK1KjJE6wO/cq5C0/G/ERIAN1Dam5u3liNC1UtJMLdFpkb0YiAbOU3y1jsjnUS151gzTgrws6ebOSBSdIOZKaYRGHvtRobXstBzKbIn02dR/dFJnRxMf43Az29wDmgYI4nRnIUePCGerLdnZcdK0EOvr41FdUCf2p/SL3gHCdBdsAaH4qq9fWQ30o1DRQejOu6B+VHfMGmNnYg= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0946DC87A1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB4990; 23:Kp4A6fJ755oNByXsribOn9KBw3v1KBEsi8IRNh5Wo?= =?us-ascii?Q?lc6xCaJu6PeKqFIVR0lG/et7ma1AwXLdsvUu1P0DRYW7096hv6s41a0YNbkG?= =?us-ascii?Q?Aa/icFbaRaSOohLZS5rPLQiaf+iVl2KraOmTZR6D5ms8bnWVIa3bmV6zYAvp?= =?us-ascii?Q?Cc7KoDRUmO95jYW3ZmU8DbfjnIYUy9DJD2txK53H8dsJzS/Tu60fvJtpTyQo?= =?us-ascii?Q?WExMpEkUC3vxD6r5lGJy2nrxLm0z3DjTTn3XcItLUnghK6ugaha7WsB8TtEO?= =?us-ascii?Q?PgnY/ttQec1V2icFbj/MEi0X/xbO1v2DV2xxouRfAi457PBCCv8g6CLSb3kM?= =?us-ascii?Q?dhJNkdBC8Bmd9GknfWdZQ4u1rhdu6388Q2iEkRsrw3HfxK80vA3naqomHLwo?= =?us-ascii?Q?iIuprAudHguI3G32G12iyypgPbm5iPkdT6sJ96Mr+DC/vUCNfrFssw21rVR8?= =?us-ascii?Q?Gf84HVU5+z3Jh3VVlWOmeoGnhc5usEovI2tu//mkNoptNy1n6XGpF8SAbE+O?= =?us-ascii?Q?VQFcMPxd38zTtbcwRLkyLzxu8EPjfff9I4wuwwW3kCvlFiVzwk4smEy32KX+?= =?us-ascii?Q?5eKl6TPMg/zhTO41PCSZjpnR09gIO6c4EdxWtzk6X4nIgy4//vWybby6j4cj?= =?us-ascii?Q?daO9I2kov/UUY50N4Oyimw+2IrS+LyEfcuv9ktW/9uCnE8QZqXCdzakfd9/Z?= =?us-ascii?Q?3c5imuofaxrXU356NqLImPltwikchp1GnVaOrqEBMj12hJ8PESMQuhWv7THd?= =?us-ascii?Q?4mWOiCnaoIdPFtzs+wLyyetl6TpsGddX5whAWE9BhmYhKxv7NWl0yoc4/KeX?= =?us-ascii?Q?zA0dys7SR7tNJSs9TaK2zlob6j1TWxb7E0kOVDsbvMU8Ew6ts8b9vEDKdJfd?= =?us-ascii?Q?nKF6dW87eijfZm0uY9/PoDN1BqJi+L8UWeYQRA91JhzFgEXmcvJAA8plWmvR?= =?us-ascii?Q?43wcCmkRu2505SZ9qLWITi+YG6d/0FXGJKH/F84oivq3lSH2wrIVzvi3rfKj?= =?us-ascii?Q?6K0iRTGNmmTO4+RuKVQFPOkd+OojpoBwINHNG3wYPeYxGkspU23J8W6MRd4K?= =?us-ascii?Q?Zj6s65Mc0GS/vLYgZgr1jEnyu0JMIIHasHTO/q++dVru5HBD2T14UvETfMUn?= =?us-ascii?Q?nOcn+zcm/SWewJUJBVJf6VDJd3opeWxLqJF53xPyxYWmBfRRmZiFnfZoK8Z+?= =?us-ascii?Q?yYzU1EZcpWxqpJgf7C1v4LWeP2IydQSInxYbUSw6/O5KAEc9+I+nLgbSRw1K?= =?us-ascii?Q?ahkDYZjYYh5Jd0CVOcix6BJYZTsNbiJVGc85o0FZaaBqz1OvQk6PoG7x3NHx?= =?us-ascii?Q?dflWNcXByJDqEIqdGh51/1JUoVcRWIoVmYuMyiyMIezP10L9WrVhQIiNyi61?= =?us-ascii?Q?AvkSLxyd5ZiWV5VMNXpd/qTjRLNVs4YWiEz9tHhhIC6deheoBpr9yDEDwK7V?= =?us-ascii?Q?/uKHXWWWBKbytQhmQjWQwb5PaSGp3aIgaSH/4o6Hy8o+iMx9+03i++VcGpKp?= =?us-ascii?Q?18IDE/kjQhPI2rHqsyFFZbik1VxqQ31KniaW5hRVvUFJvOXIAjXsMQS?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: lMNpVtqdccH3C87PrzIeO56FKYUCclQcTPv/LpfAFiiMl6wlXZJB5I3IoY6KROst/IONaYdDNtjg9V8RnyhwpL0+DEBhUp86IJssKJKX6IqdP+0vzmaUIem450YuMZWI/1xqj2MZ9MfLzbR3ENYU9xzMBsgZ2KlYhxFXNOQVYAwyKtg3vkHsMvmWq88WUivYl+pvmi7J6uZLWLY0KkDRSLE6mDuP6Sf2P7TXP6AFJjKIezZJe2sdrmyJzi4j0R5xzrCGEEE62QhbbiIGR4GDdHtq2Lug+Mlueb2P9iwP0OFg1J/PYXBcjAFhLXqhhrrlbgX1Dy7WApes6twnq14s868JJlLTV+ne/AGH9q3ElRh4OGr6vaagH7EeyuAaIsVHulBPFqxoHMDUgmsHU5FlGLnTyMh+GOlM/HAxUbhlKvI= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2019 15:49:58.3176 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 09b05025-83da-4c37-8a76-08d69101be0a X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.15]; Helo=[outgoing-exchange-1.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4990 Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 15:50:09 -0000 --_000_BBFD924FBBB34CF88EDA0BC739C2220Amitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXQgdGhlIG1vbWVudCwgSSBsaWtlIHRoaXMgc3VnZ2VzdGlvbi4gSXQgZmVlbHMgYSBsaXR0bGUg 4oCmIGZ1bm55IOKApiBidXQgdGhhdCBtaWdodCBiZSBqdXN0IGJlY2F1c2UgaXTigJlzIGRpZmZl cmVudCBmcm9tIHdoYXQgd2UgaGFkIGJlZm9yZS4NCg0KV2XigJlsbCBuZWVkIHRvIGhhdmUgYSBj bGVhciBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzaW9uIGFib3V0IHRoaXMgdGhvdWdo LCBhcyBpdCBkb2VzIGFkZCBhbm90aGVyIHZlY3RvciBmb3IgYSBtaXgtdXAgYXR0YWNrLiBJIGRv dWJ0IHRoYXQgYXQgdGhpcyBzdGFnZSB3ZSB3YW50IHRvIHNheSB0aGF0IHRoZXJlIGhhcyB0byBi ZSBhbnkgdGVzdGFibGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHZhbHVlcyBpbiB0b2tlbl9l bmRwb2ludCBhbmQgbXRsc19lbmRwb2ludHMudG9rZW5fZW5kcG9pbnQsIGJ1dCBzcGxpdHRpbmcg dGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVuZHBvaW50cyBpbiB0aGUgZGlzY292ZXJ5IGRv Y3VtZW50IGlzIGV4YWN0bHkgd2hhdCBsZWFkIHRvIHRoZSBtaXgtdXAgYXR0YWNrIHBhdHRlcm4g aW4gdGhlIGZpcnN0IHBsYWNlLiBFc3NlbnRpYWxseSwgd2hhdCBoYXBwZW5zIHdoZW4gYW4gYXR0 YWNrZXIgY3JhZnRzIGEgZG9jdW1lbnQgdGhhdCBzYXlzIHRoZSBNVExTIHRva2VuIGVuZHBvaW50 IGlzIHRoZWlycyBhbmQgdGhlIHJlZ3VsYXIgdG9rZW4gZW5kcG9pbnQgaXMgbGVnaXQsIG9yIHZp Y2UgdmVyc2E/DQoNCuKAlCBKdXN0aW4NCg0KT24gRmViIDExLCAyMDE5LCBhdCA3OjI2IEFNLCBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9y ZzxtYWlsdG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdy b3RlOg0KDQpJdCdzIGJlZW4gcG9pbnRlZCBvdXQgdGhhdCB0aGUgcG90ZW50aWFsIGlzc3VlIGlz IG5vdCBpc29sYXRlZCB0byB0aGUganVzdCB0b2tlbiBlbmRwb2ludCBidXQgdGhhdCByZXZvY2F0 aW9uLCBpbnRyb3NwZWN0aW9uLCBldGMuIGNvdWxkIGJlIGltcGFjdGVkIGFzIHdlbGwuIFNvLCAg YXQgdGhpcyBwb2ludCwgdGhlIHByb3Bvc2FsIG9uIHRoZSB0YWJsZSBpcyB0byBhZGQgYSBuZXcg b3B0aW9uYWwgQVMgbWV0YWRhdGEgcGFyYW1ldGVyIG5hbWVkICdtdGxzX2VuZHBvaW50cycgdGhh dCdzIHZhbHVlIHdlIGJlIGEgSlNPTiBvYmplY3Qgd2hpY2ggaXRzZWxmIGNvbnRhaW5zIGVuZHBv aW50cyB0aGF0LCB3aGVuIHByZXNlbnQsIGEgY2xpZW50IGRvaW5nIE1UTFMgd291bGQgdXNlIHJh dGhlciB0aGFuIHRoZSByZWd1bGFyIGVuZHBvaW50cy4gIEEgc3RyYXctbWFuIGV4YW1wbGUgbWln aHQgbG9vayBsaWtlIHRoaXMNCg0Kew0KICAiaXNzdWVyIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb208aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vPiIsDQogICJhdXRob3JpemF0aW9uX2Vu ZHBvaW50IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aHoiLA0KICAidG9rZW5fZW5k cG9pbnQiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiIsDQogICJ0b2tlbl9lbmRw b2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIjpbICAiY2xpZW50X3NlY3JldF9iYXNpYyIsInRs c19jbGllbnRfYXV0aCIsICJub25lIl0sDQogICJ1c2VyaW5mb19lbmRwb2ludCI6Imh0dHBzOi8v c2VydmVyLmV4YW1wbGUuY29tL3VzZXJpbmZvIiwNCiAgInJldm9jYXRpb25fZW5kcG9pbnQiOiJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZXZvIiwNCiAgImp3a3NfdXJpIjoiaHR0cHM6Ly9z ZXJ2ZXIuZXhhbXBsZS5jb20vandrcy5qc29uIiwNCiAgIm10bHNfZW5kcG9pbnRzIjp7DQogICAg InRva2VuX2VuZHBvaW50IjoiaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICAi dXNlcmluZm9fZW5kcG9pbnQiOiJodHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm8iLA0K ICAgICJyZXZvY2F0aW9uX2VuZHBvaW50IjoiaHR0cHM6Ly9tdGxzLmV4YW1wbGUuLmNvbS9yZXZv PGh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS9yZXZvPiINCiAgfQ0KfQ0KDQpBIGNsaWVudCBkb2lu ZyBNVExTIHdvdWxkIGxvb2sgZm9yIGFuZCBnaXZlIHByZWNlZGVuY2UgdG8gYW4gZW5kcG9pbnQg dW5kZXIgIm10bHNfZW5kcG9pbnRzIiB3aGlsZSBmYWxsaW5nIGJhY2sgdG8gdXNlIHRoZSBub3Jt YWwgZW5kcG9pbnQgZnJvbSB0aGUgdG9wIGxldmVsIG9mIG1ldGFkYXRhIHdoZW4vaWYgaXRzIG5v dCBpbiAibXRsc19lbmRwb2ludHMiLg0KDQpUaGUgaWRlYSBiZWluZyB0aGF0ICJyZWd1bGFyIiBj bGllbnRzICh0aG9zZSBub3QgZG9pbmcgTVRMUykgd2lsbCB1c2UgdGhlIHJlZ3VsYXIgZW5kcG9p bnRzLiBBbmQgb25seSB0aGUgaG9zdC9wb3J0IG9mIHRoZSBlbmRwb2ludHMgbGlzdGVkIGluIG10 bHNfZW5kcG9pbnRzIHdpbGwgYmUgc2V0IHVwIHRvIHJlcXVlc3QgVExTIGNsaWVudCBjZXJ0aWZp Y2F0ZXMgZHVyaW5nIGhhbmRzaGFrZS4gVGh1cyBhbnkgcG90ZW50aWFsIGltcGFjdCBvZiB0aGUg Q2VydGlmaWNhdGVSZXF1ZXN0IG1lc3NhZ2UgYmVpbmcgc2VudCBpbiB0aGUgVExTIGhhbmRzaGFr ZSBjYW4gYmUgYXZvaWRlZCBmb3IgYWxsIHRoZSBvdGhlciByZWd1bGFyIGNsaWVudHMgdGhhdCBh cmUgbm90IGdvaW5nIHRvIGRvIE1UTFMgLSBpbmNsdWRpbmcgYW5kIG1vc3QgaW1wb3J0YW50bHkg aW4tYnJvd3NlciBqYXZhc2NyaXB0IGNsaWVudHMgd2hlcmUgdGhlcmUgY2FuIGJlIGxlc3MgdGhh biBkZXNpcmFibGUgVUkgcHJlc2VudGVkIHRvIHRoZSBlbmQtdXNlci4NCg0KSSdtIHN0cnVnZ2xp bmcsIGhvd2V2ZXIsIHRvIGFkZXF1YXRlbHkgZ2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUncyBz dWZmaWNpZW50IGNvbnNlbnN1cyB0byBnbyBhaGVhZCB3aXRoIHRoZSB1cGRhdGUuIFRoZXJlJ3Mg YmVlbiBzb21lIHN1cHBvcnQgZm9yIGl0IHZvaWNlZC4gQXMgd2VsbCBhcyB0YWxrIG9mIG90aGVy IGFwcHJvYWNoZXMgdGhhdCBjb3VsZCBiZSBhbHRlcm5hdGl2ZXMgb3IgYWRkaXRpb25hbCBtZWFz dXJlcy4gQW5kIGFsc28gc29tZSB2b2NhbCBvcHBvc2l0aW9uIHRvIGl0Lg0KDQoNCk9uIFNhdCwg RmViIDksIDIwMTkgYXQgMzowOSBBTSBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmls ZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+IHdyb3RlOg0KV2UgYXJl IGN1cnJlbnRseSBpbXBsZW1lbnRpbmcgTVRMUyBpbiBJZGVudGl0eVNlcnZlci4NCg0KT3VyIGFw cHJvYWNoIHdpbGwgYmUgdGhhdCB3ZeKAmWxsIG9mZmVyIGEgc2VwYXJhdGUgdG9rZW4gZW5kcG9p bnQgdGhhdCBzdXBwb3J0cyBjbGllbnQgY2VydHMuIEFyZSB5b3UgcGxhbm5pbmcgb24gYWRkaW5n IGFuIG9mZmljaWFsIGVuZHBvaW50IG5hbWUgZm9yIGRpc2NvdmVyeT8gUmlnaHQgbm93IHdlIGFy ZSB1c2luZyDigJxtdGxzX3Rva2VuX2VuZHBvaW504oCdLg0KDQpUaGFua3MNCuKAlOKAlOKAlA0K RG9taW5pY2sNCg0KDQpPbiA3LiBGZWJydWFyeSAyMDE5IGF0IDIyOjM2OjU1LCBCcmlhbiBDYW1w YmVsbCAoYmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KDQpB aCB5ZXMsIHRoYXQgbWFrZXMgc2Vuc2UuIFRoYW5rcyBmb3IgY2xhcmlmeWluZy4gQW5kIGl0IGlz IGluZGVlZCBhIGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBj aGFuZ2UgdGhhdCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGJyZWFrIHRoaW5n cyB1bmV4cGVjdGVkbHkuLg0KDQoNCg0KDQoNCk9uIFRodSwgRmViIDcsIDIwMTkgYXQgODo1NyBB TSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KVGhlIGNhc2UgSeKAmW0gcmVmZXJlbmNpbmcg ZGlkbuKAmXQgc3BlY2lmaWNhbGx5IGludm9sdmUgQVMgbWV0YWRhdGEuIFdlIGhhZCBjbGllbnRz IGluIHRoZSB3aWxkIHRoYXQgYXNzdW1lZCB0aGF0IGFsbCB0aGUgcHJvcGVydGllcyBpbiB0aGUg SlNPTiBvYmplY3QgcmV0dXJuZWQgZnJvbSBvdXIgdXNlcmluZm8gZW5kcG9pbnQgd2VyZSBzY2Fs YXIgc3RyaW5ncy4gVGhpcyBicm9rZSB3aGVuIHdlIGludHJvZHVjZWQgYSBuZXcgcHJvcGVydHkg d2hvc2UgdmFsdWUgd2FzIGEgSlNPTiBvYmplY3QuIEl0IHdhcyBhIGdvb2QgcmVtaW5kZXIgdGhh dCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBjaGFuZ2UgdGhhdCBzaG91bGQgYmUgYmFja3dh cmRzIGNvbXBhdGlibGUgY2FuIGZvcmNlIG1vcmUgd29yayBvbiBjbGllbnRzIHRoYW4gd2UgZXhw ZWN0Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0K RnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDYs IDIwMTkgYXQgMTE6MzAgQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNo YW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZz4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFA YW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtV TlZFUklGSUVEIFNFTkRFUl0gUmU6IE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0 aGUgdG9rZW4gZW5kcG9pbnQNCg0KQW5kIEknbSBob25lc3RseSByZWFsbHkgc3RydWdnbGluZyB0 byBzZWUgd2hhdCBjb3VsZCBoYXZlIGdvbmUgd3Jvbmcgd2l0aCBvciBob3cgdG9rZW5fZW5kcG9p bnRfYXV0aF9tZXRob2RzIGJyb2tlIHNvbWV0aGluZyB3aXRoIHRoZSB1c2VyIGluZm8gZW5kcG9p bnQuIElmIHlvdSBoYXZlIHRoZSB0aW1lIGFuZC9vciBpdCdkIGJlIGluZm9ybWF0aXZlIHRvIHRo aXMgaGVyZSBsaXR0bGUgZGlzY3Vzc2lvbiwgcGxlYXNlIGV4cGxhaW4gdGhhdCBvbmUgYSBiaXQg bW9yZS4NCg0KT24gV2VkLCBGZWIgNiwgMjAxOSBhdCAxMjoxNSBQTSBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPj4gd3JvdGU6DQoiZmFyIiBzaG91bGQgaGF2ZSBzYWlkICJmYWlyIiBpbiB0aGUgcHJldmlv dXMgbWVzc2FnZQ0KDQoNCg0KDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgNDozNSBQTSBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpJdCBtYXkgd2VsbCBiZSBkdWUgdG8gbXkgb3duIGlu dGVsbGVjdHVhbCBzaG9ydGNvbWluZ3MgYnV0IHRoZXNlIGlzc3Vlcy9xdWVzdGlvbnMvY29uZnVz aW9uLXBvaW50cyBhcmUgbm90IHJlc29uYXRpbmcgZm9yIG1lIGFzIGJlaW5nIHByb2JsZW1hdGlj Lg0KDQpUaGUgbW9yZSBnZW5lcmFsIHN0YW5jZSBvZiAidGhpcyBpc24ndCBuZWVkZWQgb3Igd29y dGggaXQgaW4gdGhpcyBkb2N1bWVudCIgKEkgdGhpbmsgdGhhdCdzIGZhcj8pIGlzIGJlaW5nIGhl YXJkIHRob3VnaC4NCg0KDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgMTo0MiBQTSBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLm9yZz4+IHdyb3RlOg0KKFRMO0RSOiBw dW50IEFTIG1ldGFkYXRhIHRvIGEgc2VwYXJhdGUgZHJhZnQpDQoNCkFTIHBvaW50cyAjMS0zIGFy ZSBhbGwgcXVlc3Rpb25zIEkgd291bGQgaGF2ZSBhcyBhbiBpbXBsZW1lbnRlcjoNCg0KICAxLiAg U2VjdGlvbiAyIG9mIFJGQzg0MTQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MTQj c2VjdGlvbi0yPiBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBvbmx5 IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hhdCBkb2VzIHRo ZSBtVExTLW9ubHkgQVMgcHV0IGhlcmU/DQogIDIuICBUaGUgY2xhaW1zIGZvciB0aGVzZSBvdGhl ciBlbmRwb2ludHMgYXJlIE9QVElPTkFMLCBwb3RlbnRpYWxseSBsZWFkaW5nIHRvIGluY29uc2lz dGVuY3kgZGVwZW5kaW5nIG9uIGhvdyAjMSBnZXRzIGRlY2lkZWQuDQogIDMuICBUaGUgZXhhbXBs ZSB1c2FnZSBvZiB0aGUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIHByb3BlcnR5IGdpdmVu IGVhcmxpZXIgaXMgaW5jb21wYXRpYmxlIHdpdGggUkZDODQxNCwgc2luY2Ugc29tZSBvZiBpdHMg Y29udGVudHMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBub24tbVRMUyBlbmRwb2ludHMsIGFuZCBv dGhlcnMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBtVExTIGVuZHBvaW50cy4gSGVuY2UgdGhpcyBx dWVzdGlvbi4NCiAgNC4gIFRoaXMgaW50cm9kdWNlcyBhIG5ldyBtZXRhZGF0YSBwcm9wZXJ0eSB0 aGF0IGNvdWxkIGltcGFjdCBob3cgb3RoZXIgc3BlY3Mgc2hvdWxkIGV4dGVuZCBBUyBtZXRhZGF0 YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQuDQoNCg0KSSBjb3VsZCBnbyBvbiBmb3IgY2xp ZW50IHBvaW50cyBidXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdoIEnigJlsbCBz aGFyZSB0aGF0ICMzIGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwgYmFjayBhbiB1 cGRhdGUgdG8gdGhlIExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW504oCmZ29vZCB0 aW1lcy4g8J+Ygw0KDQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEg cHJvcGVydHkgaXMgd3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJv bHRpbmcgYSBsYXllciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZ dCBkZXNpZ25lZCBmb3IgdGhhdCwgYW5kIEkgZG9u4oCZdCB0aGluayB0aGUgbWV0YWRhdGEgcHJv cG9zYWwgYXMgaXTigJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc3VmZmljaWVudGx5IGRlYWxzIHdp dGggdGhlIGZhbGxvdXQgZnJvbSB0aGF0LiBJbiBteSB2aWV3IHRoaXMgaXMgYSBjb21wbGV4IGVu b3VnaCBpc3N1ZSBhbmQgaXTigJlzIGZvciBhIG51YW5jZWQgZW5vdWdoIHVzZSBjYXNlIChhcyBm YXIgYXMgSSBjYW4gdGVsbCBmcm9tIGRpc2N1c3Npb24/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEni gJltIHdyb25nKSB0aGF0IHdlIHNob3VsZCBwdW50IGl0IHRvIGEgc2VwYXJhdGUgZHJhZnQgKGUu Zy4sIOKAnEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIEV4dGVuc2lvbnMgZm9yIG1UTFMg SHlicmlkc+KAnSkgYW5kIGdldCBtVExTIG91dCB0aGUgZG9vci4NCg0KLS0NCkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogTW9u ZGF5LCBGZWJydWFyeSA0LCAyMDE5IGF0IDU6MjggQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUiIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklF RCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2Vu IGVuZHBvaW50DQoNClRob3NlIHBvaW50cyBvZiBjb25mdXNpb24gc3RyaWtlIG1lIGFzIHNvbWV3 aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlz IHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFudGkgYWRkaXRpb25hbCBtZXRhZGF0 YSBvbiB0aGlzIGlzc3VlIGlzIG5vdGVkLg0KDQpBbGwgb2Ygd2hpY2ggbGVhdmVzIG1lIGEgYml0 IHVuY2VydGFpbiBhYm91dCBob3cgdG8gcHJvY2VlZC4gVGhlcmUgc2VlbSB0byBiZSBhIHJhbmdl IG9mIG9waW5pb25zIG9uIHRoaXMgcG9pbnQgYW5kIGdhdWdpbmcgY29uc2Vuc3VzIGlzIHByb3Zp bmcgZWx1c2l2ZSBmb3IgbWUuIFRoYXQncyBjb25mb3VuZGVkIGJ5IG15IG93biBvcGluaW9uIG9u IGl0IGJlaW5nIHNvbWV3aGF0IGZsdWlkLg0KDQpBbmQgSSdkIHJlYWxseSBsaWtlIHRvIHBvc3Qg YW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYWJvdXQgYSBtb250aCBvciB0d28gYWdvLg0KDQoNCg0K DQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCA1OjAzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLi4ub3JnPj4gd3JvdGU6DQpDb25mdXNpb24gZnJvbSB0aGUgQVPi gJlzIHBlcnNwZWN0aXZlOg0KDQogIDEuICBJZiBJIG9ubHkgc3VwcG9ydCBtVExTLCBkbyBJIG5l ZWQgdG8gaW5jbHVkZSBib3RoIHRva2VuX2VuZHBvaW50X3VyaSBhbmQgbXRsc19lbmRwb2ludHM/ IFNob3VsZCBJIG9taXQgdG9rZW5fZW5kcG9pbnRfdXJpPyBPciBzZXQgaXQgdG8gdGhlIGVtcHR5 IHN0cmluZz8NCiAgMi4gIFdoYXQgaWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3IgdGhlIHRva2Vu IGVuZHBvaW50LCBidXQgbm90IHJldm9jYXRpb24gb3IgdXNlciBpbmZvPw0KICAzLiAgSG93IGRv IEkgc3BlY2lmeSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGZvciB0aGUgbVRMUyB0b2tlbiBlbmRw b2ludD8gRG9lcyB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYXBwbHkgdG8gYm90aCB0aGUg bVRMUyBhbmQgbm9uLW1UTFMgZW5kcG9pbnRzPw0KICA0LiAgSeKAmW0gdXNpbmcgdGhlIE9BdXRo IDIuMCBEZXZpY2UgRmxvdy4gRG8gSSBpbmNsdWRlIGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRo b3JpemF0aW9uX2VuZHBvaW50IHVuZGVyIG10bHNfZW5kcG9pbnRzPw0KDQoNCkNvbmZ1c2lvbiBm cm9tIHRoZSBjbGllbnTigJlzIHBlcnNwZWN0aXZlOg0KDQogIDEuICBBcyBmYXIgYXMgSSBrbm93 LCBJ4oCZbSBhIHB1YmxpYyBjbGllbnQsIGFuZCBkb27igJl0IGtub3cgYW55dGhpbmcgYWJvdXQg bVRMUywgYnV0IHRoZSBJVCBhZG1pbnMgaW5zdGFsbGVkIGNsaWVudCBjZXJ0cyBpbiB0aGVpciB1 c2Vyc+KAmSBicm93c2VycyBhbmQgdGhlIEFTIGV4cGVjdHMgdG8gdXNlIHRoYXQgdG8gYXV0aGVu dGljYXRlIG1lLg0KICAyLiAgTXkgQVMgbWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVjYXVzZSB0 aGUgbVRMUy1vbmx5IEFTIG9taXR0ZWQgdG9rZW5fZW5kcG9pbnRfdXJpLg0KICAzLiAgTXkgQVMg bWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVjYXVzZSBpdCBkaWRu4oCZdCBleHBlY3QgdG8gZW5j b3VudGVyIGEgSlNPTiBvYmplY3QgYXMgYSBwYXJhbWV0ZXIgdmFsdWUuDQogIDQuICBUaGUgbVRM Uy1vbmx5IEFTIGRpZG7igJl0IHByb3ZpZGUgYSB2YWx1ZSBmb3IgbXRsc19lbmRwb2ludHMsIHdo YXQgZG8gSSBkbz8NCiAgNS4gIEkgZG9u4oCZdCBrbm93IHdoYXQgdGhhdCDigJxt4oCdIG1lYW5z LCBidXQgdGhleSB0b2xkIG1lIHRvIHVzZSBIVFRQUywgc28gSSBzaG91bGQgdXNlIHRoZSBvbmUg d2l0aCDigJx0bHPigJ0gaW4gaXRzIG5hbWUsIHJpZ2h0Pw0KDQoNClllcywgeW91IGNhbiB3cml0 ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4gQnV0IHlvdeKAmWxs IGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1zbGlnaHRseS1kaWZm ZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1wbGVtZW50ZXJzIHdp bGwgc3RpbGwgZ2V0IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hhbmdlIGludHJvZHVjZXMgb3Bw b3J0dW5pdGllcyBmb3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRoYXQgZG8gbm90IGV4aXN0IG5v dywgYW5kIGZvcmNlcyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBwb3J0cyBtVExTLiBJbiBjb250 cmFzdCwgdGhlIDMwNyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYW4gQVMgd2FudHMg dG8gc3VwcG9ydCBib3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMgaW4gaXRzIGJlaGF2aW9yIGFuZCBt ZWFuaW5nLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoN Cg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpE YXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQTQ0KVG86ICJSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFt YXpvbi5jb20+Pg0KQ2M6IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86 Z2ZmbGV0Y2hAYW9sLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll dGYub3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gTVRM UyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpJdCBk b2Vzbid0IHNlZW0gbGlrZSB0aGF0IGNvbmZ1c2luZyBvciBsYXJnZSBvZiBhIGNoYW5nZSB0byBt ZSAtIGlmIHRoZSBjbGllbnQgaXMgZG9pbmcgTVRMUyBhbmQgdGhlIGdpdmVuIGVuZHBvaW50IGlz IHByZXNlbnQgaW4gYG10bHNfZW5kcG9pbnRzYCwgdGhlbiBpdCB1c2VzIHRoYXQgb25lLiAgT3Ro ZXJ3aXNlIGl0IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9pbnQuIEl0IGdpdmVzIGFuIEFTIGEgbG90 IG9mIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQgb3B0aW9ucy4gSSBwZXJzb25hbGx5IHRoaW5r IGdldHRpbmcgYSAzMDcgYXBwcm9hY2ggZGVwbG95ZWQgYW5kIHdvcmtpbmcgd291bGQgYmUgbW9y ZSBjb21wbGljYXRlZCBhbmQgZXJyb3IgcHJvbmUuDQoNCkl0IGlzIGEgbWlub3JpdHkgdXNlIGNh c2UgYXQgdGhlIG1vbWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBsaWtlIHRoZSBw dXNoIGZvciBpbmNyZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2ZSBqYXZhc2Ny aXB0IGNsaWVudHMgdXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdCBpdCB3b24ndCBiZSB0 ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBj bGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuDQoNCkkn dmUgcGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhyZWFkIG9uIHdo ZXRoZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhpbmcgbGlrZSBp dCkuIFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBzb21ld2hlcmUg YmFjayBpbiB0aGUgNDAgb3Igc28gbWVzc2FnZXMgdGhhdCBtYWtlIHVwIHRoaXMgdGhyZWFkLiAg QnV0IGl0IHNlZW1zIGxpa2UgdGhlIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgZ3JvdXAgaGVyZSBp cyBpbiBmYXZvciBvZiBpdC4NCg0KDQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCAzOjE4IFBN IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4ub3JnPj4gd3JvdGU6DQpU aGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVzaW5nIGNoYW5nZSB0 byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2FzZS4gSeKAmW0gZ2V0 dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQgbmVlZGVkIHRvIGNs YXJpZnkgd2hlbiB0aGUgQVMgc2hvdWxkIHByb3ZpZGUgYG10bHNfZW5kcG9pbnRzYCBhbmQgd2hl biB0aGUgY2xpZW50IHNob3VsZCB1c2UgdGhhdCB2ZXJzdXMgdXNpbmcgYHRva2VuX2VuZHBvaW50 LmAgV2h5IGlzIHRoZSAzMDcgc3RhdHVzIGNvZGUgaW5zdWZmaWNpZW50IHRvIGNvdmVyIHRoZSBj YXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIGJvdGggbVRMUyBhbmQgbm9uLW1UTFM/DQoN Ci0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBP QXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBNDQpUbzogR2Vv cmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw YW9sLmNvbUBkbWFyYy4uLi4uLmlldGYub3JnPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1UTFMgYW5k IGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQNCg0KWWVzLCB0aGF0 IHdvdWxkIHdvcmsuDQoNCk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBHZW9yZ2UgRmxl dGNoZXIgPGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhb2wuY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpXaGF0IGlmIHRoZSBBUyB3YW50cyB0byBPTkxZIHN1 cHBvcnQgTVRMUyBjb25uZWN0aW9ucy4gRG9lcyBpdCBub3Qgc3BlY2lmeSB0aGUgb3B0aW9uYWwg Im10bHNfZW5kcG9pbnRzIiBhbmQganVzdCB1c2UgdGhlIG5vcm1hbCBtZXRhZGF0YSB2YWx1ZXM/ DQpPbiAxLzE1LzE5IDg6NDggQU0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOg0KSXQgd291bGQgZGVm aW5pdGVseSBiZSBvcHRpb25hbCwgYXBvbG9naWVzIGlmIHRoYXQgd2Fzbid0IG1hZGUgY2xlYXIu IEl0J2QgYmUgc29tZXRoaW5nIHRvIHRoZSBlZmZlY3Qgb2Ygb3B0aW9uYWwgZm9yIHRoZSBBUyB0 byBpbmNsdWRlIGFuZCBjbGllbnRzIGRvaW5nIE1UTFMgd291bGQgdXNlIGl0IHdoZW4gcHJlc2Vu dCBpbiBBUyBtZXRhZGF0YS4NCg0KT24gVHVlLCBKYW4gMTUsIDIwMTkgYXQgMjowNCBBTSBEYXZl IFRvbmdlIDxkYXZlLnRvbmdlQG1vbWVudHVtZnQuY28udWs8bWFpbHRvOmRhdmUudG9uZ2VAbW9t ZW50dW1mdC5jby51az4+IHdyb3RlOg0KSSdtIGluIGZhdm91ciBvZiB0aGUgYG10bHNfZW5kcG9p bnRzYCBtZXRhZGF0YSBwYXJhbWV0ZXIgLSBhbHRob3VnaCBpdCBzaG91bGQgYmUgb3B0aW9uYWwu DQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlz Y2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxp bmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNF OiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRl cmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9u IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWls IGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91 ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAg SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg eW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9y IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg YW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNP TkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUg YXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBl bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0 ZXIuIFRoYW5rIHlvdS5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_BBFD924FBBB34CF88EDA0BC739C2220Amitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <511F581137632D468A30884B5E464394@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkF0IHRoZSBtb21lbnQsIEkgbGlrZSB0aGlzIHN1 Z2dlc3Rpb24uIEl0IGZlZWxzIGEgbGl0dGxlIOKApiBmdW5ueSDigKYgYnV0IHRoYXQgbWlnaHQg YmUganVzdCBiZWNhdXNlIGl04oCZcyBkaWZmZXJlbnQgZnJvbSB3aGF0IHdlIGhhZCBiZWZvcmUu DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZeKA mWxsIG5lZWQgdG8gaGF2ZSBhIGNsZWFyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3Np b24gYWJvdXQgdGhpcyB0aG91Z2gsIGFzIGl0IGRvZXMgYWRkIGFub3RoZXIgdmVjdG9yIGZvciBh IG1peC11cCBhdHRhY2suIEkgZG91YnQgdGhhdCBhdCB0aGlzIHN0YWdlIHdlIHdhbnQgdG8gc2F5 IHRoYXQgdGhlcmUgaGFzIHRvIGJlIGFueSB0ZXN0YWJsZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGUgdmFsdWVzIGluDQogdG9rZW5fZW5kcG9pbnQgYW5kIG10bHNfZW5kcG9pbnRzLnRva2VuX2Vu ZHBvaW50LCBidXQgc3BsaXR0aW5nIHRoZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2lu dHMgaW4gdGhlIGRpc2NvdmVyeSBkb2N1bWVudCBpcyBleGFjdGx5IHdoYXQgbGVhZCB0byB0aGUg bWl4LXVwIGF0dGFjayBwYXR0ZXJuIGluIHRoZSBmaXJzdCBwbGFjZS4gRXNzZW50aWFsbHksIHdo YXQgaGFwcGVucyB3aGVuIGFuIGF0dGFja2VyIGNyYWZ0cyBhIGRvY3VtZW50DQogdGhhdCBzYXlz IHRoZSBNVExTIHRva2VuIGVuZHBvaW50IGlzIHRoZWlycyBhbmQgdGhlIHJlZ3VsYXIgdG9rZW4g ZW5kcG9pbnQgaXMgbGVnaXQsIG9yIHZpY2UgdmVyc2E/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K 4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIgMTEsIDIwMTksIGF0 IDc6MjYgQU0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsPTQw cGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgY2xhc3M9IiI+YmNhbXBiZWxsPTQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNs YXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRp cj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SXQncyBiZWVuIHBvaW50ZWQg b3V0IHRoYXQgdGhlIHBvdGVudGlhbCBpc3N1ZSBpcyBub3QgaXNvbGF0ZWQgdG8gdGhlIGp1c3Qg dG9rZW4gZW5kcG9pbnQgYnV0IHRoYXQgcmV2b2NhdGlvbiwgaW50cm9zcGVjdGlvbiwgZXRjLiBj b3VsZCBiZSBpbXBhY3RlZCBhcyB3ZWxsLiBTbywmbmJzcDsgYXQgdGhpcyBwb2ludCwgdGhlIHBy b3Bvc2FsIG9uIHRoZSB0YWJsZSBpcyB0byBhZGQgYSBuZXcgb3B0aW9uYWwgQVMgbWV0YWRhdGEN CiBwYXJhbWV0ZXIgbmFtZWQgJ210bHNfZW5kcG9pbnRzJyB0aGF0J3MgdmFsdWUgd2UgYmUgYSBK U09OIG9iamVjdCB3aGljaCBpdHNlbGYgY29udGFpbnMgZW5kcG9pbnRzIHRoYXQsIHdoZW4gcHJl c2VudCwgYSBjbGllbnQgZG9pbmcgTVRMUyB3b3VsZCB1c2UgcmF0aGVyIHRoYW4gdGhlIHJlZ3Vs YXIgZW5kcG9pbnRzLiZuYnNwOyBBIHN0cmF3LW1hbiBleGFtcGxlIG1pZ2h0IGxvb2sgbGlrZSB0 aGlzPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSIiPns8YnIgY2xhc3M9 IiI+DQombmJzcDsgJnF1b3Q7aXNzdWVyJnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2Vy dmVyLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vc2VydmVy LmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsgJnF1b3Q7YXV0aG9y aXphdGlvbl9lbmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFt cGxlLmNvbS9hdXRoeiIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vc2VydmVyLmV4 YW1wbGUuY29tL2F1dGh6PC9hPiZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsgJnF1b3Q7dG9r ZW5fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5j b20vdG9rZW4iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3NlcnZlci5leGFtcGxl LmNvbS90b2tlbjwvYT4mcXVvdDssPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZxdW90O3Rva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQmcXVvdDs6WyAmbmJzcDsmcXVvdDtjbGllbnRf c2VjcmV0X2Jhc2ljJnF1b3Q7LCZxdW90O3Rsc19jbGllbnRfYXV0aCZxdW90OywgJnF1b3Q7bm9u ZSZxdW90O10sPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZxdW90O3VzZXJpbmZvX2VuZHBvaW50JnF1 b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3VzZXJpbmZvIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdXNlcmlu Zm88L2E+JnF1b3Q7LDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmcXVvdDtyZXZvY2F0aW9uX2VuZHBv aW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Jldm8i IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZXZv PC9hPiZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsgJnF1b3Q7andrc191cmkmcXVvdDs6JnF1 b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vandrcy5qc29uIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vandrcy5qc29uPC9h PiZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDs8YiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7bXRsc19lbmRwb2ludHMmcXVv dDs6ezxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnQmcXVv dDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rva2VuIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rva2VuPC9hPiZxdW90 Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZxdW90O3VzZXJpbmZvX2VuZHBvaW50JnF1 b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS91c2VyaW5mbyIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS91c2VyaW5mbzwv YT4mcXVvdDssPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmcXVvdDtyZXZvY2F0aW9uX2Vu ZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS9yZXZv IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly9tdGxzLmV4YW1wbGUuLmNvbS9yZXZv PC9hPiZxdW90OzxiciBjbGFzcz0iIj4NCiZuYnNwOyB9PC9iPjxiciBjbGFzcz0iIj4NCn08YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BIGNsaWVudCBkb2luZyBNVExT IHdvdWxkIGxvb2sgZm9yIGFuZCBnaXZlIHByZWNlZGVuY2UgdG8gYW4gZW5kcG9pbnQgdW5kZXIg JnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgd2hpbGUgZmFsbGluZyBiYWNrIHRvIHVzZSB0aGUg bm9ybWFsIGVuZHBvaW50IGZyb20gdGhlIHRvcCBsZXZlbCBvZiBtZXRhZGF0YSB3aGVuL2lmIGl0 cyBub3QgaW4gJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsuPC9kaXY+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGUgaWRlYSBiZWluZyB0aGF0ICZxdW90O3JlZ3Vs YXImcXVvdDsgY2xpZW50cyAodGhvc2Ugbm90IGRvaW5nIE1UTFMpIHdpbGwgdXNlIHRoZSByZWd1 bGFyIGVuZHBvaW50cy4gQW5kIG9ubHkgdGhlIGhvc3QvcG9ydCBvZiB0aGUgZW5kcG9pbnRzIGxp c3RlZCBpbiBtdGxzX2VuZHBvaW50cyB3aWxsIGJlIHNldCB1cCB0byByZXF1ZXN0IFRMUyBjbGll bnQgY2VydGlmaWNhdGVzIGR1cmluZyBoYW5kc2hha2UuIFRodXMgYW55IHBvdGVudGlhbCBpbXBh Y3Qgb2YgdGhlDQogQ2VydGlmaWNhdGVSZXF1ZXN0IG1lc3NhZ2UgYmVpbmcgc2VudCBpbiB0aGUg VExTIGhhbmRzaGFrZSBjYW4gYmUgYXZvaWRlZCBmb3IgYWxsIHRoZSBvdGhlciByZWd1bGFyIGNs aWVudHMgdGhhdCBhcmUgbm90IGdvaW5nIHRvIGRvIE1UTFMgLSBpbmNsdWRpbmcgYW5kIG1vc3Qg aW1wb3J0YW50bHkgaW4tYnJvd3NlciBqYXZhc2NyaXB0IGNsaWVudHMgd2hlcmUgdGhlcmUgY2Fu IGJlIGxlc3MgdGhhbiBkZXNpcmFibGUgVUkgcHJlc2VudGVkIHRvDQogdGhlIGVuZC11c2VyLjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkknbSBzdHJ1Z2dsaW5nLCBob3dldmVyLCB0byBhZGVxdWF0ZWx5IGdhdWdlIHdo ZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0 aCB0aGUgdXBkYXRlLiBUaGVyZSdzIGJlZW4gc29tZSBzdXBwb3J0IGZvciBpdCB2b2ljZWQuIEFz IHdlbGwgYXMgdGFsayBvZiBvdGhlciBhcHByb2FjaGVzIHRoYXQgY291bGQgYmUgYWx0ZXJuYXRp dmVzIG9yIGFkZGl0aW9uYWwgbWVhc3VyZXMuDQogQW5kIGFsc28gc29tZSB2b2NhbCBvcHBvc2l0 aW9uIHRvIGl0LiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5P biBTYXQsIEZlYiA5LCAyMDE5IGF0IDM6MDkgQU0gRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9 IiI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAw cHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5 bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5n LWxlZnQ6IDFleDsiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2EsIEFyaWFsOyBmb250LXNpemU6IDEzcHg7IiBjbGFzcz0iIj5XZSBhcmUgY3VycmVu dGx5IGltcGxlbWVudGluZyBNVExTIGluIElkZW50aXR5U2VydmVyLjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYSwgQXJpYWw7IGZvbnQtc2l6ZTogMTNweDsiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYSwgQXJpYWw7IGZvbnQtc2l6ZTogMTNweDsiIGNsYXNzPSIiPk91ciBhcHByb2FjaCB3aWxs IGJlIHRoYXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBvaW50IHRoYXQgc3Vw cG9ydHMgY2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGluZyBhbiBvZmZpY2lh bCBlbmRwb2ludCBuYW1lIGZvciBkaXNjb3Zlcnk/IFJpZ2h0IG5vdyB3ZSBhcmUgdXNpbmcg4oCc bXRsc190b2tlbl9lbmRwb2ludOKAnS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2EsIEFyaWFsOyBmb250LXNpemU6IDEzcHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIEFyaWFsOyBmb250 LXNpemU6IDEzcHg7IiBjbGFzcz0iIj5UaGFua3M8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsLW1f NTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW1fNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsX3NpZ25h dHVyZSI+DQrigJTigJTigJQNCjxkaXYgY2xhc3M9IiI+RG9taW5pY2s8L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPHAgY2xhc3M9ImdtYWlsLW1fNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWls LW1fNzU5MzAzMzgyODg4NzQxMjc2NmFpcm1haWxfb24iPk9uIDcuIEZlYnJ1YXJ5IDIwMTkgYXQg MjI6MzY6NTUsIEJyaWFuIENhbXBiZWxsICg8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsPTQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmJj YW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KQ0KIHdyb3RlOjwv cD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJnbWFpbC1tXzUxNDc1ODI0MjcwNTc4 OTQwMTVnbWFpbC1tXzc1OTMwMzM4Mjg4ODc0MTI3NjZjbGVhbl9icSI+DQo8c3BhbiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPkFoIHllcywgdGhhdCBtYWtlcyBzZW5zZS4gVGhhbmtzIGZvciBjbGFyaWZ5aW5n LiBBbmQgaXQgaXMgaW5kZWVkIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkg aW5ub2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4g YnJlYWsgdGhpbmdzIHVuZXhwZWN0ZWRseS4uPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9h dHRyIj5PbiBUaHUsIEZlYiA3LCAyMDE5IGF0IDg6NTcgQU0gUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxl ZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBw YWRkaW5nLWxlZnQ6IDFleDsiPg0KPGRpdiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSJnbWFpbC1tXzUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tXzc1OTMwMzM4Mjg4ODc0MTI3 NjZnbWFpbC1tXzUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tXy00OTY1ODY2ODY4ODI5MTA0NTY0 V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjYXNlIEnigJltIHJlZmVy ZW5jaW5nIGRpZG7igJl0IHNwZWNpZmljYWxseSBpbnZvbHZlIEFTIG1ldGFkYXRhLiBXZSBoYWQg Y2xpZW50cyBpbiB0aGUgd2lsZCB0aGF0IGFzc3VtZWQgdGhhdCBhbGwgdGhlIHByb3BlcnRpZXMg aW4gdGhlIEpTT04gb2JqZWN0IHJldHVybmVkIGZyb20gb3VyIHVzZXJpbmZvIGVuZHBvaW50IHdl cmUgc2NhbGFyIHN0cmluZ3MuIFRoaXMgYnJva2Ugd2hlbiB3ZSBpbnRyb2R1Y2VkDQogYSBuZXcg cHJvcGVydHkgd2hvc2UgdmFsdWUgd2FzIGEgSlNPTiBvYmplY3QuIEl0IHdhcyBhIGdvb2QgcmVt aW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBjaGFuZ2UgdGhhdCBzaG91bGQg YmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGZvcmNlIG1vcmUgd29yayBvbiBjbGllbnRzIHRo YW4gd2UgZXhwZWN0LjwvcD4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQt YmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4tLSZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIi PkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj5BV1MgSWRlbnRpdHk8L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBs YWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1jb2xvcjog cmdiKDE4MSwgMTk2LCAyMjMpIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3I7IGJvcmRlci1zdHls ZTogc29saWQgbm9uZSBub25lOyBib3JkZXItd2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVtOyBwYWRk aW5nOiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkZyb206PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkJyaWFuIENhbXBiZWxsICZsdDs8 YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+RGF0ZTo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxOSBhdCAxMTozMCBBTTxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUm cXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7UmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBv YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5SZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1i cm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQt YmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIEknbSBob25lc3RseSByZWFsbHkg c3RydWdnbGluZyB0byBzZWUgd2hhdCBjb3VsZCBoYXZlIGdvbmUgd3Jvbmcgd2l0aCBvciBob3cg dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGJyb2tlIHNvbWV0aGluZyB3aXRoIHRoZSB1c2Vy IGluZm8gZW5kcG9pbnQuIElmIHlvdSBoYXZlIHRoZSB0aW1lIGFuZC9vciBpdCdkIGJlIGluZm9y bWF0aXZlIHRvIHRoaXMgaGVyZSBsaXR0bGUgZGlzY3Vzc2lvbiwgcGxlYXNlDQogZXhwbGFpbiB0 aGF0IG9uZSBhIGJpdCBtb3JlLjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgNiwgMjAx OSBhdCAxMjoxNSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXItY29sb3I6IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9y IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsg Ym9yZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxcHQ7IHBhZGRpbmc6IDBpbiAwaW4g MGluIDZwdDsgbWFyZ2luLWxlZnQ6IDQuOHB0OyBtYXJnaW4tcmlnaHQ6IDBpbjsiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JnF1b3Q7ZmFyJnF1b3Q7IHNob3VsZCBoYXZlIHNhaWQgJnF1b3Q7ZmFp ciZxdW90OyBpbiB0aGUgcHJldmlvdXMgbWVzc2FnZTwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9j ay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCA0OjM1IFBNIEJy aWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwv YT4mZ3Q7IHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1jb2xv cjogY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwgMjA0LCAy MDQpOyBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItd2lkdGg6IG1l ZGl1bSBtZWRpdW0gbWVkaXVtIDFwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNnB0OyBtYXJnaW4t bGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGluOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBtYXkgd2VsbCBiZSBkdWUgdG8gbXkgb3duIGludGVsbGVjdHVhbCBzaG9ydGNvbWluZ3MgYnV0 IHRoZXNlIGlzc3Vlcy9xdWVzdGlvbnMvY29uZnVzaW9uLXBvaW50cyBhcmUgbm90IHJlc29uYXRp bmcgZm9yIG1lIGFzIGJlaW5nIHByb2JsZW1hdGljLjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgbW9yZSBnZW5lcmFsIHN0YW5jZSBvZiAmcXVvdDt0aGlzIGlzbid0IG5lZWRlZCBvciB3 b3J0aCBpdCBpbiB0aGlzIGRvY3VtZW50JnF1b3Q7IChJIHRoaW5rIHRoYXQncyBmYXI/KSBpcyBi ZWluZyBoZWFyZCB0aG91Z2guPC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3 ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVy Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQyIFBNIFJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBh bWF6b24uY29tQGRtYXJjLmlldGYuLi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj40MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXItY29sb3I6IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3Vy cmVudGNvbG9yIHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9u ZSBzb2xpZDsgYm9yZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxcHQ7IHBhZGRpbmc6 IDBpbiAwaW4gMGluIDZwdDsgbWFyZ2luLWxlZnQ6IDQuOHB0OyBtYXJnaW4tcmlnaHQ6IDBpbjsi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4oVEw7RFI6IHB1bnQgQVMgbWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCk8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBUyBwb2ludHMgIzEtMyBhcmUgYWxsIHF1ZXN0aW9u cyBJIHdvdWxkIGhhdmUgYXMgYW4gaW1wbGVtZW50ZXI6PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBl PSIxIiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iZ21haWwtbV81MTQ3NTgyNDI3MDU3ODk0MDE1Z21h aWwtbV83NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbV81MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwt bV8tNDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2 Njc2MzkwMjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2 ODExNTU4NjJtc29saXN0cGFyYWdyYXBoIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4NDE0I3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPlNlY3Rp b24gMiBvZiBSRkM4NDE0PC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5zYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBvbmx5 IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hhdCBkb2VzIHRo ZSBtVExTLW9ubHkNCiBBUyBwdXQgaGVyZT88L2xpPjxsaSBjbGFzcz0iZ21haWwtbV81MTQ3NTgy NDI3MDU3ODk0MDE1Z21haWwtbV83NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbV81MTgwNTAzNDY2 MTY5OTc4NzMyZ21haWwtbV8tNDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMwODIyNjU0NTA4MDk2 MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21h aWwtbTI3MjIwMTgwODY2ODExNTU4NjJtc29saXN0cGFyYWdyYXBoIj4NClRoZSBjbGFpbXMgZm9y IHRoZXNlIG90aGVyIGVuZHBvaW50cyBhcmUgT1BUSU9OQUwsIHBvdGVudGlhbGx5IGxlYWRpbmcg dG8gaW5jb25zaXN0ZW5jeSBkZXBlbmRpbmcgb24gaG93ICMxIGdldHMgZGVjaWRlZC48L2xpPjxs aSBjbGFzcz0iZ21haWwtbV81MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbV83NTkzMDMzODI4ODg3 NDEyNzY2Z21haWwtbV81MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbV8tNDk2NTg2Njg2ODgyOTEw NDU2NG0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwt bS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4NjJtc29saXN0cGFy YWdyYXBoIj4NClRoZSBleGFtcGxlIHVzYWdlIG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21l dGhvZHMgcHJvcGVydHkgZ2l2ZW4gZWFybGllciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0 LCBzaW5jZSBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1t VExTIGVuZHBvaW50cywgYW5kIG90aGVycyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5k cG9pbnRzLiBIZW5jZSB0aGlzIHF1ZXN0aW9uLjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tXzUxNDc1 ODI0MjcwNTc4OTQwMTVnbWFpbC1tXzc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tXzUxODA1MDM0 NjYxNjk5Nzg3MzJnbWFpbC1tXy00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMzA4MjI2NTQ1MDgw OTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVn bWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2Mm1zb2xpc3RwYXJhZ3JhcGgiPg0KVGhpcyBpbnRyb2R1 Y2VzIGEgbmV3IG1ldGFkYXRhIHByb3BlcnR5IHRoYXQgY291bGQgaW1wYWN0IGhvdyBvdGhlciBz cGVjcyBzaG91bGQgZXh0ZW5kIEFTIG1ldGFkYXRhLiBUaGF0IG5lZWRzIHRvIGJlIGFkZHJlc3Nl ZC48L2xpPjwvb2w+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2Nr LXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjb3VsZCBnbyBv biBmb3IgY2xpZW50IHBvaW50cyBidXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdo IEnigJlsbCBzaGFyZSB0aGF0ICMzIGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwg YmFjayBhbiB1cGRhdGUgdG8gdGhlIExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW50 4oCmZ29vZCB0aW1lcy48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZx dW90OzsiIGNsYXNzPSIiPvCfmIM8L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgZG9u4oCZdCBuZWNlc3NhcmlseSB0aGluayBhbiBBUyBtZXRhZGF0YSBwcm9wZXJ0 eSBpcyB3cm9uZyBwZXIgc2UsIGJ1dCB1bmRlcnN0YW5kIHRoYXQgeW914oCZcmUgYm9sdGluZyBh IGxheWVyIG9mIGZsZXhpYmlsaXR5IG9udG8gYSBzdGFuZGFyZCB0aGF0IHdhc27igJl0IGRlc2ln bmVkIGZvciB0aGF0LCBhbmQgSSBkb27igJl0IHRoaW5rIHRoZSBtZXRhZGF0YSBwcm9wb3NhbCBh cyBpdOKAmXMgYmVlbiBkaXNjdXNzZWQgaGVyZQ0KIHN1ZmZpY2llbnRseSBkZWFscyB3aXRoIHRo ZSBmYWxsb3V0IGZyb20gdGhhdC4gSW4gbXkgdmlldyB0aGlzIGlzIGEgY29tcGxleCBlbm91Z2gg aXNzdWUgYW5kIGl04oCZcyBmb3IgYSBudWFuY2VkIGVub3VnaCB1c2UgY2FzZSAoYXMgZmFyIGFz IEkgY2FuIHRlbGwgZnJvbSBkaXNjdXNzaW9uPyBQbGVhc2UgY29ycmVjdCBtZSBpZiBJ4oCZbSB3 cm9uZykgdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFyYXRlIGRyYWZ0IChlLmcuLCDi gJxBdXRob3JpemF0aW9uDQogU2VydmVyIE1ldGFkYXRhIEV4dGVuc2lvbnMgZm9yIG1UTFMgSHli cmlkc+KAnSkgYW5kIGdldCBtVExTIG91dCB0aGUgZG9vci48L3A+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xh c3M9IiI+LS0mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oywgc2VyaWY7IiBjbGFzcz0iIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+ QVdTIElkZW50aXR5PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXdpZHRoOiAxcHQg bWVkaXVtIG1lZGl1bTsgcGFkZGluZzogM3B0IDBpbiAwaW47IGJvcmRlci1jb2xvcjogY3VycmVu dGNvbG9yOyIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsICZsdDtiY2Ft cGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RGF0ZTo8L2I+PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgRmVicnVhcnkgNCwg MjAxOSBhdCA1OjI4IEFNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDtSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vYXV0 aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5SZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93 c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxv Y2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvc2UgcG9pbnRzIG9mIGNvbmZ1c2lvbiBzdHJpa2UgbWUg YXMgc29tZXdoYXQgaHlwb3RoZXRpY2FsIG9yIGh5cGVyYm9saWMuIEJ1dCB5b3VyIGdlbmVyYWwg cG9pbnQgaXMgdGFrZW4gYW5kIHlvdXIgcG9zaXRpb24gb2YgYmVpbmcgYW50aSBhZGRpdGlvbmFs IG1ldGFkYXRhIG9uIHRoaXMgaXNzdWUgaXMgbm90ZWQuPC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhv bGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFsbCBvZiB3aGljaCBsZWF2ZXMgbWUgYSBiaXQgdW5jZXJ0YWluIGFib3V0IGhvdyB0byBw cm9jZWVkLiBUaGVyZSBzZWVtIHRvIGJlIGEgcmFuZ2Ugb2Ygb3BpbmlvbnMgb24gdGhpcyBwb2lu dCBhbmQgZ2F1Z2luZyBjb25zZW5zdXMgaXMgcHJvdmluZyBlbHVzaXZlIGZvciBtZS4gVGhhdCdz IGNvbmZvdW5kZWQgYnkgbXkgb3duIG9waW5pb24gb24gaXQgYmVpbmcgc29tZXdoYXQgZmx1aWQu PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xh c3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBJJ2QgcmVhbGx5IGxpa2UgdG8gcG9zdCBh biB1cGRhdGUgdG8gdGhpcyBkcmFmdCBhYm91dCBhIG1vbnRoIG9yIHR3byBhZ28uPC9wPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBj bGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFj ZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8 YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIgMSwg MjAxOSBhdCA1OjAzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYT08 YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi5vcmciIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBu b25lIHNvbGlkOyBib3JkZXItd2lkdGg6IG1lZGl1bSBtZWRpdW0gbWVkaXVtIDFwdDsgcGFkZGlu ZzogMGluIDBpbiAwaW4gNnB0OyBtYXJnaW46IDVwdCAwaW4gNXB0IDQuOHB0OyBib3JkZXItY29s b3I6IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsIDIwNCwg MjA0KTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db25mdXNpb24gZnJvbSB0aGUgQVPigJlzIHBlcnNwZWN0aXZlOjwvcD4N CjxvbCBzdGFydD0iMSIgdHlwZT0iMSIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9ImdtYWlsLW1fNTE0 NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW1fNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW1fNTE4MDUw MzQ2NjE2OTk3ODczMmdtYWlsLW1fLTQ5NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzMDgyMjY1NDUw ODA5NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1MDE4MzE5MzYzNDQxOTIw NWdtYWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYyZ21haWwtbS00OTAyODIzNDYxODUzMjQzMDE4Z21h aWwtbS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCI+DQpJZiBJIG9ubHkgc3Vw cG9ydCBtVExTLCBkbyBJIG5lZWQgdG8gaW5jbHVkZSBib3RoIHRva2VuX2VuZHBvaW50X3VyaSBh bmQgbXRsc19lbmRwb2ludHM/IFNob3VsZCBJIG9taXQgdG9rZW5fZW5kcG9pbnRfdXJpPyBPciBz ZXQgaXQgdG8gdGhlIGVtcHR5IHN0cmluZz88L2xpPjxsaSBjbGFzcz0iZ21haWwtbV81MTQ3NTgy NDI3MDU3ODk0MDE1Z21haWwtbV83NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbV81MTgwNTAzNDY2 MTY5OTc4NzMyZ21haWwtbV8tNDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMwODIyNjU0NTA4MDk2 MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21h aWwtbTI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1t LTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdyYXBoIj4NCldoYXQgaWYgSSBvbmx5IHN1 cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQgbm90IHJldm9jYXRpb24gb3Ig dXNlciBpbmZvPzwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tXzUxNDc1ODI0MjcwNTc4OTQwMTVnbWFp bC1tXzc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tXzUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1t Xy00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2 NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4 MTE1NTg2MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0tMTY2NjQ0NjQ0NTkxMjQy OTgxOW1zb2xpc3RwYXJhZ3JhcGgiPg0KSG93IGRvIEkgc3BlY2lmeSBhdXRoZW50aWNhdGlvbiBt ZXRob2RzIGZvciB0aGUgbVRMUyB0b2tlbiBlbmRwb2ludD8gRG9lcyB0b2tlbl9lbmRwb2ludF9h dXRoX21ldGhvZHMgYXBwbHkgdG8gYm90aCB0aGUgbVRMUyBhbmQgbm9uLW1UTFMgZW5kcG9pbnRz PzwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tXzUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tXzc1OTMw MzM4Mjg4ODc0MTI3NjZnbWFpbC1tXzUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tXy00OTY1ODY2 ODY4ODI5MTA0NTY0bS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkx MTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2Mmdt YWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xp c3RwYXJhZ3JhcGgiPg0KSeKAmW0gdXNpbmcgdGhlIE9BdXRoIDIuMCBEZXZpY2UgRmxvdy4gRG8g SSBpbmNsdWRlIGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRob3JpemF0aW9uX2VuZHBvaW50IHVu ZGVyIG10bHNfZW5kcG9pbnRzPzwvbGk+PC9vbD4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNs YXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Db25mdXNpb24gZnJvbSB0aGUgY2xpZW504oCZcyBwZXJzcGVjdGl2ZTo8L3A+DQo8b2wg c3RhcnQ9IjEiIHR5cGU9IjEiIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSJnbWFpbC1tXzUxNDc1ODI0 MjcwNTc4OTQwMTVnbWFpbC1tXzc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tXzUxODA1MDM0NjYx Njk5Nzg3MzJnbWFpbC1tXy00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMzA4MjI2NTQ1MDgwOTYy Z21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFpbC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFp bC1tMjcyMjAxODA4NjY4MTE1NTg2MmdtYWlsLW0tNDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0t MTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJhZ3JhcGgiPg0KQXMgZmFyIGFzIEkga25vdywg SeKAmW0gYSBwdWJsaWMgY2xpZW50LCBhbmQgZG9u4oCZdCBrbm93IGFueXRoaW5nIGFib3V0IG1U TFMsIGJ1dCB0aGUgSVQgYWRtaW5zIGluc3RhbGxlZCBjbGllbnQgY2VydHMgaW4gdGhlaXIgdXNl cnPigJkgYnJvd3NlcnMgYW5kIHRoZSBBUyBleHBlY3RzIHRvIHVzZSB0aGF0IHRvIGF1dGhlbnRp Y2F0ZSBtZS48L2xpPjxsaSBjbGFzcz0iZ21haWwtbV81MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwt bV83NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbV81MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbV8t NDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2 MzkwMjk5MTEwZ21haWwtbS0zNzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODEx NTU4NjJnbWFpbC1tLTQ5MDI4MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4 MTltc29saXN0cGFyYWdyYXBoIj4NCk15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1 c2UgdGhlIG1UTFMtb25seSBBUyBvbWl0dGVkIHRva2VuX2VuZHBvaW50X3VyaS48L2xpPjxsaSBj bGFzcz0iZ21haWwtbV81MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbV83NTkzMDMzODI4ODg3NDEy NzY2Z21haWwtbV81MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbV8tNDk2NTg2Njg2ODgyOTEwNDU2 NG0tODU2MzMwODIyNjU0NTA4MDk2MmdtYWlsLW02NDY2NjI2Njc2MzkwMjk5MTEwZ21haWwtbS0z NzUwMTgzMTkzNjM0NDE5MjA1Z21haWwtbTI3MjIwMTgwODY2ODExNTU4NjJnbWFpbC1tLTQ5MDI4 MjM0NjE4NTMyNDMwMThnbWFpbC1tLTE2NjY0NDY0NDU5MTI0Mjk4MTltc29saXN0cGFyYWdyYXBo Ij4NCk15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhw ZWN0IHRvIGVuY291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLjwvbGk+ PGxpIGNsYXNzPSJnbWFpbC1tXzUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tXzc1OTMwMzM4Mjg4 ODc0MTI3NjZnbWFpbC1tXzUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tXy00OTY1ODY2ODY4ODI5 MTA0NTY0bS04NTYzMzA4MjI2NTQ1MDgwOTYyZ21haWwtbTY0NjY2MjY2NzYzOTAyOTkxMTBnbWFp bC1tLTM3NTAxODMxOTM2MzQ0MTkyMDVnbWFpbC1tMjcyMjAxODA4NjY4MTE1NTg2MmdtYWlsLW0t NDkwMjgyMzQ2MTg1MzI0MzAxOGdtYWlsLW0tMTY2NjQ0NjQ0NTkxMjQyOTgxOW1zb2xpc3RwYXJh Z3JhcGgiPg0KVGhlIG1UTFMtb25seSBBUyBkaWRu4oCZdCBwcm92aWRlIGEgdmFsdWUgZm9yIG10 bHNfZW5kcG9pbnRzLCB3aGF0IGRvIEkgZG8/PC9saT48bGkgY2xhc3M9ImdtYWlsLW1fNTE0NzU4 MjQyNzA1Nzg5NDAxNWdtYWlsLW1fNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW1fNTE4MDUwMzQ2 NjE2OTk3ODczMmdtYWlsLW1fLTQ5NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzMDgyMjY1NDUwODA5 NjJnbWFpbC1tNjQ2NjYyNjY3NjM5MDI5OTExMGdtYWlsLW0tMzc1MDE4MzE5MzYzNDQxOTIwNWdt YWlsLW0yNzIyMDE4MDg2NjgxMTU1ODYyZ21haWwtbS00OTAyODIzNDYxODUzMjQzMDE4Z21haWwt bS0xNjY2NDQ2NDQ1OTEyNDI5ODE5bXNvbGlzdHBhcmFncmFwaCI+DQpJIGRvbuKAmXQga25vdyB3 aGF0IHRoYXQg4oCcbeKAnSBtZWFucywgYnV0IHRoZXkgdG9sZCBtZSB0byB1c2UgSFRUUFMsIHNv IEkgc2hvdWxkIHVzZSB0aGUgb25lIHdpdGgg4oCcdGxz4oCdIGluIGl0cyBuYW1lLCByaWdodD88 L2xpPjwvb2w+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBs YWNlaG9sZGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB5b3UgY2FuIHdy aXRlIG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5zd2VycyBtb3N0IG9mIHRoZXNlLiBCdXQgeW914oCZ bGwgaGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEgbG90IG9mIHNpbWlsYXItYnV0LXNsaWdodGx5LWRp ZmZlcmVudCBzY2VuYXJpb3MgYW5kIGJlIHZlcnkgZXhwbGljaXQuIEFuZCBpbXBsZW1lbnRlcnMg d2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9kdWNlcw0K IG9wcG9ydHVuaXRpZXMgZm9yIGNvbmZ1c2lvbiBhbmQgZmFpbHVyZSB0aGF0IGRvIG5vdCBleGlz dCBub3csIGFuZCBmb3JjZXMgdGhlbSBvbiBldmVyeW9uZSB3aG8gc3VwcG9ydHMgbVRMUy4gSW4g Y29udHJhc3QsIHRoZSAzMDcgcmVkaXJlY3QgaXMgb25seSByZXF1aXJlZCB3aGVuIGFuIEFTIHdh bnRzIHRvIHN1cHBvcnQgYm90aCwgYW5kIGlzIHVuYW1iaWd1b3VzIGluIGl0cyBiZWhhdmlvciBh bmQgbWVhbmluZy48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9j ay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssIHNlcmlmOyIgY2xhc3M9IiI+LS0mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj5Bbm5hYmVsbGUgUmljaGFyZCBC YWNrbWFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl cmlmOyIgY2xhc3M9IiI+QVdTIElkZW50aXR5PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIi Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9y ZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgcGFkZGluZzogM3B0IDBpbiAwaW47IGJvcmRl ci1jb2xvcjogY3VycmVudGNvbG9yOyIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+QnJpYW4gQ2FtcGJlbGwg Jmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+NDBwaW5naWRlbnRpdHkuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5EYXRlOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBGZWJy dWFyeSAxLCAyMDE5IGF0IDM6MTcgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90O1Jp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnJpY2hhbm5hQGFtYXpvbi5j b208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+R2VvcmdlIEZsZXRjaGVyICZsdDs8 YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi PmdmZmxldGNoQGFvbC5jb208L2E+Jmd0Oywgb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9hPiZn dDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W1VOVkVSSUZJRUQgU0VOREVSXSBSZTog W09BVVRILVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVu ZHBvaW50PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxh cmdlIG9mIGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0 aGUgZ2l2ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0 IHVzZXMgdGhhdCBvbmUuJm5ic3A7IE90aGVyd2lzZSBpdCB1c2VzIHRoZSByZWd1bGFyIGVuZHBv aW50LiBJdCBnaXZlcyBhbiBBUyBhIGxvdCBvZg0KIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQg b3B0aW9ucy4gSSBwZXJzb25hbGx5IHRoaW5rIGdldHRpbmcgYSAzMDcgYXBwcm9hY2ggZGVwbG95 ZWQgYW5kIHdvcmtpbmcgd291bGQgYmUgbW9yZSBjb21wbGljYXRlZCBhbmQgZXJyb3IgcHJvbmUu Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8 YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIGEgbWlub3JpdHkgdXNlIGNh c2UgYXQgdGhlIG1vbWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBsaWtlIHRoZSBw dXNoIGZvciBpbmNyZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2ZSBqYXZhc2Ny aXB0IGNsaWVudHMgdXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdCBpdCB3b24ndCBiZSB0 ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvDQogc3VwcG9ydCBNVExT IGNsaWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNhbWUgdGltZS48L3A+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0i d2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQg Zm9ydGggaW4gdGhpcyB0aHJlYWQgb24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0 YWRhdGEgKG9yIHNvbWV0aGluZyBsaWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkg a2luZGEgZXhwbGFpbmVkIHNvbWV3aGVyZSBiYWNrIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0 aGF0IG1ha2UgdXAgdGhpcyB0aHJlYWQuJm5ic3A7IEJ1dCBpdA0KIHNlZW1zIGxpa2UgdGhlIHJv dWdoIGNvbnNlbnN1cyBvZiB0aGUgZ3JvdXAgaGVyZSBpcyBpbiBmYXZvciBvZiBpdC48L3A+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Vi a2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJy IGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBs YWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6MTggUE0gUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5j b21AZG1hcmMuaWV0Zi4uLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci13aWR0aDog bWVkaXVtIG1lZGl1bSBtZWRpdW0gMXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2cHQ7IG1hcmdp bjogNXB0IDBpbiA1cHQgNC44cHQ7IGJvcmRlci1jb2xvcjogY3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwgMjA0LCAyMDQpOyIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc3RyaWtl cyBtZSBhcyBhIHZlcnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcgY2hhbmdlIHRvIHN1cHBvcnQg d2hhdCBzZWVtcyB0byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ4oCZbSBnZXR0aW5nIGEgaGVh ZGFjaGUganVzdCB0aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVkZWQgdG8gY2xhcmlmeSB3aGVu IHRoZSBBUyBzaG91bGQgcHJvdmlkZSBgbXRsc19lbmRwb2ludHNgIGFuZCB3aGVuIHRoZSBjbGll bnQNCiBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9lbmRwb2ludC5gIFdoeSBp cyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3ZlciB0aGUgY2FzZSB3aGVy ZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1tVExTPzwvcD4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBs YWNlaG9sZGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywg c2VyaWY7IiBjbGFzcz0iIj4tLSZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7 IiBjbGFzcz0iIj5BV1MgSWRlbnRpdHk8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PiZuYnNwOzxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXIt d2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVtOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsgYm9yZGVyLWNv bG9yOiBjdXJyZW50Y29sb3I7IiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5PQXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5v YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJl bGwgJmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+NDBwaW5naWRlbnRpdHkuY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5EYXRlOjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBG ZWJydWFyeSAxLCAyMDE5IGF0IDE6MzEgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8 L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkdlb3Jn ZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2g9PGEgaHJlZj0ibWFpbHRvOjQwYW9sLmNvbUBkbWFyYy4u Li4uLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+NDBhb2wuY29tQGRtYXJjLmll dGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm9hdXRoICZsdDs8YSBocmVm PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5vYXV0aEBp ZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgt V0ddIE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8 YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhhdCB3b3VsZCB3b3JrLiZu YnNwOzwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtpdC1i bG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdl b3JnZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2g9PGEgaHJlZj0ibWFpbHRvOjQwYW9sLmNvbUBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjQwYW9sLmNvbUBkbWFyYy5pZXRm Lm9yZzwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl ci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci13aWR0aDogbWVkaXVtIG1lZGl1 bSBtZWRpdW0gMXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2cHQ7IG1hcmdpbjogNXB0IDBpbiA1 cHQgNC44cHQ7IGJvcmRlci1jb2xvcjogY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50 Y29sb3IgcmdiKDIwNCwgMjA0LCAyMDQpOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPldoYXQgaWYgdGhlIEFTIHdhbnRz IHRvIE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rpb25zLiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRo ZSBvcHRpb25hbCAmcXVvdDttdGxzX2VuZHBvaW50cyZxdW90OyBhbmQganVzdCB1c2UgdGhlIG5v cm1hbCBtZXRhZGF0YSB2YWx1ZXM/PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAxLzE1LzE5IDg6NDggQU0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJv dHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBkZWZpbml0ZWx5IGJl IG9wdGlvbmFsLCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBiZSBz b21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUg YW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbiBwcmVzZW50IGluIEFTIG1l dGFkYXRhLjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IndlYmtp dC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKYW4gMTUsIDIwMTkgYXQgMjowNCBB TSBEYXZlIFRvbmdlICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNv LnVrIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVr PC9hPiZndDsgd3JvdGU6PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1RyZWJ1Y2hldCBNUyZx dW90Oywgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkknbSBpbiBmYXZvdXIgb2YgdGhlIGBtdGxzX2Vu ZHBvaW50c2AgbWV0YWRhdGEgcGFyYW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxkIGJlIG9wdGlv bmFsLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PGJyIGNsYXNzPSIiPg0KPGkgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6 IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVy aWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJl dmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4uJm5ic3A7DQogSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5p Y2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkg ZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZy b20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9wPg0KPHByZSBjbGFzcz0i Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcHJlPg0K PHByZSBjbGFzcz0iIj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3ByZT4NCjxwcmUgY2xhc3M9IiI+PGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1 dGhAaWV0Zi5vcmc8L2E+PC9wcmU+DQo8cHJlIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5odHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSJ3ZWJraXQtYmxv Y2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDg1LCA4NSwgODUpOyBib3JkZXI6IDFwdCBub25l IHdpbmRvd3RleHQ7IHBhZGRpbmc6IDBpbjsiIGNsYXNzPSIiPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZQ0KIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz DQogZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xv cjogcmdiKDg1LCA4NSwgODUpOyBib3JkZXI6IDFwdCBub25lIHdpbmRvd3RleHQ7IHBhZGRpbmc6 IDBpbjsiIGNsYXNzPSIiPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0K IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4m bmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzDQogZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDg1LCA4NSwgODUpOyBi b3JkZXI6IDFwdCBub25lIHdpbmRvd3RleHQ7IHBhZGRpbmc6IDBpbjsiIGNsYXNzPSIiPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0KIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzDQogZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwv aT48L2I+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxp IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig4NSwgODUsIDg1KTsgYm9yZGVyOiAx cHQgbm9uZSB3aW5kb3d0ZXh0OyBwYWRkaW5nOiAwaW47IiBjbGFzcz0iIj5DT05GSURFTlRJQUxJ VFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls ZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUNCiB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhl cnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFj aG1lbnRzDQogZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGkgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4IG5vbmU7IG91 dGxpbmU6IGN1cnJlbnRjb2xvciBub25lIDBweDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyBi YWNrZ3JvdW5kLWltYWdlOiBub25lOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IHNjcm9sbDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250LWZhbWlseTogcHJveGltYS1u b3ZhLXplbmRlc2ssIHN5c3RlbS11aSwgLWFwcGxlLXN5c3RlbSwgc3lzdGVtLXVpLCAmcXVvdDtT ZWdvZSBVSSZxdW90OywgUm9ib3RvLCBPeHlnZW4tU2FucywgVWJ1bnR1LCBDYW50YXJlbGwsICZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig4 NSwgODUsIDg1KTsgYmFja2dyb3VuZC1wb3NpdGlvbjogMCUgMCU7IGJhY2tncm91bmQtcmVwZWF0 OiByZXBlYXQgcmVwZWF0OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRk aW5nOiAwcHg7IGJvcmRlcjogMHB4IG5vbmU7IG91dGxpbmU6IGN1cnJlbnRjb2xvciBub25lIDBw eDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyBiYWNrZ3JvdW5kLWltYWdlOiBub25lOyBiYWNr Z3JvdW5kLWF0dGFjaG1lbnQ6IHNjcm9sbDsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7 IGZvbnQtZmFtaWx5OiBwcm94aW1hLW5vdmEtemVuZGVzaywgc3lzdGVtLXVpLCAtYXBwbGUtc3lz dGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICZxdW90O1NlZ29lIFVJJnF1b3Q7LCBSb2JvdG8sIE94 eWdlbi1TYW5zLCBVYnVudHUsIENhbnRhcmVsbCwgJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDss IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXdlaWdodDogNjAwOyBiYWNrZ3JvdW5kLXBvc2l0aW9u OiAwJSAwJTsgYmFja2dyb3VuZC1yZXBlYXQ6IHJlcGVhdCByZXBlYXQ7IiBjbGFzcz0iIj48Zm9u dCBzaXplPSIyIiBjbGFzcz0iIj5DT05GSURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBk aXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeQ0KIHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBk ZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21w dXRlci4gVGhhbmsgeW91LjwvZm9udD48L3NwYW4+PC9pPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1dGhAaWV0 Zi5vcmc8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu PjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQo8aSBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IG1hcmdpbjogMHB4 OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAwcHg7IHZlcnRpY2FsLWFsaWdu OiBiYXNlbGluZTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250LWZh bWlseTogcHJveGltYS1ub3ZhLXplbmRlc2ssIHN5c3RlbS11aSwgLWFwcGxlLXN5c3RlbSwgc3lz dGVtLXVpLCAmcXVvdDtTZWdvZSBVSSZxdW90OywgUm9ib3RvLCBPeHlnZW4tU2FucywgVWJ1bnR1 LCBDYW50YXJlbGwsICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCBBcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYig4NSwgODUsIDg1KTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBp bml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5l OiAwcHg7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7IGZvbnQtZmFtaWx5OiBwcm94aW1hLW5vdmEtemVuZGVzaywgc3lzdGVtLXVpLCAtYXBw bGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICZxdW90O1NlZ29lIFVJJnF1b3Q7LCBSb2Jv dG8sIE94eWdlbi1TYW5zLCBVYnVudHUsIENhbnRhcmVsbCwgJnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDssIEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXdlaWdodDogNjAwOyBiYWNrZ3JvdW5kLXBv c2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRp YWw7IiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5DT05GSURFTlRJQUxJVFkNCiBO T1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk IG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g QW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeQ0KIHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvZm9udD48L3NwYW4+PC9pPjxzcGFu IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5PQXV0aA0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5P QXV0aEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi IGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBFD924FBBB34CF88EDA0BC739C2220Amitedu_-- From nobody Tue Feb 12 10:57:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCC112785F for ; Tue, 12 Feb 2019 10:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMDGeOD5eEu0 for ; Tue, 12 Feb 2019 10:57:39 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BF312E7C1 for ; Tue, 12 Feb 2019 10:57:38 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id y184so9934943itc.1 for ; Tue, 12 Feb 2019 10:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ym8eDtbVGy/nOGh2DxOkssPC5IcLoGPZFcLHeR26LkY=; b=PWj1/EwNPJUKgS9BxaXHfMiF6JGjVlHW3gVr7yrfLgZVMKrAT5mTIF+HdLEhFj6CK2 ZivE6AcGvqRj0ptEIYgEd52CR9gdNx+kLTGko3v0CN4zCHxpSVZhPKshzx/1CqGXqjj1 yQFHta05t9zCaBLpVgtxqV9IO5XLT4L6DKlSs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ym8eDtbVGy/nOGh2DxOkssPC5IcLoGPZFcLHeR26LkY=; b=J8kGPR7wtLtjuyiXgt53CxAj6fOPfR1xN8LX3b7s5i4BhFRVDMnOp0lr2z73j4+4T7 4XefpBtMYzw83WgfU+QGoEHNZWPBgsgGgqP6+YiJSJwJ8k4/EaXrv0qhHZD1Sal5cnAo ctVtdweBvgDnbpJkz0MFBx8GEDo268nDP9qvKiCd0cf2v0YgwGIpmt6po6cEMnjqWCVK Y1C2A7DV7cNA0M0zNwQKYVAUGh+C/sL1nXXlwhZ07JyoEAh5HRxuGrKS/bks+b3Eq8Uq IeI3bw2vtTlrWRzmV0JpIIGVd+CXVwTHgPZFzfbhUwKLBRYxLiL4aBicWPhY9eU/a0Pg yiIg== X-Gm-Message-State: AHQUAuZmx6cbc8lVJSXAnuxM4ODtR+pzhtfKCeb3veC3jKC3//4ZpfC6 ZL0Gy6OWrgjFxOnzFIYawF24WVV60QYaekTGQYsjwKSyfcfyulxLjwLfTDstks9DE13XH6snFBe 1x0pcLXbbt4z2QA== X-Google-Smtp-Source: AHgI3IYHhjmwbHJuq2imGDmK1JzEKEyA3hLzXIrvx9kJVRMGV22FXGkdVQkyYRPovjEO5sbAXcsQIKKMRQZLfuAOwGw= X-Received: by 2002:a24:3644:: with SMTP id l65mr190206itl.124.1549997856795; Tue, 12 Feb 2019 10:57:36 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: From: Brian Campbell Date: Tue, 12 Feb 2019 11:57:10 -0700 Message-ID: To: Dominick Baier Cc: oauth Content-Type: multipart/alternative; boundary="000000000000a84eb90581b6ffb4" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 18:57:46 -0000 --000000000000a84eb90581b6ffb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the input, Dominick. I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action. On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier wrote: > IMHO that=E2=80=99s a reasonable and pragmatic option. > > Thanks > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 11. February 2019 at 13:26:37, Brian Campbell ( > bcampbell@pingidentity.com) wrote: > > It's been pointed out that the potential issue is not isolated to the jus= t > token endpoint but that revocation, introspection, etc. could be impacted > as well. So, at this point, the proposal on the table is to add a new > optional AS metadata parameter named 'mtls_endpoints' that's value we be = a > JSON object which itself contains endpoints that, when present, a client > doing MTLS would use rather than the regular endpoints. A straw-man > example might look like this > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token > ", > "userinfo_endpoint":"https://mtls.example.com/userinfo > ", > "revocation_endpoint":"https://mtls.example.com/revo > " }* > } > > > A client doing MTLS would look for and give precedence to an endpoint > under "mtls_endpoints" while falling back to use the normal endpoint from > the top level of metadata when/if its not in "mtls_endpoints". > > The idea being that "regular" clients (those not doing MTLS) will use the > regular endpoints. And only the host/port of the endpoints listed in > mtls_endpoints will be set up to request TLS client certificates during > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > I'm struggling, however, to adequately gauge whether or not there's > sufficient consensus to go ahead with the update. There's been some suppo= rt > for it voiced. As well as talk of other approaches that could be > alternatives or additional measures. And also some vocal opposition to it= . > > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > wrote: > >> We are currently implementing MTLS in IdentityServer. >> >> Our approach will be that we=E2=80=99ll offer a separate token endpoint = that >> supports client certs. Are you planning on adding an official endpoint n= ame >> for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. >> >> Thanks >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick >> >> On 7. February 2019 at 22:36:55, Brian Campbell ( >> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: >> >> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can break things unexpectedly.. >> >> >> >> >> >> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >>> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS= metadata. We had >>> clients in the wild that assumed that all the properties in the JSON ob= ject >>> returned from our userinfo endpoint were scalar strings. This broke whe= n we >>> introduced a new property whose value was a JSON object. It was a good >>> reminder that even a seemingly innocuous change that should be backward= s >>> compatible can force more work on clients than we expect. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* Brian Campbell >>> *Date:* Wednesday, February 6, 2019 at 11:30 AM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* "Richard Backman, Annabelle" , oauth < >>> oauth@ietf.org> >>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> And I'm honestly really struggling to see what could have gone wrong >>> with or how token_endpoint_auth_methods broke something with the user i= nfo >>> endpoint. If you have the time and/or it'd be informative to this here >>> little discussion, please explain that one a bit more. >>> >>> >>> >>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> "far" should have said "fair" in the previous message >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> It may well be due to my own intellectual shortcomings but these >>> issues/questions/confusion-points are not resonating for me as being >>> problematic. >>> >>> >>> >>> The more general stance of "this isn't needed or worth it in this >>> document" (I think that's far?) is being heard though. >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >>> >>> (TL;DR: punt AS metadata to a separate draft) >>> >>> AS points #1-3 are all questions I would have as an implementer: >>> >>> 1. Section 2 of RFC8414 >>> says token_endpoint >>> =E2=80=9Cis REQUIRED unless only the implicit grant type is supporte= d.=E2=80=9D So what >>> does the mTLS-only AS put here? >>> 2. The claims for these other endpoints are OPTIONAL, potentially >>> leading to inconsistency depending on how #1 gets decided. >>> 3. The example usage of the token_endpoint_auth_methods property >>> given earlier is incompatible with RFC8414, since some of its conten= ts are >>> only valid for the non-mTLS endpoints, and others are only valid for= the >>> mTLS endpoints. Hence this question. >>> 4. This introduces a new metadata property that could impact how >>> other specs should extend AS metadata. That needs to be addressed. >>> >>> >>> >>> I could go on for client points but you already get the point. Though >>> I=E2=80=99ll share that #3 is real and once forced me to roll back an u= pdate to the >>> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>> >>> >>> >>> I don=E2=80=99t necessarily think an AS metadata property is wrong per = se, but >>> understand that you=E2=80=99re bolting a layer of flexibility onto a st= andard that >>> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadat= a proposal as it=E2=80=99s >>> been discussed here sufficiently deals with the fallout from that. In m= y >>> view this is a complex enough issue and it=E2=80=99s for a nuanced enou= gh use case >>> (as far as I can tell from discussion? Please correct me if I=E2=80=99m= wrong) that >>> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Ser= ver Metadata >>> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Monday, February 4, 2019 at 5:28 AM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> Those points of confusion strike me as somewhat hypothetical or >>> hyperbolic. But your general point is taken and your position of being = anti >>> additional metadata on this issue is noted. >>> >>> >>> >>> All of which leaves me a bit uncertain about how to proceed. There seem >>> to be a range of opinions on this point and gauging consensus is provin= g >>> elusive for me. That's confounded by my own opinion on it being somewha= t >>> fluid. >>> >>> >>> >>> And I'd really like to post an update to this draft about a month or tw= o >>> ago. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >>> >>> Confusion from the AS=E2=80=99s perspective: >>> >>> 1. If I only support mTLS, do I need to include both >>> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_= uri? Or >>> set it to the empty string? >>> 2. What if I only support mTLS for the token endpoint, but not >>> revocation or user info? >>> 3. How do I specify authentication methods for the mTLS token >>> endpoint? Does token_endpoint_auth_methods apply to both the mTLS an= d >>> non-mTLS endpoints? >>> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-= enabled >>> device_authorization_endpoint under mtls_endpoints? >>> >>> >>> >>> Confusion from the client=E2=80=99s perspective: >>> >>> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t = know anything >>> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >>> browsers and the AS expects to use that to authenticate me. >>> 2. My AS metadata parser crashed because the mTLS-only AS omitted >>> token_endpoint_uri. >>> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >>> encounter a JSON object as a parameter value. >>> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoint= s, what >>> do I do? >>> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but the= y told me to use HTTPS, >>> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, righ= t? >>> >>> >>> >>> Yes, you can write normative text that answers most of these. But you= =E2=80=99ll >>> have to clearly cover a lot of similar-but-slightly-different scenarios= and >>> be very explicit. And implementers will still get it wrong. The metadat= a >>> change introduces opportunities for confusion and failure that do not e= xist >>> now, and forces them on everyone who supports mTLS. In contrast, the 30= 7 >>> redirect is only required when an AS wants to support both, and is >>> unambiguous in its behavior and meaning. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* Brian Campbell >>> *Date:* Friday, February 1, 2019 at 3:17 PM >>> *To:* "Richard Backman, Annabelle" >>> *Cc:* George Fletcher , oauth >>> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> It doesn't seem like that confusing or large of a change to me - if the >>> client is doing MTLS and the given endpoint is present in `mtls_endpoin= ts`, >>> then it uses that one. Otherwise it uses the regular endpoint. It give= s an >>> AS a lot of flexibility in deployment options. I personally think getti= ng a >>> 307 approach deployed and working would be more complicated and error >>> prone. >>> >>> >>> >>> It is a minority use case at the moment but there are forces in play, >>> like the push for increased security in general and to have javascript >>> clients use the code flow, that suggest it won't be terribly unusual to= see >>> an AS that wants to support MTLS clients and javascript/spa clients at = the >>> same time. >>> >>> >>> >>> I've personally wavered back and forth in this thread on whether or not >>> to add the new metadata (or something like it). With my reasoning each = way >>> kinda explained somewhere back in the 40 or so messages that make up th= is >>> thread. But it seems like the rough consensus of the group here is in >>> favor of it. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >>> >>> This strikes me as a very prominent and confusing change to support wha= t >>> seems to be a minority use case. I=E2=80=99m getting a headache just th= inking about >>> the text needed to clarify when the AS should provide `mtls_endpoints` = and >>> when the client should use that versus using `token_endpoint.` Why is t= he >>> 307 status code insufficient to cover the case where a single AS suppor= ts >>> both mTLS and non-mTLS? >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Friday, February 1, 2019 at 1:31 PM >>> *To:* George Fletcher >> <40aol.com@dmarc.....ietf.org>> >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >>> endpoint >>> >>> >>> >>> Yes, that would work. >>> >>> >>> >>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher >> 40aol.com@dmarc.ietf.org> wrote: >>> >>> What if the AS wants to ONLY support MTLS connections. Does it not >>> specify the optional "mtls_endpoints" and just use the normal metadata >>> values? >>> >>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>> >>> It would definitely be optional, apologies if that wasn't made clear. >>> It'd be something to the effect of optional for the AS to include and >>> clients doing MTLS would use it when present in AS metadata. >>> >>> >>> >>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >>> wrote: >>> >>> I'm in favour of the `mtls_endpoints` metadata parameter - although it >>> should be optional. >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> >>> >>> >>> * CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> * CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> * CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> * CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a84eb90581b6ffb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Th= anks for the input, Dominick.

I'd said pr= eviously that I was having trouble adequately gauging whether or not there&= #39;s sufficient consensus to go ahead with the update. I was even thinking= of asking the chairs about a consensus call during the office hours meetin= g yesterday. But it got canceled. And looking again back over the discussio= n, I don't believe a consensus call is necessary. There's been a lo= t of general discussion over the last several weeks during which several fo= lks have stated support for the proposal while there's been only one vo= ice of direct dissent. That seems like rough enough consensus and, as such,= I plan to make the change in the next revision of the document (which shou= ld be done soon). Chairs, please let me know, if you believe the situation = warrants a different course of action.



On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastpr= ivilege.com> wrote:
I= MHO that=E2=80=99s a reasonable and pragmatic option.

Thanks
=E2=80=94= =E2=80=94=E2=80=94
Dominick

On 11. February = 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,=C2=A0 at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a = JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"client_secret_basic","tls_client_auth", "no= ne"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo"= ;
=C2=A0 }
}

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".

The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it.=C2=A0


On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:
We are currently implementing MTLS in IdentityServer.

Our approach will be that we=E2=80=99ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D.

Thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..
On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99= t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pin= gidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discus= sed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" an= d just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.t= onge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a84eb90581b6ffb4-- From nobody Tue Feb 12 11:05:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062B112D4F0 for ; Tue, 12 Feb 2019 11:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWgIRTybDjPW for ; Tue, 12 Feb 2019 11:05:39 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9B312785F for ; Tue, 12 Feb 2019 11:05:39 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id v72so10453816itc.0 for ; Tue, 12 Feb 2019 11:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3mpfAPp5S/8VzB+uNbQ3O3ojfjoF3JSlg5nvso8tDBg=; b=d/FoSfLXz636Gdl2pPLXL2jXfx5TmC93co4ZyTbJEwExiw1N/GNLV+ti9iAODYpnVj qKbBAxLCX/k9T+AaFd55V4OkJJRnwuMIcJmveT+tcm3zfWWqbLvDQ/J28kvD1K5WwVlG gLXwCMHItz4AoojnjXSBz6MM0VPl7ah3nJQjU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3mpfAPp5S/8VzB+uNbQ3O3ojfjoF3JSlg5nvso8tDBg=; b=b2m/bp4RZ78z2M5Uh9amabZ5jxR+p1/0WTcAQwxlAVd0CTHrznmzWGf/IaX4nAXjAa uZDxK7Ra6fKFZPbGAIlRIg3eTRDpJwWiQs6MVaEYnBMdwDUmQgTg08lsFGm0v1tbpZ4L dmZMvn/6V8kSjDayU+hYZXiXy4NWk9JW3itbaqFQHg666kB4tIOk3AQjM+RnyoSmf67M UB3IcV5VJuFhlVeKWLs/4mSoZpTh5ivS/ePhoHzbLwbxFTpn356iEoRoC2X50ltiyzGX oWS15mdQeIPMfrp0DJv4bWwWAM5DgiQuwJ03X71ZEtu69XcFEOj2tYBbRYzhuXznkRZo k1mQ== X-Gm-Message-State: AHQUAubEpmr1hugXDvdyZgLwXdLrxCNEsfcSogKbOHqUuoeOrpM00hiP xeQDd+XkLmduKC86b7p90dzeMms74RFPqpzUWYDyq+CEMzRPw1mkKKGmA9F9Xu8Hkg1lZuxE1Vb mRjBw8yjtBUi39A== X-Google-Smtp-Source: AHgI3IY8ZmRqTVhRepY3ufbcLSJ7OICYFbbvvwZqHvMMJCAEcguqt5Y7PhNcwDDutv+90Jkj2voRJMramwrw6+K0gTU= X-Received: by 2002:a24:3644:: with SMTP id l65mr210151itl.124.1549998338328; Tue, 12 Feb 2019 11:05:38 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: From: Brian Campbell Date: Tue, 12 Feb 2019 12:05:12 -0700 Message-ID: To: Justin Richer Cc: Dominick Baier , oauth Content-Type: multipart/alternative; boundary="0000000000005be2b80581b71c54" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 19:05:44 -0000 --0000000000005be2b80581b71c54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps it's due to my own lack of imagination but I don't see any new vectors or how the existing mitigations don't work here too. Please propose some text though, if there's something that should be in the document. On Tue, Feb 12, 2019 at 8:50 AM Justin Richer wrote: > At the moment, I like this suggestion. It feels a little =E2=80=A6 funny = =E2=80=A6 but > that might be just because it=E2=80=99s different from what we had before= . > > We=E2=80=99ll need to have a clear security considerations discussion abo= ut this > though, as it does add another vector for a mix-up attack. I doubt that a= t > this stage we want to say that there has to be any testable relationship > between the values in token_endpoint and mtls_endpoints.token_endpoint, b= ut > splitting the authorization and token endpoints in the discovery document > is exactly what lead to the mix-up attack pattern in the first place. > Essentially, what happens when an attacker crafts a document that says th= e > MTLS token endpoint is theirs and the regular token endpoint is legit, or > vice versa? > > =E2=80=94 Justin > > On Feb 11, 2019, at 7:26 AM, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote: > > It's been pointed out that the potential issue is not isolated to the jus= t > token endpoint but that revocation, introspection, etc. could be impacted > as well. So, at this point, the proposal on the table is to add a new > optional AS metadata parameter named 'mtls_endpoints' that's value we be = a > JSON object which itself contains endpoints that, when present, a client > doing MTLS would use rather than the regular endpoints. A straw-man > example might look like this > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > * "mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token > ", > "userinfo_endpoint":"https://mtls.example.com/userinfo > ", > "revocation_endpoint":"https://mtls.example..com/revo > " }* > } > > > A client doing MTLS would look for and give precedence to an endpoint > under "mtls_endpoints" while falling back to use the normal endpoint from > the top level of metadata when/if its not in "mtls_endpoints". > > The idea being that "regular" clients (those not doing MTLS) will use the > regular endpoints. And only the host/port of the endpoints listed in > mtls_endpoints will be set up to request TLS client certificates during > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > I'm struggling, however, to adequately gauge whether or not there's > sufficient consensus to go ahead with the update. There's been some suppo= rt > for it voiced. As well as talk of other approaches that could be > alternatives or additional measures. And also some vocal opposition to it= . > > > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > wrote: > >> We are currently implementing MTLS in IdentityServer. >> >> Our approach will be that we=E2=80=99ll offer a separate token endpoint = that >> supports client certs. Are you planning on adding an official endpoint n= ame >> for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. >> >> Thanks >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick >> >> On 7. February 2019 at 22:36:55, Brian Campbell ( >> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: >> >> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can break things unexpectedly.. >> >> >> >> >> >> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >>> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS= metadata. We had >>> clients in the wild that assumed that all the properties in the JSON ob= ject >>> returned from our userinfo endpoint were scalar strings. This broke whe= n we >>> introduced a new property whose value was a JSON object. It was a good >>> reminder that even a seemingly innocuous change that should be backward= s >>> compatible can force more work on clients than we expect. >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> *From:* Brian Campbell >>> *Date:* Wednesday, February 6, 2019 at 11:30 AM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* "Richard Backman, Annabelle" , oauth < >>> oauth@ietf.org> >>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> And I'm honestly really struggling to see what could have gone wrong >>> with or how token_endpoint_auth_methods broke something with the user i= nfo >>> endpoint. If you have the time and/or it'd be informative to this here >>> little discussion, please explain that one a bit more. >>> >>> >>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> "far" should have said "fair" in the previous message >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> It may well be due to my own intellectual shortcomings but these >>> issues/questions/confusion-points are not resonating for me as being >>> problematic. >>> >>> >>> The more general stance of "this isn't needed or worth it in this >>> document" (I think that's far?) is being heard though. >>> >>> >>> >>> >>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: >>> >>> (TL;DR: punt AS metadata to a separate draft) >>> >>> AS points #1-3 are all questions I would have as an implementer: >>> >>> 1. Section 2 of RFC8414 >>> says token_endpoint >>> =E2=80=9Cis REQUIRED unless only the implicit grant type is supporte= d.=E2=80=9D So what >>> does the mTLS-only AS put here? >>> 2. The claims for these other endpoints are OPTIONAL, potentially >>> leading to inconsistency depending on how #1 gets decided. >>> 3. The example usage of the token_endpoint_auth_methods property >>> given earlier is incompatible with RFC8414, since some of its conten= ts are >>> only valid for the non-mTLS endpoints, and others are only valid for= the >>> mTLS endpoints. Hence this question. >>> 4. This introduces a new metadata property that could impact how >>> other specs should extend AS metadata. That needs to be addressed. >>> >>> >>> >>> I could go on for client points but you already get the point. Though >>> I=E2=80=99ll share that #3 is real and once forced me to roll back an u= pdate to the >>> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>> >>> >>> I don=E2=80=99t necessarily think an AS metadata property is wrong per = se, but >>> understand that you=E2=80=99re bolting a layer of flexibility onto a st= andard that >>> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadat= a proposal as it=E2=80=99s >>> been discussed here sufficiently deals with the fallout from that. In m= y >>> view this is a complex enough issue and it=E2=80=99s for a nuanced enou= gh use case >>> (as far as I can tell from discussion? Please correct me if I=E2=80=99m= wrong) that >>> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Ser= ver Metadata >>> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Monday, February 4, 2019 at 5:28 AM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> Those points of confusion strike me as somewhat hypothetical or >>> hyperbolic. But your general point is taken and your position of being = anti >>> additional metadata on this issue is noted. >>> >>> >>> All of which leaves me a bit uncertain about how to proceed. There seem >>> to be a range of opinions on this point and gauging consensus is provin= g >>> elusive for me. That's confounded by my own opinion on it being somewha= t >>> fluid. >>> >>> >>> And I'd really like to post an update to this draft about a month or tw= o >>> ago. >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: >>> >>> Confusion from the AS=E2=80=99s perspective: >>> >>> 1. If I only support mTLS, do I need to include both >>> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_= uri? Or >>> set it to the empty string? >>> 2. What if I only support mTLS for the token endpoint, but not >>> revocation or user info? >>> 3. How do I specify authentication methods for the mTLS token >>> endpoint? Does token_endpoint_auth_methods apply to both the mTLS an= d >>> non-mTLS endpoints? >>> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-= enabled >>> device_authorization_endpoint under mtls_endpoints? >>> >>> >>> >>> Confusion from the client=E2=80=99s perspective: >>> >>> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t = know anything >>> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >>> browsers and the AS expects to use that to authenticate me. >>> 2. My AS metadata parser crashed because the mTLS-only AS omitted >>> token_endpoint_uri. >>> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >>> encounter a JSON object as a parameter value. >>> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoint= s, what >>> do I do? >>> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but the= y told me to use HTTPS, >>> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, righ= t? >>> >>> >>> >>> Yes, you can write normative text that answers most of these. But you= =E2=80=99ll >>> have to clearly cover a lot of similar-but-slightly-different scenarios= and >>> be very explicit. And implementers will still get it wrong. The metadat= a >>> change introduces opportunities for confusion and failure that do not e= xist >>> now, and forces them on everyone who supports mTLS. In contrast, the 30= 7 >>> redirect is only required when an AS wants to support both, and is >>> unambiguous in its behavior and meaning. >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> *From:* Brian Campbell >>> *Date:* Friday, February 1, 2019 at 3:17 PM >>> *To:* "Richard Backman, Annabelle" >>> *Cc:* George Fletcher , oauth >>> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> It doesn't seem like that confusing or large of a change to me - if the >>> client is doing MTLS and the given endpoint is present in `mtls_endpoin= ts`, >>> then it uses that one. Otherwise it uses the regular endpoint. It give= s an >>> AS a lot of flexibility in deployment options. I personally think getti= ng a >>> 307 approach deployed and working would be more complicated and error >>> prone. >>> >>> >>> It is a minority use case at the moment but there are forces in play, >>> like the push for increased security in general and to have javascript >>> clients use the code flow, that suggest it won't be terribly unusual to= see >>> an AS that wants to support MTLS clients and javascript/spa clients at = the >>> same time. >>> >>> >>> I've personally wavered back and forth in this thread on whether or not >>> to add the new metadata (or something like it). With my reasoning each = way >>> kinda explained somewhere back in the 40 or so messages that make up th= is >>> thread. But it seems like the rough consensus of the group here is in >>> favor of it. >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: >>> >>> This strikes me as a very prominent and confusing change to support wha= t >>> seems to be a minority use case. I=E2=80=99m getting a headache just th= inking about >>> the text needed to clarify when the AS should provide `mtls_endpoints` = and >>> when the client should use that versus using `token_endpoint.` Why is t= he >>> 307 status code insufficient to cover the case where a single AS suppor= ts >>> both mTLS and non-mTLS? >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Friday, February 1, 2019 at 1:31 PM >>> *To:* George Fletcher >> <40aol.com@dmarc......ietf.org>> >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >>> endpoint >>> >>> >>> Yes, that would work. >>> >>> >>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher >> 40aol.com@dmarc.ietf.org> wrote: >>> >>> What if the AS wants to ONLY support MTLS connections. Does it not >>> specify the optional "mtls_endpoints" and just use the normal metadata >>> values? >>> >>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>> >>> It would definitely be optional, apologies if that wasn't made clear. >>> It'd be something to the effect of optional for the AS to include and >>> clients doing MTLS would use it when present in AS metadata. >>> >>> >>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >>> wrote: >>> >>> I'm in favour of the `mtls_endpoints` metadata parameter - although it >>> should be optional. >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000005be2b80581b71c54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps it's due to my own lack of imagination but I d= on't see any new vectors or how the existing mitigations don't work= here too. Please propose some text though, if there's something that s= hould be in the document.

On Tue, Feb 12, 2019 at 8:50 AM Justin Richer= <jricher@mit.edu> wrote:
<= /div>
At the moment, I like this suggestion. It feels a little =E2=80=A6 funny = =E2=80=A6 but that might be just because it=E2=80=99s different from what w= e had before.

We=E2=80=99ll need to have a clear security considerations discussion = about this though, as it does add another vector for a mix-up attack. I dou= bt that at this stage we want to say that there has to be any testable rela= tionship between the values in token_endpoint and mtls_endpoints.token_endpoint, but splitting the author= ization and token endpoints in the discovery document is exactly what lead = to the mix-up attack pattern in the first place. Essentially, what happens = when an attacker crafts a document that says the MTLS token endpoint is theirs and the regular token endpoint= is legit, or vice versa?

=E2=80=94 Justin

On Feb 11, 2019, at 7:26 AM, Brian Campbell <bcampbell=3D40= pingidentity.com@dmarc.ietf.org> wrote:

It's been pointed out that the potential issue is not = isolated to the just token endpoint but that revocation, introspection, etc= . could be impacted as well. So,=C2=A0 at this point, the proposal on the t= able is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON obj= ect which itself contains endpoints that, when present, a client doing MTLS= would use rather than the regular endpoints.=C2=A0 A straw-man example mig= ht look like this=C2=A0

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"clie= nt_secret_basic","tls_client_auth", "none"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0= =C2=A0"mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example..com/revo&quo= t;
=C2=A0 }
}

A client doing MTLS would look for and give precedence to an endpoint = under "mtls_endpoints" while falling back to use the normal endpo= int from the top level of metadata when/if its not in "mtls_endpoints&= quot;.

The idea being that "regular" clients (those not doing MTLS) will= use the regular endpoints. And only the host/port of the endpoints listed = in mtls_endpoints will be set up to request TLS client certificates during = handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided = for all the other regular clients that are not going to do MTLS - including= and most importantly in-browser javascript clients where there can be less= than desirable UI presented to the end-user.

I'm struggling, however, to adequately gauge whether or not there&= #39;s sufficient consensus to go ahead with the update. There's been so= me support for it voiced. As well as talk of other approaches that could be= alternatives or additional measures. And also some vocal opposition to it.=C2=A0=C2=A0


On Sat, Feb 9, 2019 at 3:09 AM Domini= ck Baier <dbaier@leastprivilege.com> wrote:
We are currently = implementing MTLS in IdentityServer.

Our approach will= be that we=E2=80=99ll offer a separate token endpoint that supports client= certs. Are you planning on adding an official endpoint name for discovery?= Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D.

Thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 7. February 2019 at 22:36:55, Brian Campb= ell (bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a go= od reminder that even a seemingly innocuous change that should be backwards= compatible can break things unexpectedly..





On Thu, Feb 7, 2019 at 8:57 AM Richar= d Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that = all the properties in the JSON object returned from our userinfo endpoint w= ere scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that = even a seemingly innocuous change that should be backwards compatible can f= orce more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0
=C2=A0

From:=C2=A0Brian Campbell <bcampbell@pingidentity.com>=
Date:=C2=A0Wednesday, February 6, 2019 at 11:30 AM
To:=C2=A0"Richard Backman, Annabelle" <richanna=3D40amazon.com@dmar= c.ietf.org>
Cc:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>, oauth &= lt;oauth@ietf.org&g= t;
Subject:=C2=A0Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-brows= er clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what c= ould have gone wrong with or how token_endpoint_auth_methods broke somethin= g with the user info endpoint. If you have the time and/or it'd be info= rmative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pin= gidentity.com> wrote:

It may well be due to my own intellectual shortcomin= gs but these issues/questions/confusion-points are not resonating for me as= being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being he= ard though.

=C2=A0
=C2=A0
=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414=C2=A0says token_endpoint =E2=80=9Cis REQUIRED unles= s only the implicit grant type is supported.=E2=80=9D So what does the mTLS= -only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier= is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question.
  4. This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed.
=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good= times.= =C2=A0=F0= =9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I = don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed he= re sufficiently deals with the fallout from that. In my view this is a comple= x enough issue and it=E2=80=99s for a nuanced enough use case (as far as I = can tell from discussion? Please correct me if I=E2=80=99m wrong) that we s= hould punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the= door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0
=C2=A0

From:=C2=A0OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org<= /a>>
Date:=C2=A0Monday, February 4, 2019 at 5:28 AM
To:=C2=A0"Richard Backman, Annabelle" <richanna=3D40amazon.com@dmar= c.ietf.org>
Cc:=C2=A0oauth <oauth@ietf.org>
Subject:=C2=A0Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-brows= er clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion o= n it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?
=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?
=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still= get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces = them on everyone who supports mTLS. In contrast, the 307 redirect is only r= equired when an AS wants to support both, and is unambiguous in its behavio= r and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0
=C2=A0

From:=C2=A0Brian Campbell <bcampbell=3D40pingidentity.= com@dmarc.ietf.org>
Date:=C2=A0Friday, February 1, 2019 at 3:17 PM
To:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>
Cc:=C2=A0George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject:=C2=A0[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser c= lients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the= regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approa= ch deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terri= bly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so mess= ages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0
=C2=A0
=C2=A0
=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should= provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code = insufficient to cover the case where a single AS supports both mTLS and non= -mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0
=C2=A0

From:=C2=A0OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org<= /a>>
Date:=C2=A0Friday, February 1, 2019 at 1:31 PM
To:=C2=A0George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc:=C2=A0oauth <oauth@ietf.org>
Subject:=C2=A0Re: [OAUTH-WG] MTLS and in-browser clients using the tok= en endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS met= adata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender= immediately by e-mail and delete the message and any file attachments from= your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf..org/mailman/listinfo/oauth
=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclos= ure by others is strictly prohibited..=C2=A0 If you have received this comm= unication in error, please notify the sender immediately by e-mail and dele= te the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclos= ure by others is strictly prohibited..=C2=A0 If you have received this comm= unication in error, please notify the sender immediately by e-mail and dele= te the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclos= ure by others is strictly prohibited..=C2=A0 If you have received this comm= unication in error, please notify the sender immediately by e-mail and dele= te the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclos= ure by others is strictly prohibited.=C2=A0 If you have received this commu= nication in error, please notify the sender immediately by e-mail and delet= e the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..=C2=A0 If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.=C2=A0________________= _______________________________=C2=A0
OAuth mailing list=C2=A0
OAuth@ietf.org=C2=A0<= br> h= ttps://www.ietf.org/mailman/listinfo/oauth=C2=A0

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..=C2=A0 If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you._______________________________________________=
OAuth mailing list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000005be2b80581b71c54-- From nobody Tue Feb 12 11:47:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDCE12785F for ; Tue, 12 Feb 2019 11:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.801 X-Spam-Level: X-Spam-Status: No, score=-11.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3Pv5u7Xa2Pt for ; Tue, 12 Feb 2019 11:47:08 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC61130DC0 for ; Tue, 12 Feb 2019 11:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1550000828; x=1581536828; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fY1n26BS4ucUR1nnWO4JgXeMnPbdwAtFTqXnmkgQyaA=; b=B7wIKzMu4kHMA641zMY13QbjUEq9TV1NqkAWkMSX8FF6vGVtmuRT/aTg GIQsxoCNng80DHUJUsf6gs5agOcy8xl6sf2Y4ZV6kfN0DQ2aF3as3R+o3 EYpFYUjpFBMa9pFX/XGXTt8QG145pQioNnu6epcAp8/kiWYHtSe8rdxvN c=; X-IronPort-AV: E=Sophos;i="5.58,362,1544486400"; d="scan'208,217";a="782479980" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2b-c300ac87.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2019 19:47:06 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2b-c300ac87.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id x1CJl6KG032164 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Feb 2019 19:47:06 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Feb 2019 19:47:06 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Feb 2019 19:47:05 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Tue, 12 Feb 2019 19:47:05 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell , "Dominick Baier" CC: oauth Thread-Topic: [OAUTH-WG] MTLS token endoint & discovery Thread-Index: AQHUwF+tRWyMOv1EVkK3Bn3jwrq7jqXaiS+AgAEmvgCAANjXAP//h9UA Date: Tue, 12 Feb 2019 19:47:05 +0000 Message-ID: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.245] Content-Type: multipart/alternative; boundary="_000_DDDC7C8460FF43CDBC1FE13CD6937655amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 19:47:13 -0000 --_000_DDDC7C8460FF43CDBC1FE13CD6937655amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IG9wcG9zZWQgdG8gaW50cm9kdWNpbmcgYSBtZXRhZGF0YSBjaGFuZ2UsIGlmIHRo ZSBzY2VuYXJpbyBpcyByZWxldmFudCBhbmQgb3RoZXIgYXBwcm9hY2hlcyBjYW7igJl0IGFkZXF1 YXRlbHkgYWRkcmVzcyBpdCDigJMgYW5kIEnigJlsbCByZWFkaWx5IGdyYW50IHRoYXQgd2UgcHJv YmFibHkgZG9u4oCZdCB3YW50IHRvIGRlcGVuZCBvbiBjb25zaXN0ZW5jeSBvZiBicm93c2VyIGJl aGF2aW9yIGF0IHRoZSBpbnRlcnNlY3Rpb24gb2YgY2xpZW50IGNlcnRpZmljYXRlcyBhbmQgQWNj ZXNzLUNvbnRyb2wtQWxsb3ctQ3JlZGVudGlhbHMuIEJ1dCBjYXJlIG5lZWRzIHRvIGJlIHRha2Vu IGluIGRlc2lnbmluZyB0aGF0IG1ldGFkYXRhIHRvIGF2b2lkIHZpb2xhdGluZyBvciBvdGhlcndp c2UgbmVnYXRpdmVseSBpbXBhY3RpbmcgdXNhZ2Ugb2YgUkZDODQxNC4NCg0KQWxvbmcgdGhvc2Ug bGluZXMsIGluc3RlYWQgb2YgYWRkaW5nIGFuIOKAnG10bHNfZW5kcG9pbnRz4oCdIG1ldGFkYXRh IHBhcmFtZXRlciwgd2UgY291bGQgYWRkIGFuIOKAnG10bHNfYWx0ZXJuYXRlX21ldGFkYXRh4oCd IHBhcmFtZXRlciB3aG9zZSB2YWx1ZSBpcyB0aGUgVVJMIG9mIGFuIGFsdGVybmF0ZSBtZXRhZGF0 YSBkb2N1bWVudCBpbnRlbmRlZCBmb3IgY2xpZW50cyB1c2luZyBtVExTLiBBbiBtVExTLW9wdGlv bmFsIEFTIGNvdWxkIGhhdmUgdHdvIGRpZmZlcmVudCBtZXRhZGF0YSBkb2N1bWVudHMgZm9yIG1U TFMgYW5kIG5vbi1tVExTIGNsaWVudHMsIHJlZHVjaW5nIHRoZSBtVExTLW9wdGlvbmFsIHNjZW5h cmlvIHRvIHRoZSBtVExTLW9ubHkgc2NlbmFyaW8uIFRoaXMgc2lkZXN0ZXBzIHRoZSBjaGFsbGVu Z2VzIG9mIGFsaWduaW5nIHRoZSDigJxlaXRoZXIvb3LigJ0gc2VtYW50aWNzIG9mIG1UTFMtb3B0 aW9uYWwgd2l0aCBzb21lIG9mIHRoZSByaWdpZCBwYXJhbWV0ZXIgZGVmaW5pdGlvbnMgaW4gUkZD ODQxNCAoc2VlOiB0b2tlbl9lbmRwb2ludCwgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1 cHBvcnRlZCkuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkN Cg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn Pg0KRGF0ZTogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQgMTA6NTggQU0NClRvOiBEb21p bmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNVExTIHRva2VuIGVuZG9pbnQgJiBk aXNjb3ZlcnkNCg0KVGhhbmtzIGZvciB0aGUgaW5wdXQsIERvbWluaWNrLg0KDQpJJ2Qgc2FpZCBw cmV2aW91c2x5IHRoYXQgSSB3YXMgaGF2aW5nIHRyb3VibGUgYWRlcXVhdGVseSBnYXVnaW5nIHdo ZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0 aCB0aGUgdXBkYXRlLiBJIHdhcyBldmVuIHRoaW5raW5nIG9mIGFza2luZyB0aGUgY2hhaXJzIGFi b3V0IGEgY29uc2Vuc3VzIGNhbGwgZHVyaW5nIHRoZSBvZmZpY2UgaG91cnMgbWVldGluZyB5ZXN0 ZXJkYXkuIEJ1dCBpdCBnb3QgY2FuY2VsZWQuIEFuZCBsb29raW5nIGFnYWluIGJhY2sgb3ZlciB0 aGUgZGlzY3Vzc2lvbiwgSSBkb24ndCBiZWxpZXZlIGEgY29uc2Vuc3VzIGNhbGwgaXMgbmVjZXNz YXJ5LiBUaGVyZSdzIGJlZW4gYSBsb3Qgb2YgZ2VuZXJhbCBkaXNjdXNzaW9uIG92ZXIgdGhlIGxh c3Qgc2V2ZXJhbCB3ZWVrcyBkdXJpbmcgd2hpY2ggc2V2ZXJhbCBmb2xrcyBoYXZlIHN0YXRlZCBz dXBwb3J0IGZvciB0aGUgcHJvcG9zYWwgd2hpbGUgdGhlcmUncyBiZWVuIG9ubHkgb25lIHZvaWNl IG9mIGRpcmVjdCBkaXNzZW50LiBUaGF0IHNlZW1zIGxpa2Ugcm91Z2ggZW5vdWdoIGNvbnNlbnN1 cyBhbmQsIGFzIHN1Y2gsIEkgcGxhbiB0byBtYWtlIHRoZSBjaGFuZ2UgaW4gdGhlIG5leHQgcmV2 aXNpb24gb2YgdGhlIGRvY3VtZW50ICh3aGljaCBzaG91bGQgYmUgZG9uZSBzb29uKS4gQ2hhaXJz LCBwbGVhc2UgbGV0IG1lIGtub3csIGlmIHlvdSBiZWxpZXZlIHRoZSBzaXR1YXRpb24gd2FycmFu dHMgYSBkaWZmZXJlbnQgY291cnNlIG9mIGFjdGlvbi4NCg0KDQoNCk9uIE1vbiwgRmViIDExLCAy MDE5IGF0IDExOjAxIFBNIERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t PG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQpJTUhPIHRoYXTigJlz IGEgcmVhc29uYWJsZSBhbmQgcHJhZ21hdGljIG9wdGlvbi4NCg0KVGhhbmtzDQrigJTigJTigJQN CkRvbWluaWNrDQoNCg0KT24gMTEuIEZlYnJ1YXJ5IDIwMTkgYXQgMTM6MjY6MzcsIEJyaWFuIENh bXBiZWxsIChiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20+KSB3cm90ZToNCkl0J3MgYmVlbiBwb2ludGVkIG91dCB0aGF0IHRoZSBwb3Rl bnRpYWwgaXNzdWUgaXMgbm90IGlzb2xhdGVkIHRvIHRoZSBqdXN0IHRva2VuIGVuZHBvaW50IGJ1 dCB0aGF0IHJldm9jYXRpb24sIGludHJvc3BlY3Rpb24sIGV0Yy4gY291bGQgYmUgaW1wYWN0ZWQg YXMgd2VsbC4gU28sICBhdCB0aGlzIHBvaW50LCB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlIGlz IHRvIGFkZCBhIG5ldyBvcHRpb25hbCBBUyBtZXRhZGF0YSBwYXJhbWV0ZXIgbmFtZWQgJ210bHNf ZW5kcG9pbnRzJyB0aGF0J3MgdmFsdWUgd2UgYmUgYSBKU09OIG9iamVjdCB3aGljaCBpdHNlbGYg Y29udGFpbnMgZW5kcG9pbnRzIHRoYXQsIHdoZW4gcHJlc2VudCwgYSBjbGllbnQgZG9pbmcgTVRM UyB3b3VsZCB1c2UgcmF0aGVyIHRoYW4gdGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiAgQSBzdHJhdy1t YW4gZXhhbXBsZSBtaWdodCBsb29rIGxpa2UgdGhpcw0Kew0KICAiaXNzdWVyIjoiaHR0cHM6Ly9z ZXJ2ZXIuZXhhbXBsZS5jb20iLA0KICAiYXV0aG9yaXphdGlvbl9lbmRwb2ludCI6Imh0dHBzOi8v c2VydmVyLmV4YW1wbGUuY29tL2F1dGh6IiwNCiAgInRva2VuX2VuZHBvaW50IjoiaHR0cHM6Ly9z ZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iLA0KICAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2Rz X3N1cHBvcnRlZCI6WyAgImNsaWVudF9zZWNyZXRfYmFzaWMiLCJ0bHNfY2xpZW50X2F1dGgiLCAi bm9uZSJdLA0KICAidXNlcmluZm9fZW5kcG9pbnQiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNv bS91c2VyaW5mbyIsDQogICJyZXZvY2F0aW9uX2VuZHBvaW50IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhh bXBsZS5jb20vcmV2byIsDQogICJqd2tzX3VyaSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29t L2p3a3MuanNvbiIsDQogICJtdGxzX2VuZHBvaW50cyI6ew0KICAgICJ0b2tlbl9lbmRwb2ludCI6 Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS90b2tlbiIsDQogICAgInVzZXJpbmZvX2VuZHBvaW50 IjoiaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3VzZXJpbmZvIiwNCiAgICAicmV2b2NhdGlvbl9l bmRwb2ludCI6Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS9yZXZvPGh0dHBzOi8vbXRscy4uZXhh bXBsZS5jb20vcmV2bz4iDQogIH0NCn0NCg0KQSBjbGllbnQgZG9pbmcgTVRMUyB3b3VsZCBsb29r IGZvciBhbmQgZ2l2ZSBwcmVjZWRlbmNlIHRvIGFuIGVuZHBvaW50IHVuZGVyICJtdGxzX2VuZHBv aW50cyIgd2hpbGUgZmFsbGluZyBiYWNrIHRvIHVzZSB0aGUgbm9ybWFsIGVuZHBvaW50IGZyb20g dGhlIHRvcCBsZXZlbCBvZiBtZXRhZGF0YSB3aGVuL2lmIGl0cyBub3QgaW4gIm10bHNfZW5kcG9p bnRzIi4NCg0KVGhlIGlkZWEgYmVpbmcgdGhhdCAicmVndWxhciIgY2xpZW50cyAodGhvc2Ugbm90 IGRvaW5nIE1UTFMpIHdpbGwgdXNlIHRoZSByZWd1bGFyIGVuZHBvaW50cy4gQW5kIG9ubHkgdGhl IGhvc3QvcG9ydCBvZiB0aGUgZW5kcG9pbnRzIGxpc3RlZCBpbiBtdGxzX2VuZHBvaW50cyB3aWxs IGJlIHNldCB1cCB0byByZXF1ZXN0IFRMUyBjbGllbnQgY2VydGlmaWNhdGVzIGR1cmluZyBoYW5k c2hha2UuIFRodXMgYW55IHBvdGVudGlhbCBpbXBhY3Qgb2YgdGhlIENlcnRpZmljYXRlUmVxdWVz dCBtZXNzYWdlIGJlaW5nIHNlbnQgaW4gdGhlIFRMUyBoYW5kc2hha2UgY2FuIGJlIGF2b2lkZWQg Zm9yIGFsbCB0aGUgb3RoZXIgcmVndWxhciBjbGllbnRzIHRoYXQgYXJlIG5vdCBnb2luZyB0byBk byBNVExTIC0gaW5jbHVkaW5nIGFuZCBtb3N0IGltcG9ydGFudGx5IGluLWJyb3dzZXIgamF2YXNj cmlwdCBjbGllbnRzIHdoZXJlIHRoZXJlIGNhbiBiZSBsZXNzIHRoYW4gZGVzaXJhYmxlIFVJIHBy ZXNlbnRlZCB0byB0aGUgZW5kLXVzZXIuDQoNCkknbSBzdHJ1Z2dsaW5nLCBob3dldmVyLCB0byBh ZGVxdWF0ZWx5IGdhdWdlIHdoZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5z dXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBUaGVyZSdzIGJlZW4gc29tZSBzdXBwb3J0 IGZvciBpdCB2b2ljZWQuIEFzIHdlbGwgYXMgdGFsayBvZiBvdGhlciBhcHByb2FjaGVzIHRoYXQg Y291bGQgYmUgYWx0ZXJuYXRpdmVzIG9yIGFkZGl0aW9uYWwgbWVhc3VyZXMuIEFuZCBhbHNvIHNv bWUgdm9jYWwgb3Bwb3NpdGlvbiB0byBpdC4NCg0KDQpPbiBTYXQsIEZlYiA5LCAyMDE5IGF0IDM6 MDkgQU0gRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRi YWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNCldlIGFyZSBjdXJyZW50bHkgaW1wbGVt ZW50aW5nIE1UTFMgaW4gSWRlbnRpdHlTZXJ2ZXIuDQoNCk91ciBhcHByb2FjaCB3aWxsIGJlIHRo YXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBvaW50IHRoYXQgc3VwcG9ydHMg Y2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGluZyBhbiBvZmZpY2lhbCBlbmRw b2ludCBuYW1lIGZvciBkaXNjb3Zlcnk/IFJpZ2h0IG5vdyB3ZSBhcmUgdXNpbmcg4oCcbXRsc190 b2tlbl9lbmRwb2ludOKAnS4NCg0KVGhhbmtzDQrigJTigJTigJQNCkRvbWluaWNrDQoNCg0KT24g Ny4gRmVicnVhcnkgMjAxOSBhdCAyMjozNjo1NSwgQnJpYW4gQ2FtcGJlbGwgKGJjYW1wYmVsbD00 MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmJjYW1wYmVsbD00MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNCkFoIHllcywgdGhhdCBtYWtlcyBz ZW5zZS4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nLiBBbmQgaXQgaXMgaW5kZWVkIGEgZ29vZCByZW1p bmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5ub2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBi ZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gYnJlYWsgdGhpbmdzIHVuZXhwZWN0ZWRseS4uDQoN Cg0KDQoNCg0KT24gVGh1LCBGZWIgNywgMjAxOSBhdCA4OjU3IEFNIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t Pj4gd3JvdGU6DQpUaGUgY2FzZSBJ4oCZbSByZWZlcmVuY2luZyBkaWRu4oCZdCBzcGVjaWZpY2Fs bHkgaW52b2x2ZSBBUyBtZXRhZGF0YS4gV2UgaGFkIGNsaWVudHMgaW4gdGhlIHdpbGQgdGhhdCBh c3N1bWVkIHRoYXQgYWxsIHRoZSBwcm9wZXJ0aWVzIGluIHRoZSBKU09OIG9iamVjdCByZXR1cm5l ZCBmcm9tIG91ciB1c2VyaW5mbyBlbmRwb2ludCB3ZXJlIHNjYWxhciBzdHJpbmdzLiBUaGlzIGJy b2tlIHdoZW4gd2UgaW50cm9kdWNlZCBhIG5ldyBwcm9wZXJ0eSB3aG9zZSB2YWx1ZSB3YXMgYSBK U09OIG9iamVjdC4gSXQgd2FzIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkg aW5ub2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4g Zm9yY2UgbW9yZSB3b3JrIG9uIGNsaWVudHMgdGhhbiB3ZSBleHBlY3QuDQoNCi0tDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxOSBhdCAxMTozMCBBTQ0K VG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBk bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiAi UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBS ZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0K DQpBbmQgSSdtIGhvbmVzdGx5IHJlYWxseSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IGNvdWxkIGhh dmUgZ29uZSB3cm9uZyB3aXRoIG9yIGhvdyB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYnJv a2Ugc29tZXRoaW5nIHdpdGggdGhlIHVzZXIgaW5mbyBlbmRwb2ludC4gSWYgeW91IGhhdmUgdGhl IHRpbWUgYW5kL29yIGl0J2QgYmUgaW5mb3JtYXRpdmUgdG8gdGhpcyBoZXJlIGxpdHRsZSBkaXNj dXNzaW9uLCBwbGVhc2UgZXhwbGFpbiB0aGF0IG9uZSBhIGJpdCBtb3JlLg0KDQpPbiBXZWQsIEZl YiA2LCAyMDE5IGF0IDEyOjE1IFBNIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCiJmYXIi IHNob3VsZCBoYXZlIHNhaWQgImZhaXIiIGluIHRoZSBwcmV2aW91cyBtZXNzYWdlDQoNCg0KDQoN Cg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCA0OjM1IFBNIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3 cm90ZToNCkl0IG1heSB3ZWxsIGJlIGR1ZSB0byBteSBvd24gaW50ZWxsZWN0dWFsIHNob3J0Y29t aW5ncyBidXQgdGhlc2UgaXNzdWVzL3F1ZXN0aW9ucy9jb25mdXNpb24tcG9pbnRzIGFyZSBub3Qg cmVzb25hdGluZyBmb3IgbWUgYXMgYmVpbmcgcHJvYmxlbWF0aWMuDQoNClRoZSBtb3JlIGdlbmVy YWwgc3RhbmNlIG9mICJ0aGlzIGlzbid0IG5lZWRlZCBvciB3b3J0aCBpdCBpbiB0aGlzIGRvY3Vt ZW50IiAoSSB0aGluayB0aGF0J3MgZmFyPykgaXMgYmVpbmcgaGVhcmQgdGhvdWdoLg0KDQoNCg0K T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQyIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl IDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLi4ub3JnPj4gd3JvdGU6DQooVEw7RFI6IHB1bnQgQVMgbWV0YWRhdGEgdG8g YSBzZXBhcmF0ZSBkcmFmdCkNCg0KQVMgcG9pbnRzICMxLTMgYXJlIGFsbCBxdWVzdGlvbnMgSSB3 b3VsZCBoYXZlIGFzIGFuIGltcGxlbWVudGVyOg0KDQogIDEuICBTZWN0aW9uIDIgb2YgUkZDODQx NDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQxNCNzZWN0aW9uLTI+IHNheXMgdG9r ZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlSRUQgdW5sZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50 IHR5cGUgaXMgc3VwcG9ydGVkLuKAnSBTbyB3aGF0IGRvZXMgdGhlIG1UTFMtb25seSBBUyBwdXQg aGVyZT8NCiAgMi4gIFRoZSBjbGFpbXMgZm9yIHRoZXNlIG90aGVyIGVuZHBvaW50cyBhcmUgT1BU SU9OQUwsIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8gaW5jb25zaXN0ZW5jeSBkZXBlbmRpbmcgb24g aG93ICMxIGdldHMgZGVjaWRlZC4NCiAgMy4gIFRoZSBleGFtcGxlIHVzYWdlIG9mIHRoZSB0b2tl bl9lbmRwb2ludF9hdXRoX21ldGhvZHMgcHJvcGVydHkgZ2l2ZW4gZWFybGllciBpcyBpbmNvbXBh dGlibGUgd2l0aCBSRkM4NDE0LCBzaW5jZSBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUgb25seSB2 YWxpZCBmb3IgdGhlIG5vbi1tVExTIGVuZHBvaW50cywgYW5kIG90aGVycyBhcmUgb25seSB2YWxp ZCBmb3IgdGhlIG1UTFMgZW5kcG9pbnRzLiBIZW5jZSB0aGlzIHF1ZXN0aW9uLg0KICA0LiAgVGhp cyBpbnRyb2R1Y2VzIGEgbmV3IG1ldGFkYXRhIHByb3BlcnR5IHRoYXQgY291bGQgaW1wYWN0IGhv dyBvdGhlciBzcGVjcyBzaG91bGQgZXh0ZW5kIEFTIG1ldGFkYXRhLiBUaGF0IG5lZWRzIHRvIGJl IGFkZHJlc3NlZC4NCg0KSSBjb3VsZCBnbyBvbiBmb3IgY2xpZW50IHBvaW50cyBidXQgeW91IGFs cmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdoIEnigJlsbCBzaGFyZSB0aGF0ICMzIGlzIHJlYWwg YW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwgYmFjayBhbiB1cGRhdGUgdG8gdGhlIExvZ2luIHdp dGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW504oCmZ29vZCB0aW1lcy4g8J+Ygw0KDQpJIGRvbuKA mXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEgcHJvcGVydHkgaXMgd3JvbmcgcGVy IHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJvbHRpbmcgYSBsYXllciBvZiBmbGV4 aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZdCBkZXNpZ25lZCBmb3IgdGhhdCwg YW5kIEkgZG9u4oCZdCB0aGluayB0aGUgbWV0YWRhdGEgcHJvcG9zYWwgYXMgaXTigJlzIGJlZW4g ZGlzY3Vzc2VkIGhlcmUgc3VmZmljaWVudGx5IGRlYWxzIHdpdGggdGhlIGZhbGxvdXQgZnJvbSB0 aGF0LiBJbiBteSB2aWV3IHRoaXMgaXMgYSBjb21wbGV4IGVub3VnaCBpc3N1ZSBhbmQgaXTigJlz IGZvciBhIG51YW5jZWQgZW5vdWdoIHVzZSBjYXNlIChhcyBmYXIgYXMgSSBjYW4gdGVsbCBmcm9t IGRpc2N1c3Npb24/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEnigJltIHdyb25nKSB0aGF0IHdlIHNo b3VsZCBwdW50IGl0IHRvIGEgc2VwYXJhdGUgZHJhZnQgKGUuZy4sIOKAnEF1dGhvcml6YXRpb24g U2VydmVyIE1ldGFkYXRhIEV4dGVuc2lvbnMgZm9yIG1UTFMgSHlicmlkc+KAnSkgYW5kIGdldCBt VExTIG91dCB0aGUgZG9vci4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJ ZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsIDxiY2Ft cGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVu dGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5 IGF0IDU6MjggQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYT00 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRm Lm9yZz4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExTIGFu ZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNClRob3NlIHBv aW50cyBvZiBjb25mdXNpb24gc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBo eXBlcmJvbGljLiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0 aW9uIG9mIGJlaW5nIGFudGkgYWRkaXRpb25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzIG5v dGVkLg0KDQpBbGwgb2Ygd2hpY2ggbGVhdmVzIG1lIGEgYml0IHVuY2VydGFpbiBhYm91dCBob3cg dG8gcHJvY2VlZC4gVGhlcmUgc2VlbSB0byBiZSBhIHJhbmdlIG9mIG9waW5pb25zIG9uIHRoaXMg cG9pbnQgYW5kIGdhdWdpbmcgY29uc2Vuc3VzIGlzIHByb3ZpbmcgZWx1c2l2ZSBmb3IgbWUuIFRo YXQncyBjb25mb3VuZGVkIGJ5IG15IG93biBvcGluaW9uIG9uIGl0IGJlaW5nIHNvbWV3aGF0IGZs dWlkLg0KDQpBbmQgSSdkIHJlYWxseSBsaWtlIHRvIHBvc3QgYW4gdXBkYXRlIHRvIHRoaXMgZHJh ZnQgYWJvdXQgYSBtb250aCBvciB0d28gYWdvLg0KDQoNCg0KDQoNCg0KT24gRnJpLCBGZWIgMSwg MjAxOSBhdCA1OjAzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4u b3JnPj4gd3JvdGU6DQpDb25mdXNpb24gZnJvbSB0aGUgQVPigJlzIHBlcnNwZWN0aXZlOg0KDQog IDEuICBJZiBJIG9ubHkgc3VwcG9ydCBtVExTLCBkbyBJIG5lZWQgdG8gaW5jbHVkZSBib3RoIHRv a2VuX2VuZHBvaW50X3VyaSBhbmQgbXRsc19lbmRwb2ludHM/IFNob3VsZCBJIG9taXQgdG9rZW5f ZW5kcG9pbnRfdXJpPyBPciBzZXQgaXQgdG8gdGhlIGVtcHR5IHN0cmluZz8NCiAgMi4gIFdoYXQg aWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQgbm90IHJl dm9jYXRpb24gb3IgdXNlciBpbmZvPw0KICAzLiAgSG93IGRvIEkgc3BlY2lmeSBhdXRoZW50aWNh dGlvbiBtZXRob2RzIGZvciB0aGUgbVRMUyB0b2tlbiBlbmRwb2ludD8gRG9lcyB0b2tlbl9lbmRw b2ludF9hdXRoX21ldGhvZHMgYXBwbHkgdG8gYm90aCB0aGUgbVRMUyBhbmQgbm9uLW1UTFMgZW5k cG9pbnRzPw0KICA0LiAgSeKAmW0gdXNpbmcgdGhlIE9BdXRoIDIuMCBEZXZpY2UgRmxvdy4gRG8g SSBpbmNsdWRlIGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRob3JpemF0aW9uX2VuZHBvaW50IHVu ZGVyIG10bHNfZW5kcG9pbnRzPw0KDQpDb25mdXNpb24gZnJvbSB0aGUgY2xpZW504oCZcyBwZXJz cGVjdGl2ZToNCg0KICAxLiAgQXMgZmFyIGFzIEkga25vdywgSeKAmW0gYSBwdWJsaWMgY2xpZW50 LCBhbmQgZG9u4oCZdCBrbm93IGFueXRoaW5nIGFib3V0IG1UTFMsIGJ1dCB0aGUgSVQgYWRtaW5z IGluc3RhbGxlZCBjbGllbnQgY2VydHMgaW4gdGhlaXIgdXNlcnPigJkgYnJvd3NlcnMgYW5kIHRo ZSBBUyBleHBlY3RzIHRvIHVzZSB0aGF0IHRvIGF1dGhlbnRpY2F0ZSBtZS4NCiAgMi4gIE15IEFT IG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgdGhlIG1UTFMtb25seSBBUyBvbWl0dGVk IHRva2VuX2VuZHBvaW50X3VyaS4NCiAgMy4gIE15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVk IGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRvIGVuY291bnRlciBhIEpTT04gb2JqZWN0IGFz IGEgcGFyYW1ldGVyIHZhbHVlLg0KICA0LiAgVGhlIG1UTFMtb25seSBBUyBkaWRu4oCZdCBwcm92 aWRlIGEgdmFsdWUgZm9yIG10bHNfZW5kcG9pbnRzLCB3aGF0IGRvIEkgZG8/DQogIDUuICBJIGRv buKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKAnSBtZWFucywgYnV0IHRoZXkgdG9sZCBtZSB0byB1 c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0aGUgb25lIHdpdGgg4oCcdGxz4oCdIGluIGl0cyBu YW1lLCByaWdodD8NCg0KWWVzLCB5b3UgY2FuIHdyaXRlIG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5z d2VycyBtb3N0IG9mIHRoZXNlLiBCdXQgeW914oCZbGwgaGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEg bG90IG9mIHNpbWlsYXItYnV0LXNsaWdodGx5LWRpZmZlcmVudCBzY2VuYXJpb3MgYW5kIGJlIHZl cnkgZXhwbGljaXQuIEFuZCBpbXBsZW1lbnRlcnMgd2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRo ZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9kdWNlcyBvcHBvcnR1bml0aWVzIGZvciBjb25mdXNpb24g YW5kIGZhaWx1cmUgdGhhdCBkbyBub3QgZXhpc3Qgbm93LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZl cnlvbmUgd2hvIHN1cHBvcnRzIG1UTFMuIEluIGNvbnRyYXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlz IG9ubHkgcmVxdWlyZWQgd2hlbiBhbiBBUyB3YW50cyB0byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1 bmFtYmlndW91cyBpbiBpdHMgYmVoYXZpb3IgYW5kIG1lYW5pbmcuDQoNCi0tDQpBbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5n aWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwg MjAxOSBhdCAzOjE3IFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFu bmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+DQpDYzogR2VvcmdlIEZs ZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPj4sIG9hdXRo IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1VOVkVS SUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMg dXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNCkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29u ZnVzaW5nIG9yIGxhcmdlIG9mIGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2lu ZyBNVExTIGFuZCB0aGUgZ2l2ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2lu dHNgLCB0aGVuIGl0IHVzZXMgdGhhdCBvbmUuICBPdGhlcndpc2UgaXQgdXNlcyB0aGUgcmVndWxh ciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4gQVMgYSBsb3Qgb2YgZmxleGliaWxpdHkgaW4gZGVwbG95 bWVudCBvcHRpb25zLiBJIHBlcnNvbmFsbHkgdGhpbmsgZ2V0dGluZyBhIDMwNyBhcHByb2FjaCBk ZXBsb3llZCBhbmQgd29ya2luZyB3b3VsZCBiZSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBw cm9uZS4NCg0KSXQgaXMgYSBtaW5vcml0eSB1c2UgY2FzZSBhdCB0aGUgbW9tZW50IGJ1dCB0aGVy ZSBhcmUgZm9yY2VzIGluIHBsYXksIGxpa2UgdGhlIHB1c2ggZm9yIGluY3JlYXNlZCBzZWN1cml0 eSBpbiBnZW5lcmFsIGFuZCB0byBoYXZlIGphdmFzY3JpcHQgY2xpZW50cyB1c2UgdGhlIGNvZGUg ZmxvdywgdGhhdCBzdWdnZXN0IGl0IHdvbid0IGJlIHRlcnJpYmx5IHVudXN1YWwgdG8gc2VlIGFu IEFTIHRoYXQgd2FudHMgdG8gc3VwcG9ydCBNVExTIGNsaWVudHMgYW5kIGphdmFzY3JpcHQvc3Bh IGNsaWVudHMgYXQgdGhlIHNhbWUgdGltZS4NCg0KSSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFj ayBhbmQgZm9ydGggaW4gdGhpcyB0aHJlYWQgb24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBu ZXcgbWV0YWRhdGEgKG9yIHNvbWV0aGluZyBsaWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFj aCB3YXkga2luZGEgZXhwbGFpbmVkIHNvbWV3aGVyZSBiYWNrIGluIHRoZSA0MCBvciBzbyBtZXNz YWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0aHJlYWQuICBCdXQgaXQgc2VlbXMgbGlrZSB0aGUgcm91 Z2ggY29uc2Vuc3VzIG9mIHRoZSBncm91cCBoZXJlIGlzIGluIGZhdm9yIG9mIGl0Lg0KDQoNCg0K DQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6MTggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24u Y29tQGRtYXJjLmlldGYuLi5vcmc+PiB3cm90ZToNClRoaXMgc3RyaWtlcyBtZSBhcyBhIHZlcnkg cHJvbWluZW50IGFuZCBjb25mdXNpbmcgY2hhbmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVtcyB0byBi ZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ4oCZbSBnZXR0aW5nIGEgaGVhZGFjaGUganVzdCB0aGlu a2luZyBhYm91dCB0aGUgdGV4dCBuZWVkZWQgdG8gY2xhcmlmeSB3aGVuIHRoZSBBUyBzaG91bGQg cHJvdmlkZSBgbXRsc19lbmRwb2ludHNgIGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0 aGF0IHZlcnN1cyB1c2luZyBgdG9rZW5fZW5kcG9pbnQuYCBXaHkgaXMgdGhlIDMwNyBzdGF0dXMg Y29kZSBpbnN1ZmZpY2llbnQgdG8gY292ZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgQVMgc3Vw cG9ydHMgYm90aCBtVExTIGFuZCBub24tbVRMUz8NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJyaWFuIENh bXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogRnJpZGF5LCBGZWJy dWFyeSAxLCAyMDE5IGF0IDE6MzEgUE0NClRvOiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoPTQw YW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhb2wuY29tQGRtYXJjLi4uLi4uaWV0Zi5v cmc+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5n IHRoZSB0b2tlbiBlbmRwb2ludA0KDQpZZXMsIHRoYXQgd291bGQgd29yay4NCg0KT24gRnJpLCBG ZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29t QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToN CldoYXQgaWYgdGhlIEFTIHdhbnRzIHRvIE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rpb25zLiBE b2VzIGl0IG5vdCBzcGVjaWZ5IHRoZSBvcHRpb25hbCAibXRsc19lbmRwb2ludHMiIGFuZCBqdXN0 IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRhIHZhbHVlcz8NCk9uIDEvMTUvMTkgODo0OCBBTSwgQnJp YW4gQ2FtcGJlbGwgd3JvdGU6DQpJdCB3b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFsLCBhcG9s b2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhl IGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9p bmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbiBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0KDQpPbiBU dWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9tZW50 dW1mdC5jby51azxtYWlsdG86ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3JvdGU6DQpJ J20gaW4gZmF2b3VyIG9mIHRoZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAt IGFsdGhvdWdoIGl0IHNob3VsZCBiZSBvcHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZIE5PVElD RTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0 ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkg cmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFp bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlv dXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aD4NCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9y IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5k IGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpD T05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1 cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxl IGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3Ro ZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9U SUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt YXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFu eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMg ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9z dXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxl IGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3Ro ZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_DDDC7C8460FF43CDBC1FE13CD6937655amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIg MTEgNiAzIDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw LmdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21h aWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1t MzczMjQyODAzMDUyOTExODc3MWFpcm1haWxvbiwgbGkuZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3 MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdt YWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFp bG9uLCBkaXYuZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4 NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5 M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmdt YWlsLW1fNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW1fLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFp bC1tXzIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tXy0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwt bV8zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAuZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1 NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYz MTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4 OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmFpcm1haWxvbiwgbGkuZ21haWwtbTYwODQz MTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0 MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5 MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2 NmFpcm1haWxvbiwgZGl2LmdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYx NjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3 MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0 MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtbV82MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbV8tMjM4NjU2MTYxMTMzMTg0NDUwOWdt YWlsLW1fMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW1fLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFp bC1tXzM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tXzUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1t Xzc1OTMwMzM4Mjg4ODc0MTI3NjZhaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2 MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMx NzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5 NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJn bWFpbC1tLTQ5NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzLCBsaS5nbWFpbC1tNjA4NDMxNDgwNTQ5 Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYy MTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFn bWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwt bTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzLCBk aXYuZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDln bWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWls LW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5 MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2 ODY4ODI5MTA0NTY0bS04NTYzMw0KCXttc28tc3R5bGUtbmFtZToiZ21haWwtbV82MDg0MzE0ODA1 NDk3OTQ5NzIyZ21haWwtbV8tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW1fMjE5NjUzMjU0MzEx ODM2MjEzMWdtYWlsLW1fLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tXzM3MzI0MjgwMzA1Mjkx MTg3NzFnbWFpbC1tXzUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tXzc1OTMwMzM4Mjg4ODc0MTI3 NjZnbWFpbC1tXzUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tXy00OTY1ODY2ODY4ODI5MTA0NTY0 bS04NTYzMyI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjMyNTQ2Mjg4 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgwMjA2MzU5MDt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxMDA2MDU3MTEzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ5NTYyNzQ1ODt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMDUxMzQ3NDEwOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoyMTM3MzExMTM0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IG9wcG9zZWQgdG8gaW50cm9kdWNpbmcgYSBt ZXRhZGF0YSBjaGFuZ2UsIGlmIHRoZSBzY2VuYXJpbyBpcyByZWxldmFudCBhbmQgb3RoZXIgYXBw cm9hY2hlcyBjYW7igJl0IGFkZXF1YXRlbHkgYWRkcmVzcyBpdCDigJMgYW5kIEnigJlsbCByZWFk aWx5IGdyYW50IHRoYXQgd2UgcHJvYmFibHkgZG9u4oCZdCB3YW50IHRvIGRlcGVuZCBvbiBjb25z aXN0ZW5jeSBvZiBicm93c2VyIGJlaGF2aW9yIGF0IHRoZSBpbnRlcnNlY3Rpb24NCiBvZiBjbGll bnQgY2VydGlmaWNhdGVzIGFuZCBBY2Nlc3MtQ29udHJvbC1BbGxvdy1DcmVkZW50aWFscy4gQnV0 IGNhcmUgbmVlZHMgdG8gYmUgdGFrZW4gaW4gZGVzaWduaW5nIHRoYXQgbWV0YWRhdGEgdG8gYXZv aWQgdmlvbGF0aW5nIG9yIG90aGVyd2lzZSBuZWdhdGl2ZWx5IGltcGFjdGluZyB1c2FnZSBvZiBS RkM4NDE0Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsb25nIHRob3NlIGxpbmVzLCBpbnN0 ZWFkIG9mIGFkZGluZyBhbiDigJxtdGxzX2VuZHBvaW50c+KAnSBtZXRhZGF0YSBwYXJhbWV0ZXIs IHdlIGNvdWxkIGFkZCBhbiDigJxtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YeKAnSBwYXJhbWV0ZXIg d2hvc2UgdmFsdWUgaXMgdGhlIFVSTCBvZiBhbiBhbHRlcm5hdGUgbWV0YWRhdGEgZG9jdW1lbnQg aW50ZW5kZWQgZm9yIGNsaWVudHMgdXNpbmcgbVRMUy4gQW4gbVRMUy1vcHRpb25hbA0KIEFTIGNv dWxkIGhhdmUgdHdvIGRpZmZlcmVudCBtZXRhZGF0YSBkb2N1bWVudHMgZm9yIG1UTFMgYW5kIG5v bi1tVExTIGNsaWVudHMsIHJlZHVjaW5nIHRoZSBtVExTLW9wdGlvbmFsIHNjZW5hcmlvIHRvIHRo ZSBtVExTLW9ubHkgc2NlbmFyaW8uIFRoaXMgc2lkZXN0ZXBzIHRoZSBjaGFsbGVuZ2VzIG9mIGFs aWduaW5nIHRoZSDigJxlaXRoZXIvb3LigJ0gc2VtYW50aWNzIG9mIG1UTFMtb3B0aW9uYWwgd2l0 aCBzb21lIG9mIHRoZSByaWdpZCBwYXJhbWV0ZXINCiBkZWZpbml0aW9ucyBpbiBSRkM4NDE0IChz ZWU6IHRva2VuX2VuZHBvaW50LCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVk KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsICZs dDtiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5UdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxOSBhdCAxMDo1OCBBTTxicj4NCjxi PlRvOiA8L2I+RG9taW5pY2sgQmFpZXIgJmx0O2RiYWllckBsZWFzdHByaXZpbGVnZS5jb20mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmYW1wOyBkaXNjb3Zl cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBpbnB1dCwg RG9taW5pY2suIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ2Qgc2FpZCBwcmV2aW91c2x5IHRoYXQgSSB3YXMgaGF2aW5nIHRyb3VibGUgYWRl cXVhdGVseSBnYXVnaW5nIHdoZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5z dXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBJIHdhcyBldmVuIHRoaW5raW5nIG9mIGFz a2luZyB0aGUgY2hhaXJzIGFib3V0IGEgY29uc2Vuc3VzIGNhbGwgZHVyaW5nIHRoZSBvZmZpY2Ug aG91cnMgbWVldGluZyB5ZXN0ZXJkYXkuDQogQnV0IGl0IGdvdCBjYW5jZWxlZC4gQW5kIGxvb2tp bmcgYWdhaW4gYmFjayBvdmVyIHRoZSBkaXNjdXNzaW9uLCBJIGRvbid0IGJlbGlldmUgYSBjb25z ZW5zdXMgY2FsbCBpcyBuZWNlc3NhcnkuIFRoZXJlJ3MgYmVlbiBhIGxvdCBvZiBnZW5lcmFsIGRp c2N1c3Npb24gb3ZlciB0aGUgbGFzdCBzZXZlcmFsIHdlZWtzIGR1cmluZyB3aGljaCBzZXZlcmFs IGZvbGtzIGhhdmUgc3RhdGVkIHN1cHBvcnQgZm9yIHRoZSBwcm9wb3NhbCB3aGlsZSB0aGVyZSdz DQogYmVlbiBvbmx5IG9uZSB2b2ljZSBvZiBkaXJlY3QgZGlzc2VudC4gVGhhdCBzZWVtcyBsaWtl IHJvdWdoIGVub3VnaCBjb25zZW5zdXMgYW5kLCBhcyBzdWNoLCBJIHBsYW4gdG8gbWFrZSB0aGUg Y2hhbmdlIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudCAod2hpY2ggc2hvdWxk IGJlIGRvbmUgc29vbikuIENoYWlycywgcGxlYXNlIGxldCBtZSBrbm93LCBpZiB5b3UgYmVsaWV2 ZSB0aGUgc2l0dWF0aW9uIHdhcnJhbnRzIGEgZGlmZmVyZW50DQogY291cnNlIG9mIGFjdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDExLCAyMDE5IGF0IDExOjAxIFBN IERvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhIj5JTUhPIHRoYXTigJlzIGEgcmVhc29uYWJsZSBhbmQgcHJhZ21hdGlj IG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCU4oCU4oCUIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFp bC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0z NzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9uIj4NCk9uIDExLiBGZWJydWFyeSAyMDE5IGF0IDEz OjI2OjM3LCBCcmlhbiBDYW1wYmVsbCAoPGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+ KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JdCdzIGJlZW4gcG9pbnRlZCBvdXQgdGhhdCB0aGUg cG90ZW50aWFsIGlzc3VlIGlzIG5vdCBpc29sYXRlZCB0byB0aGUganVzdCB0b2tlbiBlbmRwb2lu dCBidXQgdGhhdCByZXZvY2F0aW9uLCBpbnRyb3NwZWN0aW9uLCBldGMuIGNvdWxkIGJlIGltcGFj dGVkIGFzIHdlbGwuIFNvLCZuYnNwOyBhdCB0aGlzIHBvaW50LCB0aGUgcHJvcG9zYWwgb24gdGhl IHRhYmxlIGlzDQogdG8gYWRkIGEgbmV3IG9wdGlvbmFsIEFTIG1ldGFkYXRhIHBhcmFtZXRlciBu YW1lZCAnbXRsc19lbmRwb2ludHMnIHRoYXQncyB2YWx1ZSB3ZSBiZSBhIEpTT04gb2JqZWN0IHdo aWNoIGl0c2VsZiBjb250YWlucyBlbmRwb2ludHMgdGhhdCwgd2hlbiBwcmVzZW50LCBhIGNsaWVu dCBkb2luZyBNVExTIHdvdWxkIHVzZSByYXRoZXIgdGhhbiB0aGUgcmVndWxhciBlbmRwb2ludHMu Jm5ic3A7IEEgc3RyYXctbWFuIGV4YW1wbGUgbWlnaHQgbG9vayBsaWtlIHRoaXM8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ezxicj4NCiZuYnNwOyAmcXVvdDtpc3N1ZXIm cXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbTwvYT4mcXVvdDssPGJyPg0KJm5ic3A7 ICZxdW90O2F1dGhvcml6YXRpb25fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aHoiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZl ci5leGFtcGxlLmNvbS9hdXRoejwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O3Rva2VuX2Vu ZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rv a2VuIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW48L2E+ JnF1b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3Vw cG9ydGVkJnF1b3Q7OlsgJm5ic3A7JnF1b3Q7Y2xpZW50X3NlY3JldF9iYXNpYyZxdW90OywmcXVv dDt0bHNfY2xpZW50X2F1dGgmcXVvdDssICZxdW90O25vbmUmcXVvdDtdLDxicj4NCiZuYnNwOyAm cXVvdDt1c2VyaW5mb19lbmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZl ci5leGFtcGxlLmNvbS91c2VyaW5mbyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4 YW1wbGUuY29tL3VzZXJpbmZvPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7cmV2b2NhdGlv bl9lbmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNv bS9yZXZvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2bzwv YT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O2p3a3NfdXJpJnF1b3Q7OiZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3a3MuanNvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3a3MuanNvbjwvYT4mcXVvdDssPGJyPg0KJm5ic3A7 IDxiPiZxdW90O210bHNfZW5kcG9pbnRzJnF1b3Q7Ons8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90 O3Rva2VuX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vbXRscy5leGFtcGxl LmNvbS90b2tlbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS90b2tl bjwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVvdDt1c2VyaW5mb19lbmRwb2ludCZx dW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm8iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm88L2E+JnF1b3Q7 LDxicj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7cmV2b2NhdGlvbl9lbmRwb2ludCZxdW90OzomcXVv dDs8YSBocmVmPSJodHRwczovL210bHMuLmV4YW1wbGUuY29tL3Jldm8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL210bHMuZXhhbXBsZS5jb20vcmV2bzwvYT4mcXVvdDs8YnI+DQombmJzcDsgfTwv Yj48YnI+DQp9PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY2xpZW50IGRvaW5nIE1UTFMgd291bGQgbG9vayBmb3Ig YW5kIGdpdmUgcHJlY2VkZW5jZSB0byBhbiBlbmRwb2ludCB1bmRlciAmcXVvdDttdGxzX2VuZHBv aW50cyZxdW90OyB3aGlsZSBmYWxsaW5nIGJhY2sgdG8gdXNlIHRoZSBub3JtYWwgZW5kcG9pbnQg ZnJvbSB0aGUgdG9wIGxldmVsIG9mIG1ldGFkYXRhIHdoZW4vaWYgaXRzIG5vdCBpbiAmcXVvdDtt dGxzX2VuZHBvaW50cyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBpZGVhIGJlaW5nIHRoYXQgJnF1b3Q7cmVndWxhciZx dW90OyBjbGllbnRzICh0aG9zZSBub3QgZG9pbmcgTVRMUykgd2lsbCB1c2UgdGhlIHJlZ3VsYXIg ZW5kcG9pbnRzLiBBbmQgb25seSB0aGUgaG9zdC9wb3J0IG9mIHRoZSBlbmRwb2ludHMgbGlzdGVk IGluIG10bHNfZW5kcG9pbnRzIHdpbGwgYmUgc2V0IHVwIHRvIHJlcXVlc3QgVExTIGNsaWVudCBj ZXJ0aWZpY2F0ZXMgZHVyaW5nIGhhbmRzaGFrZS4gVGh1cyBhbnkgcG90ZW50aWFsIGltcGFjdCBv ZiB0aGUNCiBDZXJ0aWZpY2F0ZVJlcXVlc3QgbWVzc2FnZSBiZWluZyBzZW50IGluIHRoZSBUTFMg aGFuZHNoYWtlIGNhbiBiZSBhdm9pZGVkIGZvciBhbGwgdGhlIG90aGVyIHJlZ3VsYXIgY2xpZW50 cyB0aGF0IGFyZSBub3QgZ29pbmcgdG8gZG8gTVRMUyAtIGluY2x1ZGluZyBhbmQgbW9zdCBpbXBv cnRhbnRseSBpbi1icm93c2VyIGphdmFzY3JpcHQgY2xpZW50cyB3aGVyZSB0aGVyZSBjYW4gYmUg bGVzcyB0aGFuIGRlc2lyYWJsZSBVSSBwcmVzZW50ZWQgdG8NCiB0aGUgZW5kLXVzZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBzdHJ1 Z2dsaW5nLCBob3dldmVyLCB0byBhZGVxdWF0ZWx5IGdhdWdlIHdoZXRoZXIgb3Igbm90IHRoZXJl J3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBUaGVy ZSdzIGJlZW4gc29tZSBzdXBwb3J0IGZvciBpdCB2b2ljZWQuIEFzIHdlbGwgYXMgdGFsayBvZiBv dGhlciBhcHByb2FjaGVzIHRoYXQgY291bGQgYmUgYWx0ZXJuYXRpdmVzIG9yIGFkZGl0aW9uYWwN CiBtZWFzdXJlcy4gQW5kIGFsc28gc29tZSB2b2NhbCBvcHBvc2l0aW9uIHRvIGl0LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gU2F0LCBGZWIgOSwgMjAxOSBhdCAzOjA5IEFNIERvbWluaWNrIEJhaWVyICZsdDs8 YSBocmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5XZSBh cmUgY3VycmVudGx5IGltcGxlbWVudGluZyBNVExTIGluIElkZW50aXR5U2VydmVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PdXIg YXBwcm9hY2ggd2lsbCBiZSB0aGF0IHdl4oCZbGwgb2ZmZXIgYSBzZXBhcmF0ZSB0b2tlbiBlbmRw b2ludCB0aGF0IHN1cHBvcnRzIGNsaWVudCBjZXJ0cy4gQXJlIHlvdSBwbGFubmluZyBvbiBhZGRp bmcgYW4gb2ZmaWNpYWwgZW5kcG9pbnQgbmFtZSBmb3IgZGlzY292ZXJ5PyBSaWdodCBub3cgd2Ug YXJlIHVzaW5nDQog4oCcbXRsc190b2tlbl9lbmRwb2ludOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCU4oCU 4oCUIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNr PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJn bWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWls LW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUx NDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmFpcm1haWxvbiI+DQpP biA3LiBGZWJydWFyeSAyMDE5IGF0IDIyOjM2OjU1LCBCcmlhbiBDYW1wYmVsbCAoPGEgaHJlZj0i bWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5iY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9h Pikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWggeWVzLCB0aGF0IG1ha2VzIHNlbnNlLiBUaGFu a3MgZm9yIGNsYXJpZnlpbmcuIEFuZCBpdCBpcyBpbmRlZWQgYSBnb29kIHJlbWluZGVyIHRoYXQg ZXZlbiBhIHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIGJhY2t3YXJk cyBjb21wYXRpYmxlIGNhbiBicmVhayB0aGluZ3MgdW5leHBlY3RlZGx5Li48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgRmViIDcsIDIwMTkgYXQgODo1NyBBTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IGNhc2UgSeKAmW0gcmVmZXJlbmNpbmcgZGlkbuKAmXQgc3BlY2lmaWNhbGx5IGludm9sdmUgQVMg bWV0YWRhdGEuIFdlIGhhZCBjbGllbnRzIGluIHRoZSB3aWxkIHRoYXQgYXNzdW1lZCB0aGF0IGFs bCB0aGUgcHJvcGVydGllcyBpbiB0aGUgSlNPTiBvYmplY3QgcmV0dXJuZWQgZnJvbSBvdXIgdXNl cmluZm8gZW5kcG9pbnQNCiB3ZXJlIHNjYWxhciBzdHJpbmdzLiBUaGlzIGJyb2tlIHdoZW4gd2Ug aW50cm9kdWNlZCBhIG5ldyBwcm9wZXJ0eSB3aG9zZSB2YWx1ZSB3YXMgYSBKU09OIG9iamVjdC4g SXQgd2FzIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5ub2N1b3VzIGNo YW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gZm9yY2UgbW9yZSB3 b3JrIG9uIGNsaWVudHMgdGhhbiB3ZSBleHBlY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSA2 LCAyMDE5IGF0IDExOjMwIEFNPGJyPg0KPGI+VG86PC9iPiAmcXVvdDtSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDssIG9hdXRoICZsdDs8YSBocmVm PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNF TkRFUl0gUmU6IE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5k cG9pbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIEknbSBob25lc3RseSByZWFsbHkgc3RydWdnbGluZyB0 byBzZWUgd2hhdCBjb3VsZCBoYXZlIGdvbmUgd3Jvbmcgd2l0aCBvciBob3cgdG9rZW5fZW5kcG9p bnRfYXV0aF9tZXRob2RzIGJyb2tlIHNvbWV0aGluZyB3aXRoIHRoZSB1c2VyIGluZm8gZW5kcG9p bnQuIElmIHlvdSBoYXZlIHRoZSB0aW1lIGFuZC9vcg0KIGl0J2QgYmUgaW5mb3JtYXRpdmUgdG8g dGhpcyBoZXJlIGxpdHRsZSBkaXNjdXNzaW9uLCBwbGVhc2UgZXhwbGFpbiB0aGF0IG9uZSBhIGJp dCBtb3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFdlZCwgRmViIDYsIDIwMTkgYXQgMTI6MTUgUE0gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhy ZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3 aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7 Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigy MDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mcXVvdDtmYXImcXVvdDsgc2hvdWxkIGhhdmUgc2FpZCAmcXVvdDtmYWlyJnF1b3Q7IGluIHRo ZSBwcmV2aW91cyBtZXNzYWdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgNSwgMjAxOSBh dCA0OjM1IFBNIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgbWF5IHdlbGwgYmUgZHVlIHRv IG15IG93biBpbnRlbGxlY3R1YWwgc2hvcnRjb21pbmdzIGJ1dCB0aGVzZSBpc3N1ZXMvcXVlc3Rp b25zL2NvbmZ1c2lvbi1wb2ludHMgYXJlIG5vdCByZXNvbmF0aW5nIGZvciBtZSBhcyBiZWluZyBw cm9ibGVtYXRpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBtb3JlIGdlbmVyYWwgc3RhbmNlIG9mICZxdW90O3RoaXMgaXNuJ3Qg bmVlZGVkIG9yIHdvcnRoIGl0IGluIHRoaXMgZG9jdW1lbnQmcXVvdDsgKEkgdGhpbmsgdGhhdCdz IGZhcj8pIGlzIGJlaW5nIGhlYXJkIHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g VHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQyIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZs dDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi5vcmci IHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+KFRMO0RSOiBwdW50IEFTIG1ldGFkYXRhIHRvIGEgc2VwYXJhdGUgZHJh ZnQpPGJyPg0KPGJyPg0KQVMgcG9pbnRzICMxLTMgYXJlIGFsbCBxdWVzdGlvbnMgSSB3b3VsZCBo YXZlIGFzIGFuIGltcGxlbWVudGVyOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBl PSIxIj4NCjxsaSBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1 NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYz MTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4 OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMy Z21haWwtbS00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDE0 I3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24gMiBvZiBSRkM4NDE0PC9hPiBzYXlz IHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBn cmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hhdCBkb2VzIHRoZSBtVExTLW9ubHkgQVMg cHV0IGhlcmU/DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tNjA4NDMxNDgwNTQ5 Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYy MTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFn bWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwt bTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIGNsYWltcyBmb3IgdGhlc2Ugb3Ro ZXIgZW5kcG9pbnRzIGFyZSBPUFRJT05BTCwgcG90ZW50aWFsbHkgbGVhZGluZyB0byBpbmNvbnNp c3RlbmN5IGRlcGVuZGluZyBvbiBob3cgIzEgZ2V0cyBkZWNpZGVkLg0KPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEz MzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0 OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVn bWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwt bS00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NClRoZSBleGFtcGxlIHVzYWdlIG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhv ZHMgcHJvcGVydHkgZ2l2ZW4gZWFybGllciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0LCBz aW5jZSBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1tVExT IGVuZHBvaW50cywgYW5kIG90aGVycyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5kcG9p bnRzLiBIZW5jZSB0aGlzIHF1ZXN0aW9uLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21h aWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1t MjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMy NDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgy ODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4ODI5 MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoaXMgaW50 cm9kdWNlcyBhIG5ldyBtZXRhZGF0YSBwcm9wZXJ0eSB0aGF0IGNvdWxkIGltcGFjdCBob3cgb3Ro ZXIgc3BlY3Mgc2hvdWxkIGV4dGVuZCBBUyBtZXRhZGF0YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRy ZXNzZWQuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgY291bGQgZ28gb24g Zm9yIGNsaWVudCBwb2ludHMgYnV0IHlvdSBhbHJlYWR5IGdldCB0aGUgcG9pbnQuIFRob3VnaCBJ 4oCZbGwgc2hhcmUgdGhhdCAjMyBpcyByZWFsIGFuZCBvbmNlIGZvcmNlZCBtZSB0byByb2xsIGJh Y2sgYW4gdXBkYXRlIHRvIHRoZSBMb2dpbiB3aXRoIEFtYXpvbiB1c2VyaW5mbyBlbmRwb2ludOKA pmdvb2QNCiB0aW1lcy4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9y IEVtb2ppJnF1b3Q7Ij4mIzEyODUxNTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEgcHJvcGVydHkgaXMg d3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJvbHRpbmcgYSBsYXll ciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZdCBkZXNpZ25lZCBm b3IgdGhhdCwgYW5kIEkNCiBkb27igJl0IHRoaW5rIHRoZSBtZXRhZGF0YSBwcm9wb3NhbCBhcyBp dOKAmXMgYmVlbiBkaXNjdXNzZWQgaGVyZSBzdWZmaWNpZW50bHkgZGVhbHMgd2l0aCB0aGUgZmFs bG91dCBmcm9tIHRoYXQuIEluIG15IHZpZXcgdGhpcyBpcyBhIGNvbXBsZXggZW5vdWdoIGlzc3Vl IGFuZCBpdOKAmXMgZm9yIGEgbnVhbmNlZCBlbm91Z2ggdXNlIGNhc2UgKGFzIGZhciBhcyBJIGNh biB0ZWxsIGZyb20gZGlzY3Vzc2lvbj8gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSeKAmW0gd3Jvbmcp DQogdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFyYXRlIGRyYWZ0IChlLmcuLCDigJxB dXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSBFeHRlbnNpb25zIGZvciBtVExTIEh5YnJpZHPi gJ0pIGFuZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50 aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IE1vbmRheSwgRmVicnVh cnkgNCwgMjAxOSBhdCA1OjI4IEFNPGJyPg0KPGI+VG86PC9iPiAmcXVvdDtSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJl OiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRob3NlIHBvaW50cyBvZiBjb25mdXNp b24gc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQg eW91ciBnZW5lcmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFu dGkgYWRkaXRpb25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzDQogbm90ZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGwgb2Yg d2hpY2ggbGVhdmVzIG1lIGEgYml0IHVuY2VydGFpbiBhYm91dCBob3cgdG8gcHJvY2VlZC4gVGhl cmUgc2VlbSB0byBiZSBhIHJhbmdlIG9mIG9waW5pb25zIG9uIHRoaXMgcG9pbnQgYW5kIGdhdWdp bmcgY29uc2Vuc3VzIGlzIHByb3ZpbmcgZWx1c2l2ZSBmb3IgbWUuIFRoYXQncyBjb25mb3VuZGVk DQogYnkgbXkgb3duIG9waW5pb24gb24gaXQgYmVpbmcgc29tZXdoYXQgZmx1aWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgSSdk IHJlYWxseSBsaWtlIHRvIHBvc3QgYW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYWJvdXQgYSBtb250 aCBvciB0d28gYWdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBGcmksIEZlYiAxLCAyMDE5IGF0IDU6MDMgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4u Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVu dGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Db25mdXNpb24gZnJvbSB0aGUgQVPigJlzIHBlcnNwZWN0aXZl OjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iZ21h aWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1t MjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMy NDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgy ODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4ODI5 MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCklmIEkgb25s eSBzdXBwb3J0IG1UTFMsIGRvIEkgbmVlZCB0byBpbmNsdWRlIGJvdGggdG9rZW5fZW5kcG9pbnRf dXJpIGFuZCBtdGxzX2VuZHBvaW50cz8gU2hvdWxkIEkgb21pdCB0b2tlbl9lbmRwb2ludF91cmk/ IE9yIHNldCBpdCB0byB0aGUgZW1wdHkgc3RyaW5nPw0KPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDln bWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWls LW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5 MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2 ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCldo YXQgaWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQgbm90 IHJldm9jYXRpb24gb3IgdXNlciBpbmZvPw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21h aWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1t MjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMy NDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgy ODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4ODI5 MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCkhvdyBkbyBJ IHNwZWNpZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1UTFMgdG9rZW4gZW5kcG9p bnQ/IERvZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5IHRvIGJvdGggdGhlIG1U TFMgYW5kIG5vbi1tVExTIGVuZHBvaW50cz8NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Imdt YWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwt bTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzcz MjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4 Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2Njg2ODgy OTEwNDU2NG0tODU2MzMiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpJ4oCZbSB1 c2luZyB0aGUgT0F1dGggMi4wIERldmljZSBGbG93LiBEbyBJIGluY2x1ZGUgYSBtVExTLWVuYWJs ZWQgZGV2aWNlX2F1dGhvcml6YXRpb25fZW5kcG9pbnQgdW5kZXIgbXRsc19lbmRwb2ludHM/DQo8 bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBjbGll bnTigJlzIHBlcnNwZWN0aXZlOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIx Ij4NCjxsaSBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2 MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTcz MjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQw MTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21h aWwtbS00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVs MSBsZm8zIj4NCkFzIGZhciBhcyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRv buKAmXQga25vdyBhbnl0aGluZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxs ZWQgY2xpZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhw ZWN0cyB0byB1c2UgdGhhdCB0byBhdXRoZW50aWNhdGUgbWUuDQo8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0 NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkz Z21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWls LW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5 NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMi Pg0KTXkgQVMgbWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVjYXVzZSB0aGUgbVRMUy1vbmx5IEFT IG9taXR0ZWQgdG9rZW5fZW5kcG9pbnRfdXJpLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i Z21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFp bC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0z NzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAz MzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4 ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCk15IEFT IG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRvIGVu Y291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLg0KPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2 MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTcz MjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQw MTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21h aWwtbS00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVs MSBsZm8zIj4NClRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZvciBt dGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRvPyA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJn bWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWls LW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3 MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMz ODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4Njg4 MjkxMDQ1NjRtLTg1NjMzIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KSSBkb27i gJl0IGtub3cgd2hhdCB0aGF0IOKAnG3igJ0gbWVhbnMsIGJ1dCB0aGV5IHRvbGQgbWUgdG8gdXNl IEhUVFBTLCBzbyBJIHNob3VsZCB1c2UgdGhlIG9uZSB3aXRoIOKAnHRsc+KAnSBpbiBpdHMgbmFt ZSwgcmlnaHQ/DQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgeW91IGNh biB3cml0ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4gQnV0IHlv deKAmWxsIGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1zbGlnaHRs eS1kaWZmZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1wbGVtZW50 ZXJzDQogd2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9k dWNlcyBvcHBvcnR1bml0aWVzIGZvciBjb25mdXNpb24gYW5kIGZhaWx1cmUgdGhhdCBkbyBub3Qg ZXhpc3Qgbm93LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZlcnlvbmUgd2hvIHN1cHBvcnRzIG1UTFMu IEluIGNvbnRyYXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlzIG9ubHkgcmVxdWlyZWQgd2hlbiBhbiBB UyB3YW50cyB0byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1bmFtYmlndW91cw0KIGluIGl0cyBiZWhh dmlvciBhbmQgbWVhbmluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3Ii Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0i bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8 L2I+IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAzOjE3IFBNPGJyPg0KPGI+VG86PC9iPiAm cXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdmZmxldGNoQGFvbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nZmZsZXRjaEBhb2wuY29tPC9h PiZndDssIG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtVTlZF UklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRz IHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgZG9lc24n dCBzZWVtIGxpa2UgdGhhdCBjb25mdXNpbmcgb3IgbGFyZ2Ugb2YgYSBjaGFuZ2UgdG8gbWUgLSBp ZiB0aGUgY2xpZW50IGlzIGRvaW5nIE1UTFMgYW5kIHRoZSBnaXZlbiBlbmRwb2ludCBpcyBwcmVz ZW50IGluIGBtdGxzX2VuZHBvaW50c2AsIHRoZW4gaXQgdXNlcyB0aGF0IG9uZS4mbmJzcDsgT3Ro ZXJ3aXNlDQogaXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4gQVMgYSBs b3Qgb2YgZmxleGliaWxpdHkgaW4gZGVwbG95bWVudCBvcHRpb25zLiBJIHBlcnNvbmFsbHkgdGhp bmsgZ2V0dGluZyBhIDMwNyBhcHByb2FjaCBkZXBsb3llZCBhbmQgd29ya2luZyB3b3VsZCBiZSBt b3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBwcm9uZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIGEgbWlub3JpdHkg dXNlIGNhc2UgYXQgdGhlIG1vbWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBsaWtl IHRoZSBwdXNoIGZvciBpbmNyZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2ZSBq YXZhc2NyaXB0IGNsaWVudHMgdXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdA0KIGl0IHdv bid0IGJlIHRlcnJpYmx5IHVudXN1YWwgdG8gc2VlIGFuIEFTIHRoYXQgd2FudHMgdG8gc3VwcG9y dCBNVExTIGNsaWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNhbWUgdGlt ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkndmUgcGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhyZWFk IG9uIHdoZXRoZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhpbmcg bGlrZSBpdCkuIFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBzb21l d2hlcmUgYmFjaw0KIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0 aHJlYWQuJm5ic3A7IEJ1dCBpdCBzZWVtcyBsaWtlIHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhl IGdyb3VwIGhlcmUgaXMgaW4gZmF2b3Igb2YgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZy aSwgRmViIDEsIDIwMTkgYXQgMzoxOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7 cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4ub3JnIiB0 YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3Ig Y3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoaXMgc3RyaWtlcyBtZSBhcyBhIHZlcnkgcHJvbWluZW50IGFuZCBjb25m dXNpbmcgY2hhbmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVtcyB0byBiZSBhIG1pbm9yaXR5IHVzZSBj YXNlLiBJ4oCZbSBnZXR0aW5nIGEgaGVhZGFjaGUganVzdCB0aGlua2luZyBhYm91dCB0aGUgdGV4 dCBuZWVkZWQgdG8gY2xhcmlmeSB3aGVuDQogdGhlIEFTIHNob3VsZCBwcm92aWRlIGBtdGxzX2Vu ZHBvaW50c2AgYW5kIHdoZW4gdGhlIGNsaWVudCBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5n IGB0b2tlbl9lbmRwb2ludC5gIFdoeSBpcyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVu dCB0byBjb3ZlciB0aGUgY2FzZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMg YW5kIG5vbi1tVExTPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47 Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAm bHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMToz MSBQTTxicj4NCjxiPlRvOjwvYj4gR2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVm PSJtYWlsdG86NDBhb2wuY29tQGRtYXJjLi4uLi4uaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40 MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0 OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTVRMUyBh bmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlll cywgdGhhdCB3b3VsZCB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBHZW9yZ2Ug RmxldGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5XaGF0IGlmIHRoZSBBUyB3 YW50cyB0byBPTkxZIHN1cHBvcnQgTVRMUyBjb25uZWN0aW9ucy4gRG9lcyBpdCBub3Qgc3BlY2lm eSB0aGUgb3B0aW9uYWwgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgYW5kIGp1c3QgdXNlIHRo ZSBub3JtYWwgbWV0YWRhdGEgdmFsdWVzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEvMTUvMTkgODo0OCBBTSwgQnJpYW4gQ2FtcGJlbGwg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JdCB3b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFsLCBhcG9s b2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhl IGVmZmVjdCBvZiBvcHRpb25hbCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9p bmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hlbg0KIHByZXNlbnQgaW4gQVMgbWV0YWRhdGEuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBKYW4g MTUsIDIwMTkgYXQgMjowNCBBTSBEYXZlIFRvbmdlICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2ZS50 b25nZUBtb21lbnR1bWZ0LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+ZGF2ZS50b25nZUBtb21lbnR1 bWZ0LmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5JJ20gaW4g ZmF2b3VyIG9mIHRoZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhv dWdoIGl0IHNob3VsZCBiZSBvcHRpb25hbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3Ig ZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlv dSBoYXZlDQogcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3Nh Z2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91 Ljwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFp bGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7 Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5D T05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29s b3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05G SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9p PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6 IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURF TlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQg cHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBp biI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRp c2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFu ZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3Nw YW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LA0KIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1 cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwv aT48L2I+DQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6 IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURF TlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQg cHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwv Yj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DDDC7C8460FF43CDBC1FE13CD6937655amazoncom_-- From nobody Tue Feb 12 12:27:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EC7130DE7 for ; Tue, 12 Feb 2019 12:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_n9qyCuTBRP for ; Tue, 12 Feb 2019 12:27:41 -0800 (PST) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D3212DF71 for ; Tue, 12 Feb 2019 12:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550003259; bh=b7jmBaMD9UVjrzrCfRXkJl/utWxqZeiTotkj2lH3KkM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=QUAFkrk+0IXOjLwUCpcgLja2v3WonCkJgBaSPMhGGcvh2kd5w8ayYgkDfJjMM/ReavLEIv5Xw1B7dE9b7ftdn/9B4rhI1g7S0asfSlJtv+hggw9fmHGTvb2M4C97lagGvXfA/ph4ET9lCl2xkR1HJ+x7pytQjpePumVL4/g/xuVis69hQBoOVAqqf8J+2T93QwuSOtFAzteF//QRnrvU71PqqiAiR6XOAdkCDQerd2ZAEU7HQpZvxoQjWGPonFuUMxnNZVxdYod7dyM0HiCOgyRjuDRfxQFERZjnHLO/NKalc4iza+KPx8B8zb4ttCSZhRssI8Q7fly8SZck270VoQ== X-YMail-OSG: NLHAJQ0VM1kd6pKClDSRJsxYXPg97..CPYBaX8h2hGikEKpTMI3t8VzFlGscVSV ENTOzQoxRUTKHapznxmu7pvt.Pw.kT.jslUm9TkgEBEYlTsxKiFcYDjHAbsHPamncES2chTSzUO. EUCmTbqXrwPu4oSfgjDhmI9J48RXYVgxpktNARxFKyNw4DRAB4o3RiYmoT7aEWwd0z2xo7q8Bsky 3TRx2aex5zC9rZju.H.D19H7IqcfocfUyj68J1OGvHH0zq8I0dJT.xvq7s2QEWVu67xYDd3F8z.s 3iC62k8SXCAzcb99CaTMq5V6DGDRrzB2fatDaSF4xGXIV7uFLdXYAgcvMod4SFx1dsmcv5zjGfm5 XT3ynqToW0u2d.kLBcb4yET3fVgUOw1fQvQloLn2PwSrmeVedOtAeHSSkhl.VZ.xRZyeLrTk3r9K 7LatQij891NJyNOf.kAqghCoGxR97PAe.gyoA33co3V232x8SkSks4LarS2G4Dafr_iw4H5oxAOC ff2Paez.TC6nAnhNGI.PT9jX8IpvmTeVv6Rb808OJ_V31xmfD.voFXsAl9.Gxv9wDUWDcX.2qYlT my8CI8ILwoS3wbhiHWa5wrMwel4_ueu5VhvqM1TZHRxDrwwWJJ48K.cSiWiA6UW4bwPhiQJ29_vT x6NziA6xBhnwodD_Wv88JUnRvstd2pHsLNds811HMqPD9KfTUg8O9py9.dliJEYjHIu_P3CyjaiE .HzLe1BSrtmSGprLpxiyXHvLJTP0DVZv.bqTAUkiQovXW53hdfNtLhS00ld1Ln.GCvM2G1gATliM .JcK_OVlwPhEGRqmF3KvCJLznM5QsMPChC1trUlZVLZnZugzn16RHCWCUz_2tLzSFxXa2h8Aq2Fx ZfmS1jz_yDqynWExB82uYw_c3ntWxki4Dg8mRxQ_n09_6q77ifjP3Ae.MzJfhy9OBoQ_MinLxOZ7 w9Su3WAbFo3WwmbEjY.Etk5DrMeqerpEQ7aFPjCILIeeYrcG7EGhkqRHFZI7gL03_yAbToJ0yLRG cA4_Ja1BrAtWbgT5ZpDryuiNRNhTw7oY_ClndGoRUy5avtDCWDe19r0e1x6BVTpscpIiXFsHu Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Feb 2019 20:27:39 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1c8ce54ba487be5367cca4ff53aada40; Tue, 12 Feb 2019 20:27:38 +0000 (UTC) To: "Richard Backman, Annabelle" , Brian Campbell , Dominick Baier Cc: oauth References: <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> From: George Fletcher Organization: AOL LLC Message-ID: <46105936-5ab5-af0f-764e-c9a1a2b6a66f@aol.com> Date: Tue, 12 Feb 2019 15:27:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A854F252FE9AEF83274F2E20" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 20:27:46 -0000 This is a multi-part message in MIME format. --------------A854F252FE9AEF83274F2E20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I prefer this approach to an embedded JSON object. Possibly even just making the MTLS version its own directly referencable config under .well-known. Thanks, George On 2/12/19 2:47 PM, Richard Backman, Annabelle wrote: > > I’m not opposed to introducing a metadata change, if the scenario is > relevant and other approaches can’t adequately address it – and I’ll > readily grant that we probably don’t want to depend on consistency of > browser behavior at the intersection of client certificates and > Access-Control-Allow-Credentials. But care needs to be taken in > designing that metadata to avoid violating or otherwise negatively > impacting usage of RFC8414. > > Along those lines, instead of adding an “mtls_endpoints” metadata > parameter, we could add an “mtls_alternate_metadata” parameter whose > value is the URL of an alternate metadata document intended for > clients using mTLS. An mTLS-optional AS could have two different > metadata documents for mTLS and non-mTLS clients, reducing the > mTLS-optional scenario to the mTLS-only scenario. This sidesteps the > challenges of aligning the “either/or” semantics of mTLS-optional with > some of the rigid parameter definitions in RFC8414 (see: > token_endpoint, token_endpoint_auth_methods_supported). > > -- > > Annabelle Richard Backman > > AWS Identity > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Tuesday, February 12, 2019 at 10:58 AM > *To: *Dominick Baier > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS token endoint & discovery > > Thanks for the input, Dominick. > > I'd said previously that I was having trouble adequately gauging > whether or not there's sufficient consensus to go ahead with the > update. I was even thinking of asking the chairs about a consensus > call during the office hours meeting yesterday. But it got canceled. > And looking again back over the discussion, I don't believe a > consensus call is necessary. There's been a lot of general discussion > over the last several weeks during which several folks have stated > support for the proposal while there's been only one voice of direct > dissent. That seems like rough enough consensus and, as such, I plan > to make the change in the next revision of the document (which should > be done soon). Chairs, please let me know, if you believe the > situation warrants a different course of action. > > On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier > > wrote: > > IMHO that’s a reasonable and pragmatic option. > > Thanks > > ——— > > Dominick > > On 11. February 2019 at 13:26:37, Brian Campbell > (bcampbell@pingidentity.com ) > wrote: > > It's been pointed out that the potential issue is not isolated > to the just token endpoint but that revocation, introspection, > etc. could be impacted as well. So,  at this point, the > proposal on the table is to add a new optional AS metadata > parameter named 'mtls_endpoints' that's value we be a JSON > object which itself contains endpoints that, when present, a > client doing MTLS would use rather than the regular > endpoints.  A straw-man example might look like this > > { >   "issuer":"https://server.example.com", >   "authorization_endpoint":"https://server.example.com/authz", >   "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ >  "client_secret_basic","tls_client_auth", "none"], >   "userinfo_endpoint":"https://server.example.com/userinfo", >   "revocation_endpoint":"https://server.example.com/revo", >   "jwks_uri":"https://server.example.com/jwks.json", > *"mtls_endpoints":{ >     "token_endpoint":"https://mtls.example.com/token", >     "userinfo_endpoint":"https://mtls.example.com/userinfo", >     "revocation_endpoint":"https://mtls.example.com/revo > " >   }* > } > > A client doing MTLS would look for and give precedence to an > endpoint under "mtls_endpoints" while falling back to use the > normal endpoint from the top level of metadata when/if its not > in "mtls_endpoints". > > > The idea being that "regular" clients (those not doing MTLS) > will use the regular endpoints. And only the host/port of the > endpoints listed in mtls_endpoints will be set up to request > TLS client certificates during handshake. Thus any potential > impact of the CertificateRequest message being sent in the TLS > handshake can be avoided for all the other regular clients > that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than > desirable UI presented to the end-user. > > I'm struggling, however, to adequately gauge whether or not > there's sufficient consensus to go ahead with the update. > There's been some support for it voiced. As well as talk of > other approaches that could be alternatives or additional > measures. And also some vocal opposition to it. > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > > > wrote: > > We are currently implementing MTLS in IdentityServer. > > Our approach will be that we’ll offer a separate token > endpoint that supports client certs. Are you planning on > adding an official endpoint name for discovery? Right now > we are using “mtls_token_endpoint”. > > Thanks > > ——— > > Dominick > > On 7. February 2019 at 22:36:55, Brian Campbell > (bcampbell=40pingidentity.com@dmarc.ietf.org > ) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And > it is indeed a good reminder that even a seemingly > innocuous change that should be backwards compatible > can break things unexpectedly.. > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, > Annabelle > wrote: > > The case I’m referencing didn’t specifically > involve AS metadata. We had clients in the wild > that assumed that all the properties in the JSON > object returned from our userinfo endpoint were > scalar strings. This broke when we introduced a > new property whose value was a JSON object. It was > a good reminder that even a seemingly innocuous > change that should be backwards compatible can > force more work on clients than we expect. > > -- > > Annabelle Richard Backman > > AWS Identity > > *From:* Brian Campbell > > *Date:* Wednesday, February 6, 2019 at 11:30 AM > *To:* "Richard Backman, Annabelle" > > > *Cc:* "Richard Backman, Annabelle" > >, oauth > > > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: > MTLS and in-browser clients using the token endpoint > > And I'm honestly really struggling to see what > could have gone wrong with or how > token_endpoint_auth_methods broke something with > the user info endpoint. If you have the time > and/or it'd be informative to this here little > discussion, please explain that one a bit more. > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > > wrote: > > "far" should have said "fair" in the previous > message > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > > wrote: > > It may well be due to my own intellectual > shortcomings but these > issues/questions/confusion-points are not > resonating for me as being problematic. > > The more general stance of "this isn't > needed or worth it in this document" (I > think that's far?) is being heard though. > > On Tue, Feb 5, 2019 at 1:42 PM Richard > Backman, Annabelle > > wrote: > > (TL;DR: punt AS metadata to a separate > draft) > > AS points #1-3 are all questions I > would have as an implementer: > > 1. Section 2 of RFC8414 > > says token_endpoint “is REQUIRED > unless only the implicit grant > type is supported.” So what does > the mTLS-only AS put here? > 2. The claims for these other > endpoints are OPTIONAL, > potentially leading to > inconsistency depending on how #1 > gets decided. > 3. The example usage of the > token_endpoint_auth_methods > property given earlier is > incompatible with RFC8414, since > some of its contents are only > valid for the non-mTLS endpoints, > and others are only valid for the > mTLS endpoints. Hence this question. > 4. This introduces a new metadata > property that could impact how > other specs should extend AS > metadata. That needs to be addressed. > > I could go on for client points but > you already get the point. Though I’ll > share that #3 is real and once forced > me to roll back an update to the Login > with Amazon userinfo endpoint…good > times. 😃 > > I don’t necessarily think an AS > metadata property is wrong per se, but > understand that you’re bolting a layer > of flexibility onto a standard that > wasn’t designed for that, and I don’t > think the metadata proposal as it’s > been discussed here sufficiently deals > with the fallout from that. In my view > this is a complex enough issue and > it’s for a nuanced enough use case (as > far as I can tell from discussion? > Please correct me if I’m wrong) that > we should punt it to a separate draft > (e.g., “Authorization Server Metadata > Extensions for mTLS Hybrids”) and get > mTLS out the door. > > -- > > Annabelle Richard Backman > > AWS Identity > > *From:* OAuth > on > behalf of Brian Campbell > > > *Date:* Monday, February 4, 2019 at > 5:28 AM > *To:* "Richard Backman, Annabelle" > > > *Cc:* oauth > > *Subject:* Re: [OAUTH-WG] [UNVERIFIED > SENDER] Re: MTLS and in-browser > clients using the token endpoint > > Those points of confusion strike me as > somewhat hypothetical or hyperbolic. > But your general point is taken and > your position of being anti additional > metadata on this issue is noted. > > All of which leaves me a bit uncertain > about how to proceed. There seem to be > a range of opinions on this point and > gauging consensus is proving elusive > for me. That's confounded by my own > opinion on it being somewhat fluid. > > And I'd really like to post an update > to this draft about a month or two ago. > > On Fri, Feb 1, 2019 at 5:03 PM Richard > Backman, Annabelle > > > wrote: > > Confusion from the AS’s perspective: > > 1. If I only support mTLS, do I > need to include both > token_endpoint_uri and > mtls_endpoints? Should I omit > token_endpoint_uri? Or set it > to the empty string? > 2. What if I only support mTLS > for the token endpoint, but > not revocation or user info? > 3. How do I specify > authentication methods for the > mTLS token endpoint? Does > token_endpoint_auth_methods > apply to both the mTLS and > non-mTLS endpoints? > 4. I’m using the OAuth 2.0 Device > Flow. Do I include a > mTLS-enabled > device_authorization_endpoint > under mtls_endpoints? > > Confusion from the client’s > perspective: > > 1. As far as I know, I’m a public > client, and don’t know > anything about mTLS, but the > IT admins installed client > certs in their users’ browsers > and the AS expects to use that > to authenticate me. > 2. My AS metadata parser crashed > because the mTLS-only AS > omitted token_endpoint_uri. > 3. My AS metadata parser crashed > because it didn’t expect to > encounter a JSON object as a > parameter value. > 4. The mTLS-only AS didn’t > provide a value for > mtls_endpoints, what do I do? > 5. I don’t know what that “m” > means, but they told me to use > HTTPS, so I should use the one > with “tls” in its name, right? > > Yes, you can write normative text > that answers most of these. But > you’ll have to clearly cover a lot > of similar-but-slightly-different > scenarios and be very explicit. > And implementers will still get it > wrong. The metadata change > introduces opportunities for > confusion and failure that do not > exist now, and forces them on > everyone who supports mTLS. In > contrast, the 307 redirect is only > required when an AS wants to > support both, and is unambiguous > in its behavior and meaning. > > -- > > Annabelle Richard Backman > > AWS Identity > > *From:* Brian Campbell > > > *Date:* Friday, February 1, 2019 > at 3:17 PM > *To:* "Richard Backman, Annabelle" > > > *Cc:* George Fletcher > >, oauth > > > *Subject:* [UNVERIFIED SENDER] Re: > [OAUTH-WG] MTLS and in-browser > clients using the token endpoint > > It doesn't seem like that > confusing or large of a change to > me - if the client is doing MTLS > and the given endpoint is present > in `mtls_endpoints`, then it uses > that one. Otherwise it uses the > regular endpoint. It gives an AS a > lot of flexibility in deployment > options. I personally think > getting a 307 approach deployed > and working would be more > complicated and error prone. > > It is a minority use case at the > moment but there are forces in > play, like the push for increased > security in general and to have > javascript clients use the code > flow, that suggest it won't be > terribly unusual to see an AS that > wants to support MTLS clients and > javascript/spa clients at the same > time. > > I've personally wavered back and > forth in this thread on whether or > not to add the new metadata (or > something like it). With my > reasoning each way kinda explained > somewhere back in the 40 or so > messages that make up this thread. > But it seems like the rough > consensus of the group here is in > favor of it. > > On Fri, Feb 1, 2019 at 3:18 PM > Richard Backman, Annabelle > > > wrote: > > This strikes me as a very > prominent and confusing change > to support what seems to be a > minority use case. I’m getting > a headache just thinking about > the text needed to clarify > when the AS should provide > `mtls_endpoints` and when the > client should use that versus > using `token_endpoint.` Why is > the 307 status code > insufficient to cover the case > where a single AS supports > both mTLS and non-mTLS? > > -- > > Annabelle Richard Backman > > AWS Identity > > *From:* OAuth > > > on behalf of Brian Campbell > > > *Date:* Friday, February 1, > 2019 at 1:31 PM > *To:* George Fletcher > > > *Cc:* oauth > > *Subject:* Re: [OAUTH-WG] MTLS > and in-browser clients using > the token endpoint > > Yes, that would work. > > On Fri, Feb 1, 2019 at 2:28 PM > George Fletcher > > > wrote: > > What if the AS wants to > ONLY support MTLS > connections. Does it not > specify the optional > "mtls_endpoints" and just > use the normal metadata > values? > > On 1/15/19 8:48 AM, Brian > Campbell wrote: > > It would definitely be > optional, apologies if > that wasn't made > clear. It'd be > something to the > effect of optional for > the AS to include and > clients doing MTLS > would use it when > present in AS metadata. > > On Tue, Jan 15, 2019 > at 2:04 AM Dave Tonge > > > wrote: > > I'm in favour of > the > `mtls_endpoints` > metadata parameter > - although it > should be optional. > > > /CONFIDENTIALITY > NOTICE: This email may > contain confidential > and privileged > material for the sole > use of the intended > recipient(s). Any > review, use, > distribution or > disclosure by others > is strictly > prohibited.. If you > have received this > communication in > error, please notify > the sender immediately > by e-mail and delete > the message and any > file attachments from > your computer. Thank you./ > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > */CONFIDENTIALITY NOTICE: This > email may contain confidential > and privileged material for > the sole use of the intended > recipient(s). Any review, use, > distribution or disclosure by > others is strictly > prohibited.. If you have > received this communication in > error, please notify the > sender immediately by e-mail > and delete the message and any > file attachments from your > computer. Thank you./* > > > */CONFIDENTIALITY NOTICE: This > email may contain confidential and > privileged material for the sole > use of the intended recipient(s). > Any review, use, distribution or > disclosure by others is strictly > prohibited.. If you have received > this communication in error, > please notify the sender > immediately by e-mail and delete > the message and any file > attachments from your computer. > Thank you./* > > > */CONFIDENTIALITY NOTICE: This email > may contain confidential and > privileged material for the sole use > of the intended recipient(s). Any > review, use, distribution or > disclosure by others is strictly > prohibited.. If you have received this > communication in error, please notify > the sender immediately by e-mail and > delete the message and any file > attachments from your computer. Thank > you./* > > > */CONFIDENTIALITY NOTICE: This email may contain > confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly > prohibited.  If you have received this > communication in error, please notify the sender > immediately by e-mail and delete the message and > any file attachments from your computer. Thank you./* > > > */CONFIDENTIALITY NOTICE: This email may contain > confidential and privileged material for the sole use > of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly > prohibited.. If you have received this communication > in error, please notify the sender immediately by > e-mail and delete the message and any file attachments > from your computer. Thank you./* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > */CONFIDENTIALITY NOTICE: This email may contain confidential > and privileged material for the sole use of the intended > recipient(s). Any review, use, distribution or disclosure by > others is strictly prohibited.  If you have received this > communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from > your computer. Thank you./* > > > */CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./* > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------A854F252FE9AEF83274F2E20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I prefer this approach to an embedded JSON object. Possibly even just making the MTLS version its own directly referencable config under .well-known.

Thanks,
George

On 2/12/19 2:47 PM, Richard Backman, Annabelle wrote:

I’m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can’t adequately address it – and I’ll readily grant that we probably don’t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

 

Along those lines, instead of adding an “mtls_endpoints” metadata parameter, we could add an “mtls_alternate_metadata” parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the “either/or” semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO that’s a reasonable and pragmatic option.

 

Thanks

———

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A straw-man example might look like this

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

 

Our approach will be that we’ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using “mtls_token_endpoint”.

 

Thanks

———

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I’m referencing didn’t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Though I’ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint…good times. 😃

 

I don’t necessarily think an AS metadata property is wrong per se, but understand that you’re bolting a layer of flexibility onto a standard that wasn’t designed for that, and I don’t think the metadata proposal as it’s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it’s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I’m wrong) that we should punt it to a separate draft (e.g., “Authorization Server Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS’s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

 

Confusion from the client’s perspective:

  1. As far as I know, I’m a public client, and don’t know anything about mTLS, but the IT admins installed client certs in their users’ browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
  5. I don’t know what that “m” means, but they told me to use HTTPS, so I should use the one with “tls” in its name, right?

 

Yes, you can write normative text that answers most of these. But you’ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I’m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 


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

--------------A854F252FE9AEF83274F2E20-- From nobody Tue Feb 12 12:36:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940CE128B36 for ; Tue, 12 Feb 2019 12:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwkiY-FlbbPQ for ; Tue, 12 Feb 2019 12:36:37 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820139.outbound.protection.outlook.com [40.107.82.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC1212785F for ; Tue, 12 Feb 2019 12:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z89+NaChIeg93MVCZP0HR5gA2aS1+ZHJfb9zcPhMQIs=; b=vHrjsFvNiPK2tqQypi/QRvR0I4l1hW25ZEnfm2P5LozeZ7yEJ+MfHF5r7KrjSA5pQDFu/bp/jH1TnhGOLXDZQBtRfT1R4ZvdpmU0uDJ7tgU+zEq9xuCzWTXWIL7zGA32YQz8I5/eAFuQgkrV76iZDkikN05vty+cvzGZMUepyCs= Received: from BYAPR01CA0045.prod.exchangelabs.com (2603:10b6:a03:94::22) by BYAPR01MB3750.prod.exchangelabs.com (2603:10b6:a02:81::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Tue, 12 Feb 2019 20:36:34 +0000 Received: from BY2NAM03FT042.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::202) by BYAPR01CA0045.outlook.office365.com (2603:10b6:a03:94::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Tue, 12 Feb 2019 20:36:34 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.13) smtp.mailfrom=mit.edu; dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.13 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.13; helo=outgoing-exchange-3.mit.edu; Received: from outgoing-exchange-3.mit.edu (18.9.28.13) by BY2NAM03FT042.mail.protection.outlook.com (10.152.85.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Tue, 12 Feb 2019 20:36:33 +0000 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x1CKaQTo003951; Tue, 12 Feb 2019 15:36:31 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 12 Feb 2019 15:35:53 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 12 Feb 2019 15:36:19 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 12 Feb 2019 15:36:19 -0500 From: Justin Richer To: George Fletcher CC: "Richard Backman, Annabelle" , "Brian Campbell" , Dominick Baier , oauth Thread-Topic: [OAUTH-WG] MTLS token endoint & discovery Thread-Index: AQHUwF+R+S8P+Onl5kOpyXoHXgpqsaXa3QGAgAEmvgCAANjXAIAADfKAgAALU4CAAAJugA== Date: Tue, 12 Feb 2019 20:36:19 +0000 Message-ID: <542035A2-06B8-43E5-94FD-06FD398E7B60@mit.edu> References: <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <46105936-5ab5-af0f-764e-c9a1a2b6a66f@aol.com> In-Reply-To: <46105936-5ab5-af0f-764e-c9a1a2b6a66f@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_542035A206B843E594FD06FD398E7B60mitedu_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.13; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(376002)(396003)(2980300002)(199004)(38314003)(51914003)(189003)(51444003)(8936002)(54906003)(561944003)(2616005)(956004)(93886005)(126002)(236005)(246002)(66066001)(316002)(486006)(966005)(33656002)(6246003)(36906005)(786003)(476003)(478600001)(11346002)(88552002)(446003)(16586007)(26826003)(106002)(606006)(76176011)(33964004)(84326002)(8676002)(2906002)(6306002)(54896002)(7736002)(7596002)(14444005)(5024004)(106466001)(5070765005)(71190400001)(3846002)(7696005)(6116002)(336012)(53546011)(83716004)(229853002)(82746002)(356004)(66574012)(75432002)(186003)(53946003)(86362001)(102836004)(426003)(30864003)(36756003)(26005)(4326008)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB3750; H:outgoing-exchange-3.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-exchange-3.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT042; 1:9LgeQKIlFUOQl+KalAAF8fInI+7wrTuCzWhclfn2AA42JA2CW6UWmEbfk5RGFgUcK7v4cRV/FAgsY3OzvlJqlLnehsEyFtNxJ9MS0HXKx1BNlF/7qIq159uDJs5msddZLI4srln2JXIQbZ3WeAibsexv2j8p8uH8rPdeMlOhUJ8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: be0eea55-04ec-4121-7cf8-08d69129c6ec X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR01MB3750; X-MS-TrafficTypeDiagnostic: BYAPR01MB3750: X-MS-Exchange-PUrlCount: 10 X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB3750; 20:rJgLgwxDa0pRlPvuj9AYio+SjFPfXL1tBJhDDNnMmehVzUBxfZMEk4+OOsrXfP3tAES1wt2Fk+e650A2+mfI5mkx2p2F9aaKD3VhijF314EHnIJTHDzicbxCCkxQbBN/1Z/IpbqdK3hojKIxwphqUkGE08ANoMtHxPdg3/kq6bpIZ1aIteZRbtVbFpwKce9R1DXKThBk7365JgkDrZwxhRYmulQXKCbMnqNHfeRJ1wYaSrBkZoxsvkVepp2UMARB0xHblsQYSLVDbkWqRMTghgR/gGq6nku8viYngM7R6WeR9acIzOJ0fRUAu5ILIf9r+aBQ++HVNvRchy0iGLriM2v81YiL4oIvEND3wsIOR7jZZUNWNFhIk0+gWuDncljr9pgJKImPKKJJXgQR2sntIZaYJEk/wiB0d+3r9mgruHI0iPRKTaQG9iO3JyEUjB1krZcByFFdquc7fklKs9Etq7afZJ32IwvUYdewbLw4GuEniw79/fY7kgb8ASw4PIPOmFBUQNJCgrKvzPgF+Mi0DDDI6VGQLznmAkZbghlBZCK3LiLZfkY7VFh2091za3iVWuLc0Vz8PDlcLCq1hdVt1fUF5wrirPSK8J2bW0yVVEA= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0946DC87A1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BYAPR01MB3750; 23:vVwaoTX5H8yDJVGNfSnnBQMogk9D3NeRMM/XAlrDr?= =?us-ascii?Q?yToXzyNGubuTqAsfuHUVkcgpmcuFIoVuMQdWcLofEwHmqcro8pUEGl6xGxiT?= =?us-ascii?Q?K6u3OvrSHOlovMCeZ5d6HS3C4MtQH71aqQNrTZgRmiOIc6mWEv98oIOI4E9z?= =?us-ascii?Q?OUFrawKuWtW5gseeFAJmuSmbkI4zh9YJ/BgOml75T1v/NkT7Wce9ZipFWZVP?= =?us-ascii?Q?JnKrM/eDdgXT7Trj9LapayvIZ9w/OYOxz2Yt6Il1VvFAtkakohDb44Rg2g9h?= =?us-ascii?Q?/x5I0Loul6Vv55GqUW3SXLNOU5LzoYy76hQ/mcPsrV8imoV43anugb1myvjz?= =?us-ascii?Q?11Q+TrhF0cjM/CHEsnBYtLeHvnE6ssAzRJ7cPuS4WADX1Py+BMG9ErogVlXf?= =?us-ascii?Q?aC60y7sToa9XhYxsc2qLeu9y3K1R1xEF3T81a7qi7zv945FgLcM9xaRU8awB?= =?us-ascii?Q?j5pwdt6vxRjtuRbZKGY1pjHDNsy3ewOdDipV6WkbyGOYx/Fys4wgKbGitmdE?= =?us-ascii?Q?6XuQoY+Cg5v2b7fPG6EOmWm7Nx6569rzX6kuALXDBKP/zo2a+UgWMecWBCQF?= =?us-ascii?Q?Gu0Uwx/24A6ESpKqMw7YPGcc5JoeguJjkXX5qqr5IH8N5Nro8Dsk3sbqbFcO?= =?us-ascii?Q?67o27gpqj7R/JSNQJAVK63IB5QVqI4AcqzVDdTKblot6bI3tAnhogsWQodse?= =?us-ascii?Q?pfcHcPu9vptYrnuxqTL50zkny4ELXHsIREgTPmnrL8iF9nDgurAlSLgooXM6?= =?us-ascii?Q?htp426UP5jgLiYIbP7o5ifX3JLD+4RTLwUIzgxNyaEiswcTi3kA2wWCap2it?= =?us-ascii?Q?AT1b8Vw2Ltv1dbNC3Cjuss4L7c/lUhRRHk1QN03+IlAmeC+KEFXYHiEkKNtR?= =?us-ascii?Q?51CtuSuHDeC2gz2cxfAb2GN7OcoeIZwznpZwYfqy6j1acejG/S090E0jUaso?= =?us-ascii?Q?VMt5fR0XY/AKrp/dMnIRvBiE6amfF6TuivsuNJiDyzGoqWEOV/o+337HL1de?= =?us-ascii?Q?wGmXHeSPbKfMeajUMnTJ4XPtRdNz9f0O6G/3ZWcmEaQcURAElxnGVSFCOAMx?= =?us-ascii?Q?hsNf4LzUnkM0tBVvT4+AHcFpSAvqol51XYRo12XcimmGQRhVEC6bnxM22s7r?= =?us-ascii?Q?Ob6JevCtPpkId91mQR303HRGEYtabBB11sYvFZ86tj5BdZeUmtYLT93mS2Af?= =?us-ascii?Q?aveLzCdMbdSuD7KTdhUlQYovy6CLAhyqxrUVYJfi1TdPYtt0IXD9jq9HLi3T?= =?us-ascii?Q?BVKoBXTfaJ5Iod8YE8IFndoF6i8M8aqnQhepSKMLTQNsTMvrXMcY+STiSP5E?= =?us-ascii?Q?6Ii9jjL3ZK2Qsaa4zgmi5pzo3yfplXchzd9FRxVOghFOrdAbKuKYMWPbx0Tu?= =?us-ascii?Q?pqUmOkrYlZ+Ng7JW7xJITRBfKT8riB5qCczrJ43RBH5vZaOdxJHs4c7oE0O1?= =?us-ascii?Q?bngeuCbq5Q8BCys4d1qAoMPmXDKphGCZJxoK7U42zDdnyN9ngITi8GPflJWK?= =?us-ascii?Q?wcrWBzeITNl75RoWNvI5mEZ4ksGLjiInsjp0MAiRZtX31mtPw5OF55whLiiL?= =?us-ascii?Q?5xIkDdpiyhQF8gAlQ=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: YYsPU8894D22Ug8/FGpXXIjsi5Wm5q3wr5x8n81D5Wn/Caebu2tXadBSgXHRVrQ4BHUXx1s0CKvV5XPxRSfqgO1tfBP6gJ97rDWIGcrMQsNSMmEBL11djRb4JRzHPtx8QQPFIyiKYsXZVbl3XMr+No6FZF2pohojaO+zfbKBHkEcJrydBdkzDbzZzxFuEVZBUwF2p/+4cEGxYGL3OJn9Xrb4tfg6GnmBNKw77y6gq+QvXUsi58aMH/FsZsdxJTbfj9dJjIcUzmQ0kAA3oaWMIMEtgnQU9g7tr5vWerMXad3ry/QXGUnS6aDMVsXb35UBh43P+MBPytaeHojkaXxAmjLDRgqh4svcBF7m5UqOwGzXM56suyenHL9iLafOd/CkceIhSRw7I5m7M3Clkj5qAK3c4AXs+tss/jayvG55w7g= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2019 20:36:33.1423 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: be0eea55-04ec-4121-7cf8-08d69129c6ec X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.13]; Helo=[outgoing-exchange-3.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB3750 Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 20:36:44 -0000 --_000_542035A206B843E594FD06FD398E7B60mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gd2l0aCB0aGlzIGlkZWEgaXMgdGhhdCB0aGVyZeKAmXMgbm90IGEgc2luZ2xl IGNhbm9uaWNhbCBwbGFjZSBmb3IgT0F1dGgyIHN0dWZmIHVuZGVyIC53ZWxsLWtub3duLCBhY2Nv cmRpbmcgdG8gdGhlIGRpc2NvdmVyeSBkb2N1bWVudC4gT0lEQyBoYXMgb25lLCBVTUEyIGhhcyBv bmUsIGFuZCBJ4oCZbSBzdXJlIHRoZXJlIGFyZSBvdGhlciBmbGF2b3JzIGFzIHdlbGwuIEl0IHdv dWxkIG5vdCBtYWtlIHNlbnNlIGZvciB0aGVyZSB0byBiZSBhIG5ldyBvbmUganVzdCBmb3IgTVRM Uy1lbmFibGluZyBhbGwgb2YgdGhlc2UgT0F1dGgtcG93ZXJlZCBwcm90b2NvbHMuDQoNCuKAlCBK dXN0aW4NCg0KT24gRmViIDEyLCAyMDE5LCBhdCAzOjI3IFBNLCBHZW9yZ2UgRmxldGNoZXIgPGdm ZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Z2ZmbGV0Y2g9NDBhb2wuY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkkgcHJlZmVyIHRoaXMgYXBwcm9hY2ggdG8gYW4g ZW1iZWRkZWQgSlNPTiBvYmplY3QuIFBvc3NpYmx5IGV2ZW4ganVzdCBtYWtpbmcgdGhlIE1UTFMg dmVyc2lvbiBpdHMgb3duIGRpcmVjdGx5IHJlZmVyZW5jYWJsZSBjb25maWcgdW5kZXIgLndlbGwt a25vd24uDQoNClRoYW5rcywNCkdlb3JnZQ0KDQpPbiAyLzEyLzE5IDI6NDcgUE0sIFJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOg0KSeKAmW0gbm90IG9wcG9zZWQgdG8gaW50cm9kdWNp bmcgYSBtZXRhZGF0YSBjaGFuZ2UsIGlmIHRoZSBzY2VuYXJpbyBpcyByZWxldmFudCBhbmQgb3Ro ZXIgYXBwcm9hY2hlcyBjYW7igJl0IGFkZXF1YXRlbHkgYWRkcmVzcyBpdCDigJMgYW5kIEnigJls bCByZWFkaWx5IGdyYW50IHRoYXQgd2UgcHJvYmFibHkgZG9u4oCZdCB3YW50IHRvIGRlcGVuZCBv biBjb25zaXN0ZW5jeSBvZiBicm93c2VyIGJlaGF2aW9yIGF0IHRoZSBpbnRlcnNlY3Rpb24gb2Yg Y2xpZW50IGNlcnRpZmljYXRlcyBhbmQgQWNjZXNzLUNvbnRyb2wtQWxsb3ctQ3JlZGVudGlhbHMu IEJ1dCBjYXJlIG5lZWRzIHRvIGJlIHRha2VuIGluIGRlc2lnbmluZyB0aGF0IG1ldGFkYXRhIHRv IGF2b2lkIHZpb2xhdGluZyBvciBvdGhlcndpc2UgbmVnYXRpdmVseSBpbXBhY3RpbmcgdXNhZ2Ug b2YgUkZDODQxNC4NCg0KQWxvbmcgdGhvc2UgbGluZXMsIGluc3RlYWQgb2YgYWRkaW5nIGFuIOKA nG10bHNfZW5kcG9pbnRz4oCdIG1ldGFkYXRhIHBhcmFtZXRlciwgd2UgY291bGQgYWRkIGFuIOKA nG10bHNfYWx0ZXJuYXRlX21ldGFkYXRh4oCdIHBhcmFtZXRlciB3aG9zZSB2YWx1ZSBpcyB0aGUg VVJMIG9mIGFuIGFsdGVybmF0ZSBtZXRhZGF0YSBkb2N1bWVudCBpbnRlbmRlZCBmb3IgY2xpZW50 cyB1c2luZyBtVExTLiBBbiBtVExTLW9wdGlvbmFsIEFTIGNvdWxkIGhhdmUgdHdvIGRpZmZlcmVu dCBtZXRhZGF0YSBkb2N1bWVudHMgZm9yIG1UTFMgYW5kIG5vbi1tVExTIGNsaWVudHMsIHJlZHVj aW5nIHRoZSBtVExTLW9wdGlvbmFsIHNjZW5hcmlvIHRvIHRoZSBtVExTLW9ubHkgc2NlbmFyaW8u IFRoaXMgc2lkZXN0ZXBzIHRoZSBjaGFsbGVuZ2VzIG9mIGFsaWduaW5nIHRoZSDigJxlaXRoZXIv b3LigJ0gc2VtYW50aWNzIG9mIG1UTFMtb3B0aW9uYWwgd2l0aCBzb21lIG9mIHRoZSByaWdpZCBw YXJhbWV0ZXIgZGVmaW5pdGlvbnMgaW4gUkZDODQxNCAoc2VlOiB0b2tlbl9lbmRwb2ludCwgdG9r ZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCkuDQoNCi0tDQpBbm5hYmVsbGUgUmlj aGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNl c0BpZXRmLm9yZz48bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9y Zz48bWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpE YXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxOSBhdCAxMDo1OCBBTQ0KVG86IERvbWluaWNr IEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPjxtYWlsdG86ZGJhaWVyQGxlYXN0cHJp dmlsZWdlLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2Nv dmVyeQ0KDQpUaGFua3MgZm9yIHRoZSBpbnB1dCwgRG9taW5pY2suDQoNCkknZCBzYWlkIHByZXZp b3VzbHkgdGhhdCBJIHdhcyBoYXZpbmcgdHJvdWJsZSBhZGVxdWF0ZWx5IGdhdWdpbmcgd2hldGhl ciBvciBub3QgdGhlcmUncyBzdWZmaWNpZW50IGNvbnNlbnN1cyB0byBnbyBhaGVhZCB3aXRoIHRo ZSB1cGRhdGUuIEkgd2FzIGV2ZW4gdGhpbmtpbmcgb2YgYXNraW5nIHRoZSBjaGFpcnMgYWJvdXQg YSBjb25zZW5zdXMgY2FsbCBkdXJpbmcgdGhlIG9mZmljZSBob3VycyBtZWV0aW5nIHllc3RlcmRh eS4gQnV0IGl0IGdvdCBjYW5jZWxlZC4gQW5kIGxvb2tpbmcgYWdhaW4gYmFjayBvdmVyIHRoZSBk aXNjdXNzaW9uLCBJIGRvbid0IGJlbGlldmUgYSBjb25zZW5zdXMgY2FsbCBpcyBuZWNlc3Nhcnku IFRoZXJlJ3MgYmVlbiBhIGxvdCBvZiBnZW5lcmFsIGRpc2N1c3Npb24gb3ZlciB0aGUgbGFzdCBz ZXZlcmFsIHdlZWtzIGR1cmluZyB3aGljaCBzZXZlcmFsIGZvbGtzIGhhdmUgc3RhdGVkIHN1cHBv cnQgZm9yIHRoZSBwcm9wb3NhbCB3aGlsZSB0aGVyZSdzIGJlZW4gb25seSBvbmUgdm9pY2Ugb2Yg ZGlyZWN0IGRpc3NlbnQuIFRoYXQgc2VlbXMgbGlrZSByb3VnaCBlbm91Z2ggY29uc2Vuc3VzIGFu ZCwgYXMgc3VjaCwgSSBwbGFuIHRvIG1ha2UgdGhlIGNoYW5nZSBpbiB0aGUgbmV4dCByZXZpc2lv biBvZiB0aGUgZG9jdW1lbnQgKHdoaWNoIHNob3VsZCBiZSBkb25lIHNvb24pLiBDaGFpcnMsIHBs ZWFzZSBsZXQgbWUga25vdywgaWYgeW91IGJlbGlldmUgdGhlIHNpdHVhdGlvbiB3YXJyYW50cyBh IGRpZmZlcmVudCBjb3Vyc2Ugb2YgYWN0aW9uLg0KDQoNCg0KT24gTW9uLCBGZWIgMTEsIDIwMTkg YXQgMTE6MDEgUE0gRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFp bHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNCklNSE8gdGhhdOKAmXMgYSBy ZWFzb25hYmxlIGFuZCBwcmFnbWF0aWMgb3B0aW9uLg0KDQpUaGFua3MNCuKAlOKAlOKAlA0KRG9t aW5pY2sNCg0KDQpPbiAxMS4gRmVicnVhcnkgMjAxOSBhdCAxMzoyNjozNywgQnJpYW4gQ2FtcGJl bGwgKGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT4pIHdyb3RlOg0KSXQncyBiZWVuIHBvaW50ZWQgb3V0IHRoYXQgdGhlIHBvdGVudGlh bCBpc3N1ZSBpcyBub3QgaXNvbGF0ZWQgdG8gdGhlIGp1c3QgdG9rZW4gZW5kcG9pbnQgYnV0IHRo YXQgcmV2b2NhdGlvbiwgaW50cm9zcGVjdGlvbiwgZXRjLiBjb3VsZCBiZSBpbXBhY3RlZCBhcyB3 ZWxsLiBTbywgIGF0IHRoaXMgcG9pbnQsIHRoZSBwcm9wb3NhbCBvbiB0aGUgdGFibGUgaXMgdG8g YWRkIGEgbmV3IG9wdGlvbmFsIEFTIG1ldGFkYXRhIHBhcmFtZXRlciBuYW1lZCAnbXRsc19lbmRw b2ludHMnIHRoYXQncyB2YWx1ZSB3ZSBiZSBhIEpTT04gb2JqZWN0IHdoaWNoIGl0c2VsZiBjb250 YWlucyBlbmRwb2ludHMgdGhhdCwgd2hlbiBwcmVzZW50LCBhIGNsaWVudCBkb2luZyBNVExTIHdv dWxkIHVzZSByYXRoZXIgdGhhbiB0aGUgcmVndWxhciBlbmRwb2ludHMuICBBIHN0cmF3LW1hbiBl eGFtcGxlIG1pZ2h0IGxvb2sgbGlrZSB0aGlzDQp7DQogICJpc3N1ZXIiOiJodHRwczovL3NlcnZl ci5leGFtcGxlLmNvbTxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8+IiwNCiAgImF1dGhvcml6 YXRpb25fZW5kcG9pbnQiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRoeiIsDQogICJ0 b2tlbl9lbmRwb2ludCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgInRv a2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQiOlsgICJjbGllbnRfc2VjcmV0X2Jh c2ljIiwidGxzX2NsaWVudF9hdXRoIiwgIm5vbmUiXSwNCiAgInVzZXJpbmZvX2VuZHBvaW50Ijoi aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdXNlcmluZm8iLA0KICAicmV2b2NhdGlvbl9lbmRw b2ludCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Jldm8iLA0KICAiandrc191cmkiOiJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9qd2tzLmpzb24iLA0KICAibXRsc19lbmRwb2ludHMi OnsNCiAgICAidG9rZW5fZW5kcG9pbnQiOiJodHRwczovL210bHMuZXhhbXBsZS5jb20vdG9rZW4i LA0KICAgICJ1c2VyaW5mb19lbmRwb2ludCI6Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS91c2Vy aW5mbyIsDQogICAgInJldm9jYXRpb25fZW5kcG9pbnQiOiJodHRwczovL210bHMuZXhhbXBsZS5j b20vcmV2bzxodHRwczovL210bHMuLmV4YW1wbGUuY29tL3Jldm8+Ig0KICB9DQp9DQoNCkEgY2xp ZW50IGRvaW5nIE1UTFMgd291bGQgbG9vayBmb3IgYW5kIGdpdmUgcHJlY2VkZW5jZSB0byBhbiBl bmRwb2ludCB1bmRlciAibXRsc19lbmRwb2ludHMiIHdoaWxlIGZhbGxpbmcgYmFjayB0byB1c2Ug dGhlIG5vcm1hbCBlbmRwb2ludCBmcm9tIHRoZSB0b3AgbGV2ZWwgb2YgbWV0YWRhdGEgd2hlbi9p ZiBpdHMgbm90IGluICJtdGxzX2VuZHBvaW50cyIuDQoNClRoZSBpZGVhIGJlaW5nIHRoYXQgInJl Z3VsYXIiIGNsaWVudHMgKHRob3NlIG5vdCBkb2luZyBNVExTKSB3aWxsIHVzZSB0aGUgcmVndWxh ciBlbmRwb2ludHMuIEFuZCBvbmx5IHRoZSBob3N0L3BvcnQgb2YgdGhlIGVuZHBvaW50cyBsaXN0 ZWQgaW4gbXRsc19lbmRwb2ludHMgd2lsbCBiZSBzZXQgdXAgdG8gcmVxdWVzdCBUTFMgY2xpZW50 IGNlcnRpZmljYXRlcyBkdXJpbmcgaGFuZHNoYWtlLiBUaHVzIGFueSBwb3RlbnRpYWwgaW1wYWN0 IG9mIHRoZSBDZXJ0aWZpY2F0ZVJlcXVlc3QgbWVzc2FnZSBiZWluZyBzZW50IGluIHRoZSBUTFMg aGFuZHNoYWtlIGNhbiBiZSBhdm9pZGVkIGZvciBhbGwgdGhlIG90aGVyIHJlZ3VsYXIgY2xpZW50 cyB0aGF0IGFyZSBub3QgZ29pbmcgdG8gZG8gTVRMUyAtIGluY2x1ZGluZyBhbmQgbW9zdCBpbXBv cnRhbnRseSBpbi1icm93c2VyIGphdmFzY3JpcHQgY2xpZW50cyB3aGVyZSB0aGVyZSBjYW4gYmUg bGVzcyB0aGFuIGRlc2lyYWJsZSBVSSBwcmVzZW50ZWQgdG8gdGhlIGVuZC11c2VyLg0KDQpJJ20g c3RydWdnbGluZywgaG93ZXZlciwgdG8gYWRlcXVhdGVseSBnYXVnZSB3aGV0aGVyIG9yIG5vdCB0 aGVyZSdzIHN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvIGdvIGFoZWFkIHdpdGggdGhlIHVwZGF0ZS4g VGhlcmUncyBiZWVuIHNvbWUgc3VwcG9ydCBmb3IgaXQgdm9pY2VkLiBBcyB3ZWxsIGFzIHRhbGsg b2Ygb3RoZXIgYXBwcm9hY2hlcyB0aGF0IGNvdWxkIGJlIGFsdGVybmF0aXZlcyBvciBhZGRpdGlv bmFsIG1lYXN1cmVzLiBBbmQgYWxzbyBzb21lIHZvY2FsIG9wcG9zaXRpb24gdG8gaXQuDQoNCg0K T24gU2F0LCBGZWIgOSwgMjAxOSBhdCAzOjA5IEFNIERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVh c3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6 DQpXZSBhcmUgY3VycmVudGx5IGltcGxlbWVudGluZyBNVExTIGluIElkZW50aXR5U2VydmVyLg0K DQpPdXIgYXBwcm9hY2ggd2lsbCBiZSB0aGF0IHdl4oCZbGwgb2ZmZXIgYSBzZXBhcmF0ZSB0b2tl biBlbmRwb2ludCB0aGF0IHN1cHBvcnRzIGNsaWVudCBjZXJ0cy4gQXJlIHlvdSBwbGFubmluZyBv biBhZGRpbmcgYW4gb2ZmaWNpYWwgZW5kcG9pbnQgbmFtZSBmb3IgZGlzY292ZXJ5PyBSaWdodCBu b3cgd2UgYXJlIHVzaW5nIOKAnG10bHNfdG9rZW5fZW5kcG9pbnTigJ0uDQoNClRoYW5rcw0K4oCU 4oCU4oCUDQpEb21pbmljaw0KDQoNCk9uIDcuIEZlYnJ1YXJ5IDIwMTkgYXQgMjI6MzY6NTUsIEJy aWFuIENhbXBiZWxsIChiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPikgd3Jv dGU6DQoNCkFoIHllcywgdGhhdCBtYWtlcyBzZW5zZS4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nLiBB bmQgaXQgaXMgaW5kZWVkIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5u b2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gYnJl YWsgdGhpbmdzIHVuZXhwZWN0ZWRseS4uDQoNCg0KDQoNCg0KT24gVGh1LCBGZWIgNywgMjAxOSBh dCA4OjU3IEFNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29t PG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQpUaGUgY2FzZSBJ4oCZbSByZWZl cmVuY2luZyBkaWRu4oCZdCBzcGVjaWZpY2FsbHkgaW52b2x2ZSBBUyBtZXRhZGF0YS4gV2UgaGFk IGNsaWVudHMgaW4gdGhlIHdpbGQgdGhhdCBhc3N1bWVkIHRoYXQgYWxsIHRoZSBwcm9wZXJ0aWVz IGluIHRoZSBKU09OIG9iamVjdCByZXR1cm5lZCBmcm9tIG91ciB1c2VyaW5mbyBlbmRwb2ludCB3 ZXJlIHNjYWxhciBzdHJpbmdzLiBUaGlzIGJyb2tlIHdoZW4gd2UgaW50cm9kdWNlZCBhIG5ldyBw cm9wZXJ0eSB3aG9zZSB2YWx1ZSB3YXMgYSBKU09OIG9iamVjdC4gSXQgd2FzIGEgZ29vZCByZW1p bmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5ub2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBi ZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gZm9yY2UgbW9yZSB3b3JrIG9uIGNsaWVudHMgdGhh biB3ZSBleHBlY3QuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRp dHkNCg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208 bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgRmVi cnVhcnkgNiwgMjAxOSBhdCAxMTozMCBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24u Y29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxy aWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIG9hdXRoIDxv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRz IHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpBbmQgSSdtIGhvbmVzdGx5IHJlYWxseSBzdHJ1 Z2dsaW5nIHRvIHNlZSB3aGF0IGNvdWxkIGhhdmUgZ29uZSB3cm9uZyB3aXRoIG9yIGhvdyB0b2tl bl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYnJva2Ugc29tZXRoaW5nIHdpdGggdGhlIHVzZXIgaW5m byBlbmRwb2ludC4gSWYgeW91IGhhdmUgdGhlIHRpbWUgYW5kL29yIGl0J2QgYmUgaW5mb3JtYXRp dmUgdG8gdGhpcyBoZXJlIGxpdHRsZSBkaXNjdXNzaW9uLCBwbGVhc2UgZXhwbGFpbiB0aGF0IG9u ZSBhIGJpdCBtb3JlLg0KDQpPbiBXZWQsIEZlYiA2LCAyMDE5IGF0IDEyOjE1IFBNIEJyaWFuIENh bXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20+PiB3cm90ZToNCiJmYXIiIHNob3VsZCBoYXZlIHNhaWQgImZhaXIiIGluIHRo ZSBwcmV2aW91cyBtZXNzYWdlDQoNCg0KDQoNCg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCA0OjM1 IFBNIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkl0IG1heSB3ZWxsIGJlIGR1ZSB0byBt eSBvd24gaW50ZWxsZWN0dWFsIHNob3J0Y29taW5ncyBidXQgdGhlc2UgaXNzdWVzL3F1ZXN0aW9u cy9jb25mdXNpb24tcG9pbnRzIGFyZSBub3QgcmVzb25hdGluZyBmb3IgbWUgYXMgYmVpbmcgcHJv YmxlbWF0aWMuDQoNClRoZSBtb3JlIGdlbmVyYWwgc3RhbmNlIG9mICJ0aGlzIGlzbid0IG5lZWRl ZCBvciB3b3J0aCBpdCBpbiB0aGlzIGRvY3VtZW50IiAoSSB0aGluayB0aGF0J3MgZmFyPykgaXMg YmVpbmcgaGVhcmQgdGhvdWdoLg0KDQoNCg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQyIFBN IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4ub3JnPj4gd3JvdGU6DQoo VEw7RFI6IHB1bnQgQVMgbWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCkNCg0KQVMgcG9pbnRz ICMxLTMgYXJlIGFsbCBxdWVzdGlvbnMgSSB3b3VsZCBoYXZlIGFzIGFuIGltcGxlbWVudGVyOg0K DQogIDEuICBTZWN0aW9uIDIgb2YgUkZDODQxNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODQxNCNzZWN0aW9uLTI+IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlSRUQgdW5s ZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKAnSBTbyB3aGF0 IGRvZXMgdGhlIG1UTFMtb25seSBBUyBwdXQgaGVyZT8NCiAgMi4gIFRoZSBjbGFpbXMgZm9yIHRo ZXNlIG90aGVyIGVuZHBvaW50cyBhcmUgT1BUSU9OQUwsIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8g aW5jb25zaXN0ZW5jeSBkZXBlbmRpbmcgb24gaG93ICMxIGdldHMgZGVjaWRlZC4NCiAgMy4gIFRo ZSBleGFtcGxlIHVzYWdlIG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgcHJvcGVy dHkgZ2l2ZW4gZWFybGllciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0LCBzaW5jZSBzb21l IG9mIGl0cyBjb250ZW50cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1tVExTIGVuZHBvaW50 cywgYW5kIG90aGVycyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5kcG9pbnRzLiBIZW5j ZSB0aGlzIHF1ZXN0aW9uLg0KICA0LiAgVGhpcyBpbnRyb2R1Y2VzIGEgbmV3IG1ldGFkYXRhIHBy b3BlcnR5IHRoYXQgY291bGQgaW1wYWN0IGhvdyBvdGhlciBzcGVjcyBzaG91bGQgZXh0ZW5kIEFT IG1ldGFkYXRhLiBUaGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4NCg0KDQpJIGNvdWxkIGdvIG9u IGZvciBjbGllbnQgcG9pbnRzIGJ1dCB5b3UgYWxyZWFkeSBnZXQgdGhlIHBvaW50LiBUaG91Z2gg SeKAmWxsIHNoYXJlIHRoYXQgIzMgaXMgcmVhbCBhbmQgb25jZSBmb3JjZWQgbWUgdG8gcm9sbCBi YWNrIGFuIHVwZGF0ZSB0byB0aGUgTG9naW4gd2l0aCBBbWF6b24gdXNlcmluZm8gZW5kcG9pbnTi gKZnb29kIHRpbWVzLiDwn5iDDQoNCkkgZG9u4oCZdCBuZWNlc3NhcmlseSB0aGluayBhbiBBUyBt ZXRhZGF0YSBwcm9wZXJ0eSBpcyB3cm9uZyBwZXIgc2UsIGJ1dCB1bmRlcnN0YW5kIHRoYXQgeW91 4oCZcmUgYm9sdGluZyBhIGxheWVyIG9mIGZsZXhpYmlsaXR5IG9udG8gYSBzdGFuZGFyZCB0aGF0 IHdhc27igJl0IGRlc2lnbmVkIGZvciB0aGF0LCBhbmQgSSBkb27igJl0IHRoaW5rIHRoZSBtZXRh ZGF0YSBwcm9wb3NhbCBhcyBpdOKAmXMgYmVlbiBkaXNjdXNzZWQgaGVyZSBzdWZmaWNpZW50bHkg ZGVhbHMgd2l0aCB0aGUgZmFsbG91dCBmcm9tIHRoYXQuIEluIG15IHZpZXcgdGhpcyBpcyBhIGNv bXBsZXggZW5vdWdoIGlzc3VlIGFuZCBpdOKAmXMgZm9yIGEgbnVhbmNlZCBlbm91Z2ggdXNlIGNh c2UgKGFzIGZhciBhcyBJIGNhbiB0ZWxsIGZyb20gZGlzY3Vzc2lvbj8gUGxlYXNlIGNvcnJlY3Qg bWUgaWYgSeKAmW0gd3JvbmcpIHRoYXQgd2Ugc2hvdWxkIHB1bnQgaXQgdG8gYSBzZXBhcmF0ZSBk cmFmdCAoZS5nLiwg4oCcQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGEgRXh0ZW5zaW9ucyBm b3IgbVRMUyBIeWJyaWRz4oCdKSBhbmQgZ2V0IG1UTFMgb3V0IHRoZSBkb29yLg0KDQotLQ0KQW5u YWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpE YXRlOiBNb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkgYXQgNToyOCBBTQ0KVG86ICJSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtV TlZFUklGSUVEIFNFTkRFUl0gUmU6IE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0 aGUgdG9rZW4gZW5kcG9pbnQNCg0KVGhvc2UgcG9pbnRzIG9mIGNvbmZ1c2lvbiBzdHJpa2UgbWUg YXMgc29tZXdoYXQgaHlwb3RoZXRpY2FsIG9yIGh5cGVyYm9saWMuIEJ1dCB5b3VyIGdlbmVyYWwg cG9pbnQgaXMgdGFrZW4gYW5kIHlvdXIgcG9zaXRpb24gb2YgYmVpbmcgYW50aSBhZGRpdGlvbmFs IG1ldGFkYXRhIG9uIHRoaXMgaXNzdWUgaXMgbm90ZWQuDQoNCkFsbCBvZiB3aGljaCBsZWF2ZXMg bWUgYSBiaXQgdW5jZXJ0YWluIGFib3V0IGhvdyB0byBwcm9jZWVkLiBUaGVyZSBzZWVtIHRvIGJl IGEgcmFuZ2Ugb2Ygb3BpbmlvbnMgb24gdGhpcyBwb2ludCBhbmQgZ2F1Z2luZyBjb25zZW5zdXMg aXMgcHJvdmluZyBlbHVzaXZlIGZvciBtZS4gVGhhdCdzIGNvbmZvdW5kZWQgYnkgbXkgb3duIG9w aW5pb24gb24gaXQgYmVpbmcgc29tZXdoYXQgZmx1aWQuDQoNCkFuZCBJJ2QgcmVhbGx5IGxpa2Ug dG8gcG9zdCBhbiB1cGRhdGUgdG8gdGhpcyBkcmFmdCBhYm91dCBhIG1vbnRoIG9yIHR3byBhZ28u DQoNCg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDU6MDMgUE0gUmljaGFyZCBCYWNr bWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi5vcmc+PiB3cm90ZToNCkNvbmZ1c2lvbiBmcm9t IHRoZSBBU+KAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIElmIEkgb25seSBzdXBwb3J0IG1UTFMs IGRvIEkgbmVlZCB0byBpbmNsdWRlIGJvdGggdG9rZW5fZW5kcG9pbnRfdXJpIGFuZCBtdGxzX2Vu ZHBvaW50cz8gU2hvdWxkIEkgb21pdCB0b2tlbl9lbmRwb2ludF91cmk/IE9yIHNldCBpdCB0byB0 aGUgZW1wdHkgc3RyaW5nPw0KICAyLiAgV2hhdCBpZiBJIG9ubHkgc3VwcG9ydCBtVExTIGZvciB0 aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCBub3QgcmV2b2NhdGlvbiBvciB1c2VyIGluZm8/DQogIDMu ICBIb3cgZG8gSSBzcGVjaWZ5IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgZm9yIHRoZSBtVExTIHRv a2VuIGVuZHBvaW50PyBEb2VzIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBhcHBseSB0byBi b3RoIHRoZSBtVExTIGFuZCBub24tbVRMUyBlbmRwb2ludHM/DQogIDQuICBJ4oCZbSB1c2luZyB0 aGUgT0F1dGggMi4wIERldmljZSBGbG93LiBEbyBJIGluY2x1ZGUgYSBtVExTLWVuYWJsZWQgZGV2 aWNlX2F1dGhvcml6YXRpb25fZW5kcG9pbnQgdW5kZXIgbXRsc19lbmRwb2ludHM/DQoNCg0KQ29u ZnVzaW9uIGZyb20gdGhlIGNsaWVudOKAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIEFzIGZhciBh cyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0aGlu ZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRzIGlu IHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhhdCB0 byBhdXRoZW50aWNhdGUgbWUuDQogIDIuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBi ZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuDQogIDMu ICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIGl0IGRpZG7igJl0IGV4cGVj dCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBhcyBhIHBhcmFtZXRlciB2YWx1ZS4NCiAgNC4g IFRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZvciBtdGxzX2VuZHBv aW50cywgd2hhdCBkbyBJIGRvPw0KICA1LiAgSSBkb27igJl0IGtub3cgd2hhdCB0aGF0IOKAnG3i gJ0gbWVhbnMsIGJ1dCB0aGV5IHRvbGQgbWUgdG8gdXNlIEhUVFBTLCBzbyBJIHNob3VsZCB1c2Ug dGhlIG9uZSB3aXRoIOKAnHRsc+KAnSBpbiBpdHMgbmFtZSwgcmlnaHQ/DQoNCg0KWWVzLCB5b3Ug Y2FuIHdyaXRlIG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5zd2VycyBtb3N0IG9mIHRoZXNlLiBCdXQg eW914oCZbGwgaGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEgbG90IG9mIHNpbWlsYXItYnV0LXNsaWdo dGx5LWRpZmZlcmVudCBzY2VuYXJpb3MgYW5kIGJlIHZlcnkgZXhwbGljaXQuIEFuZCBpbXBsZW1l bnRlcnMgd2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9k dWNlcyBvcHBvcnR1bml0aWVzIGZvciBjb25mdXNpb24gYW5kIGZhaWx1cmUgdGhhdCBkbyBub3Qg ZXhpc3Qgbm93LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZlcnlvbmUgd2hvIHN1cHBvcnRzIG1UTFMu IEluIGNvbnRyYXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlzIG9ubHkgcmVxdWlyZWQgd2hlbiBhbiBB UyB3YW50cyB0byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1bmFtYmlndW91cyBpbiBpdHMgYmVoYXZp b3IgYW5kIG1lYW5pbmcuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRl bnRpdHkNCg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAzOjE3IFBNDQpUbzogIlJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+DQpDYzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29t PG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRI LVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50 DQoNCkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxhcmdlIG9mIGEgY2hh bmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0aGUgZ2l2ZW4gZW5k cG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0IHVzZXMgdGhhdCBv bmUuICBPdGhlcndpc2UgaXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4g QVMgYSBsb3Qgb2YgZmxleGliaWxpdHkgaW4gZGVwbG95bWVudCBvcHRpb25zLiBJIHBlcnNvbmFs bHkgdGhpbmsgZ2V0dGluZyBhIDMwNyBhcHByb2FjaCBkZXBsb3llZCBhbmQgd29ya2luZyB3b3Vs ZCBiZSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBwcm9uZS4NCg0KSXQgaXMgYSBtaW5vcml0 eSB1c2UgY2FzZSBhdCB0aGUgbW9tZW50IGJ1dCB0aGVyZSBhcmUgZm9yY2VzIGluIHBsYXksIGxp a2UgdGhlIHB1c2ggZm9yIGluY3JlYXNlZCBzZWN1cml0eSBpbiBnZW5lcmFsIGFuZCB0byBoYXZl IGphdmFzY3JpcHQgY2xpZW50cyB1c2UgdGhlIGNvZGUgZmxvdywgdGhhdCBzdWdnZXN0IGl0IHdv bid0IGJlIHRlcnJpYmx5IHVudXN1YWwgdG8gc2VlIGFuIEFTIHRoYXQgd2FudHMgdG8gc3VwcG9y dCBNVExTIGNsaWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNhbWUgdGlt ZS4NCg0KSSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQgZm9ydGggaW4gdGhpcyB0aHJl YWQgb24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0YWRhdGEgKG9yIHNvbWV0aGlu ZyBsaWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkga2luZGEgZXhwbGFpbmVkIHNv bWV3aGVyZSBiYWNrIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0 aHJlYWQuICBCdXQgaXQgc2VlbXMgbGlrZSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSBncm91 cCBoZXJlIGlzIGluIGZhdm9yIG9mIGl0Lg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0 IDM6MTggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi5vcmc+PiB3 cm90ZToNClRoaXMgc3RyaWtlcyBtZSBhcyBhIHZlcnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcg Y2hhbmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVtcyB0byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ 4oCZbSBnZXR0aW5nIGEgaGVhZGFjaGUganVzdCB0aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVk ZWQgdG8gY2xhcmlmeSB3aGVuIHRoZSBBUyBzaG91bGQgcHJvdmlkZSBgbXRsc19lbmRwb2ludHNg IGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGF0IHZlcnN1cyB1c2luZyBgdG9rZW5f ZW5kcG9pbnQuYCBXaHkgaXMgdGhlIDMwNyBzdGF0dXMgY29kZSBpbnN1ZmZpY2llbnQgdG8gY292 ZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgQVMgc3VwcG9ydHMgYm90aCBtVExTIGFuZCBub24t bVRMUz8NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoN CkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5n aWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmc+Pg0KRGF0ZTogRnJpZGF5LCBGZWJydWFyeSAxLCAyMDE5IGF0IDE6MzEgUE0N ClRvOiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBhb2wuY29tQGRtYXJjLi4uLi4uaWV0Zi5vcmc+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBp ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g TVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpZ ZXMsIHRoYXQgd291bGQgd29yay4NCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdl b3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCldoYXQgaWYgdGhlIEFTIHdhbnRzIHRv IE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rpb25zLiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRoZSBv cHRpb25hbCAibXRsc19lbmRwb2ludHMiIGFuZCBqdXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRh IHZhbHVlcz8NCk9uIDEvMTUvMTkgODo0OCBBTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQpJdCB3 b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFsLCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFk ZSBjbGVhci4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3Ig dGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hl biBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0KDQpPbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0 IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51azxtYWlsdG86ZGF2ZS50 b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3JvdGU6DQpJJ20gaW4gZmF2b3VyIG9mIHRoZSBgbXRs c19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhvdWdoIGl0IHNob3VsZCBiZSBv cHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1 dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCg0KDQoNCkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6 IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVy aWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJl dmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNF OiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRl cmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_542035A206B843E594FD06FD398E7B60mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoZSBwcm9ibGVtIHdpdGggdGhpcyBpZGVhIGlz IHRoYXQgdGhlcmXigJlzIG5vdCBhIHNpbmdsZSBjYW5vbmljYWwgcGxhY2UgZm9yIE9BdXRoMiBz dHVmZiB1bmRlciAud2VsbC1rbm93biwgYWNjb3JkaW5nIHRvIHRoZSBkaXNjb3ZlcnkgZG9jdW1l bnQuIE9JREMgaGFzIG9uZSwgVU1BMiBoYXMgb25lLCBhbmQgSeKAmW0gc3VyZSB0aGVyZSBhcmUg b3RoZXIgZmxhdm9ycyBhcyB3ZWxsLiBJdCB3b3VsZCBub3QgbWFrZSBzZW5zZSBmb3IgdGhlcmUg dG8gYmUNCiBhIG5ldyBvbmUganVzdCBmb3IgTVRMUy1lbmFibGluZyBhbGwgb2YgdGhlc2UgT0F1 dGgtcG93ZXJlZCBwcm90b2NvbHMuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIEZlYiAxMiwgMjAxOSwgYXQgMzoyNyBQTSwgR2VvcmdlIEZsZXRjaGVyICZs dDs8YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnIiBjbGFz cz0iIj5nZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGZhY2U9IkhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPkkNCiBwcmVmZXIg dGhpcyBhcHByb2FjaCB0byBhbiBlbWJlZGRlZCBKU09OIG9iamVjdC4gUG9zc2libHkgZXZlbiBq dXN0IG1ha2luZyB0aGUgTVRMUyB2ZXJzaW9uIGl0cyBvd24gZGlyZWN0bHkgcmVmZXJlbmNhYmxl IGNvbmZpZyB1bmRlciAud2VsbC1rbm93bi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGFua3MsPGJyIGNsYXNzPSIiPg0KR2VvcmdlPGJyIGNsYXNzPSIiPg0KPC9mb250PjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyI+DQpPbiAyLzEyLzE5IDI6NDcgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2l0ZT0ibWlkOkREREM3Qzg0LTYwRkYtNDNDRC1CQzFGLUUxM0NENjkzNzY1NUBhbWF6b24u Y29tIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2Vj dGlvbjE7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSeKA mW0gbm90IG9wcG9zZWQgdG8gaW50cm9kdWNpbmcgYSBtZXRhZGF0YSBjaGFuZ2UsIGlmIHRoZSBz Y2VuYXJpbyBpcyByZWxldmFudCBhbmQgb3RoZXIgYXBwcm9hY2hlcyBjYW7igJl0IGFkZXF1YXRl bHkgYWRkcmVzcyBpdCDigJMgYW5kIEnigJlsbCByZWFkaWx5IGdyYW50IHRoYXQgd2UgcHJvYmFi bHkgZG9u4oCZdCB3YW50IHRvIGRlcGVuZCBvbiBjb25zaXN0ZW5jeSBvZiBicm93c2VyIGJlaGF2 aW9yIGF0IHRoZSBpbnRlcnNlY3Rpb24gb2YgY2xpZW50IGNlcnRpZmljYXRlcw0KIGFuZCBBY2Nl c3MtQ29udHJvbC1BbGxvdy1DcmVkZW50aWFscy4gQnV0IGNhcmUgbmVlZHMgdG8gYmUgdGFrZW4g aW4gZGVzaWduaW5nIHRoYXQgbWV0YWRhdGEgdG8gYXZvaWQgdmlvbGF0aW5nIG9yIG90aGVyd2lz ZSBuZWdhdGl2ZWx5IGltcGFjdGluZyB1c2FnZSBvZiBSRkM4NDE0LjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCkFsb25nIHRob3NlIGxpbmVzLCBpbnN0ZWFkIG9mIGFkZGluZyBh biDigJxtdGxzX2VuZHBvaW50c+KAnSBtZXRhZGF0YSBwYXJhbWV0ZXIsIHdlIGNvdWxkIGFkZCBh biDigJxtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YeKAnSBwYXJhbWV0ZXIgd2hvc2UgdmFsdWUgaXMg dGhlIFVSTCBvZiBhbiBhbHRlcm5hdGUgbWV0YWRhdGEgZG9jdW1lbnQgaW50ZW5kZWQgZm9yIGNs aWVudHMgdXNpbmcgbVRMUy4gQW4gbVRMUy1vcHRpb25hbCBBUyBjb3VsZCBoYXZlIHR3byBkaWZm ZXJlbnQNCiBtZXRhZGF0YSBkb2N1bWVudHMgZm9yIG1UTFMgYW5kIG5vbi1tVExTIGNsaWVudHMs IHJlZHVjaW5nIHRoZSBtVExTLW9wdGlvbmFsIHNjZW5hcmlvIHRvIHRoZSBtVExTLW9ubHkgc2Nl bmFyaW8uIFRoaXMgc2lkZXN0ZXBzIHRoZSBjaGFsbGVuZ2VzIG9mIGFsaWduaW5nIHRoZSDigJxl aXRoZXIvb3LigJ0gc2VtYW50aWNzIG9mIG1UTFMtb3B0aW9uYWwgd2l0aCBzb21lIG9mIHRoZSBy aWdpZCBwYXJhbWV0ZXIgZGVmaW5pdGlvbnMgaW4gUkZDODQxNCAoc2VlOg0KIHRva2VuX2VuZHBv aW50LCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkKS48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsiIGNsYXNzPSIiPi0tJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBj bGFzcz0iIj5BV1MgSWRlbnRpdHk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBwYWRkaW5nOiAzcHQgMGluIDBp bjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+RnJv bTo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+T0F1dGg8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgY2xhc3M9Im1vei10 eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPiZsdDtvYXV0 aC1ib3VuY2VzQGlldGYub3JnJmd0OzwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+b24NCiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGw8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgY2xhc3M9Im1vei10eHQt bGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21A ZG1hcmMuaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiPiZsdDtiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn Jmd0OzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5EYXRlOjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwgRmVicnVhcnkgMTIs IDIwMTkgYXQgMTA6NTggQU08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkRvbWluaWNrIEJhaWVy PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGNsYXNz PSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxl Z2UuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 Ij4mbHQ7ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSZndDs8L2E+PGJyIGNsYXNzPSIiPg0KPGIg Y2xhc3M9IiI+Q2M6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvYj5vYXV0aDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ U3ViamVjdDo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPlJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmYW1wOyBkaXNjb3Zlcnk8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIGlucHV0 LCBEb21pbmljay48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSSdkIHNhaWQgcHJldmlvdXNseSB0aGF0IEkg d2FzIGhhdmluZyB0cm91YmxlIGFkZXF1YXRlbHkgZ2F1Z2luZyB3aGV0aGVyIG9yIG5vdCB0aGVy ZSdzIHN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvIGdvIGFoZWFkIHdpdGggdGhlIHVwZGF0ZS4gSSB3 YXMgZXZlbiB0aGlua2luZyBvZiBhc2tpbmcgdGhlIGNoYWlycyBhYm91dCBhIGNvbnNlbnN1cyBj YWxsIGR1cmluZyB0aGUgb2ZmaWNlIGhvdXJzIG1lZXRpbmcgeWVzdGVyZGF5LiBCdXQgaXQgZ290 IGNhbmNlbGVkLg0KIEFuZCBsb29raW5nIGFnYWluIGJhY2sgb3ZlciB0aGUgZGlzY3Vzc2lvbiwg SSBkb24ndCBiZWxpZXZlIGEgY29uc2Vuc3VzIGNhbGwgaXMgbmVjZXNzYXJ5LiBUaGVyZSdzIGJl ZW4gYSBsb3Qgb2YgZ2VuZXJhbCBkaXNjdXNzaW9uIG92ZXIgdGhlIGxhc3Qgc2V2ZXJhbCB3ZWVr cyBkdXJpbmcgd2hpY2ggc2V2ZXJhbCBmb2xrcyBoYXZlIHN0YXRlZCBzdXBwb3J0IGZvciB0aGUg cHJvcG9zYWwgd2hpbGUgdGhlcmUncyBiZWVuIG9ubHkgb25lIHZvaWNlDQogb2YgZGlyZWN0IGRp c3NlbnQuIFRoYXQgc2VlbXMgbGlrZSByb3VnaCBlbm91Z2ggY29uc2Vuc3VzIGFuZCwgYXMgc3Vj aCwgSSBwbGFuIHRvIG1ha2UgdGhlIGNoYW5nZSBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUg ZG9jdW1lbnQgKHdoaWNoIHNob3VsZCBiZSBkb25lIHNvb24pLiBDaGFpcnMsIHBsZWFzZSBsZXQg bWUga25vdywgaWYgeW91IGJlbGlldmUgdGhlIHNpdHVhdGlvbiB3YXJyYW50cyBhIGRpZmZlcmVu dCBjb3Vyc2Ugb2YgYWN0aW9uLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9uIE1vbiwgRmVi IDExLCAyMDE5IGF0IDExOjAxIFBNIERvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJtYWlsdG86 ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgY2xhc3M9IiI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXIt c3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBib3Jk ZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2 cHQ7IG1hcmdpbi1sZWZ0OiA0LjhwdDsgbWFyZ2luLXJpZ2h0OiAwaW47IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogSGVsdmV0aWNhOyIgY2xhc3M9IiI+SU1ITyB0aGF04oCZcyBhIHJlYXNvbmFibGUgYW5kIHBy YWdtYXRpYyBvcHRpb24uPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsiIGNsYXNzPSIiPlRoYW5rczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQrigJTigJTigJQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkRvbWluaWNrPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 cCBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4 NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5 M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9uIiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCk9uIDExLiBGZWJydWFyeSAyMDE5IGF0IDEzOjI2OjM3LCBC cmlhbiBDYW1wYmVsbCAoPGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t IiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5iY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbTwvYT4pIHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCkl0J3MgYmVlbiBwb2ludGVkIG91dCB0aGF0IHRoZSBw b3RlbnRpYWwgaXNzdWUgaXMgbm90IGlzb2xhdGVkIHRvIHRoZSBqdXN0IHRva2VuIGVuZHBvaW50 IGJ1dCB0aGF0IHJldm9jYXRpb24sIGludHJvc3BlY3Rpb24sIGV0Yy4gY291bGQgYmUgaW1wYWN0 ZWQgYXMgd2VsbC4gU28sJm5ic3A7IGF0IHRoaXMgcG9pbnQsIHRoZSBwcm9wb3NhbCBvbiB0aGUg dGFibGUgaXMgdG8gYWRkIGEgbmV3IG9wdGlvbmFsIEFTIG1ldGFkYXRhIHBhcmFtZXRlciBuYW1l ZA0KICdtdGxzX2VuZHBvaW50cycgdGhhdCdzIHZhbHVlIHdlIGJlIGEgSlNPTiBvYmplY3Qgd2hp Y2ggaXRzZWxmIGNvbnRhaW5zIGVuZHBvaW50cyB0aGF0LCB3aGVuIHByZXNlbnQsIGEgY2xpZW50 IGRvaW5nIE1UTFMgd291bGQgdXNlIHJhdGhlciB0aGFuIHRoZSByZWd1bGFyIGVuZHBvaW50cy4m bmJzcDsgQSBzdHJhdy1tYW4gZXhhbXBsZSBtaWdodCBsb29rIGxpa2UgdGhpczxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2lu LWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCns8YnIgY2xhc3M9IiI+DQombmJzcDsgJnF1b3Q7aXNzdWVyJnF1b3Q7OiZx dW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsi IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb208L2E+ JnF1b3Q7LDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmcXVvdDthdXRob3JpemF0aW9uX2VuZHBvaW50 JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGh6IiB0 YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3NlcnZlci5l eGFtcGxlLmNvbS9hdXRoejwvYT4mcXVvdDssPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZxdW90O3Rv a2VuX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUu Y29tL3Rva2VuIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRw czovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbjwvYT4mcXVvdDssPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZxdW90O3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQmcXVvdDs6WyAm bmJzcDsmcXVvdDtjbGllbnRfc2VjcmV0X2Jhc2ljJnF1b3Q7LCZxdW90O3Rsc19jbGllbnRfYXV0 aCZxdW90OywgJnF1b3Q7bm9uZSZxdW90O10sPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZxdW90O3Vz ZXJpbmZvX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1w bGUuY29tL3VzZXJpbmZvIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbS91c2VyaW5mbzwvYT4mcXVvdDssPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZxdW90O3Jldm9jYXRpb25fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2byIgdGFyZ2V0PSJfYmxhbmsiIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2bzwvYT4m cXVvdDssPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZxdW90O2p3a3NfdXJpJnF1b3Q7OiZxdW90Ozxh IGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3a3MuanNvbiIgdGFyZ2V0PSJfYmxh bmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20v andrcy5qc29uPC9hPiZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDs8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+JnF1b3Q7bXRsc19l bmRwb2ludHMmcXVvdDs6ezxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7dG9rZW5f ZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rv a2VuIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL210 bHMuZXhhbXBsZS5jb20vdG9rZW48L2E+JnF1b3Q7LDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJnF1b3Q7dXNlcmluZm9fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9t dGxzLmV4YW1wbGUuY29tL3VzZXJpbmZvIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5odHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm88L2E+JnF1b3Q7LDxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7cmV2b2NhdGlvbl9lbmRwb2ludCZxdW90 OzomcXVvdDs8YSBocmVmPSJodHRwczovL210bHMuLmV4YW1wbGUuY29tL3Jldm8iIHRhcmdldD0i X2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vbXRscy5leGFtcGxlLmNv bS9yZXZvPC9hPiZxdW90OzxiciBjbGFzcz0iIj4NCiZuYnNwOyB9PC9iPjxiciBjbGFzcz0iIj4N Cn08bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpBIGNsaWVudCBkb2lu ZyBNVExTIHdvdWxkIGxvb2sgZm9yIGFuZCBnaXZlIHByZWNlZGVuY2UgdG8gYW4gZW5kcG9pbnQg dW5kZXIgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgd2hpbGUgZmFsbGluZyBiYWNrIHRvIHVz ZSB0aGUgbm9ybWFsIGVuZHBvaW50IGZyb20gdGhlIHRvcCBsZXZlbCBvZiBtZXRhZGF0YSB3aGVu L2lmIGl0cyBub3QgaW4gJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsuPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGlkZWEgYmVpbmcgdGhh dCAmcXVvdDtyZWd1bGFyJnF1b3Q7IGNsaWVudHMgKHRob3NlIG5vdCBkb2luZyBNVExTKSB3aWxs IHVzZSB0aGUgcmVndWxhciBlbmRwb2ludHMuIEFuZCBvbmx5IHRoZSBob3N0L3BvcnQgb2YgdGhl IGVuZHBvaW50cyBsaXN0ZWQgaW4gbXRsc19lbmRwb2ludHMgd2lsbCBiZSBzZXQgdXAgdG8gcmVx dWVzdCBUTFMgY2xpZW50IGNlcnRpZmljYXRlcyBkdXJpbmcgaGFuZHNoYWtlLiBUaHVzIGFueSBw b3RlbnRpYWwgaW1wYWN0IG9mIHRoZQ0KIENlcnRpZmljYXRlUmVxdWVzdCBtZXNzYWdlIGJlaW5n IHNlbnQgaW4gdGhlIFRMUyBoYW5kc2hha2UgY2FuIGJlIGF2b2lkZWQgZm9yIGFsbCB0aGUgb3Ro ZXIgcmVndWxhciBjbGllbnRzIHRoYXQgYXJlIG5vdCBnb2luZyB0byBkbyBNVExTIC0gaW5jbHVk aW5nIGFuZCBtb3N0IGltcG9ydGFudGx5IGluLWJyb3dzZXIgamF2YXNjcmlwdCBjbGllbnRzIHdo ZXJlIHRoZXJlIGNhbiBiZSBsZXNzIHRoYW4gZGVzaXJhYmxlIFVJIHByZXNlbnRlZCB0bw0KIHRo ZSBlbmQtdXNlci48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJJ20gc3RydWdnbGluZywgaG93 ZXZlciwgdG8gYWRlcXVhdGVseSBnYXVnZSB3aGV0aGVyIG9yIG5vdCB0aGVyZSdzIHN1ZmZpY2ll bnQgY29uc2Vuc3VzIHRvIGdvIGFoZWFkIHdpdGggdGhlIHVwZGF0ZS4gVGhlcmUncyBiZWVuIHNv bWUgc3VwcG9ydCBmb3IgaXQgdm9pY2VkLiBBcyB3ZWxsIGFzIHRhbGsgb2Ygb3RoZXIgYXBwcm9h Y2hlcyB0aGF0IGNvdWxkIGJlIGFsdGVybmF0aXZlcyBvciBhZGRpdGlvbmFsIG1lYXN1cmVzLiBB bmQgYWxzbyBzb21lDQogdm9jYWwgb3Bwb3NpdGlvbiB0byBpdC4mbmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NCk9uIFNhdCwgRmViIDksIDIwMTkgYXQgMzowOSBBTSBEb21pbmljayBCYWllciAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2Js YW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxl ZnQtd2lkdGg6IDFwdDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFk ZGluZzogMGluIDBpbiAwaW4gNnB0OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDog MGluOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPldlIGFyZSBjdXJyZW50 bHkgaW1wbGVtZW50aW5nIE1UTFMgaW4gSWRlbnRpdHlTZXJ2ZXIuPG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPk91ciBhcHByb2FjaCB3aWxsIGJl IHRoYXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBvaW50IHRoYXQgc3VwcG9y dHMgY2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGluZyBhbiBvZmZpY2lhbCBl bmRwb2ludCBuYW1lIGZvciBkaXNjb3Zlcnk/IFJpZ2h0IG5vdyB3ZSBhcmUgdXNpbmcg4oCcbXRs c190b2tlbl9lbmRwb2ludOKAnS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogSGVs dmV0aWNhOyIgY2xhc3M9IiI+VGhhbmtzPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCuKAlOKAlOKAlDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KRG9taW5pY2s8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjxwIGNsYXNzPSJnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYx MTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMy NjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAx NWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2YWlybWFpbG9uIiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCk9uIDcuIEZlYnJ1YXJ5IDIwMTkgYXQgMjI6MzY6NTUsIEJy aWFuIENhbXBiZWxsICg8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pDQogd3Jv dGU6PG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpBaCB5ZXMs IHRoYXQgbWFrZXMgc2Vuc2UuIFRoYW5rcyBmb3IgY2xhcmlmeWluZy4gQW5kIGl0IGlzIGluZGVl ZCBhIGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBjaGFuZ2Ug dGhhdCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGJyZWFrIHRoaW5ncyB1bmV4 cGVjdGVkbHkuLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT24g VGh1LCBGZWIgNywgMjAxOSBhdCA4OjU3IEFNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZs dDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0 OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nOiAwaW4gMGlu IDBpbiA2cHQ7IG1hcmdpbi1sZWZ0OiA0LjhwdDsgbWFyZ2luLXJpZ2h0OiAwaW47IiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpUaGUgY2FzZSBJ4oCZbSByZWZlcmVuY2luZyBkaWRu4oCZ dCBzcGVjaWZpY2FsbHkgaW52b2x2ZSBBUyBtZXRhZGF0YS4gV2UgaGFkIGNsaWVudHMgaW4gdGhl IHdpbGQgdGhhdCBhc3N1bWVkIHRoYXQgYWxsIHRoZSBwcm9wZXJ0aWVzIGluIHRoZSBKU09OIG9i amVjdCByZXR1cm5lZCBmcm9tIG91ciB1c2VyaW5mbyBlbmRwb2ludCB3ZXJlIHNjYWxhciBzdHJp bmdzLiBUaGlzIGJyb2tlIHdoZW4gd2UgaW50cm9kdWNlZCBhIG5ldyBwcm9wZXJ0eSB3aG9zZQ0K IHZhbHVlIHdhcyBhIEpTT04gb2JqZWN0LiBJdCB3YXMgYSBnb29kIHJlbWluZGVyIHRoYXQgZXZl biBhIHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIGJhY2t3YXJkcyBj b21wYXRpYmxlIGNhbiBmb3JjZSBtb3JlIHdvcmsgb24gY2xpZW50cyB0aGFuIHdlIGV4cGVjdC48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4tLSZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48 L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj5BV1Mg SWRlbnRpdHk8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0 eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgcGFkZGluZzogM3B0 IDBpbiAwaW47IGJvcmRlci1jb2xvcjogY3VycmVudGNvbG9yOyIgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5CcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyIGNsYXNz PSIiPg0KPGIgY2xhc3M9IiI+RGF0ZTo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxOSBhdCAxMTozMCBB TTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUmcXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4m cXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRy dWUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNs YXNzPSIiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0Oywgb2F1dGgNCiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0 cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IE1UTFMgYW5kIGluLWJy b3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8L3NwYW4+PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkFuZCBJJ20gaG9uZXN0bHkgcmVhbGx5IHN0 cnVnZ2xpbmcgdG8gc2VlIHdoYXQgY291bGQgaGF2ZSBnb25lIHdyb25nIHdpdGggb3IgaG93IHRv a2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBicm9rZSBzb21ldGhpbmcgd2l0aCB0aGUgdXNlciBp bmZvIGVuZHBvaW50LiBJZiB5b3UgaGF2ZSB0aGUgdGltZSBhbmQvb3IgaXQnZCBiZSBpbmZvcm1h dGl2ZSB0byB0aGlzIGhlcmUgbGl0dGxlIGRpc2N1c3Npb24sIHBsZWFzZSBleHBsYWluIHRoYXQg b25lDQogYSBiaXQgbW9yZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT24gV2VkLCBGZWIgNiwgMjAxOSBh dCAxMjoxNSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6IG5v bmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBwYWRkaW5nOiAwaW4g MGluIDBpbiA2cHQ7IG1hcmdpbjogNXB0IDBpbiA1cHQgNC44cHQ7IGJvcmRlci1jb2xvcjogY3Vy cmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwgMjA0LCAyMDQpOyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZxdW90O2ZhciZx dW90OyBzaG91bGQgaGF2ZSBzYWlkICZxdW90O2ZhaXImcXVvdDsgaW4gdGhlIHByZXZpb3VzIG1l c3NhZ2U8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPbiBUdWUsIEZlYiA1LCAy MDE5IGF0IDQ6MzUgUE0gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxl OiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgcGFkZGluZzog MGluIDBpbiAwaW4gNnB0OyBtYXJnaW46IDVwdCAwaW4gNXB0IDQuOHB0OyBib3JkZXItY29sb3I6 IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsIDIwNCwgMjA0 KTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJdCBtYXkg d2VsbCBiZSBkdWUgdG8gbXkgb3duIGludGVsbGVjdHVhbCBzaG9ydGNvbWluZ3MgYnV0IHRoZXNl IGlzc3Vlcy9xdWVzdGlvbnMvY29uZnVzaW9uLXBvaW50cyBhcmUgbm90IHJlc29uYXRpbmcgZm9y IG1lIGFzIGJlaW5nIHByb2JsZW1hdGljLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRoZSBt b3JlIGdlbmVyYWwgc3RhbmNlIG9mICZxdW90O3RoaXMgaXNuJ3QgbmVlZGVkIG9yIHdvcnRoIGl0 IGluIHRoaXMgZG9jdW1lbnQmcXVvdDsgKEkgdGhpbmsgdGhhdCdzIGZhcj8pIGlzIGJlaW5nIGhl YXJkIHRob3VnaC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPbiBUdWUsIEZlYiA1LCAyMDE5 IGF0IDE6NDIgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhy ZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDZwdDsgbWFyZ2luOiA1cHQgMGluIDVw dCA0LjhwdDsgYm9yZGVyLWNvbG9yOiBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciByZ2IoMjA0LCAyMDQsIDIwNCk7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQoo VEw7RFI6IHB1bnQgQVMgbWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCk8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpBUyBwb2ludHMgIzEtMyBhcmUgYWxsIHF1ZXN0aW9ucyBJIHdvdWxk IGhhdmUgYXMgYW4gaW1wbGVtZW50ZXI6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxvbCBz dGFydD0iMSIgdHlwZT0iMSIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDBpbjsiIGNsYXNzPSIiPg0K PGxpIGNsYXNzPSJnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMz MTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5 OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdt YWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1t LTQ5NjU4NjY4Njg4MjkxMDQ1NjRtLTg1NjMzIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDE0 I3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+U2Vj dGlvbiAyIG9mIFJGQzg0MTQ8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPnNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlSRUQgdW5sZXNzDQog b25seSB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBpcyBzdXBwb3J0ZWQu4oCdIFNvIHdoYXQgZG9l cyB0aGUgbVRMUy1vbmx5IEFTIHB1dCBoZXJlPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkg Y2xhc3M9ImdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0 NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNn bWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwt bTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2 NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KVGhlIGNsYWltcyBmb3IgdGhlc2Ugb3RoZXIgZW5kcG9pbnRzIGFyZSBPUFRJT05B TCwgcG90ZW50aWFsbHkgbGVhZGluZyB0byBpbmNvbnNpc3RlbmN5IGRlcGVuZGluZyBvbiBob3cg IzEgZ2V0cyBkZWNpZGVkLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWls LW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIx OTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQy ODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4 ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2Njg2ODgyOTEw NDU2NG0tODU2MzMiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KVGhl IGV4YW1wbGUgdXNhZ2Ugb2YgdGhlIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBwcm9wZXJ0 eSBnaXZlbiBlYXJsaWVyIGlzIGluY29tcGF0aWJsZSB3aXRoIFJGQzg0MTQsIHNpbmNlIHNvbWUg b2YgaXRzIGNvbnRlbnRzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbm9uLW1UTFMgZW5kcG9pbnRz LCBhbmQgb3RoZXJzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbVRMUyBlbmRwb2ludHMuIEhlbmNl IHRoaXMgcXVlc3Rpb24uPG86cCBjbGFzcz0iIj48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwt bTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5 NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4 MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4 NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4ODI5MTA0 NTY0bS04NTYzMyIgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQpUaGlz IGludHJvZHVjZXMgYSBuZXcgbWV0YWRhdGEgcHJvcGVydHkgdGhhdCBjb3VsZCBpbXBhY3QgaG93 IG90aGVyIHNwZWNzIHNob3VsZCBleHRlbmQgQVMgbWV0YWRhdGEuIFRoYXQgbmVlZHMgdG8gYmUg YWRkcmVzc2VkLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48L29sPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJIGNvdWxk IGdvIG9uIGZvciBjbGllbnQgcG9pbnRzIGJ1dCB5b3UgYWxyZWFkeSBnZXQgdGhlIHBvaW50LiBU aG91Z2ggSeKAmWxsIHNoYXJlIHRoYXQgIzMgaXMgcmVhbCBhbmQgb25jZSBmb3JjZWQgbWUgdG8g cm9sbCBiYWNrIGFuIHVwZGF0ZSB0byB0aGUgTG9naW4gd2l0aCBBbWF6b24gdXNlcmluZm8gZW5k cG9pbnTigKZnb29kIHRpbWVzLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0FwcGxlIENvbG9yIEVt b2ppJnF1b3Q7OyIgY2xhc3M9IiI+8J+Ygzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEgcHJv cGVydHkgaXMgd3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJvbHRp bmcgYSBsYXllciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZdCBk ZXNpZ25lZCBmb3IgdGhhdCwgYW5kIEkgZG9u4oCZdCB0aGluayB0aGUgbWV0YWRhdGEgcHJvcG9z YWwgYXMgaXTigJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc3VmZmljaWVudGx5IGRlYWxzDQogd2l0 aCB0aGUgZmFsbG91dCBmcm9tIHRoYXQuIEluIG15IHZpZXcgdGhpcyBpcyBhIGNvbXBsZXggZW5v dWdoIGlzc3VlIGFuZCBpdOKAmXMgZm9yIGEgbnVhbmNlZCBlbm91Z2ggdXNlIGNhc2UgKGFzIGZh ciBhcyBJIGNhbiB0ZWxsIGZyb20gZGlzY3Vzc2lvbj8gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSeKA mW0gd3JvbmcpIHRoYXQgd2Ugc2hvdWxkIHB1bnQgaXQgdG8gYSBzZXBhcmF0ZSBkcmFmdCAoZS5n Liwg4oCcQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGENCiBFeHRlbnNpb25zIGZvciBtVExT IEh5YnJpZHPigJ0pIGFuZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5i c3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEycHQ7IiBjbGFzcz0iIj4tLSZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwv c3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9 IiI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRp bmc6IDNwdCAwaW4gMGluOyBib3JkZXItY29sb3I6IGN1cnJlbnRjb2xvcjsiIGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0 cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgQnJp YW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHku Y29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz cz0iIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPkRhdGU6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkgYXQgNToyOCBBTTxiciBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVv dDsgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vYXV0aCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IE1U TFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8L3NwYW4+ PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRob3NlIHBvaW50cyBvZiBjb25mdXNp b24gc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQg eW91ciBnZW5lcmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFu dGkgYWRkaXRpb25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzIG5vdGVkLjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCkFsbCBvZiB3aGljaCBsZWF2ZXMgbWUgYSBiaXQgdW5jZXJ0YWluIGFi b3V0IGhvdyB0byBwcm9jZWVkLiBUaGVyZSBzZWVtIHRvIGJlIGEgcmFuZ2Ugb2Ygb3BpbmlvbnMg b24gdGhpcyBwb2ludCBhbmQgZ2F1Z2luZyBjb25zZW5zdXMgaXMgcHJvdmluZyBlbHVzaXZlIGZv ciBtZS4gVGhhdCdzIGNvbmZvdW5kZWQgYnkgbXkgb3duIG9waW5pb24gb24gaXQgYmVpbmcgc29t ZXdoYXQgZmx1aWQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7 PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KQW5kIEknZCByZWFsbHkgbGlr ZSB0byBwb3N0IGFuIHVwZGF0ZSB0byB0aGlzIGRyYWZ0IGFib3V0IGEgbW9udGggb3IgdHdvIGFn by48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5i c3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPbiBGcmks IEZlYiAxLCAyMDE5IGF0IDU6MDMgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3Jp Y2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+NDBhbWF6b24uY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDZwdDsgbWFyZ2lu OiA1cHQgMGluIDVwdCA0LjhwdDsgYm9yZGVyLWNvbG9yOiBjdXJyZW50Y29sb3IgY3VycmVudGNv bG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LCAyMDQsIDIwNCk7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpDb25mdXNpb24gZnJvbSB0aGUgQVPigJlzIHBlcnNwZWN0aXZlOjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOiAwaW47IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5 NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEz MWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21h aWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01 MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQpJZiBJIG9ubHkgc3VwcG9ydCBt VExTLCBkbyBJIG5lZWQgdG8gaW5jbHVkZSBib3RoIHRva2VuX2VuZHBvaW50X3VyaSBhbmQgbXRs c19lbmRwb2ludHM/IFNob3VsZCBJIG9taXQgdG9rZW5fZW5kcG9pbnRfdXJpPyBPciBzZXQgaXQg dG8gdGhlIGVtcHR5IHN0cmluZz88bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJn bWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWls LW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3 MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMz ODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4Njg4 MjkxMDQ1NjRtLTg1NjMzIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CldoYXQgaWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQg bm90IHJldm9jYXRpb24gb3IgdXNlciBpbmZvPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkg Y2xhc3M9ImdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0 NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNn bWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwt bTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2 NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KSG93IGRvIEkgc3BlY2lmeSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGZvciB0aGUg bVRMUyB0b2tlbiBlbmRwb2ludD8gRG9lcyB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYXBw bHkgdG8gYm90aCB0aGUgbVRMUyBhbmQgbm9uLW1UTFMgZW5kcG9pbnRzPzxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0y Mzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0 MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3 MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3 ODczMmdtYWlsLW0tNDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMiIHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KSeKAmW0gdXNpbmcgdGhlIE9BdXRoIDIuMCBEZXZpY2Ug Rmxvdy4gRG8gSSBpbmNsdWRlIGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRob3JpemF0aW9uX2Vu ZHBvaW50IHVuZGVyIG10bHNfZW5kcG9pbnRzPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48L29s Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQpDb25mdXNpb24gZnJvbSB0aGUgY2xpZW504oCZcyBwZXJzcGVjdGl2ZTo8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTogMGluOyIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9ImdtYWlsLW02MDg0MzE0ODA1 NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgz NjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3 MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFp bC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMi IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KQXMgZmFyIGFzIEkga25v dywgSeKAmW0gYSBwdWJsaWMgY2xpZW50LCBhbmQgZG9u4oCZdCBrbm93IGFueXRoaW5nIGFib3V0 IG1UTFMsIGJ1dCB0aGUgSVQgYWRtaW5zIGluc3RhbGxlZCBjbGllbnQgY2VydHMgaW4gdGhlaXIg dXNlcnPigJkgYnJvd3NlcnMgYW5kIHRoZSBBUyBleHBlY3RzIHRvIHVzZSB0aGF0IHRvIGF1dGhl bnRpY2F0ZSBtZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tNjA4 NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMy NTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1 MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEy NzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4Njg4MjkxMDQ1NjRt LTg1NjMzIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCk15IEFTIG1l dGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgdGhlIG1UTFMtb25seSBBUyBvbWl0dGVkIHRv a2VuX2VuZHBvaW50X3VyaS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFp bC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0y MTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0 MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4 ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4Njg4Mjkx MDQ1NjRtLTg1NjMzIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCk15 IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRv IGVuY291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwt bS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4 MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgy NDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2 OTk3ODczMmdtYWlsLW0tNDk2NTg2Njg2ODgyOTEwNDU2NG0tODU2MzMiIHN0eWxlPSJtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KVGhlIG1UTFMtb25seSBBUyBkaWRu4oCZdCBwcm92 aWRlIGEgdmFsdWUgZm9yIG10bHNfZW5kcG9pbnRzLCB3aGF0IGRvIEkgZG8/PG86cCBjbGFzcz0i Ij48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1t LTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgw MDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0 MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5 OTc4NzMyZ21haWwtbS00OTY1ODY2ODY4ODI5MTA0NTY0bS04NTYzMyIgc3R5bGU9Im1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQpJIGRvbuKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKA nSBtZWFucywgYnV0IHRoZXkgdG9sZCBtZSB0byB1c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0 aGUgb25lIHdpdGgg4oCcdGxz4oCdIGluIGl0cyBuYW1lLCByaWdodD88bzpwIGNsYXNzPSIiPjwv bzpwPjwvbGk+PC9vbD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KWWVzLCB5b3UgY2FuIHdyaXRlIG5vcm1hdGl2ZSB0ZXh0 IHRoYXQgYW5zd2VycyBtb3N0IG9mIHRoZXNlLiBCdXQgeW914oCZbGwgaGF2ZSB0byBjbGVhcmx5 IGNvdmVyIGEgbG90IG9mIHNpbWlsYXItYnV0LXNsaWdodGx5LWRpZmZlcmVudCBzY2VuYXJpb3Mg YW5kIGJlIHZlcnkgZXhwbGljaXQuIEFuZCBpbXBsZW1lbnRlcnMgd2lsbCBzdGlsbCBnZXQgaXQg d3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9kdWNlcyBvcHBvcnR1bml0aWVzIGZvcg0K IGNvbmZ1c2lvbiBhbmQgZmFpbHVyZSB0aGF0IGRvIG5vdCBleGlzdCBub3csIGFuZCBmb3JjZXMg dGhlbSBvbiBldmVyeW9uZSB3aG8gc3VwcG9ydHMgbVRMUy4gSW4gY29udHJhc3QsIHRoZSAzMDcg cmVkaXJlY3QgaXMgb25seSByZXF1aXJlZCB3aGVuIGFuIEFTIHdhbnRzIHRvIHN1cHBvcnQgYm90 aCwgYW5kIGlzIHVuYW1iaWd1b3VzIGluIGl0cyBiZWhhdmlvciBhbmQgbWVhbmluZy48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMnB0OyIgY2xhc3M9IiI+LS0mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48 L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNz PSIiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRk aW5nOiAzcHQgMGluIDBpbjsgYm9yZGVyLWNvbG9yOiBjdXJyZW50Y29sb3I7IiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJl bGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+NDBwaW5naWRlbnRpdHkuY29t QGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5EYXRlOjwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5 LCBGZWJydWFyeSAxLCAyMDE5IGF0IDM6MTcgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5U bzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZx dW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5HZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIiB0 YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5nZmZsZXRjaEBhb2wuY29t PC9hPiZndDssIG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9hPiZn dDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W1VOVkVSSUZJRUQgU0VOREVSXSBSZTog W09BVVRILVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVu ZHBvaW50PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNw OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KSXQgZG9lc24ndCBzZWVtIGxpa2UgdGhhdCBjb25mdXNpbmcgb3IgbGFy Z2Ugb2YgYSBjaGFuZ2UgdG8gbWUgLSBpZiB0aGUgY2xpZW50IGlzIGRvaW5nIE1UTFMgYW5kIHRo ZSBnaXZlbiBlbmRwb2ludCBpcyBwcmVzZW50IGluIGBtdGxzX2VuZHBvaW50c2AsIHRoZW4gaXQg dXNlcyB0aGF0IG9uZS4mbmJzcDsgT3RoZXJ3aXNlIGl0IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9p bnQuIEl0IGdpdmVzIGFuIEFTIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQNCiBv cHRpb25zLiBJIHBlcnNvbmFsbHkgdGhpbmsgZ2V0dGluZyBhIDMwNyBhcHByb2FjaCBkZXBsb3ll ZCBhbmQgd29ya2luZyB3b3VsZCBiZSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBwcm9uZS4m bmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNl IGF0IHRoZSBtb21lbnQgYnV0IHRoZXJlIGFyZSBmb3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVz aCBmb3IgaW5jcmVhc2VkIHNlY3VyaXR5IGluIGdlbmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlw dCBjbGllbnRzIHVzZSB0aGUgY29kZSBmbG93LCB0aGF0IHN1Z2dlc3QgaXQgd29uJ3QgYmUgdGVy cmlibHkgdW51c3VhbCB0byBzZWUgYW4gQVMgdGhhdCB3YW50cyB0byBzdXBwb3J0IE1UTFMgY2xp ZW50cw0KIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuPG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KSSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQgZm9y dGggaW4gdGhpcyB0aHJlYWQgb24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0YWRh dGEgKG9yIHNvbWV0aGluZyBsaWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkga2lu ZGEgZXhwbGFpbmVkIHNvbWV3aGVyZSBiYWNrIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0 IG1ha2UgdXAgdGhpcyB0aHJlYWQuJm5ic3A7IEJ1dCBpdCBzZWVtcyBsaWtlIHRoZSByb3VnaA0K IGNvbnNlbnN1cyBvZiB0aGUgZ3JvdXAgaGVyZSBpcyBpbiBmYXZvciBvZiBpdC48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgRmVi IDEsIDIwMTkgYXQgMzoxOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFu bmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4ub3JnIiB0YXJnZXQ9 Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9y ZGVyLWxlZnQtd2lkdGg6IDFwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNnB0OyBtYXJnaW46IDVw dCAwaW4gNXB0IDQuOHB0OyBib3JkZXItY29sb3I6IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3Ig Y3VycmVudGNvbG9yIHJnYigyMDQsIDIwNCwgMjA0KTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NClRoaXMgc3RyaWtlcyBtZSBhcyBhIHZlcnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcg Y2hhbmdlIHRvIHN1cHBvcnQgd2hhdCBzZWVtcyB0byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ 4oCZbSBnZXR0aW5nIGEgaGVhZGFjaGUganVzdCB0aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVk ZWQgdG8gY2xhcmlmeSB3aGVuIHRoZSBBUyBzaG91bGQgcHJvdmlkZSBgbXRsc19lbmRwb2ludHNg IGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGF0IHZlcnN1cw0KIHVzaW5nIGB0b2tl bl9lbmRwb2ludC5gIFdoeSBpcyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBj b3ZlciB0aGUgY2FzZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5v bi1tVExTPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+LS0mbmJzcDs8L3NwYW4+ PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9y ZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsgYm9yZGVyLWNvbG9yOiBj dXJyZW50Y29sb3I7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNs YXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPk9B dXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7DQogb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJl Zj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmll dGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5EYXRlOjwvYj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBGZWJydWFy eSAxLCAyMDE5IGF0IDE6MzEgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkdlb3JnZSBGbGV0 Y2hlciAmbHQ7Z2ZmbGV0Y2g9PGEgaHJlZj0ibWFpbHRvOjQwYW9sLmNvbUBkbWFyYy4uLi4uLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj40MGFvbC5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b2F1dGgg Jmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5SZTogW09BVVRILVdHXSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVu dHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NClllcywgdGhhdCB3b3VsZCB3b3JrLiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5i c3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpPbiBGcmks IEZlYiAxLCAyMDE5IGF0IDI6MjggUE0gR2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBo cmVmPSJtYWlsdG86NDBhb2wuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7IiBjbGFzcz0iIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6 IDFwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNnB0OyBtYXJnaW46IDVwdCAwaW4gNXB0IDQuOHB0 OyBib3JkZXItY29sb3I6IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJn YigyMDQsIDIwNCwgMjA0KTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMTJwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IiBjbGFzcz0iIj5XaGF0IGlmIHRoZSBBUyB3YW50cyB0byBPTkxZIHN1 cHBvcnQgTVRMUyBjb25uZWN0aW9ucy4gRG9lcyBpdCBub3Qgc3BlY2lmeSB0aGUgb3B0aW9uYWwg JnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0YWRh dGEgdmFsdWVzPzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9uIDEvMTUvMTkg ODo0OCBBTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRv bTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkl0 IHdvdWxkIGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0IHdhc24ndCBt YWRlIGNsZWFyLiBJdCdkIGJlIHNvbWV0aGluZyB0byB0aGUgZWZmZWN0IG9mIG9wdGlvbmFsIGZv ciB0aGUgQVMgdG8gaW5jbHVkZSBhbmQgY2xpZW50cyBkb2luZyBNVExTIHdvdWxkIHVzZSBpdCB3 aGVuIHByZXNlbnQgaW4gQVMgbWV0YWRhdGEuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCk9uIFR1ZSwgSmFu IDE1LCAyMDE5IGF0IDI6MDQgQU0gRGF2ZSBUb25nZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmUu dG9uZ2VAbW9tZW50dW1mdC5jby51ayIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5JJ20gaW4g ZmF2b3VyIG9mIHRoZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhv dWdoIGl0IHNob3VsZCBiZSBvcHRpb25hbC48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAxMnB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyI+DQo8YnIgY2xhc3M9IiI+DQo8aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyIgY2xhc3M9IiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4m bmJzcDsNCiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9zcGFuPjwvaT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIgY2xhc3M9IiI+T0F1dGggbWFpbGlu ZyBsaXN0PG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9h PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7OyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cCBjbGFz cz0iIj48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj5DT05GSURFTlRJQUxJVFkgTk9U SUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt YXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFu eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0 cmljdGx5DQogcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyIg Y2xhc3M9IiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBv ciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseQ0KIHByb2hpYml0ZWQuLiZuYnNwOyBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuPC9zcGFuPjwvaT48L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiIGNsYXNzPSIiPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3Ry aWN0bHkNCiBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyIgY2xhc3M9IiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseQ0KIHByb2hpYml0 ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0 ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBj bGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyIgY2xhc3M9IiI+Q09ORklERU5U SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseQ0KIHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUg YXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz cz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBwYWRkaW5nOiAwaW47IiBjbGFzcz0iIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzDQogaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj b21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgcGFkZGluZzogMGluOyIgY2xhc3M9IiI+Q09ORklERU5USUFMSVRZIE5PVElDRTog VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJp YWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycw0KIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1l QXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUi IHdyYXA9IiIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8YSBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPk9B dXRoQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9BdXRoDQogbWFpbGluZyBsaXN0 PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_542035A206B843E594FD06FD398E7B60mitedu_-- From nobody Tue Feb 12 13:00:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD1A128B36 for ; Tue, 12 Feb 2019 13:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB6NrV5JOBCZ for ; Tue, 12 Feb 2019 13:00:34 -0800 (PST) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126C2130E98 for ; Tue, 12 Feb 2019 13:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550005232; bh=p5rIR4uXbagLUNWdKqa+l0GRuPXv7melVGwaEa7yrx0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=jT0I2/h2BtTW9qopzEETbh0ZLg+f6/GrPIXhks3Q5ZqBih7ufQbTnLaHXDBl16ZIbHVDutL+dQGkDg+axKpPCg8QjoRr6fqBAG6TbblcQpZt5KZCsXD2k9caazMBNFs/F0pEuOfTvEP3v/+0CjYETOtvPouZ4v2CuMmyh7fhn286VbSkpUAluTd0CS1XePLx8nNWdcdwfWTtJSQmnTnx8vykg30ezJKXFYwIqVr5M/svFLw9Yr5VR4SOD5TFTTklly/YeYMDACEqk0z65c8MlyhaktiGCSoE/die9YenVjmebO1ruFSo1k9S8AHG8W77dSCSllLlYr68BZVwGP43Pw== X-YMail-OSG: Mt6anpkVM1mSiSmENhaFi8KFRq27Gbf6H8bFv7rRNeZmyaOSTMz_VsggwPMgexj aX72.DFtfRayghnW.qsoWP7KLp2Ni2ePNI6OjB3lAKAw6G20bVLdW5HB8KRfQHOsSCgrlZO4_nOu .0YwG0hMzWBNqKAko1Jl0AHseWAOF0WWzyrVScBnX7w9wigXcchOrCO_33X.QF0E89XS4yT56N96 JrDxJOcvQ6bgwzDhcyd6Sw3MHR3UxWueSh.IdGJOaGXK8BMeKctHSCaOKEC94QN7VuE2fumjK9zW furxund4_OQA967A7ysxYr8TLFLCmn0RSnfT9tUNFvkiayJFnTn5UNvei1xNOidtPs4MgET31GBv C1vVSJK3V5vAB2EVQDd1Lh5nYbprAJWXTuTvik_BMAsdPCflKAzNMkQyqGsfZPJJYaXIVWcwNYi9 DgjY0oeKh1Q1Kn0rir9CRdf.h2kliEXi_mbY2QxvNlOh28DYSNTOHBerKj5fiMXj9G9ASDC4Q7R1 yAERVto1oQNP33ZRF.szGvpwa8y3lcpsePLmFVUdEuDz03DrQSVVuJHoz6WbDwOS3YE2tVQT7Atp 6ALyJHOXoo0xulIZeCuyg_Zg98gmPJZat9xB9TM8iitFOZ1ATX_8eU5T44yubxsCdQJsjCD09D.E scikx.dmvm9SoX5XuFcHXMg5IOhpCapfZ_Yp6DM5KVVfKrwpgcMMJt9FFFJdOtRLanBWsjpw18qO N1ZQ7V5THlRy2WEtg8lEN7ljhr67Ruy5qFNqwkLU7n7AflfCxr908K8Bd75ml2IOwmsi0U6xqq9y PluwGIln9GP9mNrz2p1q3hmxMxL9SVhkMPbejLS9kzvbmNqdoGBA8PmtJrE_bGGTv5erQJB4meJ. O4WhGlsdFjpA6t9S8May4SDjbqddIYlh41KQHOb6deS0wvei11ar1e34vbzt1VKdaLJEgm2Ojxza WXllGjlweLh9zu_Yy4LMD9RS6MWLp9Bz_VQAWGv30L8FcjiWpPM5HY29NHAeYBjuAPuKcBDhXqXc fTGha1ZPrG79e3yQOvm1Mx1.BwItZQSmg6Zodm5fMYfsz2mh4kcwEtS0GslEncFlc Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Feb 2019 21:00:32 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 370830ca2d5f2b5d09f90a0a9d7714ed; Tue, 12 Feb 2019 21:00:31 +0000 (UTC) To: Justin Richer Cc: "Richard Backman, Annabelle" , Brian Campbell , Dominick Baier , oauth References: <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <46105936-5ab5-af0f-764e-c9a1a2b6a66f@aol.com> <542035A2-06B8-43E5-94FD-06FD398E7B60@mit.edu> From: George Fletcher Organization: AOL LLC Message-ID: <3b1eaea7-59e8-88f9-dad9-43fac049e9b5@aol.com> Date: Tue, 12 Feb 2019 16:00:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <542035A2-06B8-43E5-94FD-06FD398E7B60@mit.edu> Content-Type: multipart/alternative; boundary="------------50D23FAB62D4DEFAE19F0960" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:00:42 -0000 This is a multi-part message in MIME format. --------------50D23FAB62D4DEFAE19F0960 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Unfortunately, even the concept of "signed_metadata" in RFC 8414 isn't very specific and allows for arbitrary claims to be signed forcing a client to merge values giving the signed claims precedence in the merged output (if the client supports signed_metadata). I agree with your concerns about arbitrarily specifying some endpoints as MTLS only and others as not. It just seems cleaner to say "this is the metadata for the AS with MTLS required" and "this is the metadata for the AS without MTLS required". The mixing seems like its almost assured to be implemented incorrectly. Thanks, George On 2/12/19 3:36 PM, Justin Richer wrote: > The problem with this idea is that there’s not a single canonical > place for OAuth2 stuff under .well-known, according to the discovery > document. OIDC has one, UMA2 has one, and I’m sure there are other > flavors as well. It would not make sense for there to be a new one > just for MTLS-enabling all of these OAuth-powered protocols. > > — Justin > >> On Feb 12, 2019, at 3:27 PM, George Fletcher >> > > wrote: >> >> I prefer this approach to an embedded JSON object. Possibly even just >> making the MTLS version its own directly referencable config under >> .well-known. >> >> Thanks, >> George >> >> On 2/12/19 2:47 PM, Richard Backman, Annabelle wrote: >>> I’m not opposed to introducing a metadata change, if the scenario is >>> relevant and other approaches can’t adequately address it – and I’ll >>> readily grant that we probably don’t want to depend on consistency >>> of browser behavior at the intersection of client certificates and >>> Access-Control-Allow-Credentials. But care needs to be taken in >>> designing that metadata to avoid violating or otherwise negatively >>> impacting usage of RFC8414. >>> Along those lines, instead of adding an “mtls_endpoints” metadata >>> parameter, we could add an “mtls_alternate_metadata” parameter whose >>> value is the URL of an alternate metadata document intended for >>> clients using mTLS. An mTLS-optional AS could have two different >>> metadata documents for mTLS and non-mTLS clients, reducing the >>> mTLS-optional scenario to the mTLS-only scenario. This sidesteps the >>> challenges of aligning the “either/or” semantics of mTLS-optional >>> with some of the rigid parameter definitions in RFC8414 (see: >>> token_endpoint, token_endpoint_auth_methods_supported). >>> -- >>> Annabelle Richard Backman >>> AWS Identity >>> *From:*OAuthon behalf of Brian >>> Campbell >>> *Date:*Tuesday, February 12, 2019 at 10:58 AM >>> *To:*Dominick Baier >>> *Cc:*oauth >>> *Subject:*Re: [OAUTH-WG] MTLS token endoint & discovery >>> Thanks for the input, Dominick. >>> I'd said previously that I was having trouble adequately gauging >>> whether or not there's sufficient consensus to go ahead with the >>> update. I was even thinking of asking the chairs about a consensus >>> call during the office hours meeting yesterday. But it got canceled. >>> And looking again back over the discussion, I don't believe a >>> consensus call is necessary. There's been a lot of general >>> discussion over the last several weeks during which several folks >>> have stated support for the proposal while there's been only one >>> voice of direct dissent. That seems like rough enough consensus and, >>> as such, I plan to make the change in the next revision of the >>> document (which should be done soon). Chairs, please let me know, if >>> you believe the situation warrants a different course of action. >>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier >>> > wrote: >>> >>> IMHO that’s a reasonable and pragmatic option. >>> Thanks >>> ——— >>> Dominick >>> >>> On 11. February 2019 at 13:26:37, Brian Campbell >>> (bcampbell@pingidentity.com ) >>> wrote: >>> >>> It's been pointed out that the potential issue is not >>> isolated to the just token endpoint but that revocation, >>> introspection, etc. could be impacted as well. So,  at this >>> point, the proposal on the table is to add a new optional AS >>> metadata parameter named 'mtls_endpoints' that's value we be >>> a JSON object which itself contains endpoints that, when >>> present, a client doing MTLS would use rather than the >>> regular endpoints.  A straw-man example might look like this >>> >>> { >>>   "issuer":"https://server.example.com >>> ", >>> "authorization_endpoint":"https://server.example.com/authz", >>>   "token_endpoint":"https://server.example.com/token", >>> "token_endpoint_auth_methods_supported":[ >>>  "client_secret_basic","tls_client_auth", "none"], >>>   "userinfo_endpoint":"https://server.example.com/userinfo", >>> "revocation_endpoint":"https://server.example.com/revo", >>>   "jwks_uri":"https://server.example.com/jwks.json", >>> *"mtls_endpoints":{ >>>     "token_endpoint":"https://mtls.example.com/token", >>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>> "revocation_endpoint":"https://mtls.example.com/revo >>> " >>>   }* >>> } >>> >>> A client doing MTLS would look for and give precedence to an >>> endpoint under "mtls_endpoints" while falling back to use >>> the normal endpoint from the top level of metadata when/if >>> its not in "mtls_endpoints". >>> >>> The idea being that "regular" clients (those not doing MTLS) >>> will use the regular endpoints. And only the host/port of >>> the endpoints listed in mtls_endpoints will be set up to >>> request TLS client certificates during handshake. Thus any >>> potential impact of the CertificateRequest message being >>> sent in the TLS handshake can be avoided for all the other >>> regular clients that are not going to do MTLS - including >>> and most importantly in-browser javascript clients where >>> there can be less than desirable UI presented to the end-user. >>> I'm struggling, however, to adequately gauge whether or not >>> there's sufficient consensus to go ahead with the update. >>> There's been some support for it voiced. As well as talk of >>> other approaches that could be alternatives or additional >>> measures. And also some vocal opposition to it. >>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier >>> >> > wrote: >>> >>> We are currently implementing MTLS in IdentityServer. >>> Our approach will be that we’ll offer a separate token >>> endpoint that supports client certs. Are you planning on >>> adding an official endpoint name for discovery? Right >>> now we are using “mtls_token_endpoint”. >>> Thanks >>> ——— >>> Dominick >>> >>> On 7. February 2019 at 22:36:55, Brian Campbell >>> (bcampbell=40pingidentity.com@dmarc.ietf.org >>> ) wrote: >>> >>> Ah yes, that makes sense. Thanks for clarifying. And >>> it is indeed a good reminder that even a seemingly >>> innocuous change that should be backwards compatible >>> can break things unexpectedly.. >>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, >>> Annabelle >> > wrote: >>> >>> The case I’m referencing didn’t specifically >>> involve AS metadata. We had clients in the wild >>> that assumed that all the properties in the JSON >>> object returned from our userinfo endpoint were >>> scalar strings. This broke when we introduced a >>> new property whose value was a JSON object. It >>> was a good reminder that even a seemingly >>> innocuous change that should be backwards >>> compatible can force more work on clients than >>> we expect. >>> -- >>> Annabelle Richard Backman >>> AWS Identity >>> *From:*Brian Campbell >>> >> > >>> *Date:*Wednesday, February 6, 2019 at 11:30 AM >>> *To:*"Richard Backman, Annabelle" >>> >> > >>> *Cc:*"Richard Backman, Annabelle" >>> >> >, oauth >>> > >>> *Subject:*Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: >>> MTLS and in-browser clients using the token endpoint >>> And I'm honestly really struggling to see what >>> could have gone wrong with or how >>> token_endpoint_auth_methods broke something with >>> the user info endpoint. If you have the time >>> and/or it'd be informative to this here little >>> discussion, please explain that one a bit more. >>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell >>> >> > wrote: >>> >>> "far" should have said "fair" in the >>> previous message >>> On Tue, Feb 5, 2019 at 4:35 PM Brian >>> Campbell >> > wrote: >>> >>> It may well be due to my own >>> intellectual shortcomings but these >>> issues/questions/confusion-points are >>> not resonating for me as being problematic. >>> The more general stance of "this isn't >>> needed or worth it in this document" (I >>> think that's far?) is being heard though. >>> On Tue, Feb 5, 2019 at 1:42 PM Richard >>> Backman, Annabelle >>> >> > >>> wrote: >>> >>> (TL;DR: punt AS metadata to a >>> separate draft) >>> >>> AS points #1-3 are all questions I >>> would have as an implementer: >>> >>> 1. Section 2 of RFC8414 >>> says >>> token_endpoint “is REQUIRED >>> unless only the implicit grant >>> type is supported.” So what does >>> the mTLS-only AS put here? >>> 2. The claims for these other >>> endpoints are OPTIONAL, >>> potentially leading to >>> inconsistency depending on how >>> #1 gets decided. >>> 3. The example usage of the >>> token_endpoint_auth_methods >>> property given earlier is >>> incompatible with RFC8414, since >>> some of its contents are only >>> valid for the non-mTLS >>> endpoints, and others are only >>> valid for the mTLS endpoints. >>> Hence this question. >>> 4. This introduces a new metadata >>> property that could impact how >>> other specs should extend AS >>> metadata. That needs to be >>> addressed. >>> >>> I could go on for client points but >>> you already get the point. Though >>> I’ll share that #3 is real and once >>> forced me to roll back an update to >>> the Login with Amazon userinfo >>> endpoint…good times.😃 >>> I don’t necessarily think an AS >>> metadata property is wrong per se, >>> but understand that you’re bolting a >>> layer of flexibility onto a standard >>> that wasn’t designed for that, and I >>> don’t think the metadata proposal as >>> it’s been discussed here >>> sufficiently deals with the fallout >>> from that. In my view this is a >>> complex enough issue and it’s for a >>> nuanced enough use case (as far as I >>> can tell from discussion? Please >>> correct me if I’m wrong) that we >>> should punt it to a separate draft >>> (e.g., “Authorization Server >>> Metadata Extensions for mTLS >>> Hybrids”) and get mTLS out the door. >>> -- >>> Annabelle Richard Backman >>> AWS Identity >>> *From:*OAuth >> > on >>> behalf of Brian Campbell >>> >> > >>> *Date:*Monday, February 4, 2019 at >>> 5:28 AM >>> *To:*"Richard Backman, Annabelle" >>> >> > >>> *Cc:*oauth >> > >>> *Subject:*Re: [OAUTH-WG] [UNVERIFIED >>> SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> Those points of confusion strike me >>> as somewhat hypothetical or >>> hyperbolic. But your general point >>> is taken and your position of being >>> anti additional metadata on this >>> issue is noted. >>> All of which leaves me a bit >>> uncertain about how to proceed. >>> There seem to be a range of opinions >>> on this point and gauging consensus >>> is proving elusive for me. That's >>> confounded by my own opinion on it >>> being somewhat fluid. >>> And I'd really like to post an >>> update to this draft about a month >>> or two ago. >>> On Fri, Feb 1, 2019 at 5:03 PM >>> Richard Backman, Annabelle >>> >> > >>> wrote: >>> >>> Confusion from the AS’s perspective: >>> >>> 1. If I only support mTLS, do I >>> need to include both >>> token_endpoint_uri and >>> mtls_endpoints? Should I >>> omit token_endpoint_uri? Or >>> set it to the empty string? >>> 2. What if I only support mTLS >>> for the token endpoint, but >>> not revocation or user info? >>> 3. How do I specify >>> authentication methods for >>> the mTLS token endpoint? >>> Does >>> token_endpoint_auth_methods >>> apply to both the mTLS and >>> non-mTLS endpoints? >>> 4. I’m using the OAuth 2.0 >>> Device Flow. Do I include a >>> mTLS-enabled >>> device_authorization_endpoint >>> under mtls_endpoints? >>> >>> Confusion from the client’s >>> perspective: >>> >>> 1. As far as I know, I’m a >>> public client, and don’t >>> know anything about mTLS, >>> but the IT admins installed >>> client certs in their users’ >>> browsers and the AS expects >>> to use that to authenticate me. >>> 2. My AS metadata parser >>> crashed because the >>> mTLS-only AS omitted >>> token_endpoint_uri. >>> 3. My AS metadata parser >>> crashed because it didn’t >>> expect to encounter a JSON >>> object as a parameter value. >>> 4. The mTLS-only AS didn’t >>> provide a value for >>> mtls_endpoints, what do I do? >>> 5. I don’t know what that “m” >>> means, but they told me to >>> use HTTPS, so I should use >>> the one with “tls” in its >>> name, right? >>> >>> Yes, you can write normative >>> text that answers most of these. >>> But you’ll have to clearly cover >>> a lot of >>> similar-but-slightly-different >>> scenarios and be very explicit. >>> And implementers will still get >>> it wrong. The metadata change >>> introduces opportunities for >>> confusion and failure that do >>> not exist now, and forces them >>> on everyone who supports mTLS. >>> In contrast, the 307 redirect is >>> only required when an AS wants >>> to support both, and is >>> unambiguous in its behavior and >>> meaning. >>> -- >>> Annabelle Richard Backman >>> AWS Identity >>> *From:*Brian Campbell >>> >> > >>> *Date:*Friday, February 1, 2019 >>> at 3:17 PM >>> *To:*"Richard Backman, >>> Annabelle" >> > >>> *Cc:*George Fletcher >>> >> >, >>> oauth >> > >>> *Subject:*[UNVERIFIED SENDER] >>> Re: [OAUTH-WG] MTLS and >>> in-browser clients using the >>> token endpoint >>> It doesn't seem like that >>> confusing or large of a change >>> to me - if the client is doing >>> MTLS and the given endpoint is >>> present in `mtls_endpoints`, >>> then it uses that one. Otherwise >>> it uses the regular endpoint. It >>> gives an AS a lot of flexibility >>> in deployment options. I >>> personally think getting a 307 >>> approach deployed and working >>> would be more complicated and >>> error prone. >>> It is a minority use case at the >>> moment but there are forces in >>> play, like the push for >>> increased security in general >>> and to have javascript clients >>> use the code flow, that suggest >>> it won't be terribly unusual to >>> see an AS that wants to support >>> MTLS clients and javascript/spa >>> clients at the same time. >>> I've personally wavered back and >>> forth in this thread on whether >>> or not to add the new metadata >>> (or something like it). With my >>> reasoning each way kinda >>> explained somewhere back in the >>> 40 or so messages that make up >>> this thread. But it seems like >>> the rough consensus of the group >>> here is in favor of it. >>> On Fri, Feb 1, 2019 at 3:18 PM >>> Richard Backman, Annabelle >>> >> > >>> wrote: >>> >>> This strikes me as a very >>> prominent and confusing >>> change to support what seems >>> to be a minority use case. >>> I’m getting a headache just >>> thinking about the text >>> needed to clarify when the >>> AS should provide >>> `mtls_endpoints` and when >>> the client should use that >>> versus using >>> `token_endpoint.` Why is the >>> 307 status code insufficient >>> to cover the case where a >>> single AS supports both mTLS >>> and non-mTLS? >>> -- >>> Annabelle Richard Backman >>> AWS Identity >>> *From:*OAuth >>> >> > >>> on behalf of Brian Campbell >>> >> > >>> *Date:*Friday, February 1, >>> 2019 at 1:31 PM >>> *To:*George Fletcher >>> >> > >>> *Cc:*oauth >> > >>> *Subject:*Re: [OAUTH-WG] >>> MTLS and in-browser clients >>> using the token endpoint >>> Yes, that would work. >>> On Fri, Feb 1, 2019 at 2:28 >>> PM George Fletcher >>> >> > >>> wrote: >>> >>> What if the AS wants to >>> ONLY support MTLS >>> connections. Does it not >>> specify the optional >>> "mtls_endpoints" and >>> just use the normal >>> metadata values? >>> >>> On 1/15/19 8:48 AM, >>> Brian Campbell wrote: >>> >>> It would definitely >>> be optional, >>> apologies if that >>> wasn't made clear. >>> It'd be something to >>> the effect of >>> optional for the AS >>> to include and >>> clients doing MTLS >>> would use it when >>> present in AS metadata. >>> On Tue, Jan 15, 2019 >>> at 2:04 AM Dave >>> Tonge >>> >> > >>> wrote: >>> >>> I'm in favour of >>> the >>> `mtls_endpoints` >>> metadata >>> parameter - >>> although it >>> should be optional. >>> >>> >>> /CONFIDENTIALITY >>> NOTICE: This email >>> may contain >>> confidential and >>> privileged material >>> for the sole use of >>> the intended >>> recipient(s). Any >>> review, use, >>> distribution or >>> disclosure by others >>> is strictly >>> prohibited.. If you >>> have received this >>> communication in >>> error, please notify >>> the sender >>> immediately by >>> e-mail and delete >>> the message and any >>> file attachments >>> from your computer. >>> Thank you./ >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> >>> */CONFIDENTIALITY NOTICE: >>> This email may contain >>> confidential and privileged >>> material for the sole use of >>> the intended recipient(s). >>> Any review, use, >>> distribution or disclosure >>> by others is strictly >>> prohibited.. If you have >>> received this communication >>> in error, please notify the >>> sender immediately by e-mail >>> and delete the message and >>> any file attachments from >>> your computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This >>> email may contain confidential >>> and privileged material for the >>> sole use of the intended >>> recipient(s). Any review, use, >>> distribution or disclosure by >>> others is strictly prohibited.. >>> If you have received this >>> communication in error, please >>> notify the sender immediately by >>> e-mail and delete the message >>> and any file attachments from >>> your computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email >>> may contain confidential and >>> privileged material for the sole use >>> of the intended recipient(s). Any >>> review, use, distribution or >>> disclosure by others is strictly >>> prohibited.. If you have received >>> this communication in error, please >>> notify the sender immediately by >>> e-mail and delete the message and >>> any file attachments from your >>> computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email may contain >>> confidential and privileged material for the >>> sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by >>> others is strictly prohibited. If you have >>> received this communication in error, please >>> notify the sender immediately by e-mail and >>> delete the message and any file attachments from >>> your computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email may contain >>> confidential and privileged material for the sole >>> use of the intended recipient(s). Any review, use, >>> distribution or disclosure by others is strictly >>> prohibited.. If you have received this communication >>> in error, please notify the sender immediately by >>> e-mail and delete the message and any file >>> attachments from your computer. Thank >>> you./*_______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> */CONFIDENTIALITY NOTICE: This email may contain >>> confidential and privileged material for the sole use of the >>> intended recipient(s). Any review, use, distribution or >>> disclosure by others is strictly prohibited.  If you have >>> received this communication in error, please notify the >>> sender immediately by e-mail and delete the message and any >>> file attachments from your computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). >>> Any review, use, distribution or disclosure by others is strictly >>> prohibited..  If you have received this communication in error, >>> please notify the sender immediately by e-mail and delete the >>> message and any file attachments from your computer. Thank you./* >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------50D23FAB62D4DEFAE19F0960 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Unfortunately, even the concept of "signed_metadata" in RFC 8414 isn't very specific and allows for arbitrary claims to be signed forcing a client to merge values giving the signed claims precedence in the merged output (if the client supports signed_metadata).

I agree with your concerns about arbitrarily specifying some endpoints as MTLS only and others as not.

It just seems cleaner to say "this is the metadata for the AS with MTLS required" and "this is the metadata for the AS without MTLS required". The mixing seems like its almost assured to be implemented incorrectly.

Thanks,
George

On 2/12/19 3:36 PM, Justin Richer wrote:
The problem with this idea is that there’s not a single canonical place for OAuth2 stuff under .well-known, according to the discovery document. OIDC has one, UMA2 has one, and I’m sure there are other flavors as well. It would not make sense for there to be a new one just for MTLS-enabling all of these OAuth-powered protocols. 

— Justin

On Feb 12, 2019, at 3:27 PM, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

I prefer this approach to an embedded JSON object. Possibly even just making the MTLS version its own directly referencable config under .well-known.

Thanks,
George

On 2/12/19 2:47 PM, Richard Backman, Annabelle wrote:
I’m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can’t adequately address it – and I’ll readily grant that we probably don’t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.
 
Along those lines, instead of adding an “mtls_endpoints” metadata parameter, we could add an “mtls_alternate_metadata” parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the “either/or” semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).
 
-- 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
 
Thanks for the input, Dominick. 
 
I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.
 
 
 
On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
IMHO that’s a reasonable and pragmatic option.
 
Thanks
——— 
Dominick
 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A straw-man example might look like this

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}
 
A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".

The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.
 
I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 
 
 
On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:
We are currently implementing MTLS in IdentityServer.
 
Our approach will be that we’ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using “mtls_token_endpoint”.
 
Thanks
——— 
Dominick
 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..
 
 
 
 
 
On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:
The case I’m referencing didn’t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.
 
-- 
Annabelle Richard Backman
AWS Identity
 
 
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint
 
And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.
 
On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
"far" should have said "fair" in the previous message
 
 
 
 
 
On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.
 
The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.
 
 
 
On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:
(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:
  1. Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.
 
I could go on for client points but you already get the point. Though I’ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint…good times. 😃
 
I don’t necessarily think an AS metadata property is wrong per se, but understand that you’re bolting a layer of flexibility onto a standard that wasn’t designed for that, and I don’t think the metadata proposal as it’s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it’s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I’m wrong) that we should punt it to a separate draft (e.g., “Authorization Server Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.
 
-- 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint
 
Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.
 
All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.
 
And I'd really like to post an update to this draft about a month or two ago.
 
 
 
 
 
 
On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:
Confusion from the AS’s perspective:
  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?
 
Confusion from the client’s perspective:
  1. As far as I know, I’m a public client, and don’t know anything about mTLS, but the IT admins installed client certs in their users’ browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
  5. I don’t know what that “m” means, but they told me to use HTTPS, so I should use the one with “tls” in its name, right?
 
Yes, you can write normative text that answers most of these. But you’ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.
 
-- 
Annabelle Richard Backman
AWS Identity
 
 
From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
 
It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 
 
It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.
 
I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like the rough consensus of the group here is in favor of it.
 
 
 
 
On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:
This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I’m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?
 
-- 
Annabelle Richard Backman
AWS Identity
 
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
 
Yes, that would work. 
 
On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:
It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.
 
On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

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


--------------50D23FAB62D4DEFAE19F0960-- From nobody Tue Feb 12 13:12:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39377130DD3 for ; Tue, 12 Feb 2019 13:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIWWIhuCuTzj for ; Tue, 12 Feb 2019 13:12:05 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FA2130E71 for ; Tue, 12 Feb 2019 13:12:04 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id g1so180916otj.11 for ; Tue, 12 Feb 2019 13:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2S21aIZCtqzN0hduZQuQtOA6P95K69B5BG7tUDWg0/0=; b=XvmdqUx1E6/QQApb19TIN9Nk1B9oEv2uTOSoxRLgIhlVeL50brthiUYTjbn1q7WVGN nnvg9VSKU79xPnAB3hpt/Gw7ItVstds6k0tTcBFTY5kweSHvHid6m/VIRLt3axU6AhWp HexLYHApjjK45HTtGKu90QuBja3UtJ2ZqQ0nuAG0W+i8tr1446S3vsB7J6/1vHFfYzxs LV9Bef0yICmK46g/bR7YOIUwzbgjmZDxAP7c7gq47hQe6x2Gzw/DD8sAtJ6H38IkD74D QqfjV9j3nKvwGxPY9kqPvaHFfTkaOhkBy8lPrDTSjo6bdnL1VYtUAPo8ePhNsjm3WZke opGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2S21aIZCtqzN0hduZQuQtOA6P95K69B5BG7tUDWg0/0=; b=k5vQ63Jc6m9sGoPMJDDE6ra6r4wUw3vKtCjWLxzsNwa45AyN191JjgrH+TdF5x7qvC n8jHdqebzjWVfTjINDQOmcOk2BOA56tWXBOmU3h8oBGp2/KSPQO2ldcDAhHU2N8bgPY6 LnszIRkrCvhimIkJ+Y7qJYY2KOS4d91//mG/ey8E1DnMg2rMSbnBuJW0BO/Z1mf/kUUO AIPj1zUT3COSqQj3iK//VnTG9CLsSeRYlPsC/lxky85exH354qma//xeVt1ACOSrsgYj ULAfaXO4QQEzh8aYxbhUlDpXa0egzhD1hYZ8pdSXFvd7zclUseNzJZF6p8xCCrYrHeer Ieyg== X-Gm-Message-State: AHQUAuZ5Ulk52nuWDpDbWd0CUfEQoRcokzM7ko4e+aWEZ5JtoxOYHREG s/rj1+y0iFD0oH1D4t9QjBRp11JWhUQp+M8rJWJ/KPY= X-Google-Smtp-Source: AHgI3IbY3esLd4ptK1C4ljycKAqHuuaKzB9OLHirSaIXUZ7752Kp+71ux5rvQ71Nsugm3z08ZKQLy1XXn8SILS1FBKo= X-Received: by 2002:a9d:2067:: with SMTP id n94mr6072112ota.53.1550005923314; Tue, 12 Feb 2019 13:12:03 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: From: Filip Skokan Date: Tue, 12 Feb 2019 22:11:52 +0100 Message-ID: To: "Richard Backman, Annabelle" Cc: Brian Campbell , Dominick Baier , oauth Content-Type: multipart/alternative; boundary="0000000000007583700581b8e0ed" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 21:12:12 -0000 --0000000000007583700581b8e0ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Annabelle, can you elaborate what would be the violation / negative impact of usage of RFC8414? As it already makes use of `signed_metadata` and this language is present ... > Consumers of the metadata MAY ignore the signed metadata if they do not support this feature. If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements= . ... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process. Best, *Filip* On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle wrote: > I=E2=80=99m not opposed to introducing a metadata change, if the scenario= is > relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll > readily grant that we probably don=E2=80=99t want to depend on consistenc= y of > browser behavior at the intersection of client certificates and > Access-Control-Allow-Credentials. But care needs to be taken in designing > that metadata to avoid violating or otherwise negatively impacting usage = of > RFC8414. > > > > Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D = metadata > parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D para= meter whose value > is the URL of an alternate metadata document intended for clients using > mTLS. An mTLS-optional AS could have two different metadata documents for > mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the > mTLS-only scenario. This sidesteps the challenges of aligning the > =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the r= igid parameter > definitions in RFC8414 (see: token_endpoint, > token_endpoint_auth_methods_supported). > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Tuesday, February 12, 2019 at 10:58 AM > *To: *Dominick Baier > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Thanks for the input, Dominick. > > > > I'd said previously that I was having trouble adequately gauging whether > or not there's sufficient consensus to go ahead with the update. I was ev= en > thinking of asking the chairs about a consensus call during the office > hours meeting yesterday. But it got canceled. And looking again back over > the discussion, I don't believe a consensus call is necessary. There's be= en > a lot of general discussion over the last several weeks during which > several folks have stated support for the proposal while there's been onl= y > one voice of direct dissent. That seems like rough enough consensus and, = as > such, I plan to make the change in the next revision of the document (whi= ch > should be done soon). Chairs, please let me know, if you believe the > situation warrants a different course of action. > > > > > > > > On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier > wrote: > > IMHO that=E2=80=99s a reasonable and pragmatic option. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 11. February 2019 at 13:26:37, Brian Campbell ( > bcampbell@pingidentity.com) wrote: > > It's been pointed out that the potential issue is not isolated to the jus= t > token endpoint but that revocation, introspection, etc. could be impacted > as well. So, at this point, the proposal on the table is to add a new > optional AS metadata parameter named 'mtls_endpoints' that's value we be = a > JSON object which itself contains endpoints that, when present, a client > doing MTLS would use rather than the regular endpoints. A straw-man > example might look like this > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token > ", > "userinfo_endpoint":"https://mtls.example.com/userinfo > ", > "revocation_endpoint":"https://mtls.example.com/revo > " }* > } > > > > A client doing MTLS would look for and give precedence to an endpoint > under "mtls_endpoints" while falling back to use the normal endpoint from > the top level of metadata when/if its not in "mtls_endpoints". > > > The idea being that "regular" clients (those not doing MTLS) will use the > regular endpoints. And only the host/port of the endpoints listed in > mtls_endpoints will be set up to request TLS client certificates during > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > > > I'm struggling, however, to adequately gauge whether or not there's > sufficient consensus to go ahead with the update. There's been some suppo= rt > for it voiced. As well as talk of other approaches that could be > alternatives or additional measures. And also some vocal opposition to it= . > > > > > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > wrote: > > We are currently implementing MTLS in IdentityServer. > > > > Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had > clients in the wild that assumed that all the properties in the JSON obje= ct > returned from our userinfo endpoint were scalar strings. This broke when = we > introduced a new property whose value was a JSON object. It was a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Wednesday, February 6, 2019 at 11:30 AM > *To:* "Richard Backman, Annabelle" > *Cc:* "Richard Backman, Annabelle" , oauth < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > And I'm honestly really struggling to see what could have gone wrong with > or how token_endpoint_auth_methods broke something with the user info > endpoint. If you have the time and/or it'd be informative to this here > little discussion, please explain that one a bit more. > > > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > wrote: > > "far" should have said "fair" in the previous message > > > > > > > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Monday, February 4, 2019 at 5:28 AM > *To:* "Richard Backman, Annabelle" > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Friday, February 1, 2019 at 3:17 PM > *To:* "Richard Backman, Annabelle" > *Cc:* George Fletcher , oauth > *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Friday, February 1, 2019 at 1:31 PM > *To:* George Fletcher <40aol.com@dmarc......ietf.org>> > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* ______________________________________________= _ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000007583700581b8e0ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Annabelle,

can you elaborate what would be the violation / negative impact of usage= of RFC8414?

As it already makes use of `signed_me= tadata` and this language is present ...

>=C2= =A0Consumers of the metadata MAY ignore the signed metadata if they do not = support this feature.=C2=A0 If the consumer of the metadata supports signed= metadata, metadata values conveyed in the signed metadata MUST take preced= ence over the corresponding values conveyed using plain JSON elements.

... would mtls_endpoints be any different? Clients are= free to ignore this if they don't support/use mtls, and if they do tho= se values must take precedence over the root ones. the use of mtls_endpoint= s would not be recommended for mtls-only AS but recommended for one with bo= th mtls/regular authentication methods. token_endpoint remains required for= all intents and purposes. And as for the usable client authentication meth= ods - they should all be listed, or do you think we should separate the one= s for each hostname/port location? To what end? Is there a risk having the = mtls hostname/port accepting regular requests? Other then secret/key _jwt a= uth methods assertion aud claim the endpoint location doesn't play a ro= le in the authentication process.

Best,
Filip


On= Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org&g= t; wrote:

I=E2=80=99m not opposed to introducing a metadata ch= ange, if the scenario is relevant and other approaches can=E2=80=99t adequa= tely address it =E2=80=93 and I=E2=80=99ll readily grant that we probably d= on=E2=80=99t want to depend on consistency of browser behavior at the inter= section of client certificates and Access-Control-Allow-Credentials. But care need= s to be taken in designing that metadata to avoid violating or otherwise ne= gatively impacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtl= s_endpoints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alte= rnate_metadata=E2=80=9D parameter whose value is the URL of an alternate me= tadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clien= ts, reducing the mTLS-optional scenario to the mTLS-only scenario. This sid= esteps the challenges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics= of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_s= upported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery=

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble ad= equately gauging whether or not there's sufficient consensus to go ahea= d with the update. I was even thinking of asking the chairs about a consens= us call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don'= ;t believe a consensus call is necessary. There's been a lot of general= discussion over the last several weeks during which several folks have sta= ted support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consen= sus and, as such, I plan to make the change in the next revision of the doc= ument (which should be done soon). Chairs, please let me know, if you belie= ve the situation warrants a different course of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <= dbaier@least= privilege.com> wrote:

IMHO that=E2=80=99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrot= e:

It's been pointed o= ut that the potential issue is not isolated to the just token endpoint but = that revocation, introspection, etc. could be impacted as well. So,=C2=A0 a= t this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints'= that's value we be a JSON object which itself contains endpoints that,= when present, a client doing MTLS would use rather than the regular endpoi= nts.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"clie= nt_secret_basic","tls_client_auth", "none"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo&quo= t;
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give preceden= ce to an endpoint under "mtls_endpoints" while falling back to us= e the normal endpoint from the top level of metadata when/if its not in &qu= ot;mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will= use the regular endpoints. And only the host/port of the endpoints listed = in mtls_endpoints will be set up to request TLS client certificates during = handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided = for all the other regular clients that are not going to do MTLS - including= and most importantly in-browser javascript clients where there can be less= than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whe= ther or not there's sufficient consensus to go ahead with the update. T= here's been some support for it voiced. As well as talk of other approa= ches that could be alternatives or additional measures. And also some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastpr= ivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.=

=C2=A0

Our approach will be that we=E2=80=99ll offer a separate token endpoint th= at supports client certs. Are you planning on adding an official endpoint n= ame for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And= it is indeed a good reminder that even a seemingly innocuous change that s= hould be backwards compatible can break things unexpectedly..=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Anna= belle <richanna= @amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that = all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose va= lue was a JSON object. It was a good reminder that even a seemingly innocuo= us change that should be backwards compatible can force more work on client= s than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pingidentity.c= om>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what c= ould have gone wrong with or how token_endpoint_auth_methods broke somethin= g with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain tha= t one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pin= gidentity.com> wrote:

It may well be due to my own intellectual shortcomin= gs but these issues/questions/confusion-points are not resonating for me as= being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being he= ard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /u>

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless o= nly the implicit grant type is supported.=E2=80=9D So what does the mTLS-on= ly AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier= is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question.
  4. This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98= =83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed h= ere sufficiently deals with the fallout from that. In my view this is a com= plex enough issue and it=E2=80=99s for a nuanced enough use case (as far as= I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization S= erver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the d= oor.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000007583700581b8e0ed-- From nobody Tue Feb 12 15:00:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB1A130E0A for ; Tue, 12 Feb 2019 15:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.801 X-Spam-Level: X-Spam-Status: No, score=-11.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUM0E0OasmpV for ; Tue, 12 Feb 2019 15:00:17 -0800 (PST) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DD3126C01 for ; Tue, 12 Feb 2019 15:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1550012417; x=1581548417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RQ0bAhQw6KN3BvsQDEHg/VdHbVaXQUg/xRuQLT7Wdjo=; b=W1YBLxewgV25kZWsZmCRy9QYWAyVqfdrlWbH9uARwvQHMEs/4+XH+yhH VkYYSSLmIzdVzS8xXmcuq+iLs92acmDqu/1nit26AkSyr1CCS/GurvR6C 9rFQ8QyiX7zki0jXtGzY9Xkoxwo44IiWo7fySaNCXUoH/s1lSOo/7+4WW 8=; X-IronPort-AV: E=Sophos;i="5.58,362,1544486400"; d="scan'208,217";a="380904690" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-81e76b79.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2019 23:00:14 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2b-81e76b79.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id x1CN0D6Y042178 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Feb 2019 23:00:14 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Feb 2019 23:00:13 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Feb 2019 23:00:13 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Tue, 12 Feb 2019 23:00:13 +0000 From: "Richard Backman, Annabelle" To: Filip Skokan , "Richard Backman, Annabelle" CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] MTLS token endoint & discovery Thread-Index: AQHUwF+tRWyMOv1EVkK3Bn3jwrq7jqXaiS+AgAEmvgCAANjXAP//h9UAgACdzQD//5gngA== Date: Tue, 12 Feb 2019 23:00:12 +0000 Message-ID: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.187] Content-Type: multipart/alternative; boundary="_000_4390FC233FC04F4EB3088E266391E1DDamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 23:00:23 -0000 --_000_4390FC233FC04F4EB3088E266391E1DDamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBpcyBvbmUgZXhhbXBsZSwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg4oCc c3RyYXcgbWFu4oCdIGZvcm1hdCBwcmVzZW50ZWQgaW4gdGhpcyB0aHJlYWQ6IFJGQzg0MTQgZGVm aW5lcyB0aGUgdmFsdWUgb2YgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBh cyBhIOKAnEpTT04gYXJyYXkgY29udGFpbmluZyBhIGxpc3Qgb2YgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIG1ldGhvZHMgc3VwcG9ydGVkIGJ5IHRoaXMgdG9rZW4gZW5kcG9pbnQu4oCdIElmIHRoYXQg YXJyYXkgY29udGFpbnMg4oCcdGxzX2NsaWVudF9hdXRo4oCdIGFuZCB0aGUgZW5kcG9pbnQgc3Bl Y2lmaWVkIGluIHRva2VuX2VuZHBvaW50IGRvZXMgbm90IHN1cHBvcnQgbVRMUywgdGhlbiB0aGF0 IG1ldGFkYXRhIHZpb2xhdGVzIDg0MTQuIFlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgYnkgYWRkaW5n IGEgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhl IG10bHNfZW5kcG9pbnRzIG9iamVjdCwgYW5kIGxpa2V3aXNlIGZvciB0aGUgb3RoZXIgZW5kcG9p bnRzIGFuZCBhdXRoIG1ldGhvZHMuIElmIHlvdSB0YWtlIHRoYXQgdG8gaXRzIGxvZ2ljYWwgY29u Y2x1c2lvbiwgeW91IGVuZCB1cCB3aXRoIGEgY29tcGxldGUgbWV0YWRhdGEgZG9jdW1lbnQgaGFu Z2luZyBvZmYgb2YgbXRsc19lbmRwb2ludHMuIEl04oCZcyB0aGF0IGxpbmUgb2YgdGhvdWdodCB0 aGF0IGxlZCBtZSB0byBzdWdnZXN0IGp1c3QgcG9pbnRpbmcgdG8gYW4gYWx0ZXJuYXRlIGRvY3Vt ZW50Lg0KDQpBZGRpdGlvbmFsbHksIGEgbWV0YWRhdGEgZG9jdW1lbnQgdGhhdCBvbWl0cyB0b2tl bl9lbmRwb2ludCBpbiBmYXZvciBvZiBtdGxzX2VuZHBvaW50cyBzaW5jZSBvbmx5IG1UTFMgaXMg c3VwcG9ydGVkIHdvdWxkIHZpb2xhdGUgODQxNCwgYXMgODQxNCBzYXlzIHRva2VuX2VuZHBvaW50 IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1 cHBvcnRlZC7igJ0NCg0KSXQgaXMgcG9zc2libGUgdG8gZGVmaW5lIHRoZSBtdGxzX2VuZHBvaW50 cyBwYXJhbWV0ZXIgc3VjaCB0aGF0IHRoZSBhYm92ZSB1c2UgY2FzZXMgYXJlIGludmFsaWQsIGJ1 dCB0aGF0IGRvZXMgbWFrZSB0aGUgZG9jdW1lbnQgbW9yZSBjb21wbGljYXRlZC4gSWYgd2UgZ28g dGhlIOKAnG10bHNfYWx0ZXJuYXRlX21ldGFkYXRh4oCdIHJvdXRlLCB3ZSBjYW4gc2tpcCBwYXN0 IGFsbCBvZiB0aGVzZSBpc3N1ZXMsIGJlY2F1c2UgaXQgYnJpbmdzIHVzIGJhY2sgdG8ganVzdCBw YXJzaW5nIHRoZSBzYW1lIG1ldGFkYXRhIHRoYXQgd2UgZG8gdG9kYXkuDQoNCi0tDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21h aWwuY29tPg0KRGF0ZTogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQgMToxMyBQTQ0KVG86 ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZz4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5 LmNvbUBkbWFyYy5pZXRmLm9yZz4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2NvdmVyeQ0KDQpIaSBBbm5hYmVs bGUsDQoNCmNhbiB5b3UgZWxhYm9yYXRlIHdoYXQgd291bGQgYmUgdGhlIHZpb2xhdGlvbiAvIG5l Z2F0aXZlIGltcGFjdCBvZiB1c2FnZSBvZiBSRkM4NDE0Pw0KDQpBcyBpdCBhbHJlYWR5IG1ha2Vz IHVzZSBvZiBgc2lnbmVkX21ldGFkYXRhYCBhbmQgdGhpcyBsYW5ndWFnZSBpcyBwcmVzZW50IC4u Lg0KDQo+IENvbnN1bWVycyBvZiB0aGUgbWV0YWRhdGEgTUFZIGlnbm9yZSB0aGUgc2lnbmVkIG1l dGFkYXRhIGlmIHRoZXkgZG8gbm90IHN1cHBvcnQgdGhpcyBmZWF0dXJlLiAgSWYgdGhlIGNvbnN1 bWVyIG9mIHRoZSBtZXRhZGF0YSBzdXBwb3J0cyBzaWduZWQgbWV0YWRhdGEsIG1ldGFkYXRhIHZh bHVlcyBjb252ZXllZCBpbiB0aGUgc2lnbmVkIG1ldGFkYXRhIE1VU1QgdGFrZSBwcmVjZWRlbmNl IG92ZXIgdGhlIGNvcnJlc3BvbmRpbmcgdmFsdWVzIGNvbnZleWVkIHVzaW5nIHBsYWluIEpTT04g ZWxlbWVudHMuDQoNCi4uLiB3b3VsZCBtdGxzX2VuZHBvaW50cyBiZSBhbnkgZGlmZmVyZW50PyBD bGllbnRzIGFyZSBmcmVlIHRvIGlnbm9yZSB0aGlzIGlmIHRoZXkgZG9uJ3Qgc3VwcG9ydC91c2Ug bXRscywgYW5kIGlmIHRoZXkgZG8gdGhvc2UgdmFsdWVzIG11c3QgdGFrZSBwcmVjZWRlbmNlIG92 ZXIgdGhlIHJvb3Qgb25lcy4gdGhlIHVzZSBvZiBtdGxzX2VuZHBvaW50cyB3b3VsZCBub3QgYmUg cmVjb21tZW5kZWQgZm9yIG10bHMtb25seSBBUyBidXQgcmVjb21tZW5kZWQgZm9yIG9uZSB3aXRo IGJvdGggbXRscy9yZWd1bGFyIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuIHRva2VuX2VuZHBvaW50 IHJlbWFpbnMgcmVxdWlyZWQgZm9yIGFsbCBpbnRlbnRzIGFuZCBwdXJwb3Nlcy4gQW5kIGFzIGZv ciB0aGUgdXNhYmxlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIC0gdGhleSBzaG91bGQg YWxsIGJlIGxpc3RlZCwgb3IgZG8geW91IHRoaW5rIHdlIHNob3VsZCBzZXBhcmF0ZSB0aGUgb25l cyBmb3IgZWFjaCBob3N0bmFtZS9wb3J0IGxvY2F0aW9uPyBUbyB3aGF0IGVuZD8gSXMgdGhlcmUg YSByaXNrIGhhdmluZyB0aGUgbXRscyBob3N0bmFtZS9wb3J0IGFjY2VwdGluZyByZWd1bGFyIHJl cXVlc3RzPyBPdGhlciB0aGVuIHNlY3JldC9rZXkgX2p3dCBhdXRoIG1ldGhvZHMgYXNzZXJ0aW9u IGF1ZCBjbGFpbSB0aGUgZW5kcG9pbnQgbG9jYXRpb24gZG9lc24ndCBwbGF5IGEgcm9sZSBpbiB0 aGUgYXV0aGVudGljYXRpb24gcHJvY2Vzcy4NCg0KQmVzdCwNCkZpbGlwDQoNCg0KT24gVHVlLCAx MiBGZWIgMjAxOSBhdCAyMDo0NywgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5h PTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmll dGYub3JnPj4gd3JvdGU6DQpJ4oCZbSBub3Qgb3Bwb3NlZCB0byBpbnRyb2R1Y2luZyBhIG1ldGFk YXRhIGNoYW5nZSwgaWYgdGhlIHNjZW5hcmlvIGlzIHJlbGV2YW50IGFuZCBvdGhlciBhcHByb2Fj aGVzIGNhbuKAmXQgYWRlcXVhdGVseSBhZGRyZXNzIGl0IOKAkyBhbmQgSeKAmWxsIHJlYWRpbHkg Z3JhbnQgdGhhdCB3ZSBwcm9iYWJseSBkb27igJl0IHdhbnQgdG8gZGVwZW5kIG9uIGNvbnNpc3Rl bmN5IG9mIGJyb3dzZXIgYmVoYXZpb3IgYXQgdGhlIGludGVyc2VjdGlvbiBvZiBjbGllbnQgY2Vy dGlmaWNhdGVzIGFuZCBBY2Nlc3MtQ29udHJvbC1BbGxvdy1DcmVkZW50aWFscy4gQnV0IGNhcmUg bmVlZHMgdG8gYmUgdGFrZW4gaW4gZGVzaWduaW5nIHRoYXQgbWV0YWRhdGEgdG8gYXZvaWQgdmlv bGF0aW5nIG9yIG90aGVyd2lzZSBuZWdhdGl2ZWx5IGltcGFjdGluZyB1c2FnZSBvZiBSRkM4NDE0 Lg0KDQpBbG9uZyB0aG9zZSBsaW5lcywgaW5zdGVhZCBvZiBhZGRpbmcgYW4g4oCcbXRsc19lbmRw b2ludHPigJ0gbWV0YWRhdGEgcGFyYW1ldGVyLCB3ZSBjb3VsZCBhZGQgYW4g4oCcbXRsc19hbHRl cm5hdGVfbWV0YWRhdGHigJ0gcGFyYW1ldGVyIHdob3NlIHZhbHVlIGlzIHRoZSBVUkwgb2YgYW4g YWx0ZXJuYXRlIG1ldGFkYXRhIGRvY3VtZW50IGludGVuZGVkIGZvciBjbGllbnRzIHVzaW5nIG1U TFMuIEFuIG1UTFMtb3B0aW9uYWwgQVMgY291bGQgaGF2ZSB0d28gZGlmZmVyZW50IG1ldGFkYXRh IGRvY3VtZW50cyBmb3IgbVRMUyBhbmQgbm9uLW1UTFMgY2xpZW50cywgcmVkdWNpbmcgdGhlIG1U TFMtb3B0aW9uYWwgc2NlbmFyaW8gdG8gdGhlIG1UTFMtb25seSBzY2VuYXJpby4gVGhpcyBzaWRl c3RlcHMgdGhlIGNoYWxsZW5nZXMgb2YgYWxpZ25pbmcgdGhlIOKAnGVpdGhlci9vcuKAnSBzZW1h bnRpY3Mgb2YgbVRMUy1vcHRpb25hbCB3aXRoIHNvbWUgb2YgdGhlIHJpZ2lkIHBhcmFtZXRlciBk ZWZpbml0aW9ucyBpbiBSRkM4NDE0IChzZWU6IHRva2VuX2VuZHBvaW50LCB0b2tlbl9lbmRwb2lu dF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkKS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlc2RheSwgRmVicnVh cnkgMTIsIDIwMTkgYXQgMTA6NTggQU0NClRvOiBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0 cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+DQpDYzogb2F1 dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBNVExTIHRva2VuIGVuZG9pbnQgJiBkaXNjb3ZlcnkNCg0KVGhhbmtzIGZvciB0 aGUgaW5wdXQsIERvbWluaWNrLg0KDQpJJ2Qgc2FpZCBwcmV2aW91c2x5IHRoYXQgSSB3YXMgaGF2 aW5nIHRyb3VibGUgYWRlcXVhdGVseSBnYXVnaW5nIHdoZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3Vm ZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBJIHdhcyBldmVu IHRoaW5raW5nIG9mIGFza2luZyB0aGUgY2hhaXJzIGFib3V0IGEgY29uc2Vuc3VzIGNhbGwgZHVy aW5nIHRoZSBvZmZpY2UgaG91cnMgbWVldGluZyB5ZXN0ZXJkYXkuIEJ1dCBpdCBnb3QgY2FuY2Vs ZWQuIEFuZCBsb29raW5nIGFnYWluIGJhY2sgb3ZlciB0aGUgZGlzY3Vzc2lvbiwgSSBkb24ndCBi ZWxpZXZlIGEgY29uc2Vuc3VzIGNhbGwgaXMgbmVjZXNzYXJ5LiBUaGVyZSdzIGJlZW4gYSBsb3Qg b2YgZ2VuZXJhbCBkaXNjdXNzaW9uIG92ZXIgdGhlIGxhc3Qgc2V2ZXJhbCB3ZWVrcyBkdXJpbmcg d2hpY2ggc2V2ZXJhbCBmb2xrcyBoYXZlIHN0YXRlZCBzdXBwb3J0IGZvciB0aGUgcHJvcG9zYWwg d2hpbGUgdGhlcmUncyBiZWVuIG9ubHkgb25lIHZvaWNlIG9mIGRpcmVjdCBkaXNzZW50LiBUaGF0 IHNlZW1zIGxpa2Ugcm91Z2ggZW5vdWdoIGNvbnNlbnN1cyBhbmQsIGFzIHN1Y2gsIEkgcGxhbiB0 byBtYWtlIHRoZSBjaGFuZ2UgaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIGRvY3VtZW50ICh3 aGljaCBzaG91bGQgYmUgZG9uZSBzb29uKS4gQ2hhaXJzLCBwbGVhc2UgbGV0IG1lIGtub3csIGlm IHlvdSBiZWxpZXZlIHRoZSBzaXR1YXRpb24gd2FycmFudHMgYSBkaWZmZXJlbnQgY291cnNlIG9m IGFjdGlvbi4NCg0KDQoNCk9uIE1vbiwgRmViIDExLCAyMDE5IGF0IDExOjAxIFBNIERvbWluaWNr IEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2 aWxlZ2UuY29tPj4gd3JvdGU6DQpJTUhPIHRoYXTigJlzIGEgcmVhc29uYWJsZSBhbmQgcHJhZ21h dGljIG9wdGlvbi4NCg0KVGhhbmtzDQrigJTigJTigJQNCkRvbWluaWNrDQoNCg0KT24gMTEuIEZl YnJ1YXJ5IDIwMTkgYXQgMTM6MjY6MzcsIEJyaWFuIENhbXBiZWxsIChiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+KSB3cm90ZToNCkl0 J3MgYmVlbiBwb2ludGVkIG91dCB0aGF0IHRoZSBwb3RlbnRpYWwgaXNzdWUgaXMgbm90IGlzb2xh dGVkIHRvIHRoZSBqdXN0IHRva2VuIGVuZHBvaW50IGJ1dCB0aGF0IHJldm9jYXRpb24sIGludHJv c3BlY3Rpb24sIGV0Yy4gY291bGQgYmUgaW1wYWN0ZWQgYXMgd2VsbC4gU28sICBhdCB0aGlzIHBv aW50LCB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlIGlzIHRvIGFkZCBhIG5ldyBvcHRpb25hbCBB UyBtZXRhZGF0YSBwYXJhbWV0ZXIgbmFtZWQgJ210bHNfZW5kcG9pbnRzJyB0aGF0J3MgdmFsdWUg d2UgYmUgYSBKU09OIG9iamVjdCB3aGljaCBpdHNlbGYgY29udGFpbnMgZW5kcG9pbnRzIHRoYXQs IHdoZW4gcHJlc2VudCwgYSBjbGllbnQgZG9pbmcgTVRMUyB3b3VsZCB1c2UgcmF0aGVyIHRoYW4g dGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiAgQSBzdHJhdy1tYW4gZXhhbXBsZSBtaWdodCBsb29rIGxp a2UgdGhpcw0Kew0KICAiaXNzdWVyIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLA0KICAi YXV0aG9yaXphdGlvbl9lbmRwb2ludCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGh6 IiwNCiAgInRva2VuX2VuZHBvaW50IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4i LA0KICAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCI6WyAgImNsaWVudF9z ZWNyZXRfYmFzaWMiLCJ0bHNfY2xpZW50X2F1dGgiLCAibm9uZSJdLA0KICAidXNlcmluZm9fZW5k cG9pbnQiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS91c2VyaW5mbyIsDQogICJyZXZvY2F0 aW9uX2VuZHBvaW50IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2byIsDQogICJqd2tz X3VyaSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3a3MuanNvbiIsDQogICJtdGxzX2Vu ZHBvaW50cyI6ew0KICAgICJ0b2tlbl9lbmRwb2ludCI6Imh0dHBzOi8vbXRscy5leGFtcGxlLmNv bS90b2tlbiIsDQogICAgInVzZXJpbmZvX2VuZHBvaW50IjoiaHR0cHM6Ly9tdGxzLmV4YW1wbGUu Y29tL3VzZXJpbmZvIiwNCiAgICAicmV2b2NhdGlvbl9lbmRwb2ludCI6Imh0dHBzOi8vbXRscy5l eGFtcGxlLmNvbS9yZXZvPGh0dHBzOi8vbXRscy4uLmV4YW1wbGUuY29tL3Jldm8+Ig0KICB9DQp9 DQoNCkEgY2xpZW50IGRvaW5nIE1UTFMgd291bGQgbG9vayBmb3IgYW5kIGdpdmUgcHJlY2VkZW5j ZSB0byBhbiBlbmRwb2ludCB1bmRlciAibXRsc19lbmRwb2ludHMiIHdoaWxlIGZhbGxpbmcgYmFj ayB0byB1c2UgdGhlIG5vcm1hbCBlbmRwb2ludCBmcm9tIHRoZSB0b3AgbGV2ZWwgb2YgbWV0YWRh dGEgd2hlbi9pZiBpdHMgbm90IGluICJtdGxzX2VuZHBvaW50cyIuDQoNClRoZSBpZGVhIGJlaW5n IHRoYXQgInJlZ3VsYXIiIGNsaWVudHMgKHRob3NlIG5vdCBkb2luZyBNVExTKSB3aWxsIHVzZSB0 aGUgcmVndWxhciBlbmRwb2ludHMuIEFuZCBvbmx5IHRoZSBob3N0L3BvcnQgb2YgdGhlIGVuZHBv aW50cyBsaXN0ZWQgaW4gbXRsc19lbmRwb2ludHMgd2lsbCBiZSBzZXQgdXAgdG8gcmVxdWVzdCBU TFMgY2xpZW50IGNlcnRpZmljYXRlcyBkdXJpbmcgaGFuZHNoYWtlLiBUaHVzIGFueSBwb3RlbnRp YWwgaW1wYWN0IG9mIHRoZSBDZXJ0aWZpY2F0ZVJlcXVlc3QgbWVzc2FnZSBiZWluZyBzZW50IGlu IHRoZSBUTFMgaGFuZHNoYWtlIGNhbiBiZSBhdm9pZGVkIGZvciBhbGwgdGhlIG90aGVyIHJlZ3Vs YXIgY2xpZW50cyB0aGF0IGFyZSBub3QgZ29pbmcgdG8gZG8gTVRMUyAtIGluY2x1ZGluZyBhbmQg bW9zdCBpbXBvcnRhbnRseSBpbi1icm93c2VyIGphdmFzY3JpcHQgY2xpZW50cyB3aGVyZSB0aGVy ZSBjYW4gYmUgbGVzcyB0aGFuIGRlc2lyYWJsZSBVSSBwcmVzZW50ZWQgdG8gdGhlIGVuZC11c2Vy Lg0KDQpJJ20gc3RydWdnbGluZywgaG93ZXZlciwgdG8gYWRlcXVhdGVseSBnYXVnZSB3aGV0aGVy IG9yIG5vdCB0aGVyZSdzIHN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvIGdvIGFoZWFkIHdpdGggdGhl IHVwZGF0ZS4gVGhlcmUncyBiZWVuIHNvbWUgc3VwcG9ydCBmb3IgaXQgdm9pY2VkLiBBcyB3ZWxs IGFzIHRhbGsgb2Ygb3RoZXIgYXBwcm9hY2hlcyB0aGF0IGNvdWxkIGJlIGFsdGVybmF0aXZlcyBv ciBhZGRpdGlvbmFsIG1lYXN1cmVzLiBBbmQgYWxzbyBzb21lIHZvY2FsIG9wcG9zaXRpb24gdG8g aXQuDQoNCg0KT24gU2F0LCBGZWIgOSwgMjAxOSBhdCAzOjA5IEFNIERvbWluaWNrIEJhaWVyIDxk YmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t Pj4gd3JvdGU6DQpXZSBhcmUgY3VycmVudGx5IGltcGxlbWVudGluZyBNVExTIGluIElkZW50aXR5 U2VydmVyLg0KDQpPdXIgYXBwcm9hY2ggd2lsbCBiZSB0aGF0IHdl4oCZbGwgb2ZmZXIgYSBzZXBh cmF0ZSB0b2tlbiBlbmRwb2ludCB0aGF0IHN1cHBvcnRzIGNsaWVudCBjZXJ0cy4gQXJlIHlvdSBw bGFubmluZyBvbiBhZGRpbmcgYW4gb2ZmaWNpYWwgZW5kcG9pbnQgbmFtZSBmb3IgZGlzY292ZXJ5 PyBSaWdodCBub3cgd2UgYXJlIHVzaW5nIOKAnG10bHNfdG9rZW5fZW5kcG9pbnTigJ0uDQoNClRo YW5rcw0K4oCU4oCU4oCUDQpEb21pbmljaw0KDQoNCk9uIDcuIEZlYnJ1YXJ5IDIwMTkgYXQgMjI6 MzY6NTUsIEJyaWFuIENhbXBiZWxsIChiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzpiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPikgd3JvdGU6DQpBaCB5ZXMsIHRoYXQgbWFrZXMgc2Vuc2UuIFRoYW5rcyBmb3IgY2xhcmlm eWluZy4gQW5kIGl0IGlzIGluZGVlZCBhIGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWlu Z2x5IGlubm9jdW91cyBjaGFuZ2UgdGhhdCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUg Y2FuIGJyZWFrIHRoaW5ncyB1bmV4cGVjdGVkbHkuLg0KDQoNCg0KDQoNCk9uIFRodSwgRmViIDcs IDIwMTkgYXQgODo1NyBBTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1h em9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KVGhlIGNhc2UgSeKA mW0gcmVmZXJlbmNpbmcgZGlkbuKAmXQgc3BlY2lmaWNhbGx5IGludm9sdmUgQVMgbWV0YWRhdGEu IFdlIGhhZCBjbGllbnRzIGluIHRoZSB3aWxkIHRoYXQgYXNzdW1lZCB0aGF0IGFsbCB0aGUgcHJv cGVydGllcyBpbiB0aGUgSlNPTiBvYmplY3QgcmV0dXJuZWQgZnJvbSBvdXIgdXNlcmluZm8gZW5k cG9pbnQgd2VyZSBzY2FsYXIgc3RyaW5ncy4gVGhpcyBicm9rZSB3aGVuIHdlIGludHJvZHVjZWQg YSBuZXcgcHJvcGVydHkgd2hvc2UgdmFsdWUgd2FzIGEgSlNPTiBvYmplY3QuIEl0IHdhcyBhIGdv b2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBjaGFuZ2UgdGhhdCBz aG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGZvcmNlIG1vcmUgd29yayBvbiBjbGll bnRzIHRoYW4gd2UgZXhwZWN0Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdT IElkZW50aXR5DQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+DQpEYXRlOiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDYsIDIwMTkgYXQgMTE6MzAgQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUiIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBv YXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IE1UTFMgYW5kIGluLWJyb3dzZXIg Y2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQNCg0KQW5kIEknbSBob25lc3RseSByZWFs bHkgc3RydWdnbGluZyB0byBzZWUgd2hhdCBjb3VsZCBoYXZlIGdvbmUgd3Jvbmcgd2l0aCBvciBo b3cgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGJyb2tlIHNvbWV0aGluZyB3aXRoIHRoZSB1 c2VyIGluZm8gZW5kcG9pbnQuIElmIHlvdSBoYXZlIHRoZSB0aW1lIGFuZC9vciBpdCdkIGJlIGlu Zm9ybWF0aXZlIHRvIHRoaXMgaGVyZSBsaXR0bGUgZGlzY3Vzc2lvbiwgcGxlYXNlIGV4cGxhaW4g dGhhdCBvbmUgYSBiaXQgbW9yZS4NCg0KT24gV2VkLCBGZWIgNiwgMjAxOSBhdCAxMjoxNSBQTSBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQoiZmFyIiBzaG91bGQgaGF2ZSBzYWlkICJmYWly IiBpbiB0aGUgcHJldmlvdXMgbWVzc2FnZQ0KDQoNCg0KDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkg YXQgNDozNSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpJdCBtYXkgd2VsbCBiZSBk dWUgdG8gbXkgb3duIGludGVsbGVjdHVhbCBzaG9ydGNvbWluZ3MgYnV0IHRoZXNlIGlzc3Vlcy9x dWVzdGlvbnMvY29uZnVzaW9uLXBvaW50cyBhcmUgbm90IHJlc29uYXRpbmcgZm9yIG1lIGFzIGJl aW5nIHByb2JsZW1hdGljLg0KDQpUaGUgbW9yZSBnZW5lcmFsIHN0YW5jZSBvZiAidGhpcyBpc24n dCBuZWVkZWQgb3Igd29ydGggaXQgaW4gdGhpcyBkb2N1bWVudCIgKEkgdGhpbmsgdGhhdCdzIGZh cj8pIGlzIGJlaW5nIGhlYXJkIHRob3VnaC4NCg0KDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQg MTo0MiBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29t QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLm9yZz4+IHdy b3RlOg0KKFRMO0RSOiBwdW50IEFTIG1ldGFkYXRhIHRvIGEgc2VwYXJhdGUgZHJhZnQpDQoNCkFT IHBvaW50cyAjMS0zIGFyZSBhbGwgcXVlc3Rpb25zIEkgd291bGQgaGF2ZSBhcyBhbiBpbXBsZW1l bnRlcjoNCg0KICAxLiAgU2VjdGlvbiAyIG9mIFJGQzg0MTQ8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzg0MTQjc2VjdGlvbi0yPiBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJ UkVEIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0g U28gd2hhdCBkb2VzIHRoZSBtVExTLW9ubHkgQVMgcHV0IGhlcmU/DQogIDIuICBUaGUgY2xhaW1z IGZvciB0aGVzZSBvdGhlciBlbmRwb2ludHMgYXJlIE9QVElPTkFMLCBwb3RlbnRpYWxseSBsZWFk aW5nIHRvIGluY29uc2lzdGVuY3kgZGVwZW5kaW5nIG9uIGhvdyAjMSBnZXRzIGRlY2lkZWQuDQog IDMuICBUaGUgZXhhbXBsZSB1c2FnZSBvZiB0aGUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2Rz IHByb3BlcnR5IGdpdmVuIGVhcmxpZXIgaXMgaW5jb21wYXRpYmxlIHdpdGggUkZDODQxNCwgc2lu Y2Ugc29tZSBvZiBpdHMgY29udGVudHMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBub24tbVRMUyBl bmRwb2ludHMsIGFuZCBvdGhlcnMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBtVExTIGVuZHBvaW50 cy4gSGVuY2UgdGhpcyBxdWVzdGlvbi4NCiAgNC4gIFRoaXMgaW50cm9kdWNlcyBhIG5ldyBtZXRh ZGF0YSBwcm9wZXJ0eSB0aGF0IGNvdWxkIGltcGFjdCBob3cgb3RoZXIgc3BlY3Mgc2hvdWxkIGV4 dGVuZCBBUyBtZXRhZGF0YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQuDQoNCkkgY291bGQg Z28gb24gZm9yIGNsaWVudCBwb2ludHMgYnV0IHlvdSBhbHJlYWR5IGdldCB0aGUgcG9pbnQuIFRo b3VnaCBJ4oCZbGwgc2hhcmUgdGhhdCAjMyBpcyByZWFsIGFuZCBvbmNlIGZvcmNlZCBtZSB0byBy b2xsIGJhY2sgYW4gdXBkYXRlIHRvIHRoZSBMb2dpbiB3aXRoIEFtYXpvbiB1c2VyaW5mbyBlbmRw b2ludOKApmdvb2QgdGltZXMuIPCfmIMNCg0KSSBkb27igJl0IG5lY2Vzc2FyaWx5IHRoaW5rIGFu IEFTIG1ldGFkYXRhIHByb3BlcnR5IGlzIHdyb25nIHBlciBzZSwgYnV0IHVuZGVyc3RhbmQgdGhh dCB5b3XigJlyZSBib2x0aW5nIGEgbGF5ZXIgb2YgZmxleGliaWxpdHkgb250byBhIHN0YW5kYXJk IHRoYXQgd2FzbuKAmXQgZGVzaWduZWQgZm9yIHRoYXQsIGFuZCBJIGRvbuKAmXQgdGhpbmsgdGhl IG1ldGFkYXRhIHByb3Bvc2FsIGFzIGl04oCZcyBiZWVuIGRpc2N1c3NlZCBoZXJlIHN1ZmZpY2ll bnRseSBkZWFscyB3aXRoIHRoZSBmYWxsb3V0IGZyb20gdGhhdC4gSW4gbXkgdmlldyB0aGlzIGlz IGEgY29tcGxleCBlbm91Z2ggaXNzdWUgYW5kIGl04oCZcyBmb3IgYSBudWFuY2VkIGVub3VnaCB1 c2UgY2FzZSAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgZnJvbSBkaXNjdXNzaW9uPyBQbGVhc2UgY29y cmVjdCBtZSBpZiBJ4oCZbSB3cm9uZykgdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFy YXRlIGRyYWZ0IChlLmcuLCDigJxBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSBFeHRlbnNp b25zIGZvciBtVExTIEh5YnJpZHPigJ0pIGFuZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuDQoNCi0t DQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0 aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn Pj4NCkRhdGU6IE1vbmRheSwgRmVicnVhcnkgNCwgMjAxOSBhdCA1OjI4IEFNDQpUbzogIlJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IG9hdXRoIDxvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVz aW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpUaG9zZSBwb2ludHMgb2YgY29uZnVzaW9uIHN0cmlr ZSBtZSBhcyBzb21ld2hhdCBoeXBvdGhldGljYWwgb3IgaHlwZXJib2xpYy4gQnV0IHlvdXIgZ2Vu ZXJhbCBwb2ludCBpcyB0YWtlbiBhbmQgeW91ciBwb3NpdGlvbiBvZiBiZWluZyBhbnRpIGFkZGl0 aW9uYWwgbWV0YWRhdGEgb24gdGhpcyBpc3N1ZSBpcyBub3RlZC4NCg0KQWxsIG9mIHdoaWNoIGxl YXZlcyBtZSBhIGJpdCB1bmNlcnRhaW4gYWJvdXQgaG93IHRvIHByb2NlZWQuIFRoZXJlIHNlZW0g dG8gYmUgYSByYW5nZSBvZiBvcGluaW9ucyBvbiB0aGlzIHBvaW50IGFuZCBnYXVnaW5nIGNvbnNl bnN1cyBpcyBwcm92aW5nIGVsdXNpdmUgZm9yIG1lLiBUaGF0J3MgY29uZm91bmRlZCBieSBteSBv d24gb3BpbmlvbiBvbiBpdCBiZWluZyBzb21ld2hhdCBmbHVpZC4NCg0KQW5kIEknZCByZWFsbHkg bGlrZSB0byBwb3N0IGFuIHVwZGF0ZSB0byB0aGlzIGRyYWZ0IGFib3V0IGEgbW9udGggb3IgdHdv IGFnby4NCg0KDQoNCg0KDQoNCk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgNTowMyBQTSBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLm9yZz4+IHdyb3RlOg0KQ29uZnVzaW9u IGZyb20gdGhlIEFT4oCZcyBwZXJzcGVjdGl2ZToNCg0KICAxLiAgSWYgSSBvbmx5IHN1cHBvcnQg bVRMUywgZG8gSSBuZWVkIHRvIGluY2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91cmkgYW5kIG10 bHNfZW5kcG9pbnRzPyBTaG91bGQgSSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8gT3Igc2V0IGl0 IHRvIHRoZSBlbXB0eSBzdHJpbmc/DQogIDIuICBXaGF0IGlmIEkgb25seSBzdXBwb3J0IG1UTFMg Zm9yIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IG5vdCByZXZvY2F0aW9uIG9yIHVzZXIgaW5mbz8N CiAgMy4gIEhvdyBkbyBJIHNwZWNpZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1U TFMgdG9rZW4gZW5kcG9pbnQ/IERvZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5 IHRvIGJvdGggdGhlIG1UTFMgYW5kIG5vbi1tVExTIGVuZHBvaW50cz8NCiAgNC4gIEnigJltIHVz aW5nIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cuIERvIEkgaW5jbHVkZSBhIG1UTFMtZW5hYmxl ZCBkZXZpY2VfYXV0aG9yaXphdGlvbl9lbmRwb2ludCB1bmRlciBtdGxzX2VuZHBvaW50cz8NCg0K Q29uZnVzaW9uIGZyb20gdGhlIGNsaWVudOKAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIEFzIGZh ciBhcyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0 aGluZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRz IGluIHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhh dCB0byBhdXRoZW50aWNhdGUgbWUuDQogIDIuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hl ZCBiZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuDQog IDMuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIGl0IGRpZG7igJl0IGV4 cGVjdCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBhcyBhIHBhcmFtZXRlciB2YWx1ZS4NCiAg NC4gIFRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZvciBtdGxzX2Vu ZHBvaW50cywgd2hhdCBkbyBJIGRvPw0KICA1LiAgSSBkb27igJl0IGtub3cgd2hhdCB0aGF0IOKA nG3igJ0gbWVhbnMsIGJ1dCB0aGV5IHRvbGQgbWUgdG8gdXNlIEhUVFBTLCBzbyBJIHNob3VsZCB1 c2UgdGhlIG9uZSB3aXRoIOKAnHRsc+KAnSBpbiBpdHMgbmFtZSwgcmlnaHQ/DQoNClllcywgeW91 IGNhbiB3cml0ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4gQnV0 IHlvdeKAmWxsIGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1zbGln aHRseS1kaWZmZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1wbGVt ZW50ZXJzIHdpbGwgc3RpbGwgZ2V0IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hhbmdlIGludHJv ZHVjZXMgb3Bwb3J0dW5pdGllcyBmb3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRoYXQgZG8gbm90 IGV4aXN0IG5vdywgYW5kIGZvcmNlcyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBwb3J0cyBtVExT LiBJbiBjb250cmFzdCwgdGhlIDMwNyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYW4g QVMgd2FudHMgdG8gc3VwcG9ydCBib3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMgaW4gaXRzIGJlaGF2 aW9yIGFuZCBtZWFuaW5nLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElk ZW50aXR5DQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0 eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRm Lm9yZz4+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQTQ0KVG86ICJS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+Pg0KQ2M6IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNv bTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVU SC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2lu dA0KDQpJdCBkb2Vzbid0IHNlZW0gbGlrZSB0aGF0IGNvbmZ1c2luZyBvciBsYXJnZSBvZiBhIGNo YW5nZSB0byBtZSAtIGlmIHRoZSBjbGllbnQgaXMgZG9pbmcgTVRMUyBhbmQgdGhlIGdpdmVuIGVu ZHBvaW50IGlzIHByZXNlbnQgaW4gYG10bHNfZW5kcG9pbnRzYCwgdGhlbiBpdCB1c2VzIHRoYXQg b25lLiAgT3RoZXJ3aXNlIGl0IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9pbnQuIEl0IGdpdmVzIGFu IEFTIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQgb3B0aW9ucy4gSSBwZXJzb25h bGx5IHRoaW5rIGdldHRpbmcgYSAzMDcgYXBwcm9hY2ggZGVwbG95ZWQgYW5kIHdvcmtpbmcgd291 bGQgYmUgbW9yZSBjb21wbGljYXRlZCBhbmQgZXJyb3IgcHJvbmUuDQoNCkl0IGlzIGEgbWlub3Jp dHkgdXNlIGNhc2UgYXQgdGhlIG1vbWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBs aWtlIHRoZSBwdXNoIGZvciBpbmNyZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2 ZSBqYXZhc2NyaXB0IGNsaWVudHMgdXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdCBpdCB3 b24ndCBiZSB0ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBv cnQgTVRMUyBjbGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRp bWUuDQoNCkkndmUgcGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhy ZWFkIG9uIHdoZXRoZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhp bmcgbGlrZSBpdCkuIFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBz b21ld2hlcmUgYmFjayBpbiB0aGUgNDAgb3Igc28gbWVzc2FnZXMgdGhhdCBtYWtlIHVwIHRoaXMg dGhyZWFkLiAgQnV0IGl0IHNlZW1zIGxpa2UgdGhlIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgZ3Jv dXAgaGVyZSBpcyBpbiBmYXZvciBvZiBpdC4NCg0KDQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBh dCAzOjE4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4ub3JnPj4g d3JvdGU6DQpUaGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVzaW5n IGNoYW5nZSB0byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2FzZS4g SeKAmW0gZ2V0dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQgbmVl ZGVkIHRvIGNsYXJpZnkgd2hlbiB0aGUgQVMgc2hvdWxkIHByb3ZpZGUgYG10bHNfZW5kcG9pbnRz YCBhbmQgd2hlbiB0aGUgY2xpZW50IHNob3VsZCB1c2UgdGhhdCB2ZXJzdXMgdXNpbmcgYHRva2Vu X2VuZHBvaW50LmAgV2h5IGlzIHRoZSAzMDcgc3RhdHVzIGNvZGUgaW5zdWZmaWNpZW50IHRvIGNv dmVyIHRoZSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIGJvdGggbVRMUyBhbmQgbm9u LW1UTFM/DQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0K DQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRt YXJjLmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBN DQpUbzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy4uLi4uLi5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoN ClllcywgdGhhdCB3b3VsZCB3b3JrLg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDI6MjggUE0g R2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv OjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2hhdCBpZiB0aGUgQVMgd2FudHMg dG8gT05MWSBzdXBwb3J0IE1UTFMgY29ubmVjdGlvbnMuIERvZXMgaXQgbm90IHNwZWNpZnkgdGhl IG9wdGlvbmFsICJtdGxzX2VuZHBvaW50cyIgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0YWRh dGEgdmFsdWVzPw0KT24gMS8xNS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCkl0 IHdvdWxkIGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0IHdhc24ndCBt YWRlIGNsZWFyLiBJdCdkIGJlIHNvbWV0aGluZyB0byB0aGUgZWZmZWN0IG9mIG9wdGlvbmFsIGZv ciB0aGUgQVMgdG8gaW5jbHVkZSBhbmQgY2xpZW50cyBkb2luZyBNVExTIHdvdWxkIHVzZSBpdCB3 aGVuIHByZXNlbnQgaW4gQVMgbWV0YWRhdGEuDQoNCk9uIFR1ZSwgSmFuIDE1LCAyMDE5IGF0IDI6 MDQgQU0gRGF2ZSBUb25nZSA8ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPG1haWx0bzpkYXZl LnRvbmdlQG1vbWVudHVtZnQuY28udWs+PiB3cm90ZToNCkknbSBpbiBmYXZvdXIgb2YgdGhlIGBt dGxzX2VuZHBvaW50c2AgbWV0YWRhdGEgcGFyYW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxkIGJl IG9wdGlvbmFsLg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0 aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3Nh Z2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91 Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpP QXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KDQpodHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6 IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVy aWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJl dmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNF OiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRl cmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_4390FC233FC04F4EB3088E266391E1DDamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4C60464DFC253B43B3192B19566EF2F4@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIg MTEgNiAzIDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw LmdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFp bC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0t MzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9uLCBs aS5nbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21h aWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1t LTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWFpcm1haWxvbiwg ZGl2LmdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJn bWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWls LW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9u DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0 MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1 NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUy OTExODc3MWFpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnAuZ21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdt YWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwt bS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0 NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2YWlybWFpbG9uLCBsaS5n bWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwt bS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4 MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgy NDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZhaXJtYWlsb24sIGRpdi5nbWFp bC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0y Mzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0 MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3 MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZhaXJtYWlsb24NCgl7bXNvLXN0eWxl LW5hbWU6Z21haWwtbV8yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3 MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdt YWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwt bTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmFpcm1haWxvbjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbTIwMzMxOTY5 Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMz MTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5 OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdt YWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1t LTQ5NjU4NjY4LCBsaS5nbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1 NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgz NjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3 MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFp bC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2NjgsIGRpdi5nbWFpbC1tMjAzMzE5 NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjEx MzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2 NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1 Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWls LW0tNDk2NTg2NjgNCgl7bXNvLXN0eWxlLW5hbWU6ImdtYWlsLW1fMjAzMzE5NjkzNzc5NzYyMjMw MGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21h aWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1t MzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMw MzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2Njgi Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDczMTMwNzg7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xNjM1NjEyMjYwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6NTMzNzM4ODg0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU1ODY4NzUzODt9DQpA bGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjIwMDA3NjU4OTc7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE4OTc0MDIyNzQ7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw1 DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgb25l IGV4YW1wbGUsIGJhc2VkIG9uIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIOKAnHN0cmF3IG1hbuKA nSBmb3JtYXQgcHJlc2VudGVkIGluIHRoaXMgdGhyZWFkOiBSRkM4NDE0IGRlZmluZXMgdGhlIHZh bHVlIG9mIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgYXMgYSDigJxKU09O IGFycmF5IGNvbnRhaW5pbmcgYSBsaXN0IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2Rz IHN1cHBvcnRlZA0KIGJ5IHRoaXMgdG9rZW4gZW5kcG9pbnQu4oCdIElmIHRoYXQgYXJyYXkgY29u dGFpbnMg4oCcdGxzX2NsaWVudF9hdXRo4oCdIGFuZCB0aGUgZW5kcG9pbnQgc3BlY2lmaWVkIGlu IHRva2VuX2VuZHBvaW50IGRvZXMgbm90IHN1cHBvcnQgbVRMUywgdGhlbiB0aGF0IG1ldGFkYXRh IHZpb2xhdGVzIDg0MTQuIFlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgYnkgYWRkaW5nIGEgdG9rZW5f ZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhlDQogbXRsc19l bmRwb2ludHMgb2JqZWN0LCBhbmQgbGlrZXdpc2UgZm9yIHRoZSBvdGhlciBlbmRwb2ludHMgYW5k IGF1dGggbWV0aG9kcy4gSWYgeW91IHRha2UgdGhhdCB0byBpdHMgbG9naWNhbCBjb25jbHVzaW9u LCB5b3UgZW5kIHVwIHdpdGggYSBjb21wbGV0ZSBtZXRhZGF0YSBkb2N1bWVudCBoYW5naW5nIG9m ZiBvZiBtdGxzX2VuZHBvaW50cy4gSXTigJlzIHRoYXQgbGluZSBvZiB0aG91Z2h0IHRoYXQgbGVk IG1lIHRvIHN1Z2dlc3QganVzdCBwb2ludGluZw0KIHRvIGFuIGFsdGVybmF0ZSBkb2N1bWVudC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25hbGx5LCBhIG1ldGFkYXRhIGRvY3VtZW50 IHRoYXQgb21pdHMgdG9rZW5fZW5kcG9pbnQgaW4gZmF2b3Igb2YgbXRsc19lbmRwb2ludHMgc2lu Y2Ugb25seSBtVExTIGlzIHN1cHBvcnRlZCB3b3VsZCB2aW9sYXRlIDg0MTQsIGFzIDg0MTQgc2F5 cyB0b2tlbl9lbmRwb2ludCDigJxpcyBSRVFVSVJFRCB1bmxlc3Mgb25seSB0aGUgaW1wbGljaXQg Z3JhbnQgdHlwZSBpcyBzdXBwb3J0ZWQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlz IHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgbXRsc19lbmRwb2ludHMgcGFyYW1ldGVyIHN1Y2ggdGhh dCB0aGUgYWJvdmUgdXNlIGNhc2VzIGFyZSBpbnZhbGlkLCBidXQgdGhhdCBkb2VzIG1ha2UgdGhl IGRvY3VtZW50IG1vcmUgY29tcGxpY2F0ZWQuIElmIHdlIGdvIHRoZSDigJxtdGxzX2FsdGVybmF0 ZV9tZXRhZGF0YeKAnSByb3V0ZSwgd2UgY2FuIHNraXAgcGFzdCBhbGwgb2YgdGhlc2UgaXNzdWVz LCBiZWNhdXNlDQogaXQgYnJpbmdzIHVzIGJhY2sgdG8ganVzdCBwYXJzaW5nIHRoZSBzYW1lIG1l dGFkYXRhIHRoYXQgd2UgZG8gdG9kYXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFs ZiBvZiBGaWxpcCBTa29rYW4gJmx0O3BhbnZhLmlwQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQgMToxMyBQTTxicj4NCjxiPlRvOiA8 L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPkJyaWFuIENhbXBi ZWxsICZsdDtiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnJmd0Oywg b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09B VVRILVdHXSBNVExTIHRva2VuIGVuZG9pbnQgJmFtcDsgZGlzY292ZXJ5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpIEFubmFiZWxsZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Y2FuIHlvdSBlbGFib3JhdGUgd2hhdCB3b3VsZCBiZSB0aGUgdmlvbGF0 aW9uIC8gbmVnYXRpdmUgaW1wYWN0IG9mIHVzYWdlIG9mIFJGQzg0MTQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGl0IGFscmVhZHkgbWFr ZXMgdXNlIG9mIGBzaWduZWRfbWV0YWRhdGFgIGFuZCB0aGlzIGxhbmd1YWdlIGlzIHByZXNlbnQg Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsmbmJzcDtDb25zdW1lcnMgb2YgdGhlIG1ldGFkYXRhIE1BWSBpZ25vcmUgdGhlIHNpZ25l ZCBtZXRhZGF0YSBpZiB0aGV5IGRvIG5vdCBzdXBwb3J0IHRoaXMgZmVhdHVyZS4mbmJzcDsgSWYg dGhlIGNvbnN1bWVyIG9mIHRoZSBtZXRhZGF0YSBzdXBwb3J0cyBzaWduZWQgbWV0YWRhdGEsIG1l dGFkYXRhIHZhbHVlcyBjb252ZXllZCBpbiB0aGUgc2lnbmVkIG1ldGFkYXRhIE1VU1QgdGFrZSBw cmVjZWRlbmNlIG92ZXIgdGhlIGNvcnJlc3BvbmRpbmcNCiB2YWx1ZXMgY29udmV5ZWQgdXNpbmcg cGxhaW4gSlNPTiBlbGVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Li4uIHdvdWxkIG10bHNfZW5kcG9pbnRzIGJlIGFueSBkaWZmZXJl bnQ/IENsaWVudHMgYXJlIGZyZWUgdG8gaWdub3JlIHRoaXMgaWYgdGhleSBkb24ndCBzdXBwb3J0 L3VzZSBtdGxzLCBhbmQgaWYgdGhleSBkbyB0aG9zZSB2YWx1ZXMgbXVzdCB0YWtlIHByZWNlZGVu Y2Ugb3ZlciB0aGUgcm9vdCBvbmVzLiB0aGUgdXNlIG9mIG10bHNfZW5kcG9pbnRzIHdvdWxkIG5v dCBiZSByZWNvbW1lbmRlZCBmb3IgbXRscy1vbmx5DQogQVMgYnV0IHJlY29tbWVuZGVkIGZvciBv bmUgd2l0aCBib3RoIG10bHMvcmVndWxhciBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiB0b2tlbl9l bmRwb2ludCByZW1haW5zIHJlcXVpcmVkIGZvciBhbGwgaW50ZW50cyBhbmQgcHVycG9zZXMuIEFu ZCBhcyBmb3IgdGhlIHVzYWJsZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kcyAtIHRoZXkg c2hvdWxkIGFsbCBiZSBsaXN0ZWQsIG9yIGRvIHlvdSB0aGluayB3ZSBzaG91bGQgc2VwYXJhdGUg dGhlDQogb25lcyBmb3IgZWFjaCBob3N0bmFtZS9wb3J0IGxvY2F0aW9uPyBUbyB3aGF0IGVuZD8g SXMgdGhlcmUgYSByaXNrIGhhdmluZyB0aGUgbXRscyBob3N0bmFtZS9wb3J0IGFjY2VwdGluZyBy ZWd1bGFyIHJlcXVlc3RzPyBPdGhlciB0aGVuIHNlY3JldC9rZXkgX2p3dCBhdXRoIG1ldGhvZHMg YXNzZXJ0aW9uIGF1ZCBjbGFpbSB0aGUgZW5kcG9pbnQgbG9jYXRpb24gZG9lc24ndCBwbGF5IGEg cm9sZSBpbiB0aGUgYXV0aGVudGljYXRpb24gcHJvY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPGJyPg0KPGI+RmlsaXA8 L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgMTIgRmViIDIwMTkgYXQgMjA6NDcsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5J4oCZbSBub3Qgb3Bwb3NlZCB0byBpbnRyb2R1Y2luZyBhIG1ldGFkYXRhIGNoYW5n ZSwgaWYgdGhlIHNjZW5hcmlvIGlzIHJlbGV2YW50IGFuZCBvdGhlciBhcHByb2FjaGVzIGNhbuKA mXQgYWRlcXVhdGVseSBhZGRyZXNzIGl0IOKAkyBhbmQgSeKAmWxsIHJlYWRpbHkgZ3JhbnQgdGhh dCB3ZSBwcm9iYWJseSBkb27igJl0IHdhbnQNCiB0byBkZXBlbmQgb24gY29uc2lzdGVuY3kgb2Yg YnJvd3NlciBiZWhhdmlvciBhdCB0aGUgaW50ZXJzZWN0aW9uIG9mIGNsaWVudCBjZXJ0aWZpY2F0 ZXMgYW5kIEFjY2Vzcy1Db250cm9sLUFsbG93LUNyZWRlbnRpYWxzLiBCdXQgY2FyZSBuZWVkcyB0 byBiZSB0YWtlbiBpbiBkZXNpZ25pbmcgdGhhdCBtZXRhZGF0YSB0byBhdm9pZCB2aW9sYXRpbmcg b3Igb3RoZXJ3aXNlIG5lZ2F0aXZlbHkgaW1wYWN0aW5nIHVzYWdlIG9mIFJGQzg0MTQuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsb25nIHRob3NlIGxpbmVzLCBpbnN0ZWFkIG9mIGFk ZGluZyBhbiDigJxtdGxzX2VuZHBvaW50c+KAnSBtZXRhZGF0YSBwYXJhbWV0ZXIsIHdlIGNvdWxk IGFkZCBhbiDigJxtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YeKAnSBwYXJhbWV0ZXIgd2hvc2UgdmFs dWUgaXMgdGhlIFVSTCBvZiBhbiBhbHRlcm5hdGUgbWV0YWRhdGENCiBkb2N1bWVudCBpbnRlbmRl ZCBmb3IgY2xpZW50cyB1c2luZyBtVExTLiBBbiBtVExTLW9wdGlvbmFsIEFTIGNvdWxkIGhhdmUg dHdvIGRpZmZlcmVudCBtZXRhZGF0YSBkb2N1bWVudHMgZm9yIG1UTFMgYW5kIG5vbi1tVExTIGNs aWVudHMsIHJlZHVjaW5nIHRoZSBtVExTLW9wdGlvbmFsIHNjZW5hcmlvIHRvIHRoZSBtVExTLW9u bHkgc2NlbmFyaW8uIFRoaXMgc2lkZXN0ZXBzIHRoZSBjaGFsbGVuZ2VzIG9mIGFsaWduaW5nIHRo ZSDigJxlaXRoZXIvb3LigJ0NCiBzZW1hbnRpY3Mgb2YgbVRMUy1vcHRpb25hbCB3aXRoIHNvbWUg b2YgdGhlIHJpZ2lkIHBhcmFtZXRlciBkZWZpbml0aW9ucyBpbiBSRkM4NDE0IChzZWU6IHRva2Vu X2VuZHBvaW50LCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0 aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEJyaWFuIENh bXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBk bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAy MDE5IGF0IDEwOjU4IEFNPGJyPg0KPGI+VG86IDwvYj5Eb21pbmljayBCYWllciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYmFp ZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPm9hdXRoICZsdDs8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIE1UTFMgdG9r ZW4gZW5kb2ludCAmYW1wOyBkaXNjb3Zlcnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzIGZvciB0aGUgaW5wdXQsIERvbWluaWNrLg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ2Qgc2FpZCBwcmV2aW91 c2x5IHRoYXQgSSB3YXMgaGF2aW5nIHRyb3VibGUgYWRlcXVhdGVseSBnYXVnaW5nIHdoZXRoZXIg b3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUg dXBkYXRlLiBJIHdhcyBldmVuIHRoaW5raW5nIG9mIGFza2luZyB0aGUgY2hhaXJzDQogYWJvdXQg YSBjb25zZW5zdXMgY2FsbCBkdXJpbmcgdGhlIG9mZmljZSBob3VycyBtZWV0aW5nIHllc3RlcmRh eS4gQnV0IGl0IGdvdCBjYW5jZWxlZC4gQW5kIGxvb2tpbmcgYWdhaW4gYmFjayBvdmVyIHRoZSBk aXNjdXNzaW9uLCBJIGRvbid0IGJlbGlldmUgYSBjb25zZW5zdXMgY2FsbCBpcyBuZWNlc3Nhcnku IFRoZXJlJ3MgYmVlbiBhIGxvdCBvZiBnZW5lcmFsIGRpc2N1c3Npb24gb3ZlciB0aGUgbGFzdCBz ZXZlcmFsIHdlZWtzIGR1cmluZyB3aGljaA0KIHNldmVyYWwgZm9sa3MgaGF2ZSBzdGF0ZWQgc3Vw cG9ydCBmb3IgdGhlIHByb3Bvc2FsIHdoaWxlIHRoZXJlJ3MgYmVlbiBvbmx5IG9uZSB2b2ljZSBv ZiBkaXJlY3QgZGlzc2VudC4gVGhhdCBzZWVtcyBsaWtlIHJvdWdoIGVub3VnaCBjb25zZW5zdXMg YW5kLCBhcyBzdWNoLCBJIHBsYW4gdG8gbWFrZSB0aGUgY2hhbmdlIGluIHRoZSBuZXh0IHJldmlz aW9uIG9mIHRoZSBkb2N1bWVudCAod2hpY2ggc2hvdWxkIGJlIGRvbmUgc29vbikuIENoYWlycywN CiBwbGVhc2UgbGV0IG1lIGtub3csIGlmIHlvdSBiZWxpZXZlIHRoZSBzaXR1YXRpb24gd2FycmFu dHMgYSBkaWZmZXJlbnQgY291cnNlIG9mIGFjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gTW9uLCBGZWIgMTEsIDIwMTkgYXQgMTE6MDEgUE0gRG9taW5pY2sgQmFpZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjQu LjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JTUhPIHRoYXTigJlzIGEg cmVhc29uYWJsZSBhbmQgcHJhZ21hdGljIG9wdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoYW5rczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+4oCU4oCU 4oCUDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvbWlu aWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tMjAzMzE5NjkzNzc5NzYy MjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5 Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFp bC1tMzczMjQyODAzMDUyOTExODc3MWFpcm1haWxvbiI+DQpPbiAxMS4gRmVicnVhcnkgMjAxOSBh dCAxMzoyNjozNywgQnJpYW4gQ2FtcGJlbGwgKDxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SXQn cyBiZWVuIHBvaW50ZWQgb3V0IHRoYXQgdGhlIHBvdGVudGlhbCBpc3N1ZSBpcyBub3QgaXNvbGF0 ZWQgdG8gdGhlIGp1c3QgdG9rZW4gZW5kcG9pbnQgYnV0IHRoYXQgcmV2b2NhdGlvbiwgaW50cm9z cGVjdGlvbiwgZXRjLiBjb3VsZCBiZSBpbXBhY3RlZCBhcyB3ZWxsLiBTbywmbmJzcDsgYXQgdGhp cyBwb2ludCwgdGhlIHByb3Bvc2FsDQogb24gdGhlIHRhYmxlIGlzIHRvIGFkZCBhIG5ldyBvcHRp b25hbCBBUyBtZXRhZGF0YSBwYXJhbWV0ZXIgbmFtZWQgJ210bHNfZW5kcG9pbnRzJyB0aGF0J3Mg dmFsdWUgd2UgYmUgYSBKU09OIG9iamVjdCB3aGljaCBpdHNlbGYgY29udGFpbnMgZW5kcG9pbnRz IHRoYXQsIHdoZW4gcHJlc2VudCwgYSBjbGllbnQgZG9pbmcgTVRMUyB3b3VsZCB1c2UgcmF0aGVy IHRoYW4gdGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiZuYnNwOyBBIHN0cmF3LW1hbiBleGFtcGxlIG1p Z2h0DQogbG9vayBsaWtlIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj57PGJyPg0KJm5ic3A7ICZxdW90O2lzc3VlciZxdW90OzomcXVvdDs8YSBocmVmPSJodHRw czovL3NlcnZlci5leGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4 YW1wbGUuY29tPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7YXV0aG9yaXphdGlvbl9lbmRw b2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRo eiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGh6PC9hPiZx dW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbjwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90 O3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQmcXVvdDs6WyAmbmJzcDsmcXVv dDtjbGllbnRfc2VjcmV0X2Jhc2ljJnF1b3Q7LCZxdW90O3Rsc19jbGllbnRfYXV0aCZxdW90Oywg JnF1b3Q7bm9uZSZxdW90O10sPGJyPg0KJm5ic3A7ICZxdW90O3VzZXJpbmZvX2VuZHBvaW50JnF1 b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3VzZXJpbmZvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdXNlcmluZm88L2E+JnF1 b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDtyZXZvY2F0aW9uX2VuZHBvaW50JnF1b3Q7OiZxdW90Ozxh IGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Jldm8iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZXZvPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgJnF1 b3Q7andrc191cmkmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5j b20vandrcy5qc29uIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20v andrcy5qc29uPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgPGI+JnF1b3Q7bXRsc19lbmRwb2ludHMm cXVvdDs6ezxicj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnQmcXVvdDs6JnF1 b3Q7PGEgaHJlZj0iaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rva2VuIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rva2VuPC9hPiZxdW90Oyw8YnI+DQombmJzcDsg Jm5ic3A7ICZxdW90O3VzZXJpbmZvX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBz Oi8vbXRscy5leGFtcGxlLmNvbS91c2VyaW5mbyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbXRs cy5leGFtcGxlLmNvbS91c2VyaW5mbzwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVv dDtyZXZvY2F0aW9uX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vbXRscy4u LmV4YW1wbGUuY29tL3Jldm8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL210bHMuZXhhbXBsZS5j b20vcmV2bzwvYT4mcXVvdDs8YnI+DQombmJzcDsgfTwvYj48YnI+DQp9PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BIGNsaWVudCBkb2luZyBNVExTIHdvdWxkIGxvb2sgZm9yIGFuZCBnaXZlIHByZWNlZGVuY2Ug dG8gYW4gZW5kcG9pbnQgdW5kZXIgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgd2hpbGUgZmFs bGluZyBiYWNrIHRvIHVzZSB0aGUgbm9ybWFsIGVuZHBvaW50IGZyb20gdGhlIHRvcCBsZXZlbCBv ZiBtZXRhZGF0YSB3aGVuL2lmDQogaXRzIG5vdCBpbiAmcXVvdDttdGxzX2VuZHBvaW50cyZxdW90 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGJyPg0KVGhlIGlkZWEgYmVpbmcgdGhhdCAmcXVvdDtyZWd1bGFyJnF1b3Q7IGNsaWVudHMgKHRo b3NlIG5vdCBkb2luZyBNVExTKSB3aWxsIHVzZSB0aGUgcmVndWxhciBlbmRwb2ludHMuIEFuZCBv bmx5IHRoZSBob3N0L3BvcnQgb2YgdGhlIGVuZHBvaW50cyBsaXN0ZWQgaW4gbXRsc19lbmRwb2lu dHMgd2lsbCBiZSBzZXQgdXAgdG8gcmVxdWVzdCBUTFMgY2xpZW50IGNlcnRpZmljYXRlcyBkdXJp bmcgaGFuZHNoYWtlLiBUaHVzIGFueSBwb3RlbnRpYWwgaW1wYWN0IG9mIHRoZQ0KIENlcnRpZmlj YXRlUmVxdWVzdCBtZXNzYWdlIGJlaW5nIHNlbnQgaW4gdGhlIFRMUyBoYW5kc2hha2UgY2FuIGJl IGF2b2lkZWQgZm9yIGFsbCB0aGUgb3RoZXIgcmVndWxhciBjbGllbnRzIHRoYXQgYXJlIG5vdCBn b2luZyB0byBkbyBNVExTIC0gaW5jbHVkaW5nIGFuZCBtb3N0IGltcG9ydGFudGx5IGluLWJyb3dz ZXIgamF2YXNjcmlwdCBjbGllbnRzIHdoZXJlIHRoZXJlIGNhbiBiZSBsZXNzIHRoYW4gZGVzaXJh YmxlIFVJIHByZXNlbnRlZCB0bw0KIHRoZSBlbmQtdXNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBzdHJ1Z2dsaW5nLCBob3dl dmVyLCB0byBhZGVxdWF0ZWx5IGdhdWdlIHdoZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVu dCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBUaGVyZSdzIGJlZW4gc29t ZSBzdXBwb3J0IGZvciBpdCB2b2ljZWQuIEFzIHdlbGwgYXMgdGFsayBvZg0KIG90aGVyIGFwcHJv YWNoZXMgdGhhdCBjb3VsZCBiZSBhbHRlcm5hdGl2ZXMgb3IgYWRkaXRpb25hbCBtZWFzdXJlcy4g QW5kIGFsc28gc29tZSB2b2NhbCBvcHBvc2l0aW9uIHRvIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gU2F0LCBGZWIgOSwgMjAxOSBhdCAzOjA5IEFNIERvbWluaWNrIEJhaWVyICZsdDs8YSBocmVm PSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWll ckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+V2UgYXJlIGN1cnJlbnRseSBpbXBsZW1lbnRp bmcgTVRMUyBpbiBJZGVudGl0eVNlcnZlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPk91ciBhcHByb2FjaCB3aWxsIGJlIHRo YXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBvaW50IHRoYXQgc3VwcG9ydHMg Y2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGluZyBhbiBvZmZpY2lhbA0KIGVu ZHBvaW50IG5hbWUgZm9yIGRpc2NvdmVyeT8gUmlnaHQgbm93IHdlIGFyZSB1c2luZyDigJxtdGxz X3Rva2VuX2VuZHBvaW504oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJTigJTigJQNCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG9taW5pY2s8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYw ODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUz MjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMw NTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQx Mjc2NmFpcm1haWxvbiI+DQpPbiA3LiBGZWJydWFyeSAyMDE5IGF0IDIyOjM2OjU1LCBCcmlhbiBD YW1wYmVsbCAoPGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29t QGRtYXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BaCB5ZXMsIHRo YXQgbWFrZXMgc2Vuc2UuIFRoYW5rcyBmb3IgY2xhcmlmeWluZy4gQW5kIGl0IGlzIGluZGVlZCBh IGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBjaGFuZ2UgdGhh dCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGJyZWFrIHRoaW5ncyB1bmV4cGVj dGVkbHkuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBGZWIgNywgMjAxOSBhdCA4 OjU3IEFNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBjYXNlIEnigJltIHJlZmVyZW5jaW5nIGRpZG7igJl0IHNwZWNpZmljYWxs eSBpbnZvbHZlIEFTIG1ldGFkYXRhLiBXZSBoYWQgY2xpZW50cyBpbiB0aGUgd2lsZCB0aGF0IGFz c3VtZWQgdGhhdCBhbGwgdGhlIHByb3BlcnRpZXMgaW4gdGhlIEpTT04gb2JqZWN0IHJldHVybmVk IGZyb20gb3VyIHVzZXJpbmZvIGVuZHBvaW50DQogd2VyZSBzY2FsYXIgc3RyaW5ncy4gVGhpcyBi cm9rZSB3aGVuIHdlIGludHJvZHVjZWQgYSBuZXcgcHJvcGVydHkgd2hvc2UgdmFsdWUgd2FzIGEg SlNPTiBvYmplY3QuIEl0IHdhcyBhIGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5 IGlubm9jdW91cyBjaGFuZ2UgdGhhdCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2Fu IGZvcmNlIG1vcmUgd29yayBvbiBjbGllbnRzIHRoYW4gd2UgZXhwZWN0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5CcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDYsIDIwMTkgYXQgMTE6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+ICZxdW90O1JpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZxdW90O1JpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0Oywgb2F1dGggJmx0 OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gW1VOVkVS SUZJRUQgU0VOREVSXSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0 b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgSSdtIGhvbmVzdGx5IHJlYWxseSBzdHJ1 Z2dsaW5nIHRvIHNlZSB3aGF0IGNvdWxkIGhhdmUgZ29uZSB3cm9uZyB3aXRoIG9yIGhvdyB0b2tl bl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYnJva2Ugc29tZXRoaW5nIHdpdGggdGhlIHVzZXIgaW5m byBlbmRwb2ludC4gSWYgeW91IGhhdmUgdGhlIHRpbWUgYW5kL29yDQogaXQnZCBiZSBpbmZvcm1h dGl2ZSB0byB0aGlzIGhlcmUgbGl0dGxlIGRpc2N1c3Npb24sIHBsZWFzZSBleHBsYWluIHRoYXQg b25lIGEgYml0IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gV2VkLCBGZWIgNiwgMjAxOSBhdCAxMjoxNSBQTSBCcmlhbiBDYW1wYmVsbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9i bGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdDtib3JkZXItdG9wOmN1cnJlbnRjb2xvcjtib3JkZXItcmlnaHQ6Y3VycmVudGNvbG9yO2Jv cmRlci1ib3R0b206Y3VycmVudGNvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+JnF1b3Q7ZmFyJnF1b3Q7IHNob3VsZCBoYXZlIHNhaWQgJnF1b3Q7ZmFp ciZxdW90OyBpbiB0aGUgcHJldmlvdXMgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwg RmViIDUsIDIwMTkgYXQgNDozNSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItdG9wOmN1 cnJlbnRjb2xvcjtib3JkZXItcmlnaHQ6Y3VycmVudGNvbG9yO2JvcmRlci1ib3R0b206Y3VycmVu dGNvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQg bWF5IHdlbGwgYmUgZHVlIHRvIG15IG93biBpbnRlbGxlY3R1YWwgc2hvcnRjb21pbmdzIGJ1dCB0 aGVzZSBpc3N1ZXMvcXVlc3Rpb25zL2NvbmZ1c2lvbi1wb2ludHMgYXJlIG5vdCByZXNvbmF0aW5n IGZvciBtZSBhcyBiZWluZyBwcm9ibGVtYXRpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBtb3JlIGdlbmVyYWwgc3RhbmNlIG9m ICZxdW90O3RoaXMgaXNuJ3QgbmVlZGVkIG9yIHdvcnRoIGl0IGluIHRoaXMgZG9jdW1lbnQmcXVv dDsgKEkgdGhpbmsgdGhhdCdzIGZhcj8pIGlzIGJlaW5nIGhlYXJkIHRob3VnaC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQyIFBNIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29t QGRtYXJjLmlldGYuLi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItdG9wOmN1cnJlbnRjb2xv cjtib3JkZXItcmlnaHQ6Y3VycmVudGNvbG9yO2JvcmRlci1ib3R0b206Y3VycmVudGNvbG9yIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oVEw7RFI6IHB1bnQgQVMgbWV0 YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCk8YnI+DQo8YnI+DQpBUyBwb2ludHMgIzEtMyBhcmUg YWxsIHF1ZXN0aW9ucyBJIHdvdWxkIGhhdmUgYXMgYW4gaW1wbGVtZW50ZXI6PG86cD48L286cD48 L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJnbWFpbC1tMjAzMzE5Njkz Nzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMx ODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5 OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21h aWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0t NDk2NTg2NjgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQxNCNzZWN0aW9uLTIiIHRhcmdldD0iX2JsYW5r Ij5TZWN0aW9uIDIgb2YgUkZDODQxNDwvYT4gc2F5cyB0b2tlbl9lbmRwb2ludCDigJxpcyBSRVFV SVJFRCB1bmxlc3Mgb25seSB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBpcyBzdXBwb3J0ZWQu4oCd IFNvIHdoYXQgZG9lcyB0aGUgbVRMUy1vbmx5IEFTIHB1dCBoZXJlPw0KPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iZ21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5 Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYy MTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFn bWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwt bTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4IiBzdHlsZT0ibXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KVGhlIGNsYWltcyBmb3IgdGhlc2Ugb3RoZXIgZW5kcG9pbnRzIGFyZSBP UFRJT05BTCwgcG90ZW50aWFsbHkgbGVhZGluZyB0byBpbmNvbnNpc3RlbmN5IGRlcGVuZGluZyBv biBob3cgIzEgZ2V0cyBkZWNpZGVkLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwt bTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4 NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3 NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1 Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3 MzJnbWFpbC1tLTQ5NjU4NjY4IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhl IGV4YW1wbGUgdXNhZ2Ugb2YgdGhlIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBwcm9wZXJ0 eSBnaXZlbiBlYXJsaWVyIGlzIGluY29tcGF0aWJsZSB3aXRoIFJGQzg0MTQsIHNpbmNlIHNvbWUg b2YgaXRzIGNvbnRlbnRzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbm9uLW1UTFMgZW5kcG9pbnRz LCBhbmQgb3RoZXJzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbVRMUyBlbmRwb2ludHMuIEhlbmNl IHRoaXMgcXVlc3Rpb24uDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tMjAzMzE5 NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjEx MzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2 NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1 Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWls LW0tNDk2NTg2NjgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGlzIGludHJv ZHVjZXMgYSBuZXcgbWV0YWRhdGEgcHJvcGVydHkgdGhhdCBjb3VsZCBpbXBhY3QgaG93IG90aGVy IHNwZWNzIHNob3VsZCBleHRlbmQgQVMgbWV0YWRhdGEuIFRoYXQgbmVlZHMgdG8gYmUgYWRkcmVz c2VkLg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGNvdWxkIGdvIG9uIGZv ciBjbGllbnQgcG9pbnRzIGJ1dCB5b3UgYWxyZWFkeSBnZXQgdGhlIHBvaW50LiBUaG91Z2ggSeKA mWxsIHNoYXJlIHRoYXQgIzMgaXMgcmVhbCBhbmQgb25jZSBmb3JjZWQgbWUgdG8gcm9sbCBiYWNr IGFuIHVwZGF0ZSB0byB0aGUgTG9naW4gd2l0aCBBbWF6b24gdXNlcmluZm8gZW5kcG9pbnTigKZn b29kDQogdGltZXMuIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBDb2xvciBF bW9qaSZxdW90OyI+JiMxMjg1MTU7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSBkb27igJl0IG5lY2Vzc2FyaWx5IHRoaW5rIGFuIEFTIG1ldGFkYXRhIHByb3BlcnR5IGlzIHdy b25nIHBlciBzZSwgYnV0IHVuZGVyc3RhbmQgdGhhdCB5b3XigJlyZSBib2x0aW5nIGEgbGF5ZXIg b2YgZmxleGliaWxpdHkgb250byBhIHN0YW5kYXJkIHRoYXQgd2FzbuKAmXQgZGVzaWduZWQgZm9y IHRoYXQsIGFuZCBJDQogZG9u4oCZdCB0aGluayB0aGUgbWV0YWRhdGEgcHJvcG9zYWwgYXMgaXTi gJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc3VmZmljaWVudGx5IGRlYWxzIHdpdGggdGhlIGZhbGxv dXQgZnJvbSB0aGF0LiBJbiBteSB2aWV3IHRoaXMgaXMgYSBjb21wbGV4IGVub3VnaCBpc3N1ZSBh bmQgaXTigJlzIGZvciBhIG51YW5jZWQgZW5vdWdoIHVzZSBjYXNlIChhcyBmYXIgYXMgSSBjYW4g dGVsbCBmcm9tIGRpc2N1c3Npb24/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEnigJltIHdyb25nKQ0K IHRoYXQgd2Ugc2hvdWxkIHB1bnQgaXQgdG8gYSBzZXBhcmF0ZSBkcmFmdCAoZS5nLiwg4oCcQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGEgRXh0ZW5zaW9ucyBmb3IgbVRMUyBIeWJyaWRz4oCd KSBhbmQgZ2V0IG1UTFMgb3V0IHRoZSBkb29yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJp Y2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50 aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IE1vbmRheSwg RmVicnVhcnkgNCwgMjAxOSBhdCA1OjI4IEFNPGJyPg0KPGI+VG86PC9iPiAmcXVvdDtSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBk bWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5E RVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBv aW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRob3NlIHBvaW50cyBvZiBj b25mdXNpb24gc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGlj LiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJl aW5nIGFudGkgYWRkaXRpb25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzDQogbm90ZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B bGwgb2Ygd2hpY2ggbGVhdmVzIG1lIGEgYml0IHVuY2VydGFpbiBhYm91dCBob3cgdG8gcHJvY2Vl ZC4gVGhlcmUgc2VlbSB0byBiZSBhIHJhbmdlIG9mIG9waW5pb25zIG9uIHRoaXMgcG9pbnQgYW5k IGdhdWdpbmcgY29uc2Vuc3VzIGlzIHByb3ZpbmcgZWx1c2l2ZSBmb3IgbWUuIFRoYXQncyBjb25m b3VuZGVkDQogYnkgbXkgb3duIG9waW5pb24gb24gaXQgYmVpbmcgc29tZXdoYXQgZmx1aWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B bmQgSSdkIHJlYWxseSBsaWtlIHRvIHBvc3QgYW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYWJvdXQg YSBtb250aCBvciB0d28gYWdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBGcmksIEZlYiAxLCAyMDE5IGF0IDU6MDMgUE0gUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi4uLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci10b3A6Y3VycmVudGNvbG9yO2JvcmRl ci1yaWdodDpjdXJyZW50Y29sb3I7Ym9yZGVyLWJvdHRvbTpjdXJyZW50Y29sb3IiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBBU+KAmXMg cGVyc3BlY3RpdmU6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxp IGNsYXNzPSJnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5 NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFn bWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWls LW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4 MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2NjgiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZl bDEgbGZvMiI+DQpJZiBJIG9ubHkgc3VwcG9ydCBtVExTLCBkbyBJIG5lZWQgdG8gaW5jbHVkZSBi b3RoIHRva2VuX2VuZHBvaW50X3VyaSBhbmQgbXRsc19lbmRwb2ludHM/IFNob3VsZCBJIG9taXQg dG9rZW5fZW5kcG9pbnRfdXJpPyBPciBzZXQgaXQgdG8gdGhlIGVtcHR5IHN0cmluZz8NCjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYw ODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUz MjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMw NTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQx Mjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2OCIgc3R5bGU9Im1z by1saXN0OmwyIGxldmVsMSBsZm8yIj4NCldoYXQgaWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3Ig dGhlIHRva2VuIGVuZHBvaW50LCBidXQgbm90IHJldm9jYXRpb24gb3IgdXNlciBpbmZvPw0KPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1t NjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2 NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0Mjgw MzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3 NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4IiBzdHlsZT0i bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KSG93IGRvIEkgc3BlY2lmeSBhdXRoZW50aWNhdGlv biBtZXRob2RzIGZvciB0aGUgbVRMUyB0b2tlbiBlbmRwb2ludD8gRG9lcyB0b2tlbl9lbmRwb2lu dF9hdXRoX21ldGhvZHMgYXBwbHkgdG8gYm90aCB0aGUgbVRMUyBhbmQgbm9uLW1UTFMgZW5kcG9p bnRzPw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbTIwMzMxOTY5Mzc3OTc2MjIz MDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdt YWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwt bTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkz MDMzODI4ODg3NDEyNzY2Z21haWwtbTUxODA1MDM0NjYxNjk5Nzg3MzJnbWFpbC1tLTQ5NjU4NjY4 IiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KSeKAmW0gdXNpbmcgdGhlIE9BdXRo IDIuMCBEZXZpY2UgRmxvdy4gRG8gSSBpbmNsdWRlIGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRo b3JpemF0aW9uX2VuZHBvaW50IHVuZGVyIG10bHNfZW5kcG9pbnRzPw0KPG86cD48L286cD48L2xp Pjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Db25mdXNpb24gZnJvbSB0aGUgY2xpZW504oCZcyBwZXJzcGVj dGl2ZTo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 ImdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFp bC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0t MzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1 ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2 MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2OCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8z Ij4NCkFzIGZhciBhcyBJIGtub3csIEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQg a25vdyBhbnl0aGluZyBhYm91dCBtVExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xp ZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0 byB1c2UgdGhhdCB0byBhdXRoZW50aWNhdGUgbWUuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21h aWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1t LTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3 NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2 NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2NjgiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZv MyI+DQpNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIHRoZSBtVExTLW9ubHkg QVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21h aWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1t LTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3 NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZnbWFpbC1tNTE4MDUwMzQ2 NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2NjgiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZv MyI+DQpNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIGl0IGRpZG7igJl0IGV4 cGVjdCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBhcyBhIHBhcmFtZXRlciB2YWx1ZS4NCjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwt bTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5 NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4 MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4 NzQxMjc2NmdtYWlsLW01MTgwNTAzNDY2MTY5OTc4NzMyZ21haWwtbS00OTY1ODY2OCIgc3R5bGU9 Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSBtVExTLW9ubHkgQVMgZGlkbuKAmXQgcHJv dmlkZSBhIHZhbHVlIGZvciBtdGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRvPyA8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0 ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMx MTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTEx ODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MTI3NjZn bWFpbC1tNTE4MDUwMzQ2NjE2OTk3ODczMmdtYWlsLW0tNDk2NTg2NjgiIHN0eWxlPSJtc28tbGlz dDpsMSBsZXZlbDEgbGZvMyI+DQpJIGRvbuKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKAnSBtZWFu cywgYnV0IHRoZXkgdG9sZCBtZSB0byB1c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0aGUgb25l IHdpdGgg4oCcdGxz4oCdIGluIGl0cyBuYW1lLCByaWdodD8NCjxvOnA+PC9vOnA+PC9saT48L29s Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+WWVzLCB5b3UgY2FuIHdyaXRlIG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5z d2VycyBtb3N0IG9mIHRoZXNlLiBCdXQgeW914oCZbGwgaGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEg bG90IG9mIHNpbWlsYXItYnV0LXNsaWdodGx5LWRpZmZlcmVudCBzY2VuYXJpb3MgYW5kIGJlIHZl cnkgZXhwbGljaXQuIEFuZCBpbXBsZW1lbnRlcnMNCiB3aWxsIHN0aWxsIGdldCBpdCB3cm9uZy4g VGhlIG1ldGFkYXRhIGNoYW5nZSBpbnRyb2R1Y2VzIG9wcG9ydHVuaXRpZXMgZm9yIGNvbmZ1c2lv biBhbmQgZmFpbHVyZSB0aGF0IGRvIG5vdCBleGlzdCBub3csIGFuZCBmb3JjZXMgdGhlbSBvbiBl dmVyeW9uZSB3aG8gc3VwcG9ydHMgbVRMUy4gSW4gY29udHJhc3QsIHRoZSAzMDcgcmVkaXJlY3Qg aXMgb25seSByZXF1aXJlZCB3aGVuIGFuIEFTIHdhbnRzIHRvIHN1cHBvcnQgYm90aCwgYW5kIGlz IHVuYW1iaWd1b3VzDQogaW4gaXRzIGJlaGF2aW9yIGFuZCBtZWFuaW5nLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ccmlh biBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5j b21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEs IDIwMTkgYXQgMzoxNyBQTTxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIiB0 YXJnZXQ9Il9ibGFuayI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7LCBvYXV0aCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FV VEgtV0ddIE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9p bnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVz aW5nIG9yIGxhcmdlIG9mIGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBN VExTIGFuZCB0aGUgZ2l2ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNg LCB0aGVuIGl0IHVzZXMgdGhhdCBvbmUuJm5ic3A7IE90aGVyd2lzZQ0KIGl0IHVzZXMgdGhlIHJl Z3VsYXIgZW5kcG9pbnQuIEl0IGdpdmVzIGFuIEFTIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIGRl cGxveW1lbnQgb3B0aW9ucy4gSSBwZXJzb25hbGx5IHRoaW5rIGdldHRpbmcgYSAzMDcgYXBwcm9h Y2ggZGVwbG95ZWQgYW5kIHdvcmtpbmcgd291bGQgYmUgbW9yZSBjb21wbGljYXRlZCBhbmQgZXJy b3IgcHJvbmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNlIGF0IHRoZSBtb21lbnQg YnV0IHRoZXJlIGFyZSBmb3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVzaCBmb3IgaW5jcmVhc2Vk IHNlY3VyaXR5IGluIGdlbmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlwdCBjbGllbnRzIHVzZSB0 aGUgY29kZSBmbG93LCB0aGF0IHN1Z2dlc3QNCiBpdCB3b24ndCBiZSB0ZXJyaWJseSB1bnVzdWFs IHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBjbGllbnRzIGFuZCBqYXZh c2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ3ZlIHBlcnNvbmFsbHkgd2F2 ZXJlZCBiYWNrIGFuZCBmb3J0aCBpbiB0aGlzIHRocmVhZCBvbiB3aGV0aGVyIG9yIG5vdCB0byBh ZGQgdGhlIG5ldyBtZXRhZGF0YSAob3Igc29tZXRoaW5nIGxpa2UgaXQpLiBXaXRoIG15IHJlYXNv bmluZyBlYWNoIHdheSBraW5kYSBleHBsYWluZWQgc29tZXdoZXJlIGJhY2sNCiBpbiB0aGUgNDAg b3Igc28gbWVzc2FnZXMgdGhhdCBtYWtlIHVwIHRoaXMgdGhyZWFkLiZuYnNwOyBCdXQgaXQgc2Vl bXMgbGlrZSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSBncm91cCBoZXJlIGlzIGluIGZhdm9y IG9mIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6MTgg UE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0 bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci10 b3A6Y3VycmVudGNvbG9yO2JvcmRlci1yaWdodDpjdXJyZW50Y29sb3I7Ym9yZGVyLWJvdHRvbTpj dXJyZW50Y29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMg c3RyaWtlcyBtZSBhcyBhIHZlcnkgcHJvbWluZW50IGFuZCBjb25mdXNpbmcgY2hhbmdlIHRvIHN1 cHBvcnQgd2hhdCBzZWVtcyB0byBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlLiBJ4oCZbSBnZXR0aW5n IGEgaGVhZGFjaGUganVzdCB0aGlua2luZyBhYm91dCB0aGUgdGV4dCBuZWVkZWQgdG8gY2xhcmlm eSB3aGVuDQogdGhlIEFTIHNob3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2AgYW5kIHdoZW4g dGhlIGNsaWVudCBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9lbmRwb2ludC5g IFdoeSBpcyB0aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3ZlciB0aGUgY2Fz ZSB3aGVyZSBhIHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1tVExTPzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRp dHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJl bGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTo8L2I+IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBNPGJyPg0K PGI+VG86PC9iPiBHZW9yZ2UgRmxldGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0 MGFvbC5jb21AZG1hcmMuLi4uLi4uaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJv d3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgdGhhdCB3 b3VsZCB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBHZW9yZ2UgRmxldGNoZXIg Jmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdDtib3JkZXItdG9wOmN1cnJlbnRjb2xvcjtib3JkZXItcmlnaHQ6Y3VycmVudGNv bG9yO2JvcmRlci1ib3R0b206Y3VycmVudGNvbG9yIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPldoYXQgaWYgdGhlIEFTIHdhbnRz IHRvIE9OTFkgc3VwcG9ydCBNVExTIGNvbm5lY3Rpb25zLiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRo ZSBvcHRpb25hbCAmcXVvdDttdGxzX2VuZHBvaW50cyZxdW90OyBhbmQganVzdCB1c2UgdGhlIG5v cm1hbCBtZXRhZGF0YSB2YWx1ZXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gMS8xNS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkl0IHdvdWxkIGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2ll cyBpZiB0aGF0IHdhc24ndCBtYWRlIGNsZWFyLiBJdCdkIGJlIHNvbWV0aGluZyB0byB0aGUgZWZm ZWN0IG9mIG9wdGlvbmFsIGZvciB0aGUgQVMgdG8gaW5jbHVkZSBhbmQgY2xpZW50cyBkb2luZyBN VExTIHdvdWxkIHVzZSBpdCB3aGVuDQogcHJlc2VudCBpbiBBUyBtZXRhZGF0YS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEphbiAxNSwg MjAxOSBhdCAyOjA0IEFNIERhdmUgVG9uZ2UgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZlLnRvbmdl QG1vbWVudHVtZnQuY28udWsiIHRhcmdldD0iX2JsYW5rIj5kYXZlLnRvbmdlQG1vbWVudHVtZnQu Y28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkknbSBpbiBmYXZv dXIgb2YgdGhlIGBtdGxzX2VuZHBvaW50c2AgbWV0YWRhdGEgcGFyYW1ldGVyIC0gYWx0aG91Z2gg aXQgc2hvdWxkIGJlIG9wdGlvbmFsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNj bG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhh dmUNCiByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9z cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjoj NTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVO VElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBw cml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lw aWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxl IGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1 NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElB TElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2 aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7 Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5D T05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFu eSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48 L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+ PC9iPg0KIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+ PC9iPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4390FC233FC04F4EB3088E266391E1DDamazoncom_-- From nobody Wed Feb 13 03:24:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442AE12DDA3 for ; Wed, 13 Feb 2019 03:24:54 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh0eYFh9d_mb for ; Wed, 13 Feb 2019 03:24:49 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B21128CB7 for ; Wed, 13 Feb 2019 03:24:48 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id n8so3304409otl.6 for ; Wed, 13 Feb 2019 03:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vBG0FNQgqKDUBrA/GhJWXDwvPReT7drU6PQKmn9SV+4=; b=tLkwzMNDq3qvxNroiumZJNp6S98XRuv33Lw6KYQVrRou/fXflNkSm3B1sPwE73NQ61 zvNhsRrCjsAn366r7BivlukmLn9W/LDHhnDP3dGsbHpbHdISvwo5oGDPr9yqSxh82i5J /srIWR6dzNoASn+BP/MrSdSNqu9BK7gcPvASloXs8LJKO1Q3EPapkaTYAe5tC/iZUtIG iB0ME00M/zGpNb/yKbgXlu58cAADSFV39m2+y6Y3clYXkPav6ncRe0ajspOyXfa5Zmwo XN9DB1e/xXmYZCttamGBrYdMjntJBi8wVckLT4wqnpkBjdJw+XzGEbQ6Y++3MxiMlJIz EDrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vBG0FNQgqKDUBrA/GhJWXDwvPReT7drU6PQKmn9SV+4=; b=cF36x826zDrmUST4WF+k0eaAKofYZj0ZqZTcLmF7qiH7KxTmsyvpgm2LP32DnL0gqN 1v+V7cGnWoxjCFtrTpr1GV8gXuCnkk6vDIl3NNhY1x3rA3B2MCOMXek+mGSBHhzd9dxt zxQkGJo0uqzKotVTFIMu3zgrR6YX1IOOfFFtJM6JfpftXLvnbmGxuNzHSNQD8ZjY9kjq Npqy53gBztHcxPDTw8jEHijeb7rdQN00Q66DouuDDhzJWVyBbHE9y2yrANKjt1tq9Jt+ Js8iKFSf+Ronm6kPESp98az8mFZjBIIK9yUQCioSO2uJCgkrOtrNBptP4JJOTojbADnI inwA== X-Gm-Message-State: AHQUAuaBCL/RvbzJmDKOpzj5lrzBhohU2fPsOyhvqVi7+pyFk77lOb4s KnjcDtr4yWWVGeNEwvZrM4kGB3qMVCk8y4o3hkVMCw1QPA== X-Google-Smtp-Source: AHgI3IaAkT0DP8yQR0VGaRMghrUadx6ZtkwLTg+0Vu38LrXnV/wZUPk0fwbSWyoWDznRQ2CWG4xPeLlHe4T1B7ZHOag= X-Received: by 2002:a9d:5d0e:: with SMTP id b14mr8199110oti.263.1550057087512; Wed, 13 Feb 2019 03:24:47 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> In-Reply-To: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> From: Filip Skokan Date: Wed, 13 Feb 2019 12:24:36 +0100 Message-ID: To: "Richard Backman, Annabelle" Cc: "Richard Backman, Annabelle" , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000001536e90581c4caee" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 11:24:54 -0000 --0000000000001536e90581c4caee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, > Additionally, a metadata document that omits token_endpoint in favor of > mtls_endpoints since only mTLS is supported would violate 8414, as 8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is > supported.=E2=80=9D mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format > presented in this thread: RFC8414 defines the value of > token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing= a list of > client authentication methods supported by this token endpoint.=E2=80=9D = If that > array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specifi= ed in > token_endpoint does not support mTLS, then that metadata violates 8414. Y= ou > could address this by adding a token_endpoint_auth_methods_supported > parameter to the mtls_endpoints object, and likewise for the other > endpoints and auth methods. If you take that to its logical conclusion, y= ou > end up with a complete metadata document hanging off of mtls_endpoints. > It=E2=80=99s that line of thought that led me to suggest just pointing to= an > alternate document. Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present. I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints. S pozdravem, *Filip Skokan* On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle < richanna@amazon.com> wrote: > Here is one example, based on my understanding of the =E2=80=9Cstraw man= =E2=80=9D format > presented in this thread: RFC8414 defines the value of > token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing= a list of > client authentication methods supported by this token endpoint.=E2=80=9D = If that > array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specifi= ed in > token_endpoint does not support mTLS, then that metadata violates 8414. Y= ou > could address this by adding a token_endpoint_auth_methods_supported > parameter to the mtls_endpoints object, and likewise for the other > endpoints and auth methods. If you take that to its logical conclusion, y= ou > end up with a complete metadata document hanging off of mtls_endpoints. > It=E2=80=99s that line of thought that led me to suggest just pointing to= an > alternate document. > > > > Additionally, a metadata document that omits token_endpoint in favor of > mtls_endpoints since only mTLS is supported would violate 8414, as 8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is > supported.=E2=80=9D > > > > It is possible to define the mtls_endpoints parameter such that the above > use cases are invalid, but that does make the document more complicated. = If > we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip pa= st all of these > issues, because it brings us back to just parsing the same metadata that = we > do today. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Filip Skokan < > panva.ip@gmail.com> > *Date: *Tuesday, February 12, 2019 at 1:13 PM > *To: *"Richard Backman, Annabelle" > *Cc: *Brian Campbell , oau= th > > *Subject: *Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Hi Annabelle, > > > > can you elaborate what would be the violation / negative impact of usage > of RFC8414? > > > > As it already makes use of `signed_metadata` and this language is present > ... > > > > > Consumers of the metadata MAY ignore the signed metadata if they do not > support this feature. If the consumer of the metadata supports signed > metadata, metadata values conveyed in the signed metadata MUST take > precedence over the corresponding values conveyed using plain JSON elemen= ts. > > > > ... would mtls_endpoints be any different? Clients are free to ignore thi= s > if they don't support/use mtls, and if they do those values must take > precedence over the root ones. the use of mtls_endpoints would not be > recommended for mtls-only AS but recommended for one with both mtls/regul= ar > authentication methods. token_endpoint remains required for all intents a= nd > purposes. And as for the usable client authentication methods - they shou= ld > all be listed, or do you think we should separate the ones for each > hostname/port location? To what end? Is there a risk having the mtls > hostname/port accepting regular requests? Other then secret/key _jwt auth > methods assertion aud claim the endpoint location doesn't play a role in > the authentication process. > > > Best, > *Filip* > > > > > > On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > I=E2=80=99m not opposed to introducing a metadata change, if the scenario= is > relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll > readily grant that we probably don=E2=80=99t want to depend on consistenc= y of > browser behavior at the intersection of client certificates and > Access-Control-Allow-Credentials. But care needs to be taken in designing > that metadata to avoid violating or otherwise negatively impacting usage = of > RFC8414. > > > > Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D = metadata > parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D para= meter whose value > is the URL of an alternate metadata document intended for clients using > mTLS. An mTLS-optional AS could have two different metadata documents for > mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the > mTLS-only scenario. This sidesteps the challenges of aligning the > =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the r= igid parameter > definitions in RFC8414 (see: token_endpoint, > token_endpoint_auth_methods_supported). > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Brian Campbell > > *Date: *Tuesday, February 12, 2019 at 10:58 AM > *To: *Dominick Baier > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Thanks for the input, Dominick. > > > > I'd said previously that I was having trouble adequately gauging whether > or not there's sufficient consensus to go ahead with the update. I was ev= en > thinking of asking the chairs about a consensus call during the office > hours meeting yesterday. But it got canceled. And looking again back over > the discussion, I don't believe a consensus call is necessary. There's be= en > a lot of general discussion over the last several weeks during which > several folks have stated support for the proposal while there's been onl= y > one voice of direct dissent. That seems like rough enough consensus and, = as > such, I plan to make the change in the next revision of the document (whi= ch > should be done soon). Chairs, please let me know, if you believe the > situation warrants a different course of action. > > > > > > > > On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier > wrote: > > IMHO that=E2=80=99s a reasonable and pragmatic option. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 11. February 2019 at 13:26:37, Brian Campbell ( > bcampbell@pingidentity.com) wrote: > > It's been pointed out that the potential issue is not isolated to the jus= t > token endpoint but that revocation, introspection, etc. could be impacted > as well. So, at this point, the proposal on the table is to add a new > optional AS metadata parameter named 'mtls_endpoints' that's value we be = a > JSON object which itself contains endpoints that, when present, a client > doing MTLS would use rather than the regular endpoints. A straw-man > example might look like this > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token > ", > "userinfo_endpoint":"https://mtls.example.com/userinfo > ", > "revocation_endpoint":"https://mtls.example.com/revo > " }* > } > > > > A client doing MTLS would look for and give precedence to an endpoint > under "mtls_endpoints" while falling back to use the normal endpoint from > the top level of metadata when/if its not in "mtls_endpoints". > > > The idea being that "regular" clients (those not doing MTLS) will use the > regular endpoints. And only the host/port of the endpoints listed in > mtls_endpoints will be set up to request TLS client certificates during > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > > > I'm struggling, however, to adequately gauge whether or not there's > sufficient consensus to go ahead with the update. There's been some suppo= rt > for it voiced. As well as talk of other approaches that could be > alternatives or additional measures. And also some vocal opposition to it= . > > > > > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > wrote: > > We are currently implementing MTLS in IdentityServer. > > > > Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had > clients in the wild that assumed that all the properties in the JSON obje= ct > returned from our userinfo endpoint were scalar strings. This broke when = we > introduced a new property whose value was a JSON object. It was a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Wednesday, February 6, 2019 at 11:30 AM > *To:* "Richard Backman, Annabelle" > *Cc:* "Richard Backman, Annabelle" , oauth < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > And I'm honestly really struggling to see what could have gone wrong with > or how token_endpoint_auth_methods broke something with the user info > endpoint. If you have the time and/or it'd be informative to this here > little discussion, please explain that one a bit more. > > > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > wrote: > > "far" should have said "fair" in the previous message > > > > > > > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Monday, February 4, 2019 at 5:28 AM > *To:* "Richard Backman, Annabelle" > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Friday, February 1, 2019 at 3:17 PM > *To:* "Richard Backman, Annabelle" > *Cc:* George Fletcher , oauth > *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Friday, February 1, 2019 at 1:31 PM > *To:* George Fletcher <40aol.com@dmarc.......ietf.org>> > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* ______________________________________________= _ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000001536e90581c4caee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
=C2=A0
Additionally, a metadata document that omits token_endpo= int in favor of mtls_endpoints since only mTLS is supported would violate 8= 414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the impli= cit grant type is supported.=E2=80=9D

mtls only AS doesn= 9;t get anything out of using mtls_endpoints, its use should not be recomme= nded for such AS and regular endpoints will be used, this satisfies the req= uirement

Here is o= ne example, based on my understanding of the =E2=80=9Cstraw man=E2=80=9D fo= rmat presented in this thread: RFC8414 defines the value of token_endpoint_= auth_methods_supported as a =E2=80=9CJSON array containing a list of client= authentication methods supported by this token endpoint.=E2=80=9D If that = array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified= in token_endpoint does not support mTLS, then that metadata violates 8414.= You could address this by adding a token_endpoint_auth_methods_supported p= arameter to the mtls_endpoints object, and likewise for the other endpoints= and auth methods. If you take that to its logical conclusion, you end up w= ith a complete metadata document hanging off of mtls_endpoints. It=E2=80=99= s that line of thought that led me to suggest just pointing to an alternate= document.

Assuming we go with using the same root auth met= hods property, what's the issue? Clients not having mtls capabilities w= on't care about the additional method members being present. Clients th= at do implement mtls by the specification will know to look for mtls_endpoi= nts and fall back to regular ones if the specific endpoint or mtls_endpoint= s root property is not present.

I gave `mtls_alternate_m= etadata` route a thought and don't see how it helps, given the two abov= e are non-issues (my $.02) another discovery document only brings more of t= hem since every property can now be different, not just the endpoints.
<= div dir=3D"ltr">
S pozdravem,<= br>Filip Skokan


=
On Wed, 13 Feb 2019 at 00:00, Richard= Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of th= e =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 defi= nes the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON a= rray containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_clien= t_auth=E2=80=9D and the endpoint specified in token_endpoint does not suppo= rt mTLS, then that metadata violates 8414. You could address this by adding= a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth metho= ds. If you take that to its logical conclusion, you end up with a complete = metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of = thought that led me to suggest just pointing to an alternate document.

=C2=A0

Additionally, a metadata document that omits token_e= ndpoint in favor of mtls_endpoints since only mTLS is supported would viola= te 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the i= mplicit grant type is supported.=E2=80=9D

=C2=A0

It is possible to define the mtls_endpoints paramete= r such that the above use cases are invalid, but that does make the documen= t more complicated. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D = route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >, oauth <oauth@i= etf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery=

=C2=A0

Hi Annabelle,

=C2=A0

can you elaborate what would be the violation / nega= tive impact of usage of RFC8414?

=C2=A0

As it already makes use of `signed_metadata` and thi= s language is present ...

=C2=A0

>=C2=A0Consumers of the metadata MAY ignore the s= igned metadata if they do not support this feature.=C2=A0 If the consumer o= f the metadata supports signed metadata, metadata values conveyed in the si= gned metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

=C2=A0

... would mtls_endpoints be any different? Clients a= re free to ignore this if they don't support/use mtls, and if they do t= hose values must take precedence over the root ones. the use of mtls_endpoi= nts would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. = token_endpoint remains required for all intents and purposes. And as for th= e usable client authentication methods - they should all be listed, or do y= ou think we should separate the ones for each hostname/port location? To what end? Is there a risk having = the mtls hostname/port accepting regular requests? Other then secret/key _j= wt auth methods assertion aud claim the endpoint location doesn't play = a role in the authentication process.


Best,
Filip

=C2=A0

=C2=A0

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annab= elle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata ch= ange, if the scenario is relevant and other approaches can=E2=80=99t adequa= tely address it =E2=80=93 and I=E2=80=99ll readily grant that we probably d= on=E2=80=99t want to depend on consistency of browser behavior at the intersection of client= certificates and Access-Control-Allow-Credentials. But care needs to be ta= ken in designing that metadata to avoid violating or otherwise negatively i= mpacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtl= s_endpoints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alte= rnate_metadata=E2=80=9D parameter whose value is the URL of an alternate me= tadata document intended for clients using mTLS. An mTLS-optional AS could have t= wo different metadata documents for mTLS and non-mTLS clients, reducing the= mTLS-optional scenario to the mTLS-only scenario. This sidesteps the chall= enges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in= RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery=

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble ad= equately gauging whether or not there's sufficient consensus to go ahea= d with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it g= ot canceled. And looking again back over the discussion, I don't believ= e a consensus call is necessary. There's been a lot of general discussi= on over the last several weeks during which several folks have stated support for the proposal while there's been = only one voice of direct dissent. That seems like rough enough consensus an= d, as such, I plan to make the change in the next revision of the document = (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different cour= se of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <= dbaier@least= privilege.com> wrote:

IMHO that=E2=80=99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrot= e:

It's been pointed o= ut that the potential issue is not isolated to the just token endpoint but = that revocation, introspection, etc. could be impacted as well. So,=C2=A0 a= t this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtl= s_endpoints' that's value we be a JSON object which itself contains= endpoints that, when present, a client doing MTLS would use rather than th= e regular endpoints.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"clie= nt_secret_basic","tls_client_auth", "none"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo&qu= ot;
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give preceden= ce to an endpoint under "mtls_endpoints" while falling back to us= e the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will= use the regular endpoints. And only the host/port of the endpoints listed = in mtls_endpoints will be set up to request TLS client certificates during = handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided = for all the other regular clients that are not going to do MTLS - including= and most importantly in-browser javascript clients where there can be less= than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whe= ther or not there's sufficient consensus to go ahead with the update. T= here's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And al= so some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastpr= ivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.=

=C2=A0

Our approach will be that we=E2=80=99ll offer a separate token endpoint th= at supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_en= dpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And= it is indeed a good reminder that even a seemingly innocuous change that s= hould be backwards compatible can break things unexpectedly..=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Anna= belle <richanna= @amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that = all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose va= lue was a JSON object. It was a good reminder that even a seemingly innocuo= us change that should be backwards compatible can force more work on client= s than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pingidentity.c= om>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what c= ould have gone wrong with or how token_endpoint_auth_methods broke somethin= g with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain tha= t one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pin= gidentity.com> wrote:

It may well be due to my own intellectual shortcomin= gs but these issues/questions/confusion-points are not resonating for me as= being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being he= ard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /u>

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless o= nly the implicit grant type is supported.=E2=80=9D So what does the mTLS-on= ly AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier= is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question.
  4. This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98= =83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed h= ere sufficiently deals with the fallout from that. In my view this is a com= plex enough issue and it=E2=80=99s for a nuanced enough use case (as far as= I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization S= erver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the d= oor.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:<= u>

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:<= /u>

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.

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

--0000000000001536e90581c4caee-- From nobody Wed Feb 13 04:18:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A043128CB7 for ; Wed, 13 Feb 2019 04:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V--eG1hfk3dB for ; Wed, 13 Feb 2019 04:18:36 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB37130DCB for ; Wed, 13 Feb 2019 04:18:31 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id a48so2260206qtb.4 for ; Wed, 13 Feb 2019 04:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=NGBcpKZf8GoaIlOJ9w+JsoeBB8K6x6uDJTfRmFf9ysI=; b=Yz7njkTHzgjom0tL6xc1lvHQaBialPlY2iYMyKe9THqYf2gL95q8cpbMzJlUfWEzPr 3ndr8IFyPU/2QvxGtWfUIynSiZSDIPNY9atS//MXD7fEXr8IsaYbw19esTMvqIXpR4ds DaMdtfdhw7YwcgxtbfNvn5NEMiVsve2ViNbB6dX53CuGjZG3vJtjfDRoTXGAnJUwDahy jd45B7/hyx/z6GNy3pdROor8ltOuUdlg0IzN8hx7qzKt8QnIasmsHZHUgegP8InqUo5s ZP3WdqBjRlA2fxo3NFlhcfxDxLC8PGMu2HCqM63EiuMUc59KT2PO6zjqKwJQDrTNU7uw GV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=NGBcpKZf8GoaIlOJ9w+JsoeBB8K6x6uDJTfRmFf9ysI=; b=Tw1dug4Uul/g6bCQ8atnmFARMIwyA3RTh5gPpnuiQM2/Uv3ec7A01ixqEuudL0Qmka xn8czAcwpwyVJ9yWh+eMWe8UsLy8aBjEfkxcTOn0kn3AKnpuxXFPJS7zCI7sY3hIsnzk C9vGJ4EuTL7E4l5xkrayuv6+zbfVk8n91sgLivKREWjFu+imTp/fotrS5sfY+11Q7ZJ5 0iu1awPqnNYKxGcFotElLYaioLJQ0sYFW0vuyQd/wSkQr09BbRZ7XuF7wjY+QnpMH1iZ sLWtOhIHsA/t3FuEgLI8ye6BLJ37Pl4NT97MVStAqW/eB9sJmq2vxdZNwNGBKJQgNfkk 5Fuw== X-Gm-Message-State: AHQUAuaHbRx7hOmBeqHmAUtcM4cZEyJJ5szLc9ss7Ayrbrcu8ZWmW6ox WuzCHfp6a3hjZp7+Jyx6NCgG3GQOgeHhR/wu95wW X-Google-Smtp-Source: AHgI3IaT9k3zhusOVThgkeDD+fCvhecPwPpZ9wXqSnePbAwh9baYHMyzZRE1ZlHPKq3vc7tBrDDQXiW+n9HB+2hB6bs= X-Received: by 2002:ac8:649:: with SMTP id e9mr182849qth.178.1550060309772; Wed, 13 Feb 2019 04:18:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 04:18:29 -0800 From: Dominick Baier In-Reply-To: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> MIME-Version: 1.0 Date: Wed, 13 Feb 2019 04:18:29 -0800 Message-ID: To: "Richard Backman, Annabelle" , Filip Skokan Cc: Brian Campbell , "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="0000000000002506fd0581c58a16" Archived-At: Subject: Re: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 12:18:41 -0000 --0000000000002506fd0581c58a16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am for keeping it simple and not introducing another link to follow. I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;) =E2=80=94=E2=80=94=E2=80=94 Dominick On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote: Hello, > Additionally, a metadata document that omits token_endpoint in favor of > mtls_endpoints since only mTLS is supported would violate 8414, as 8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is > supported.=E2=80=9D mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format > presented in this thread: RFC8414 defines the value of > token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing= a list of > client authentication methods supported by this token endpoint.=E2=80=9D = If that > array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specifi= ed in > token_endpoint does not support mTLS, then that metadata violates 8414. Y= ou > could address this by adding a token_endpoint_auth_methods_supported > parameter to the mtls_endpoints object, and likewise for the other > endpoints and auth methods. If you take that to its logical conclusion, y= ou > end up with a complete metadata document hanging off of mtls_endpoints. > It=E2=80=99s that line of thought that led me to suggest just pointing to= an > alternate document. Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present. I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints. S pozdravem, *Filip Skokan* On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle < richanna@amazon.com> wrote: > Here is one example, based on my understanding of the =E2=80=9Cstraw man= =E2=80=9D format > presented in this thread: RFC8414 defines the value of > token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing= a list of > client authentication methods supported by this token endpoint.=E2=80=9D = If that > array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specifi= ed in > token_endpoint does not support mTLS, then that metadata violates 8414. Y= ou > could address this by adding a token_endpoint_auth_methods_supported > parameter to the mtls_endpoints object, and likewise for the other > endpoints and auth methods. If you take that to its logical conclusion, y= ou > end up with a complete metadata document hanging off of mtls_endpoints. > It=E2=80=99s that line of thought that led me to suggest just pointing to= an > alternate document. > > > > Additionally, a metadata document that omits token_endpoint in favor of > mtls_endpoints since only mTLS is supported would violate 8414, as 8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is > supported.=E2=80=9D > > > > It is possible to define the mtls_endpoints parameter such that the above > use cases are invalid, but that does make the document more complicated. = If > we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip pa= st all of these > issues, because it brings us back to just parsing the same metadata that = we > do today. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Filip Skokan < > panva.ip@gmail.com> > *Date:* Tuesday, February 12, 2019 at 1:13 PM > *To:* "Richard Backman, Annabelle" > *Cc:* Brian Campbell , oau= th > > *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Hi Annabelle, > > > > can you elaborate what would be the violation / negative impact of usage > of RFC8414? > > > > As it already makes use of `signed_metadata` and this language is present > ... > > > > > Consumers of the metadata MAY ignore the signed metadata if they do not > support this feature. If the consumer of the metadata supports signed > metadata, metadata values conveyed in the signed metadata MUST take > precedence over the corresponding values conveyed using plain JSON elemen= ts. > > > > ... would mtls_endpoints be any different? Clients are free to ignore thi= s > if they don't support/use mtls, and if they do those values must take > precedence over the root ones. the use of mtls_endpoints would not be > recommended for mtls-only AS but recommended for one with both mtls/regul= ar > authentication methods. token_endpoint remains required for all intents a= nd > purposes. And as for the usable client authentication methods - they shou= ld > all be listed, or do you think we should separate the ones for each > hostname/port location? To what end? Is there a risk having the mtls > hostname/port accepting regular requests? Other then secret/key _jwt auth > methods assertion aud claim the endpoint location doesn't play a role in > the authentication process. > > > Best, > *Filip* > > > > > > On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > I=E2=80=99m not opposed to introducing a metadata change, if the scenario= is > relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll > readily grant that we probably don=E2=80=99t want to depend on consistenc= y of > browser behavior at the intersection of client certificates and > Access-Control-Allow-Credentials. But care needs to be taken in designing > that metadata to avoid violating or otherwise negatively impacting usage = of > RFC8414. > > > > Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D = metadata > parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D para= meter whose value > is the URL of an alternate metadata document intended for clients using > mTLS. An mTLS-optional AS could have two different metadata documents for > mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the > mTLS-only scenario. This sidesteps the challenges of aligning the > =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the r= igid parameter > definitions in RFC8414 (see: token_endpoint, > token_endpoint_auth_methods_supported). > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Tuesday, February 12, 2019 at 10:58 AM > *To:* Dominick Baier > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Thanks for the input, Dominick. > > > > I'd said previously that I was having trouble adequately gauging whether > or not there's sufficient consensus to go ahead with the update. I was ev= en > thinking of asking the chairs about a consensus call during the office > hours meeting yesterday. But it got canceled. And looking again back over > the discussion, I don't believe a consensus call is necessary. There's be= en > a lot of general discussion over the last several weeks during which > several folks have stated support for the proposal while there's been onl= y > one voice of direct dissent. That seems like rough enough consensus and, = as > such, I plan to make the change in the next revision of the document (whi= ch > should be done soon). Chairs, please let me know, if you believe the > situation warrants a different course of action. > > > > > > > > On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier > wrote: > > IMHO that=E2=80=99s a reasonable and pragmatic option. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 11. February 2019 at 13:26:37, Brian Campbell ( > bcampbell@pingidentity.com) wrote: > > It's been pointed out that the potential issue is not isolated to the jus= t > token endpoint but that revocation, introspection, etc. could be impacted > as well. So, at this point, the proposal on the table is to add a new > optional AS metadata parameter named 'mtls_endpoints' that's value we be = a > JSON object which itself contains endpoints that, when present, a client > doing MTLS would use rather than the regular endpoints. A straw-man > example might look like this > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token > ", > "userinfo_endpoint":"https://mtls.example.com/userinfo > ", > "revocation_endpoint":"https://mtls.example.com/revo > " }* > } > > > > A client doing MTLS would look for and give precedence to an endpoint > under "mtls_endpoints" while falling back to use the normal endpoint from > the top level of metadata when/if its not in "mtls_endpoints". > > > The idea being that "regular" clients (those not doing MTLS) will use the > regular endpoints. And only the host/port of the endpoints listed in > mtls_endpoints will be set up to request TLS client certificates during > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > > > I'm struggling, however, to adequately gauge whether or not there's > sufficient consensus to go ahead with the update. There's been some suppo= rt > for it voiced. As well as talk of other approaches that could be > alternatives or additional measures. And also some vocal opposition to it= . > > > > > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > wrote: > > We are currently implementing MTLS in IdentityServer. > > > > Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had > clients in the wild that assumed that all the properties in the JSON obje= ct > returned from our userinfo endpoint were scalar strings. This broke when = we > introduced a new property whose value was a JSON object. It was a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Wednesday, February 6, 2019 at 11:30 AM > *To:* "Richard Backman, Annabelle" > *Cc:* "Richard Backman, Annabelle" , oauth < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > And I'm honestly really struggling to see what could have gone wrong with > or how token_endpoint_auth_methods broke something with the user info > endpoint. If you have the time and/or it'd be informative to this here > little discussion, please explain that one a bit more. > > > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > wrote: > > "far" should have said "fair" in the previous message > > > > > > > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Monday, February 4, 2019 at 5:28 AM > *To:* "Richard Backman, Annabelle" > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Friday, February 1, 2019 at 3:17 PM > *To:* "Richard Backman, Annabelle" > *Cc:* George Fletcher , oauth > *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf...org>> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Friday, February 1, 2019 at 1:31 PM > *To:* George Fletcher <40aol.com@dmarc........ietf.org>> > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* ______________________________________________= _ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000002506fd0581c58a16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I am= for keeping it simple and not introducing another link to follow.

I sometimes wonder how many= of the spec authors are actually developers - these suggestions make softw= are unnecessary complex ;)

=E2=80= =94=E2=80=94=E2=80=94
Dominick

= On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,
=C2=A0
Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2=80=9D= and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to an alternate document.

Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.

S pozdravem,
Filip Skokan


On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414= defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_au= th=E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to an alternate document.

=C2=A0

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

=C2=A0

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past all of th= ese issues, because it brings us back to just parsing the same metadata that we do today.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Filip Skokan <panva.ip@gmail.= com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >, oauth <oauth@ietf.org&= gt;
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

Hi Annabelle,

=C2=A0

can you elaborate what would be the violation / negative impact of usage of RFC8414?

=C2=A0

As it already makes use of `signed_metadata` and this language is present ...

=C2=A0

>=C2=A0Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.=C2=A0 If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

=C2=A0

... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

=C2=A0

=C2=A0

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can=E2=80=99t adequately address it =E2=80=93 and I=E2=80=99ll readily grant that we prob= ably don=E2=80=99t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D parameter whose value is the URL = of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the= rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <db= aier@leastprivilege.com> wrote:

IMHO that=E2=80=99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrot= e:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,=C2=A0 at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"client_secret_basic","tls_client_auth", "no= ne"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo&q= uot;
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling ba= ck to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@l= eastprivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

=C2=A0

Our approach will be that we=E2=80=99ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pin= gidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discus= sed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" an= d just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.t= onge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--0000000000002506fd0581c58a16-- From nobody Wed Feb 13 11:39:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5021C1200B3 for ; Wed, 13 Feb 2019 11:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-DLqnzI8gN1 for ; Wed, 13 Feb 2019 11:39:17 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7775E12E036 for ; Wed, 13 Feb 2019 11:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1550086756; x=1581622756; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cm4Zfa5Xhtv0VFG0sxEYETgcKYMglWT11MTz8Xj1awc=; b=oo7erRL++wHbih/N9DLacBjjcX3PL+A+SqyIN+2cvWQmX2n580bON1kD 2zfzhYLg0xPzF3f4lJ7KeJDmQLX6KIERgm5kz82bP5TAnD/xyBG/WWCdu PhaytVFNch7xwwHgG0cIp9wKK8WNMngs/zBEkFL70WZ4JWSpsvIdOtSpi A=; X-IronPort-AV: E=Sophos;i="5.58,366,1544486400"; d="scan'208,217";a="787536632" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2b-baacba05.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2019 19:39:13 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2b-baacba05.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id x1DJdCr0025813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Feb 2019 19:39:12 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 13 Feb 2019 19:39:12 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 13 Feb 2019 19:39:11 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 13 Feb 2019 19:39:11 +0000 From: "Richard Backman, Annabelle" To: Dominick Baier , Filip Skokan CC: Brian Campbell , oauth Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery Thread-Index: AQHUwF+tRWyMOv1EVkK3Bn3jwrq7jqXaiS+AgAEmvgCAANjXAP//h9UAgACdzQD//5gngIABVhoAgAAPDoD///UGAA== Date: Wed, 13 Feb 2019 19:39:11 +0000 Message-ID: <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.36] Content-Type: multipart/alternative; boundary="_000_141CD215A86A49269FD6F58DD966F40Famazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 19:39:23 -0000 --_000_141CD215A86A49269FD6F58DD966F40Famazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGlzc3VlIGlzIHRoYXQgdGhlIHByb3Bvc2FsIHZpb2xhdGVzIHRoZSBzdGFuZGFyZCBieSBj aGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIGEgcGFyYW1ldGVyIGl0IGRlZmluZXMuIFdlIHNob3Vs ZCBiZSB2ZXJ5LCB2ZXJ5LCBWRVJZIGNhcmVmdWwgYWJvdXQgdGVsbGluZyBpbXBsZW1lbnRlcnMg dG8gdmlvbGF0ZSBhbiBleGlzdGluZyBzdGFuZGFyZC4gVGhpcyBjaGFuZ2UgbWlnaHQgcHJvdmUg aW5jb21wYXRpYmxlIHdpdGggZXhpc3Rpbmcgb3IgZnV0dXJlIGltcGxlbWVudGF0aW9ucyBvZiA4 NDE0LCBpdCBtaWdodCBub3QsIGJ1dCBieSB2aW9sYXRpbmcgdGhlIHN0YW5kYXJkIHRoZSBwcm9w b3NhbCBjcmVhdGVzIGFuIG9wcG9ydHVuaXR5IGZvciBpbmNvbXBhdGliaWxpdHkgdGhhdCBkaWRu 4oCZdCBleGlzdCBiZWZvcmUuDQoNCkFzIGZhciBhcyBzaW1wbGljaXR5IGlzIGNvbmNlcm5lZCwg SSBmaW5kIGEgc29sdXRpb24gdGhhdCByZXVzZXMgdGhlIGV4aXN0aW5nIGRhdGEgbW9kZWwgYW5k IG5hdHVyYWxseSBzdXBwb3J0cyBleGlzdGluZyBhbmQgZnV0dXJlIGV4dGVuc2lvbnMgdG8gYmUg ZmFyIHNpbXBsZXIgdGhhbiBvbmUgdGhhdCBpbnRyb2R1Y2VzIGFtYmlndW91cyBzZW1hbnRpY3Mg dG8gZXhpc3RpbmcgcGFyYW1ldGVycy4gR2VuZXJhbGx5IHNwZWFraW5nLCBkYXRhIG1vZGVscyB3 aXRoIHByb3BlcnRpZXMgdGhhdCBtZWFuIGRpZmZlcmVudCB0aGluZ3MgaW4gZGlmZmVyZW50IGNv bnRleHRzIHRlbmQgdG8gYmUgZnJhZ2lsZSBhbmQgcmVxdWlyZSBtb3JlIGNvbXBsZXggY29kZSB0 byB3b3JrIHdpdGguIEJ1dCB0aGF04oCZcyBqdXN0IG15IGV4cGVyaWVuY2UgYXMsIHlvdSBrbm93 LCBhbiBhY3R1YWwgZGV2ZWxvcGVyLg0KDQpMZXTigJlzIGtlZXAgdGhlIGFzc3VtcHRpb25zIGFu ZCBzbmlkZSByZW1hcmtzIGFib3V0IG90aGVyc+KAmSBiYWNrZ3JvdW5kcyBvZmYgdGhlIGxpc3Qs IHBsZWFzZS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0K DQoNCkZyb206IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPg0KRGF0 ZTogV2VkbmVzZGF5LCBGZWJydWFyeSAxMywgMjAxOSBhdCA0OjE4IEFNDQpUbzogIlJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbT4sIEZpbGlwIFNrb2thbiA8 cGFudmEuaXBAZ21haWwuY29tPg0KQ2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbT4sICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpv bi5jb20+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVU5WRVJJRklFRCBTRU5E RVJdIFJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2NvdmVyeQ0KDQpJIGFt IGZvciBrZWVwaW5nIGl0IHNpbXBsZSBhbmQgbm90IGludHJvZHVjaW5nIGFub3RoZXIgbGluayB0 byBmb2xsb3cuDQoNCkkgc29tZXRpbWVzIHdvbmRlciBob3cgbWFueSBvZiB0aGUgc3BlYyBhdXRo b3JzIGFyZSBhY3R1YWxseSBkZXZlbG9wZXJzIC0gdGhlc2Ugc3VnZ2VzdGlvbnMgbWFrZSBzb2Z0 d2FyZSB1bm5lY2Vzc2FyeSBjb21wbGV4IDspDQoNCuKAlOKAlOKAlA0KRG9taW5pY2sNCg0KDQpP biAxMy4gRmVicnVhcnkgMjAxOSBhdCAxMjoyNToxMywgRmlsaXAgU2tva2FuIChwYW52YS5pcEBn bWFpbC5jb208bWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbT4pIHdyb3RlOg0KSGVsbG8sDQoNCkFk ZGl0aW9uYWxseSwgYSBtZXRhZGF0YSBkb2N1bWVudCB0aGF0IG9taXRzIHRva2VuX2VuZHBvaW50 IGluIGZhdm9yIG9mIG10bHNfZW5kcG9pbnRzIHNpbmNlIG9ubHkgbVRMUyBpcyBzdXBwb3J0ZWQg d291bGQgdmlvbGF0ZSA4NDE0LCBhcyA4NDE0IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVR VUlSRUQgdW5sZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKA nQ0KDQptdGxzIG9ubHkgQVMgZG9lc24ndCBnZXQgYW55dGhpbmcgb3V0IG9mIHVzaW5nIG10bHNf ZW5kcG9pbnRzLCBpdHMgdXNlIHNob3VsZCBub3QgYmUgcmVjb21tZW5kZWQgZm9yIHN1Y2ggQVMg YW5kIHJlZ3VsYXIgZW5kcG9pbnRzIHdpbGwgYmUgdXNlZCwgdGhpcyBzYXRpc2ZpZXMgdGhlIHJl cXVpcmVtZW50DQpIZXJlIGlzIG9uZSBleGFtcGxlLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5n IG9mIHRoZSDigJxzdHJhdyBtYW7igJ0gZm9ybWF0IHByZXNlbnRlZCBpbiB0aGlzIHRocmVhZDog UkZDODQxNCBkZWZpbmVzIHRoZSB2YWx1ZSBvZiB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNf c3VwcG9ydGVkIGFzIGEg4oCcSlNPTiBhcnJheSBjb250YWluaW5nIGEgbGlzdCBvZiBjbGllbnQg YXV0aGVudGljYXRpb24gbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhpcyB0b2tlbiBlbmRwb2ludC7i gJ0gSWYgdGhhdCBhcnJheSBjb250YWlucyDigJx0bHNfY2xpZW50X2F1dGjigJ0gYW5kIHRoZSBl bmRwb2ludCBzcGVjaWZpZWQgaW4gdG9rZW5fZW5kcG9pbnQgZG9lcyBub3Qgc3VwcG9ydCBtVExT LCB0aGVuIHRoYXQgbWV0YWRhdGEgdmlvbGF0ZXMgODQxNC4gWW91IGNvdWxkIGFkZHJlc3MgdGhp cyBieSBhZGRpbmcgYSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIHBhcmFt ZXRlciB0byB0aGUgbXRsc19lbmRwb2ludHMgb2JqZWN0LCBhbmQgbGlrZXdpc2UgZm9yIHRoZSBv dGhlciBlbmRwb2ludHMgYW5kIGF1dGggbWV0aG9kcy4gSWYgeW91IHRha2UgdGhhdCB0byBpdHMg bG9naWNhbCBjb25jbHVzaW9uLCB5b3UgZW5kIHVwIHdpdGggYSBjb21wbGV0ZSBtZXRhZGF0YSBk b2N1bWVudCBoYW5naW5nIG9mZiBvZiBtdGxzX2VuZHBvaW50cy4gSXTigJlzIHRoYXQgbGluZSBv ZiB0aG91Z2h0IHRoYXQgbGVkIG1lIHRvIHN1Z2dlc3QganVzdCBwb2ludGluZyB0byBhbiBhbHRl cm5hdGUgZG9jdW1lbnQuDQoNCkFzc3VtaW5nIHdlIGdvIHdpdGggdXNpbmcgdGhlIHNhbWUgcm9v dCBhdXRoIG1ldGhvZHMgcHJvcGVydHksIHdoYXQncyB0aGUgaXNzdWU/IENsaWVudHMgbm90IGhh dmluZyBtdGxzIGNhcGFiaWxpdGllcyB3b24ndCBjYXJlIGFib3V0IHRoZSBhZGRpdGlvbmFsIG1l dGhvZCBtZW1iZXJzIGJlaW5nIHByZXNlbnQuIENsaWVudHMgdGhhdCBkbyBpbXBsZW1lbnQgbXRs cyBieSB0aGUgc3BlY2lmaWNhdGlvbiB3aWxsIGtub3cgdG8gbG9vayBmb3IgbXRsc19lbmRwb2lu dHMgYW5kIGZhbGwgYmFjayB0byByZWd1bGFyIG9uZXMgaWYgdGhlIHNwZWNpZmljIGVuZHBvaW50 IG9yIG10bHNfZW5kcG9pbnRzIHJvb3QgcHJvcGVydHkgaXMgbm90IHByZXNlbnQuDQoNCkkgZ2F2 ZSBgbXRsc19hbHRlcm5hdGVfbWV0YWRhdGFgIHJvdXRlIGEgdGhvdWdodCBhbmQgZG9uJ3Qgc2Vl IGhvdyBpdCBoZWxwcywgZ2l2ZW4gdGhlIHR3byBhYm92ZSBhcmUgbm9uLWlzc3VlcyAobXkgJC4w MikgYW5vdGhlciBkaXNjb3ZlcnkgZG9jdW1lbnQgb25seSBicmluZ3MgbW9yZSBvZiB0aGVtIHNp bmNlIGV2ZXJ5IHByb3BlcnR5IGNhbiBub3cgYmUgZGlmZmVyZW50LCBub3QganVzdCB0aGUgZW5k cG9pbnRzLg0KDQpTIHBvemRyYXZlbSwNCkZpbGlwIFNrb2thbg0KDQoNCk9uIFdlZCwgMTMgRmVi IDIwMTkgYXQgMDA6MDAsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6 b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQpIZXJlIGlzIG9uZSBl eGFtcGxlLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSDigJxzdHJhdyBtYW7igJ0g Zm9ybWF0IHByZXNlbnRlZCBpbiB0aGlzIHRocmVhZDogUkZDODQxNCBkZWZpbmVzIHRoZSB2YWx1 ZSBvZiB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIGFzIGEg4oCcSlNPTiBh cnJheSBjb250YWluaW5nIGEgbGlzdCBvZiBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBz dXBwb3J0ZWQgYnkgdGhpcyB0b2tlbiBlbmRwb2ludC7igJ0gSWYgdGhhdCBhcnJheSBjb250YWlu cyDigJx0bHNfY2xpZW50X2F1dGjigJ0gYW5kIHRoZSBlbmRwb2ludCBzcGVjaWZpZWQgaW4gdG9r ZW5fZW5kcG9pbnQgZG9lcyBub3Qgc3VwcG9ydCBtVExTLCB0aGVuIHRoYXQgbWV0YWRhdGEgdmlv bGF0ZXMgODQxNC4gWW91IGNvdWxkIGFkZHJlc3MgdGhpcyBieSBhZGRpbmcgYSB0b2tlbl9lbmRw b2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIHBhcmFtZXRlciB0byB0aGUgbXRsc19lbmRwb2lu dHMgb2JqZWN0LCBhbmQgbGlrZXdpc2UgZm9yIHRoZSBvdGhlciBlbmRwb2ludHMgYW5kIGF1dGgg bWV0aG9kcy4gSWYgeW91IHRha2UgdGhhdCB0byBpdHMgbG9naWNhbCBjb25jbHVzaW9uLCB5b3Ug ZW5kIHVwIHdpdGggYSBjb21wbGV0ZSBtZXRhZGF0YSBkb2N1bWVudCBoYW5naW5nIG9mZiBvZiBt dGxzX2VuZHBvaW50cy4gSXTigJlzIHRoYXQgbGluZSBvZiB0aG91Z2h0IHRoYXQgbGVkIG1lIHRv IHN1Z2dlc3QganVzdCBwb2ludGluZyB0byBhbiBhbHRlcm5hdGUgZG9jdW1lbnQuDQoNCkFkZGl0 aW9uYWxseSwgYSBtZXRhZGF0YSBkb2N1bWVudCB0aGF0IG9taXRzIHRva2VuX2VuZHBvaW50IGlu IGZhdm9yIG9mIG10bHNfZW5kcG9pbnRzIHNpbmNlIG9ubHkgbVRMUyBpcyBzdXBwb3J0ZWQgd291 bGQgdmlvbGF0ZSA4NDE0LCBhcyA4NDE0IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlS RUQgdW5sZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKAnQ0K DQpJdCBpcyBwb3NzaWJsZSB0byBkZWZpbmUgdGhlIG10bHNfZW5kcG9pbnRzIHBhcmFtZXRlciBz dWNoIHRoYXQgdGhlIGFib3ZlIHVzZSBjYXNlcyBhcmUgaW52YWxpZCwgYnV0IHRoYXQgZG9lcyBt YWtlIHRoZSBkb2N1bWVudCBtb3JlIGNvbXBsaWNhdGVkLiBJZiB3ZSBnbyB0aGUg4oCcbXRsc19h bHRlcm5hdGVfbWV0YWRhdGHigJ0gcm91dGUsIHdlIGNhbiBza2lwIHBhc3QgYWxsIG9mIHRoZXNl IGlzc3VlcywgYmVjYXVzZSBpdCBicmluZ3MgdXMgYmFjayB0byBqdXN0IHBhcnNpbmcgdGhlIHNh bWUgbWV0YWRhdGEgdGhhdCB3ZSBkbyB0b2RheS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEZpbGlwIFNr b2thbiA8cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20+Pg0KRGF0 ZTogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQgMToxMyBQTQ0KVG86ICJSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5n aWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWls dG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTVRMUyB0b2tlbiBl bmRvaW50ICYgZGlzY292ZXJ5DQoNCkhpIEFubmFiZWxsZSwNCg0KY2FuIHlvdSBlbGFib3JhdGUg d2hhdCB3b3VsZCBiZSB0aGUgdmlvbGF0aW9uIC8gbmVnYXRpdmUgaW1wYWN0IG9mIHVzYWdlIG9m IFJGQzg0MTQ/DQoNCkFzIGl0IGFscmVhZHkgbWFrZXMgdXNlIG9mIGBzaWduZWRfbWV0YWRhdGFg IGFuZCB0aGlzIGxhbmd1YWdlIGlzIHByZXNlbnQgLi4uDQoNCj4gQ29uc3VtZXJzIG9mIHRoZSBt ZXRhZGF0YSBNQVkgaWdub3JlIHRoZSBzaWduZWQgbWV0YWRhdGEgaWYgdGhleSBkbyBub3Qgc3Vw cG9ydCB0aGlzIGZlYXR1cmUuICBJZiB0aGUgY29uc3VtZXIgb2YgdGhlIG1ldGFkYXRhIHN1cHBv cnRzIHNpZ25lZCBtZXRhZGF0YSwgbWV0YWRhdGEgdmFsdWVzIGNvbnZleWVkIGluIHRoZSBzaWdu ZWQgbWV0YWRhdGEgTVVTVCB0YWtlIHByZWNlZGVuY2Ugb3ZlciB0aGUgY29ycmVzcG9uZGluZyB2 YWx1ZXMgY29udmV5ZWQgdXNpbmcgcGxhaW4gSlNPTiBlbGVtZW50cy4NCg0KLi4uIHdvdWxkIG10 bHNfZW5kcG9pbnRzIGJlIGFueSBkaWZmZXJlbnQ/IENsaWVudHMgYXJlIGZyZWUgdG8gaWdub3Jl IHRoaXMgaWYgdGhleSBkb24ndCBzdXBwb3J0L3VzZSBtdGxzLCBhbmQgaWYgdGhleSBkbyB0aG9z ZSB2YWx1ZXMgbXVzdCB0YWtlIHByZWNlZGVuY2Ugb3ZlciB0aGUgcm9vdCBvbmVzLiB0aGUgdXNl IG9mIG10bHNfZW5kcG9pbnRzIHdvdWxkIG5vdCBiZSByZWNvbW1lbmRlZCBmb3IgbXRscy1vbmx5 IEFTIGJ1dCByZWNvbW1lbmRlZCBmb3Igb25lIHdpdGggYm90aCBtdGxzL3JlZ3VsYXIgYXV0aGVu dGljYXRpb24gbWV0aG9kcy4gdG9rZW5fZW5kcG9pbnQgcmVtYWlucyByZXF1aXJlZCBmb3IgYWxs IGludGVudHMgYW5kIHB1cnBvc2VzLiBBbmQgYXMgZm9yIHRoZSB1c2FibGUgY2xpZW50IGF1dGhl bnRpY2F0aW9uIG1ldGhvZHMgLSB0aGV5IHNob3VsZCBhbGwgYmUgbGlzdGVkLCBvciBkbyB5b3Ug dGhpbmsgd2Ugc2hvdWxkIHNlcGFyYXRlIHRoZSBvbmVzIGZvciBlYWNoIGhvc3RuYW1lL3BvcnQg bG9jYXRpb24/IFRvIHdoYXQgZW5kPyBJcyB0aGVyZSBhIHJpc2sgaGF2aW5nIHRoZSBtdGxzIGhv c3RuYW1lL3BvcnQgYWNjZXB0aW5nIHJlZ3VsYXIgcmVxdWVzdHM/IE90aGVyIHRoZW4gc2VjcmV0 L2tleSBfand0IGF1dGggbWV0aG9kcyBhc3NlcnRpb24gYXVkIGNsYWltIHRoZSBlbmRwb2ludCBs b2NhdGlvbiBkb2Vzbid0IHBsYXkgYSByb2xlIGluIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNz Lg0KDQpCZXN0LA0KRmlsaXANCg0KDQpPbiBUdWUsIDEyIEZlYiAyMDE5IGF0IDIwOjQ3LCBSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCknigJltIG5v dCBvcHBvc2VkIHRvIGludHJvZHVjaW5nIGEgbWV0YWRhdGEgY2hhbmdlLCBpZiB0aGUgc2NlbmFy aW8gaXMgcmVsZXZhbnQgYW5kIG90aGVyIGFwcHJvYWNoZXMgY2Fu4oCZdCBhZGVxdWF0ZWx5IGFk ZHJlc3MgaXQg4oCTIGFuZCBJ4oCZbGwgcmVhZGlseSBncmFudCB0aGF0IHdlIHByb2JhYmx5IGRv buKAmXQgd2FudCB0byBkZXBlbmQgb24gY29uc2lzdGVuY3kgb2YgYnJvd3NlciBiZWhhdmlvciBh dCB0aGUgaW50ZXJzZWN0aW9uIG9mIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYW5kIEFjY2Vzcy1Db250 cm9sLUFsbG93LUNyZWRlbnRpYWxzLiBCdXQgY2FyZSBuZWVkcyB0byBiZSB0YWtlbiBpbiBkZXNp Z25pbmcgdGhhdCBtZXRhZGF0YSB0byBhdm9pZCB2aW9sYXRpbmcgb3Igb3RoZXJ3aXNlIG5lZ2F0 aXZlbHkgaW1wYWN0aW5nIHVzYWdlIG9mIFJGQzg0MTQuDQoNCkFsb25nIHRob3NlIGxpbmVzLCBp bnN0ZWFkIG9mIGFkZGluZyBhbiDigJxtdGxzX2VuZHBvaW50c+KAnSBtZXRhZGF0YSBwYXJhbWV0 ZXIsIHdlIGNvdWxkIGFkZCBhbiDigJxtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YeKAnSBwYXJhbWV0 ZXIgd2hvc2UgdmFsdWUgaXMgdGhlIFVSTCBvZiBhbiBhbHRlcm5hdGUgbWV0YWRhdGEgZG9jdW1l bnQgaW50ZW5kZWQgZm9yIGNsaWVudHMgdXNpbmcgbVRMUy4gQW4gbVRMUy1vcHRpb25hbCBBUyBj b3VsZCBoYXZlIHR3byBkaWZmZXJlbnQgbWV0YWRhdGEgZG9jdW1lbnRzIGZvciBtVExTIGFuZCBu b24tbVRMUyBjbGllbnRzLCByZWR1Y2luZyB0aGUgbVRMUy1vcHRpb25hbCBzY2VuYXJpbyB0byB0 aGUgbVRMUy1vbmx5IHNjZW5hcmlvLiBUaGlzIHNpZGVzdGVwcyB0aGUgY2hhbGxlbmdlcyBvZiBh bGlnbmluZyB0aGUg4oCcZWl0aGVyL29y4oCdIHNlbWFudGljcyBvZiBtVExTLW9wdGlvbmFsIHdp dGggc29tZSBvZiB0aGUgcmlnaWQgcGFyYW1ldGVyIGRlZmluaXRpb25zIGluIFJGQzg0MTQgKHNl ZTogdG9rZW5fZW5kcG9pbnQsIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQp Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJv bTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVu dGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p ZXRmLm9yZz4+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxOSBhdCAxMDo1OCBBTQ0K VG86IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFp ZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5k b2ludCAmIGRpc2NvdmVyeQ0KDQpUaGFua3MgZm9yIHRoZSBpbnB1dCwgRG9taW5pY2suDQoNCkkn ZCBzYWlkIHByZXZpb3VzbHkgdGhhdCBJIHdhcyBoYXZpbmcgdHJvdWJsZSBhZGVxdWF0ZWx5IGdh dWdpbmcgd2hldGhlciBvciBub3QgdGhlcmUncyBzdWZmaWNpZW50IGNvbnNlbnN1cyB0byBnbyBh aGVhZCB3aXRoIHRoZSB1cGRhdGUuIEkgd2FzIGV2ZW4gdGhpbmtpbmcgb2YgYXNraW5nIHRoZSBj aGFpcnMgYWJvdXQgYSBjb25zZW5zdXMgY2FsbCBkdXJpbmcgdGhlIG9mZmljZSBob3VycyBtZWV0 aW5nIHllc3RlcmRheS4gQnV0IGl0IGdvdCBjYW5jZWxlZC4gQW5kIGxvb2tpbmcgYWdhaW4gYmFj ayBvdmVyIHRoZSBkaXNjdXNzaW9uLCBJIGRvbid0IGJlbGlldmUgYSBjb25zZW5zdXMgY2FsbCBp cyBuZWNlc3NhcnkuIFRoZXJlJ3MgYmVlbiBhIGxvdCBvZiBnZW5lcmFsIGRpc2N1c3Npb24gb3Zl ciB0aGUgbGFzdCBzZXZlcmFsIHdlZWtzIGR1cmluZyB3aGljaCBzZXZlcmFsIGZvbGtzIGhhdmUg c3RhdGVkIHN1cHBvcnQgZm9yIHRoZSBwcm9wb3NhbCB3aGlsZSB0aGVyZSdzIGJlZW4gb25seSBv bmUgdm9pY2Ugb2YgZGlyZWN0IGRpc3NlbnQuIFRoYXQgc2VlbXMgbGlrZSByb3VnaCBlbm91Z2gg Y29uc2Vuc3VzIGFuZCwgYXMgc3VjaCwgSSBwbGFuIHRvIG1ha2UgdGhlIGNoYW5nZSBpbiB0aGUg bmV4dCByZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnQgKHdoaWNoIHNob3VsZCBiZSBkb25lIHNvb24p LiBDaGFpcnMsIHBsZWFzZSBsZXQgbWUga25vdywgaWYgeW91IGJlbGlldmUgdGhlIHNpdHVhdGlv biB3YXJyYW50cyBhIGRpZmZlcmVudCBjb3Vyc2Ugb2YgYWN0aW9uLg0KDQoNCg0KT24gTW9uLCBG ZWIgMTEsIDIwMTkgYXQgMTE6MDEgUE0gRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZp bGVnZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNCklNSE8g dGhhdOKAmXMgYSByZWFzb25hYmxlIGFuZCBwcmFnbWF0aWMgb3B0aW9uLg0KDQpUaGFua3MNCuKA lOKAlOKAlA0KRG9taW5pY2sNCg0KDQpPbiAxMS4gRmVicnVhcnkgMjAxOSBhdCAxMzoyNjozNywg QnJpYW4gQ2FtcGJlbGwgKGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbT4pIHdyb3RlOg0KSXQncyBiZWVuIHBvaW50ZWQgb3V0IHRoYXQg dGhlIHBvdGVudGlhbCBpc3N1ZSBpcyBub3QgaXNvbGF0ZWQgdG8gdGhlIGp1c3QgdG9rZW4gZW5k cG9pbnQgYnV0IHRoYXQgcmV2b2NhdGlvbiwgaW50cm9zcGVjdGlvbiwgZXRjLiBjb3VsZCBiZSBp bXBhY3RlZCBhcyB3ZWxsLiBTbywgIGF0IHRoaXMgcG9pbnQsIHRoZSBwcm9wb3NhbCBvbiB0aGUg dGFibGUgaXMgdG8gYWRkIGEgbmV3IG9wdGlvbmFsIEFTIG1ldGFkYXRhIHBhcmFtZXRlciBuYW1l ZCAnbXRsc19lbmRwb2ludHMnIHRoYXQncyB2YWx1ZSB3ZSBiZSBhIEpTT04gb2JqZWN0IHdoaWNo IGl0c2VsZiBjb250YWlucyBlbmRwb2ludHMgdGhhdCwgd2hlbiBwcmVzZW50LCBhIGNsaWVudCBk b2luZyBNVExTIHdvdWxkIHVzZSByYXRoZXIgdGhhbiB0aGUgcmVndWxhciBlbmRwb2ludHMuICBB IHN0cmF3LW1hbiBleGFtcGxlIG1pZ2h0IGxvb2sgbGlrZSB0aGlzDQp7DQogICJpc3N1ZXIiOiJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogICJhdXRob3JpemF0aW9uX2VuZHBvaW50Ijoi aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aHoiLA0KICAidG9rZW5fZW5kcG9pbnQiOiJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiIsDQogICJ0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZHNfc3VwcG9ydGVkIjpbICAiY2xpZW50X3NlY3JldF9iYXNpYyIsInRsc19jbGllbnRf YXV0aCIsICJub25lIl0sDQogICJ1c2VyaW5mb19lbmRwb2ludCI6Imh0dHBzOi8vc2VydmVyLmV4 YW1wbGUuY29tL3VzZXJpbmZvIiwNCiAgInJldm9jYXRpb25fZW5kcG9pbnQiOiJodHRwczovL3Nl cnZlci5leGFtcGxlLmNvbS9yZXZvIiwNCiAgImp3a3NfdXJpIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhh bXBsZS5jb20vandrcy5qc29uIiwNCiAgIm10bHNfZW5kcG9pbnRzIjp7DQogICAgInRva2VuX2Vu ZHBvaW50IjoiaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICAidXNlcmluZm9f ZW5kcG9pbnQiOiJodHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm8iLA0KICAgICJyZXZv Y2F0aW9uX2VuZHBvaW50IjoiaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3Jldm88aHR0cHM6Ly9t dGxzLi4uLi5leGFtcGxlLmNvbS9yZXZvPiINCiAgfQ0KfQ0KDQpBIGNsaWVudCBkb2luZyBNVExT IHdvdWxkIGxvb2sgZm9yIGFuZCBnaXZlIHByZWNlZGVuY2UgdG8gYW4gZW5kcG9pbnQgdW5kZXIg Im10bHNfZW5kcG9pbnRzIiB3aGlsZSBmYWxsaW5nIGJhY2sgdG8gdXNlIHRoZSBub3JtYWwgZW5k cG9pbnQgZnJvbSB0aGUgdG9wIGxldmVsIG9mIG1ldGFkYXRhIHdoZW4vaWYgaXRzIG5vdCBpbiAi bXRsc19lbmRwb2ludHMiLg0KDQpUaGUgaWRlYSBiZWluZyB0aGF0ICJyZWd1bGFyIiBjbGllbnRz ICh0aG9zZSBub3QgZG9pbmcgTVRMUykgd2lsbCB1c2UgdGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiBB bmQgb25seSB0aGUgaG9zdC9wb3J0IG9mIHRoZSBlbmRwb2ludHMgbGlzdGVkIGluIG10bHNfZW5k cG9pbnRzIHdpbGwgYmUgc2V0IHVwIHRvIHJlcXVlc3QgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZXMg ZHVyaW5nIGhhbmRzaGFrZS4gVGh1cyBhbnkgcG90ZW50aWFsIGltcGFjdCBvZiB0aGUgQ2VydGlm aWNhdGVSZXF1ZXN0IG1lc3NhZ2UgYmVpbmcgc2VudCBpbiB0aGUgVExTIGhhbmRzaGFrZSBjYW4g YmUgYXZvaWRlZCBmb3IgYWxsIHRoZSBvdGhlciByZWd1bGFyIGNsaWVudHMgdGhhdCBhcmUgbm90 IGdvaW5nIHRvIGRvIE1UTFMgLSBpbmNsdWRpbmcgYW5kIG1vc3QgaW1wb3J0YW50bHkgaW4tYnJv d3NlciBqYXZhc2NyaXB0IGNsaWVudHMgd2hlcmUgdGhlcmUgY2FuIGJlIGxlc3MgdGhhbiBkZXNp cmFibGUgVUkgcHJlc2VudGVkIHRvIHRoZSBlbmQtdXNlci4NCg0KSSdtIHN0cnVnZ2xpbmcsIGhv d2V2ZXIsIHRvIGFkZXF1YXRlbHkgZ2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUncyBzdWZmaWNp ZW50IGNvbnNlbnN1cyB0byBnbyBhaGVhZCB3aXRoIHRoZSB1cGRhdGUuIFRoZXJlJ3MgYmVlbiBz b21lIHN1cHBvcnQgZm9yIGl0IHZvaWNlZC4gQXMgd2VsbCBhcyB0YWxrIG9mIG90aGVyIGFwcHJv YWNoZXMgdGhhdCBjb3VsZCBiZSBhbHRlcm5hdGl2ZXMgb3IgYWRkaXRpb25hbCBtZWFzdXJlcy4g QW5kIGFsc28gc29tZSB2b2NhbCBvcHBvc2l0aW9uIHRvIGl0Lg0KDQoNCk9uIFNhdCwgRmViIDks IDIwMTkgYXQgMzowOSBBTSBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNv bTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+IHdyb3RlOg0KV2UgYXJlIGN1cnJl bnRseSBpbXBsZW1lbnRpbmcgTVRMUyBpbiBJZGVudGl0eVNlcnZlci4NCg0KT3VyIGFwcHJvYWNo IHdpbGwgYmUgdGhhdCB3ZeKAmWxsIG9mZmVyIGEgc2VwYXJhdGUgdG9rZW4gZW5kcG9pbnQgdGhh dCBzdXBwb3J0cyBjbGllbnQgY2VydHMuIEFyZSB5b3UgcGxhbm5pbmcgb24gYWRkaW5nIGFuIG9m ZmljaWFsIGVuZHBvaW50IG5hbWUgZm9yIGRpc2NvdmVyeT8gUmlnaHQgbm93IHdlIGFyZSB1c2lu ZyDigJxtdGxzX3Rva2VuX2VuZHBvaW504oCdLg0KDQpUaGFua3MNCuKAlOKAlOKAlA0KRG9taW5p Y2sNCg0KDQpPbiA3LiBGZWJydWFyeSAyMDE5IGF0IDIyOjM2OjU1LCBCcmlhbiBDYW1wYmVsbCAo YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86YmNhbXBi ZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KQWggeWVzLCB0 aGF0IG1ha2VzIHNlbnNlLiBUaGFua3MgZm9yIGNsYXJpZnlpbmcuIEFuZCBpdCBpcyBpbmRlZWQg YSBnb29kIHJlbWluZGVyIHRoYXQgZXZlbiBhIHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRo YXQgc2hvdWxkIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIGNhbiBicmVhayB0aGluZ3MgdW5leHBl Y3RlZGx5Li4NCg0KDQoNCg0KDQpPbiBUaHUsIEZlYiA3LCAyMDE5IGF0IDg6NTcgQU0gUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20+PiB3cm90ZToNClRoZSBjYXNlIEnigJltIHJlZmVyZW5jaW5nIGRpZG7igJl0 IHNwZWNpZmljYWxseSBpbnZvbHZlIEFTIG1ldGFkYXRhLiBXZSBoYWQgY2xpZW50cyBpbiB0aGUg d2lsZCB0aGF0IGFzc3VtZWQgdGhhdCBhbGwgdGhlIHByb3BlcnRpZXMgaW4gdGhlIEpTT04gb2Jq ZWN0IHJldHVybmVkIGZyb20gb3VyIHVzZXJpbmZvIGVuZHBvaW50IHdlcmUgc2NhbGFyIHN0cmlu Z3MuIFRoaXMgYnJva2Ugd2hlbiB3ZSBpbnRyb2R1Y2VkIGEgbmV3IHByb3BlcnR5IHdob3NlIHZh bHVlIHdhcyBhIEpTT04gb2JqZWN0LiBJdCB3YXMgYSBnb29kIHJlbWluZGVyIHRoYXQgZXZlbiBh IHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIGJhY2t3YXJkcyBjb21w YXRpYmxlIGNhbiBmb3JjZSBtb3JlIHdvcmsgb24gY2xpZW50cyB0aGFuIHdlIGV4cGVjdC4NCg0K LS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSA2LCAyMDE5IGF0 IDExOjMwIEFNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmE9NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmc+Pg0KQ2M6ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5j b208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Piwgb2F1dGggPG9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklF RCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2Vu IGVuZHBvaW50DQoNCkFuZCBJJ20gaG9uZXN0bHkgcmVhbGx5IHN0cnVnZ2xpbmcgdG8gc2VlIHdo YXQgY291bGQgaGF2ZSBnb25lIHdyb25nIHdpdGggb3IgaG93IHRva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kcyBicm9rZSBzb21ldGhpbmcgd2l0aCB0aGUgdXNlciBpbmZvIGVuZHBvaW50LiBJZiB5 b3UgaGF2ZSB0aGUgdGltZSBhbmQvb3IgaXQnZCBiZSBpbmZvcm1hdGl2ZSB0byB0aGlzIGhlcmUg bGl0dGxlIGRpc2N1c3Npb24sIHBsZWFzZSBleHBsYWluIHRoYXQgb25lIGEgYml0IG1vcmUuDQoN Ck9uIFdlZCwgRmViIDYsIDIwMTkgYXQgMTI6MTUgUE0gQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdy b3RlOg0KImZhciIgc2hvdWxkIGhhdmUgc2FpZCAiZmFpciIgaW4gdGhlIHByZXZpb3VzIG1lc3Nh Z2UNCg0KDQoNCg0KDQpPbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDQ6MzUgUE0gQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT4+IHdyb3RlOg0KSXQgbWF5IHdlbGwgYmUgZHVlIHRvIG15IG93biBpbnRlbGxlY3R1 YWwgc2hvcnRjb21pbmdzIGJ1dCB0aGVzZSBpc3N1ZXMvcXVlc3Rpb25zL2NvbmZ1c2lvbi1wb2lu dHMgYXJlIG5vdCByZXNvbmF0aW5nIGZvciBtZSBhcyBiZWluZyBwcm9ibGVtYXRpYy4NCg0KVGhl IG1vcmUgZ2VuZXJhbCBzdGFuY2Ugb2YgInRoaXMgaXNuJ3QgbmVlZGVkIG9yIHdvcnRoIGl0IGlu IHRoaXMgZG9jdW1lbnQiIChJIHRoaW5rIHRoYXQncyBmYXI/KSBpcyBiZWluZyBoZWFyZCB0aG91 Z2guDQoNCg0KDQpPbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDE6NDIgUE0gUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi4ub3JnPj4gd3JvdGU6DQooVEw7RFI6IHB1bnQgQVMg bWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCkNCg0KQVMgcG9pbnRzICMxLTMgYXJlIGFsbCBx dWVzdGlvbnMgSSB3b3VsZCBoYXZlIGFzIGFuIGltcGxlbWVudGVyOg0KDQogIDEuICBTZWN0aW9u IDIgb2YgUkZDODQxNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQxNCNzZWN0aW9u LTI+IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlSRUQgdW5sZXNzIG9ubHkgdGhlIGlt cGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKAnSBTbyB3aGF0IGRvZXMgdGhlIG1UTFMt b25seSBBUyBwdXQgaGVyZT8NCiAgMi4gIFRoZSBjbGFpbXMgZm9yIHRoZXNlIG90aGVyIGVuZHBv aW50cyBhcmUgT1BUSU9OQUwsIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8gaW5jb25zaXN0ZW5jeSBk ZXBlbmRpbmcgb24gaG93ICMxIGdldHMgZGVjaWRlZC4NCiAgMy4gIFRoZSBleGFtcGxlIHVzYWdl IG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgcHJvcGVydHkgZ2l2ZW4gZWFybGll ciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0LCBzaW5jZSBzb21lIG9mIGl0cyBjb250ZW50 cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1tVExTIGVuZHBvaW50cywgYW5kIG90aGVycyBh cmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5kcG9pbnRzLiBIZW5jZSB0aGlzIHF1ZXN0aW9u Lg0KICA0LiAgVGhpcyBpbnRyb2R1Y2VzIGEgbmV3IG1ldGFkYXRhIHByb3BlcnR5IHRoYXQgY291 bGQgaW1wYWN0IGhvdyBvdGhlciBzcGVjcyBzaG91bGQgZXh0ZW5kIEFTIG1ldGFkYXRhLiBUaGF0 IG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4NCg0KSSBjb3VsZCBnbyBvbiBmb3IgY2xpZW50IHBvaW50 cyBidXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdoIEnigJlsbCBzaGFyZSB0aGF0 ICMzIGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwgYmFjayBhbiB1cGRhdGUgdG8g dGhlIExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW504oCmZ29vZCB0aW1lcy4g8J+Y gw0KDQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEgcHJvcGVydHkg aXMgd3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJvbHRpbmcgYSBs YXllciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZdCBkZXNpZ25l ZCBmb3IgdGhhdCwgYW5kIEkgZG9u4oCZdCB0aGluayB0aGUgbWV0YWRhdGEgcHJvcG9zYWwgYXMg aXTigJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc3VmZmljaWVudGx5IGRlYWxzIHdpdGggdGhlIGZh bGxvdXQgZnJvbSB0aGF0LiBJbiBteSB2aWV3IHRoaXMgaXMgYSBjb21wbGV4IGVub3VnaCBpc3N1 ZSBhbmQgaXTigJlzIGZvciBhIG51YW5jZWQgZW5vdWdoIHVzZSBjYXNlIChhcyBmYXIgYXMgSSBj YW4gdGVsbCBmcm9tIGRpc2N1c3Npb24/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEnigJltIHdyb25n KSB0aGF0IHdlIHNob3VsZCBwdW50IGl0IHRvIGEgc2VwYXJhdGUgZHJhZnQgKGUuZy4sIOKAnEF1 dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIEV4dGVuc2lvbnMgZm9yIG1UTFMgSHlicmlkc+KA nSkgYW5kIGdldCBtVExTIG91dCB0aGUgZG9vci4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJyaWFuIENh bXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCBGZWJy dWFyeSA0LCAyMDE5IGF0IDU6MjggQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUi IDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJd IFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50 DQoNClRob3NlIHBvaW50cyBvZiBjb25mdXNpb24gc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGh5cG90 aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlzIHRha2VuIGFu ZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFudGkgYWRkaXRpb25hbCBtZXRhZGF0YSBvbiB0aGlz IGlzc3VlIGlzIG5vdGVkLg0KDQpBbGwgb2Ygd2hpY2ggbGVhdmVzIG1lIGEgYml0IHVuY2VydGFp biBhYm91dCBob3cgdG8gcHJvY2VlZC4gVGhlcmUgc2VlbSB0byBiZSBhIHJhbmdlIG9mIG9waW5p b25zIG9uIHRoaXMgcG9pbnQgYW5kIGdhdWdpbmcgY29uc2Vuc3VzIGlzIHByb3ZpbmcgZWx1c2l2 ZSBmb3IgbWUuIFRoYXQncyBjb25mb3VuZGVkIGJ5IG15IG93biBvcGluaW9uIG9uIGl0IGJlaW5n IHNvbWV3aGF0IGZsdWlkLg0KDQpBbmQgSSdkIHJlYWxseSBsaWtlIHRvIHBvc3QgYW4gdXBkYXRl IHRvIHRoaXMgZHJhZnQgYWJvdXQgYSBtb250aCBvciB0d28gYWdvLg0KDQoNCg0KDQoNCg0KT24g RnJpLCBGZWIgMSwgMjAxOSBhdCA1OjAzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxy aWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBk bWFyYy5pZXRmLi4uLm9yZz4+IHdyb3RlOg0KQ29uZnVzaW9uIGZyb20gdGhlIEFT4oCZcyBwZXJz cGVjdGl2ZToNCg0KICAxLiAgSWYgSSBvbmx5IHN1cHBvcnQgbVRMUywgZG8gSSBuZWVkIHRvIGlu Y2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91cmkgYW5kIG10bHNfZW5kcG9pbnRzPyBTaG91bGQg SSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8gT3Igc2V0IGl0IHRvIHRoZSBlbXB0eSBzdHJpbmc/ DQogIDIuICBXaGF0IGlmIEkgb25seSBzdXBwb3J0IG1UTFMgZm9yIHRoZSB0b2tlbiBlbmRwb2lu dCwgYnV0IG5vdCByZXZvY2F0aW9uIG9yIHVzZXIgaW5mbz8NCiAgMy4gIEhvdyBkbyBJIHNwZWNp ZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1UTFMgdG9rZW4gZW5kcG9pbnQ/IERv ZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5IHRvIGJvdGggdGhlIG1UTFMgYW5k IG5vbi1tVExTIGVuZHBvaW50cz8NCiAgNC4gIEnigJltIHVzaW5nIHRoZSBPQXV0aCAyLjAgRGV2 aWNlIEZsb3cuIERvIEkgaW5jbHVkZSBhIG1UTFMtZW5hYmxlZCBkZXZpY2VfYXV0aG9yaXphdGlv bl9lbmRwb2ludCB1bmRlciBtdGxzX2VuZHBvaW50cz8NCg0KQ29uZnVzaW9uIGZyb20gdGhlIGNs aWVudOKAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIEFzIGZhciBhcyBJIGtub3csIEnigJltIGEg cHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBtVExTLCBidXQg dGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz4oCZIGJy b3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhhdCB0byBhdXRoZW50aWNhdGUgbWUu DQogIDIuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIHRoZSBtVExTLW9u bHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuDQogIDMuICBNeSBBUyBtZXRhZGF0YSBw YXJzZXIgY3Jhc2hlZCBiZWNhdXNlIGl0IGRpZG7igJl0IGV4cGVjdCB0byBlbmNvdW50ZXIgYSBK U09OIG9iamVjdCBhcyBhIHBhcmFtZXRlciB2YWx1ZS4NCiAgNC4gIFRoZSBtVExTLW9ubHkgQVMg ZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZvciBtdGxzX2VuZHBvaW50cywgd2hhdCBkbyBJIGRv Pw0KICA1LiAgSSBkb27igJl0IGtub3cgd2hhdCB0aGF0IOKAnG3igJ0gbWVhbnMsIGJ1dCB0aGV5 IHRvbGQgbWUgdG8gdXNlIEhUVFBTLCBzbyBJIHNob3VsZCB1c2UgdGhlIG9uZSB3aXRoIOKAnHRs c+KAnSBpbiBpdHMgbmFtZSwgcmlnaHQ/DQoNClllcywgeW91IGNhbiB3cml0ZSBub3JtYXRpdmUg dGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4gQnV0IHlvdeKAmWxsIGhhdmUgdG8gY2xl YXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1zbGlnaHRseS1kaWZmZXJlbnQgc2NlbmFy aW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1wbGVtZW50ZXJzIHdpbGwgc3RpbGwgZ2V0 IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hhbmdlIGludHJvZHVjZXMgb3Bwb3J0dW5pdGllcyBm b3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRoYXQgZG8gbm90IGV4aXN0IG5vdywgYW5kIGZvcmNl cyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBwb3J0cyBtVExTLiBJbiBjb250cmFzdCwgdGhlIDMw NyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYW4gQVMgd2FudHMgdG8gc3VwcG9ydCBi b3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMgaW4gaXRzIGJlaGF2aW9yIGFuZCBtZWFuaW5nLg0KDQot LQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogQnJp YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBGcmlkYXks IEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzoxNyBQTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Pg0K Q2M6IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9s LmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1 YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJv d3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludA0KDQpJdCBkb2Vzbid0IHNlZW0g bGlrZSB0aGF0IGNvbmZ1c2luZyBvciBsYXJnZSBvZiBhIGNoYW5nZSB0byBtZSAtIGlmIHRoZSBj bGllbnQgaXMgZG9pbmcgTVRMUyBhbmQgdGhlIGdpdmVuIGVuZHBvaW50IGlzIHByZXNlbnQgaW4g YG10bHNfZW5kcG9pbnRzYCwgdGhlbiBpdCB1c2VzIHRoYXQgb25lLiAgT3RoZXJ3aXNlIGl0IHVz ZXMgdGhlIHJlZ3VsYXIgZW5kcG9pbnQuIEl0IGdpdmVzIGFuIEFTIGEgbG90IG9mIGZsZXhpYmls aXR5IGluIGRlcGxveW1lbnQgb3B0aW9ucy4gSSBwZXJzb25hbGx5IHRoaW5rIGdldHRpbmcgYSAz MDcgYXBwcm9hY2ggZGVwbG95ZWQgYW5kIHdvcmtpbmcgd291bGQgYmUgbW9yZSBjb21wbGljYXRl ZCBhbmQgZXJyb3IgcHJvbmUuDQoNCkl0IGlzIGEgbWlub3JpdHkgdXNlIGNhc2UgYXQgdGhlIG1v bWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBsaWtlIHRoZSBwdXNoIGZvciBpbmNy ZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2ZSBqYXZhc2NyaXB0IGNsaWVudHMg dXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdCBpdCB3b24ndCBiZSB0ZXJyaWJseSB1bnVz dWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBjbGllbnRzIGFuZCBq YXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuDQoNCkkndmUgcGVyc29uYWxs eSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhyZWFkIG9uIHdoZXRoZXIgb3Igbm90 IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhpbmcgbGlrZSBpdCkuIFdpdGggbXkg cmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBzb21ld2hlcmUgYmFjayBpbiB0aGUg NDAgb3Igc28gbWVzc2FnZXMgdGhhdCBtYWtlIHVwIHRoaXMgdGhyZWFkLiAgQnV0IGl0IHNlZW1z IGxpa2UgdGhlIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgZ3JvdXAgaGVyZSBpcyBpbiBmYXZvciBv ZiBpdC4NCg0KDQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCAzOjE4IFBNIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4uLm9yZz4+IHdyb3RlOg0KVGhpcyBzdHJpa2Vz IG1lIGFzIGEgdmVyeSBwcm9taW5lbnQgYW5kIGNvbmZ1c2luZyBjaGFuZ2UgdG8gc3VwcG9ydCB3 aGF0IHNlZW1zIHRvIGJlIGEgbWlub3JpdHkgdXNlIGNhc2UuIEnigJltIGdldHRpbmcgYSBoZWFk YWNoZSBqdXN0IHRoaW5raW5nIGFib3V0IHRoZSB0ZXh0IG5lZWRlZCB0byBjbGFyaWZ5IHdoZW4g dGhlIEFTIHNob3VsZCBwcm92aWRlIGBtdGxzX2VuZHBvaW50c2AgYW5kIHdoZW4gdGhlIGNsaWVu dCBzaG91bGQgdXNlIHRoYXQgdmVyc3VzIHVzaW5nIGB0b2tlbl9lbmRwb2ludC5gIFdoeSBpcyB0 aGUgMzA3IHN0YXR1cyBjb2RlIGluc3VmZmljaWVudCB0byBjb3ZlciB0aGUgY2FzZSB3aGVyZSBh IHNpbmdsZSBBUyBzdXBwb3J0cyBib3RoIG1UTFMgYW5kIG5vbi1tVExTPw0KDQotLQ0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh bGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRl OiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMTozMSBQTQ0KVG86IEdlb3JnZSBGbGV0Y2hl ciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1h cmMuLi4uLi4uLi5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNVExTIGFuZCBpbi1icm93 c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNClllcywgdGhhdCB3b3VsZCB3 b3JrLg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDI6MjggUE0gR2VvcmdlIEZsZXRjaGVyIDxn ZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy5p ZXRmLm9yZz4+IHdyb3RlOg0KV2hhdCBpZiB0aGUgQVMgd2FudHMgdG8gT05MWSBzdXBwb3J0IE1U TFMgY29ubmVjdGlvbnMuIERvZXMgaXQgbm90IHNwZWNpZnkgdGhlIG9wdGlvbmFsICJtdGxzX2Vu ZHBvaW50cyIgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0YWRhdGEgdmFsdWVzPw0KT24gMS8x NS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCkl0IHdvdWxkIGRlZmluaXRlbHkg YmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0IHdhc24ndCBtYWRlIGNsZWFyLiBJdCdkIGJl IHNvbWV0aGluZyB0byB0aGUgZWZmZWN0IG9mIG9wdGlvbmFsIGZvciB0aGUgQVMgdG8gaW5jbHVk ZSBhbmQgY2xpZW50cyBkb2luZyBNVExTIHdvdWxkIHVzZSBpdCB3aGVuIHByZXNlbnQgaW4gQVMg bWV0YWRhdGEuDQoNCk9uIFR1ZSwgSmFuIDE1LCAyMDE5IGF0IDI6MDQgQU0gRGF2ZSBUb25nZSA8 ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPG1haWx0bzpkYXZlLnRvbmdlQG1vbWVudHVtZnQu Y28udWs+PiB3cm90ZToNCkknbSBpbiBmYXZvdXIgb2YgdGhlIGBtdGxzX2VuZHBvaW50c2AgbWV0 YWRhdGEgcGFyYW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxkIGJlIG9wdGlvbmFsLg0KDQpDT05G SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUg Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QN Cg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3Ig ZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg YW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNP TkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBh dHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFM SVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3Ig ZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg YW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo= --_000_141CD215A86A49269FD6F58DD966F40Famazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIg MTEgNiAzIDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw LmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1l OmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm0x OTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2 OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEz MzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0 OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9uLCBsaS5tMTk5MzI4ODEzNzA4 NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMw MGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21h aWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1t MzczMjQyODAzMDUyOTExODc3MWFpcm1haWxvbiwgZGl2Lm0xOTkzMjg4MTM3MDg1MDkzMzJnbWFp bC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYw ODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUz MjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMw NTI5MTE4NzcxYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOm1fMTk5MzI4ODEzNzA4NTA5MzMy Z21haWwtbV82NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFp bC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0y MTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0 MjgwMzA1MjkxMTg3NzFhaXJtYWlsb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdt YWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1t LTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgw MDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0 MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxLCBsaS5tMTk5MzI4ODEzNzA4NTA5MzMy Z21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWls LW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIx OTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQy ODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4 ODc0MSwgZGl2Lm0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdt YWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1t LTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgw MDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0 MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxDQoJe21zby1zdHlsZS1uYW1lOiJtXzE5 OTMyODgxMzcwODUwOTMzMmdtYWlsLW1fNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2 OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEz MzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0 OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVn bWFpbC1tNzU5MzAzMzgyODg4NzQxIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDc3 NjQ3ODQxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTg4ODg3OTgyO30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjExMDE1MzQyMTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1OTkzODU2 O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE4Mjc1MDQxMjQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xODkxMDg2NDk4O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlIGlzIHRoYXQgdGhlIHByb3Bvc2FsIHZp b2xhdGVzIHRoZSBzdGFuZGFyZCBieSBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIGEgcGFyYW1l dGVyIGl0IGRlZmluZXMuIFdlIHNob3VsZCBiZSB2ZXJ5LCB2ZXJ5LCBWRVJZIGNhcmVmdWwgYWJv dXQgdGVsbGluZyBpbXBsZW1lbnRlcnMgdG8gdmlvbGF0ZSBhbiBleGlzdGluZyBzdGFuZGFyZC4g VGhpcyBjaGFuZ2UgbWlnaHQgcHJvdmUgaW5jb21wYXRpYmxlDQogd2l0aCBleGlzdGluZyBvciBm dXR1cmUgaW1wbGVtZW50YXRpb25zIG9mIDg0MTQsIGl0IG1pZ2h0IG5vdCwgYnV0IGJ5IHZpb2xh dGluZyB0aGUgc3RhbmRhcmQgdGhlIHByb3Bvc2FsIGNyZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9y IGluY29tcGF0aWJpbGl0eSB0aGF0IGRpZG7igJl0IGV4aXN0IGJlZm9yZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QXMgZmFyIGFzIHNpbXBsaWNpdHkgaXMgY29uY2VybmVkLCBJIGZpbmQgYSBz b2x1dGlvbiB0aGF0IHJldXNlcyB0aGUgZXhpc3RpbmcgZGF0YSBtb2RlbCBhbmQgbmF0dXJhbGx5 IHN1cHBvcnRzIGV4aXN0aW5nIGFuZCBmdXR1cmUgZXh0ZW5zaW9ucyB0byBiZSBmYXIgc2ltcGxl ciB0aGFuIG9uZSB0aGF0IGludHJvZHVjZXMgYW1iaWd1b3VzIHNlbWFudGljcyB0byBleGlzdGlu ZyBwYXJhbWV0ZXJzLiBHZW5lcmFsbHkNCiBzcGVha2luZywgZGF0YSBtb2RlbHMgd2l0aCBwcm9w ZXJ0aWVzIHRoYXQgbWVhbiBkaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBjb250ZXh0cyB0 ZW5kIHRvIGJlIGZyYWdpbGUgYW5kIHJlcXVpcmUgbW9yZSBjb21wbGV4IGNvZGUgdG8gd29yayB3 aXRoLiBCdXQgdGhhdOKAmXMganVzdCBteSBleHBlcmllbmNlIGFzLCB5b3Uga25vdywgYW4gYWN0 dWFsIGRldmVsb3Blci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV04oCZcyBrZWVwIHRoZSBh c3N1bXB0aW9ucyBhbmQgc25pZGUgcmVtYXJrcyBhYm91dCBvdGhlcnPigJkgYmFja2dyb3VuZHMg b2ZmIHRoZSBsaXN0LCBwbGVhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RG9taW5pY2sgQmFpZXIgJmx0O2RiYWllckBsZWFzdHByaXZpbGVnZS5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTkgYXQgNDoxOCBB TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsg Jmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7LCBGaWxpcCBTa29rYW4gJmx0O3BhbnZhLmlwQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbSZndDssICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1 b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24uY29tJmd0Oywgb2F1dGggJmx0O29hdXRoQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgt V0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmYW1wOyBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SSBhbSBmb3Iga2VlcGluZyBp dCBzaW1wbGUgYW5kIG5vdCBpbnRyb2R1Y2luZyBhbm90aGVyIGxpbmsgdG8gZm9sbG93LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5J IHNvbWV0aW1lcyB3b25kZXIgaG93IG1hbnkgb2YgdGhlIHNwZWMgYXV0aG9ycyBhcmUgYWN0dWFs bHkgZGV2ZWxvcGVycyAtIHRoZXNlIHN1Z2dlc3Rpb25zIG1ha2Ugc29mdHdhcmUgdW5uZWNlc3Nh cnkgY29tcGxleCA7KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+4oCU4oCU4oCUIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRvbWluaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj5PbiAxMy4g RmVicnVhcnkgMjAxOSBhdCAxMjoyNToxMywgRmlsaXAgU2tva2FuICg8YSBocmVmPSJtYWlsdG86 cGFudmEuaXBAZ21haWwuY29tIj5wYW52YS5pcEBnbWFpbC5jb208L2E+KSB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B ZGRpdGlvbmFsbHksIGEgbWV0YWRhdGEgZG9jdW1lbnQgdGhhdCBvbWl0cyB0b2tlbl9lbmRwb2lu dCBpbiBmYXZvciBvZiBtdGxzX2VuZHBvaW50cyBzaW5jZSBvbmx5IG1UTFMgaXMgc3VwcG9ydGVk IHdvdWxkIHZpb2xhdGUgODQxNCwgYXMgODQxNCBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJF UVVJUkVEIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7i gJ08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KbXRscyBvbmx5IEFTIGRvZXNuJ3QgZ2V0 IGFueXRoaW5nIG91dCBvZiB1c2luZyBtdGxzX2VuZHBvaW50cywgaXRzIHVzZSBzaG91bGQgbm90 IGJlIHJlY29tbWVuZGVkIGZvciBzdWNoIEFTIGFuZCByZWd1bGFyIGVuZHBvaW50cyB3aWxsIGJl IHVzZWQsIHRoaXMgc2F0aXNmaWVzIHRoZSByZXF1aXJlbWVudDxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgb25lIGV4YW1wbGUsIGJhc2Vk IG9uIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIOKAnHN0cmF3IG1hbuKAnSBmb3JtYXQgcHJlc2Vu dGVkIGluIHRoaXMgdGhyZWFkOiBSRkM4NDE0IGRlZmluZXMgdGhlIHZhbHVlIG9mIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgYXMgYSDigJxKU09OIGFycmF5IGNvbnRhaW5p bmcgYSBsaXN0IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIHN1cHBvcnRlZA0KIGJ5 IHRoaXMgdG9rZW4gZW5kcG9pbnQu4oCdIElmIHRoYXQgYXJyYXkgY29udGFpbnMg4oCcdGxzX2Ns aWVudF9hdXRo4oCdIGFuZCB0aGUgZW5kcG9pbnQgc3BlY2lmaWVkIGluIHRva2VuX2VuZHBvaW50 IGRvZXMgbm90IHN1cHBvcnQgbVRMUywgdGhlbiB0aGF0IG1ldGFkYXRhIHZpb2xhdGVzIDg0MTQu IFlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgYnkgYWRkaW5nIGEgdG9rZW5fZW5kcG9pbnRfYXV0aF9t ZXRob2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhlDQogbXRsc19lbmRwb2ludHMgb2JqZWN0 LCBhbmQgbGlrZXdpc2UgZm9yIHRoZSBvdGhlciBlbmRwb2ludHMgYW5kIGF1dGggbWV0aG9kcy4g SWYgeW91IHRha2UgdGhhdCB0byBpdHMgbG9naWNhbCBjb25jbHVzaW9uLCB5b3UgZW5kIHVwIHdp dGggYSBjb21wbGV0ZSBtZXRhZGF0YSBkb2N1bWVudCBoYW5naW5nIG9mZiBvZiBtdGxzX2VuZHBv aW50cy4gSXTigJlzIHRoYXQgbGluZSBvZiB0aG91Z2h0IHRoYXQgbGVkIG1lIHRvIHN1Z2dlc3Qg anVzdCBwb2ludGluZw0KIHRvIGFuIGFsdGVybmF0ZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkFzc3VtaW5nIHdlIGdv IHdpdGggdXNpbmcgdGhlIHNhbWUgcm9vdCBhdXRoIG1ldGhvZHMgcHJvcGVydHksIHdoYXQncyB0 aGUgaXNzdWU/IENsaWVudHMgbm90IGhhdmluZyBtdGxzIGNhcGFiaWxpdGllcyB3b24ndCBjYXJl IGFib3V0IHRoZSBhZGRpdGlvbmFsIG1ldGhvZCBtZW1iZXJzIGJlaW5nIHByZXNlbnQuIENsaWVu dHMgdGhhdCBkbyBpbXBsZW1lbnQgbXRscyBieSB0aGUgc3BlY2lmaWNhdGlvbiB3aWxsIGtub3cg dG8gbG9vayBmb3IgbXRsc19lbmRwb2ludHMNCiBhbmQgZmFsbCBiYWNrIHRvIHJlZ3VsYXIgb25l cyBpZiB0aGUgc3BlY2lmaWMgZW5kcG9pbnQgb3IgbXRsc19lbmRwb2ludHMgcm9vdCBwcm9wZXJ0 eSBpcyBub3QgcHJlc2VudC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBnYXZlIGBtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YWAgcm91dGUgYSB0aG91Z2h0 IGFuZCBkb24ndCBzZWUgaG93IGl0IGhlbHBzLCBnaXZlbiB0aGUgdHdvIGFib3ZlIGFyZSBub24t aXNzdWVzIChteSAkLjAyKSBhbm90aGVyIGRpc2NvdmVyeSBkb2N1bWVudCBvbmx5IGJyaW5ncyBt b3JlIG9mIHRoZW0gc2luY2UgZXZlcnkgcHJvcGVydHkgY2FuIG5vdyBiZSBkaWZmZXJlbnQsIG5v dCBqdXN0IHRoZSBlbmRwb2ludHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlMgcG96ZHJhdmVtLDxicj4NCjxiPkZpbGlwIFNrb2thbjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdl ZCwgMTMgRmViIDIwMTkgYXQgMDA6MDAsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8 YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hh bm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZXJlIGlzIG9u ZSBleGFtcGxlLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSDigJxzdHJhdyBtYW7i gJ0gZm9ybWF0IHByZXNlbnRlZCBpbiB0aGlzIHRocmVhZDogUkZDODQxNCBkZWZpbmVzIHRoZSB2 YWx1ZSBvZiB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIGFzIGEg4oCcSlNP Tg0KIGFycmF5IGNvbnRhaW5pbmcgYSBsaXN0IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRo b2RzIHN1cHBvcnRlZCBieSB0aGlzIHRva2VuIGVuZHBvaW50LuKAnSBJZiB0aGF0IGFycmF5IGNv bnRhaW5zIOKAnHRsc19jbGllbnRfYXV0aOKAnSBhbmQgdGhlIGVuZHBvaW50IHNwZWNpZmllZCBp biB0b2tlbl9lbmRwb2ludCBkb2VzIG5vdCBzdXBwb3J0IG1UTFMsIHRoZW4gdGhhdCBtZXRhZGF0 YSB2aW9sYXRlcyA4NDE0LiBZb3UgY291bGQgYWRkcmVzcyB0aGlzDQogYnkgYWRkaW5nIGEgdG9r ZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhlIG10bHNf ZW5kcG9pbnRzIG9iamVjdCwgYW5kIGxpa2V3aXNlIGZvciB0aGUgb3RoZXIgZW5kcG9pbnRzIGFu ZCBhdXRoIG1ldGhvZHMuIElmIHlvdSB0YWtlIHRoYXQgdG8gaXRzIGxvZ2ljYWwgY29uY2x1c2lv biwgeW91IGVuZCB1cCB3aXRoIGEgY29tcGxldGUgbWV0YWRhdGEgZG9jdW1lbnQgaGFuZ2luZyBv ZmYgb2YgbXRsc19lbmRwb2ludHMuDQogSXTigJlzIHRoYXQgbGluZSBvZiB0aG91Z2h0IHRoYXQg bGVkIG1lIHRvIHN1Z2dlc3QganVzdCBwb2ludGluZyB0byBhbiBhbHRlcm5hdGUgZG9jdW1lbnQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZGRpdGlvbmFsbHksIGEgbWV0YWRhdGEgZG9j dW1lbnQgdGhhdCBvbWl0cyB0b2tlbl9lbmRwb2ludCBpbiBmYXZvciBvZiBtdGxzX2VuZHBvaW50 cyBzaW5jZSBvbmx5IG1UTFMgaXMgc3VwcG9ydGVkIHdvdWxkIHZpb2xhdGUgODQxNCwgYXMgODQx NCBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEDQogdW5sZXNzIG9ubHkgdGhlIGlt cGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SXQgaXMgcG9zc2libGUgdG8gZGVmaW5lIHRoZSBtdGxzX2VuZHBvaW50cyBwYXJhbWV0 ZXIgc3VjaCB0aGF0IHRoZSBhYm92ZSB1c2UgY2FzZXMgYXJlIGludmFsaWQsIGJ1dCB0aGF0IGRv ZXMgbWFrZSB0aGUgZG9jdW1lbnQgbW9yZSBjb21wbGljYXRlZC4gSWYgd2UgZ28gdGhlIOKAnG10 bHNfYWx0ZXJuYXRlX21ldGFkYXRh4oCdDQogcm91dGUsIHdlIGNhbiBza2lwIHBhc3QgYWxsIG9m IHRoZXNlIGlzc3VlcywgYmVjYXVzZSBpdCBicmluZ3MgdXMgYmFjayB0byBqdXN0IHBhcnNpbmcg dGhlIHNhbWUgbWV0YWRhdGEgdGhhdCB3ZSBkbyB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhbnZhLmlwQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAy MDE5IGF0IDE6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+ICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRt YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEg aHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7LCBvYXV0aCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBNVExT IHRva2VuIGVuZG9pbnQgJmFtcDsgZGlzY292ZXJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBB bm5hYmVsbGUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5jYW4geW91IGVsYWJvcmF0ZSB3aGF0IHdvdWxkIGJlIHRoZSB2aW9sYXRpb24g LyBuZWdhdGl2ZSBpbXBhY3Qgb2YgdXNhZ2Ugb2YgUkZDODQxND88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGl0IGFscmVhZHkgbWFr ZXMgdXNlIG9mIGBzaWduZWRfbWV0YWRhdGFgIGFuZCB0aGlzIGxhbmd1YWdlIGlzIHByZXNlbnQg Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mZ3Q7Jm5ic3A7Q29uc3VtZXJzIG9mIHRoZSBtZXRhZGF0YSBNQVkgaWdub3JlIHRoZSBz aWduZWQgbWV0YWRhdGEgaWYgdGhleSBkbyBub3Qgc3VwcG9ydCB0aGlzIGZlYXR1cmUuJm5ic3A7 IElmIHRoZSBjb25zdW1lciBvZiB0aGUgbWV0YWRhdGEgc3VwcG9ydHMgc2lnbmVkIG1ldGFkYXRh LCBtZXRhZGF0YSB2YWx1ZXMgY29udmV5ZWQNCiBpbiB0aGUgc2lnbmVkIG1ldGFkYXRhIE1VU1Qg dGFrZSBwcmVjZWRlbmNlIG92ZXIgdGhlIGNvcnJlc3BvbmRpbmcgdmFsdWVzIGNvbnZleWVkIHVz aW5nIHBsYWluIEpTT04gZWxlbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4uLi4gd291bGQgbXRsc19lbmRwb2ludHMgYmUgYW55 IGRpZmZlcmVudD8gQ2xpZW50cyBhcmUgZnJlZSB0byBpZ25vcmUgdGhpcyBpZiB0aGV5IGRvbid0 IHN1cHBvcnQvdXNlIG10bHMsIGFuZCBpZiB0aGV5IGRvIHRob3NlIHZhbHVlcyBtdXN0IHRha2Ug cHJlY2VkZW5jZSBvdmVyIHRoZSByb290IG9uZXMuIHRoZQ0KIHVzZSBvZiBtdGxzX2VuZHBvaW50 cyB3b3VsZCBub3QgYmUgcmVjb21tZW5kZWQgZm9yIG10bHMtb25seSBBUyBidXQgcmVjb21tZW5k ZWQgZm9yIG9uZSB3aXRoIGJvdGggbXRscy9yZWd1bGFyIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMu IHRva2VuX2VuZHBvaW50IHJlbWFpbnMgcmVxdWlyZWQgZm9yIGFsbCBpbnRlbnRzIGFuZCBwdXJw b3Nlcy4gQW5kIGFzIGZvciB0aGUgdXNhYmxlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2Rz IC0gdGhleQ0KIHNob3VsZCBhbGwgYmUgbGlzdGVkLCBvciBkbyB5b3UgdGhpbmsgd2Ugc2hvdWxk IHNlcGFyYXRlIHRoZSBvbmVzIGZvciBlYWNoIGhvc3RuYW1lL3BvcnQgbG9jYXRpb24/IFRvIHdo YXQgZW5kPyBJcyB0aGVyZSBhIHJpc2sgaGF2aW5nIHRoZSBtdGxzIGhvc3RuYW1lL3BvcnQgYWNj ZXB0aW5nIHJlZ3VsYXIgcmVxdWVzdHM/IE90aGVyIHRoZW4gc2VjcmV0L2tleSBfand0IGF1dGgg bWV0aG9kcyBhc3NlcnRpb24gYXVkIGNsYWltIHRoZSBlbmRwb2ludA0KIGxvY2F0aW9uIGRvZXNu J3QgcGxheSBhIHJvbGUgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVzdCw8 YnI+DQo8Yj5GaWxpcDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCAxMiBGZWIgMjAxOSBhdCAyMDo0NywgUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDo0Li4uOHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBub3Qgb3Bwb3NlZCB0byBpbnRyb2R1Y2lu ZyBhIG1ldGFkYXRhIGNoYW5nZSwgaWYgdGhlIHNjZW5hcmlvIGlzIHJlbGV2YW50IGFuZCBvdGhl ciBhcHByb2FjaGVzIGNhbuKAmXQgYWRlcXVhdGVseSBhZGRyZXNzIGl0IOKAkyBhbmQgSeKAmWxs IHJlYWRpbHkgZ3JhbnQgdGhhdCB3ZSBwcm9iYWJseSBkb27igJl0IHdhbnQNCiB0byBkZXBlbmQg b24gY29uc2lzdGVuY3kgb2YgYnJvd3NlciBiZWhhdmlvciBhdCB0aGUgaW50ZXJzZWN0aW9uIG9m IGNsaWVudCBjZXJ0aWZpY2F0ZXMgYW5kIEFjY2Vzcy1Db250cm9sLUFsbG93LUNyZWRlbnRpYWxz LiBCdXQgY2FyZSBuZWVkcyB0byBiZSB0YWtlbiBpbiBkZXNpZ25pbmcgdGhhdCBtZXRhZGF0YSB0 byBhdm9pZCB2aW9sYXRpbmcgb3Igb3RoZXJ3aXNlIG5lZ2F0aXZlbHkgaW1wYWN0aW5nIHVzYWdl IG9mIFJGQzg0MTQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbG9uZyB0aG9zZSBsaW5l cywgaW5zdGVhZCBvZiBhZGRpbmcgYW4g4oCcbXRsc19lbmRwb2ludHPigJ0gbWV0YWRhdGEgcGFy YW1ldGVyLCB3ZSBjb3VsZCBhZGQgYW4g4oCcbXRsc19hbHRlcm5hdGVfbWV0YWRhdGHigJ0gcGFy YW1ldGVyIHdob3NlIHZhbHVlIGlzIHRoZSBVUkwgb2YgYW4gYWx0ZXJuYXRlIG1ldGFkYXRhDQog ZG9jdW1lbnQgaW50ZW5kZWQgZm9yIGNsaWVudHMgdXNpbmcgbVRMUy4gQW4gbVRMUy1vcHRpb25h bCBBUyBjb3VsZCBoYXZlIHR3byBkaWZmZXJlbnQgbWV0YWRhdGEgZG9jdW1lbnRzIGZvciBtVExT IGFuZCBub24tbVRMUyBjbGllbnRzLCByZWR1Y2luZyB0aGUgbVRMUy1vcHRpb25hbCBzY2VuYXJp byB0byB0aGUgbVRMUy1vbmx5IHNjZW5hcmlvLiBUaGlzIHNpZGVzdGVwcyB0aGUgY2hhbGxlbmdl cyBvZiBhbGlnbmluZyB0aGUg4oCcZWl0aGVyL29y4oCdDQogc2VtYW50aWNzIG9mIG1UTFMtb3B0 aW9uYWwgd2l0aCBzb21lIG9mIHRoZSByaWdpZCBwYXJhbWV0ZXIgZGVmaW5pdGlvbnMgaW4gUkZD ODQxNCAoc2VlOiB0b2tlbl9lbmRwb2ludCwgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1 cHBvcnRlZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBp bmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVu dGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBUdWVzZGF5 LCBGZWJydWFyeSAxMiwgMjAxOSBhdCAxMDo1OCBBTTxicj4NCjxiPlRvOjwvYj4gRG9taW5pY2sg QmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBNVExTIHRva2VuIGVuZG9pbnQgJmFtcDsgZGlzY292ZXJ5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgdGhlIGlucHV0LCBEb21pbmljay48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkn ZCBzYWlkIHByZXZpb3VzbHkgdGhhdCBJIHdhcyBoYXZpbmcgdHJvdWJsZSBhZGVxdWF0ZWx5IGdh dWdpbmcgd2hldGhlciBvciBub3QgdGhlcmUncyBzdWZmaWNpZW50IGNvbnNlbnN1cyB0byBnbyBh aGVhZCB3aXRoIHRoZSB1cGRhdGUuIEkgd2FzIGV2ZW4gdGhpbmtpbmcgb2YgYXNraW5nIHRoZSBj aGFpcnMNCiBhYm91dCBhIGNvbnNlbnN1cyBjYWxsIGR1cmluZyB0aGUgb2ZmaWNlIGhvdXJzIG1l ZXRpbmcgeWVzdGVyZGF5LiBCdXQgaXQgZ290IGNhbmNlbGVkLiBBbmQgbG9va2luZyBhZ2FpbiBi YWNrIG92ZXIgdGhlIGRpc2N1c3Npb24sIEkgZG9uJ3QgYmVsaWV2ZSBhIGNvbnNlbnN1cyBjYWxs IGlzIG5lY2Vzc2FyeS4gVGhlcmUncyBiZWVuIGEgbG90IG9mIGdlbmVyYWwgZGlzY3Vzc2lvbiBv dmVyIHRoZSBsYXN0IHNldmVyYWwgd2Vla3MgZHVyaW5nIHdoaWNoDQogc2V2ZXJhbCBmb2xrcyBo YXZlIHN0YXRlZCBzdXBwb3J0IGZvciB0aGUgcHJvcG9zYWwgd2hpbGUgdGhlcmUncyBiZWVuIG9u bHkgb25lIHZvaWNlIG9mIGRpcmVjdCBkaXNzZW50LiBUaGF0IHNlZW1zIGxpa2Ugcm91Z2ggZW5v dWdoIGNvbnNlbnN1cyBhbmQsIGFzIHN1Y2gsIEkgcGxhbiB0byBtYWtlIHRoZSBjaGFuZ2UgaW4g dGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIGRvY3VtZW50ICh3aGljaCBzaG91bGQgYmUgZG9uZSBz b29uKS4gQ2hhaXJzLA0KIHBsZWFzZSBsZXQgbWUga25vdywgaWYgeW91IGJlbGlldmUgdGhlIHNp dHVhdGlvbiB3YXJyYW50cyBhIGRpZmZlcmVudCBjb3Vyc2Ugb2YgYWN0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEZlYiAxMSwgMjAxOSBhdCAxMTowMSBQTSBE b21pbmljayBCYWllciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5j b20iIHRhcmdldD0iX2JsYW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+SU1ITyB0aGF04oCZcyBhIHJlYXNvbmFibGUgYW5kIHByYWdtYXRpYyBvcHRpb24uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPuKAlOKAlOKAlDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+RG9taW5pY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0x OTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2 OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEz MzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0 OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxYWlybWFpbG9uIj4NCk9uIDExLiBGZWJydWFy eSAyMDE5IGF0IDEzOjI2OjM3LCBCcmlhbiBDYW1wYmVsbCAoPGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij5JdCdzIGJlZW4gcG9pbnRlZCBvdXQgdGhhdCB0aGUgcG90ZW50aWFsIGlzc3VlIGlzIG5v dCBpc29sYXRlZCB0byB0aGUganVzdCB0b2tlbiBlbmRwb2ludCBidXQgdGhhdCByZXZvY2F0aW9u LCBpbnRyb3NwZWN0aW9uLCBldGMuIGNvdWxkIGJlIGltcGFjdGVkIGFzIHdlbGwuIFNvLCZuYnNw OyBhdCB0aGlzIHBvaW50LCB0aGUgcHJvcG9zYWwNCiBvbiB0aGUgdGFibGUgaXMgdG8gYWRkIGEg bmV3IG9wdGlvbmFsIEFTIG1ldGFkYXRhIHBhcmFtZXRlciBuYW1lZCAnbXRsc19lbmRwb2ludHMn IHRoYXQncyB2YWx1ZSB3ZSBiZSBhIEpTT04gb2JqZWN0IHdoaWNoIGl0c2VsZiBjb250YWlucyBl bmRwb2ludHMgdGhhdCwgd2hlbiBwcmVzZW50LCBhIGNsaWVudCBkb2luZyBNVExTIHdvdWxkIHVz ZSByYXRoZXIgdGhhbiB0aGUgcmVndWxhciBlbmRwb2ludHMuJm5ic3A7IEEgc3RyYXctbWFuIGV4 YW1wbGUgbWlnaHQNCiBsb29rIGxpa2UgdGhpczxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPns8YnI+DQombmJzcDsgJnF1b3Q7aXNzdWVyJnF1b3Q7OiZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9z ZXJ2ZXIuZXhhbXBsZS5jb208L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDthdXRob3JpemF0 aW9uX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUu Y29tL2F1dGh6IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0 aHo8L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludCZxdW90OzomcXVv dDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuPC9hPiZxdW90Oyw8YnI+DQombmJz cDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCZxdW90OzpbICZu YnNwOyZxdW90O2NsaWVudF9zZWNyZXRfYmFzaWMmcXVvdDssJnF1b3Q7dGxzX2NsaWVudF9hdXRo JnF1b3Q7LCAmcXVvdDtub25lJnF1b3Q7XSw8YnI+DQombmJzcDsgJnF1b3Q7dXNlcmluZm9fZW5k cG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdXNl cmluZm8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbS91c2VyaW5m bzwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O3Jldm9jYXRpb25fZW5kcG9pbnQmcXVvdDs6 JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2byIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Jldm88L2E+JnF1b3Q7LDxicj4NCiZu YnNwOyAmcXVvdDtqd2tzX3VyaSZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5l eGFtcGxlLmNvbS9qd2tzLmpzb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZlci5leGFt cGxlLmNvbS9qd2tzLmpzb248L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyA8Yj4mcXVvdDttdGxzX2Vu ZHBvaW50cyZxdW90Ozp7PGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludCZx dW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL210bHMuZXhhbXBsZS5jb20vdG9rZW4iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL210bHMuZXhhbXBsZS5jb20vdG9rZW48L2E+JnF1b3Q7LDxicj4N CiZuYnNwOyAmbmJzcDsgJnF1b3Q7dXNlcmluZm9fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3VzZXJpbmZvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3VzZXJpbmZvPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgJm5i c3A7ICZxdW90O3Jldm9jYXRpb25fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9tdGxzLi4uLi5leGFtcGxlLmNvbS9yZXZvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tdGxz LmV4YW1wbGUuY29tL3Jldm88L2E+JnF1b3Q7PGJyPg0KJm5ic3A7IH08L2I+PGJyPg0KfTxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QSBjbGllbnQgZG9pbmcgTVRMUyB3b3VsZCBsb29rIGZvciBhbmQgZ2l2ZSBw cmVjZWRlbmNlIHRvIGFuIGVuZHBvaW50IHVuZGVyICZxdW90O210bHNfZW5kcG9pbnRzJnF1b3Q7 IHdoaWxlIGZhbGxpbmcgYmFjayB0byB1c2UgdGhlIG5vcm1hbCBlbmRwb2ludCBmcm9tIHRoZSB0 b3AgbGV2ZWwgb2YgbWV0YWRhdGEgd2hlbi9pZg0KIGl0cyBub3QgaW4gJnF1b3Q7bXRsc19lbmRw b2ludHMmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NClRoZSBpZGVhIGJlaW5nIHRoYXQgJnF1b3Q7cmVndWxhciZxdW90OyBj bGllbnRzICh0aG9zZSBub3QgZG9pbmcgTVRMUykgd2lsbCB1c2UgdGhlIHJlZ3VsYXIgZW5kcG9p bnRzLiBBbmQgb25seSB0aGUgaG9zdC9wb3J0IG9mIHRoZSBlbmRwb2ludHMgbGlzdGVkIGluIG10 bHNfZW5kcG9pbnRzIHdpbGwgYmUgc2V0IHVwIHRvIHJlcXVlc3QgVExTIGNsaWVudCBjZXJ0aWZp Y2F0ZXMgZHVyaW5nIGhhbmRzaGFrZS4gVGh1cyBhbnkgcG90ZW50aWFsIGltcGFjdCBvZiB0aGUN CiBDZXJ0aWZpY2F0ZVJlcXVlc3QgbWVzc2FnZSBiZWluZyBzZW50IGluIHRoZSBUTFMgaGFuZHNo YWtlIGNhbiBiZSBhdm9pZGVkIGZvciBhbGwgdGhlIG90aGVyIHJlZ3VsYXIgY2xpZW50cyB0aGF0 IGFyZSBub3QgZ29pbmcgdG8gZG8gTVRMUyAtIGluY2x1ZGluZyBhbmQgbW9zdCBpbXBvcnRhbnRs eSBpbi1icm93c2VyIGphdmFzY3JpcHQgY2xpZW50cyB3aGVyZSB0aGVyZSBjYW4gYmUgbGVzcyB0 aGFuIGRlc2lyYWJsZSBVSSBwcmVzZW50ZWQgdG8NCiB0aGUgZW5kLXVzZXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gc3RydWdn bGluZywgaG93ZXZlciwgdG8gYWRlcXVhdGVseSBnYXVnZSB3aGV0aGVyIG9yIG5vdCB0aGVyZSdz IHN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvIGdvIGFoZWFkIHdpdGggdGhlIHVwZGF0ZS4gVGhlcmUn cyBiZWVuIHNvbWUgc3VwcG9ydCBmb3IgaXQgdm9pY2VkLiBBcyB3ZWxsIGFzIHRhbGsgb2YNCiBv dGhlciBhcHByb2FjaGVzIHRoYXQgY291bGQgYmUgYWx0ZXJuYXRpdmVzIG9yIGFkZGl0aW9uYWwg bWVhc3VyZXMuIEFuZCBhbHNvIHNvbWUgdm9jYWwgb3Bwb3NpdGlvbiB0byBpdC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFNhdCwgRmViIDksIDIwMTkgYXQgMzowOSBBTSBEb21pbmljayBCYWllciAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2Js YW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+V2UgYXJlIGN1 cnJlbnRseSBpbXBsZW1lbnRpbmcgTVRMUyBpbiBJZGVudGl0eVNlcnZlci48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPk91ciBh cHByb2FjaCB3aWxsIGJlIHRoYXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBv aW50IHRoYXQgc3VwcG9ydHMgY2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGlu ZyBhbiBvZmZpY2lhbA0KIGVuZHBvaW50IG5hbWUgZm9yIGRpc2NvdmVyeT8gUmlnaHQgbm93IHdl IGFyZSB1c2luZyDigJxtdGxzX3Rva2VuX2VuZHBvaW504oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7i gJTigJTigJQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRv bWluaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTk5MzI4ODEzNzA4NTA5MzMy Z21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWls LW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIx OTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQy ODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4 ODc0MSI+DQpPbiA3LiBGZWJydWFyeSAyMDE5IGF0IDIyOjM2OjU1LCBCcmlhbiBDYW1wYmVsbCAo PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmll dGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BaCB5ZXMsIHRoYXQgbWFrZXMg c2Vuc2UuIFRoYW5rcyBmb3IgY2xhcmlmeWluZy4gQW5kIGl0IGlzIGluZGVlZCBhIGdvb2QgcmVt aW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9jdW91cyBjaGFuZ2UgdGhhdCBzaG91bGQg YmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGJyZWFrIHRoaW5ncyB1bmV4cGVjdGVkbHkuLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBGZWIgNywgMjAxOSBhdCA4OjU3IEFNIFJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1h em9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+VGhlIGNhc2UgSeKAmW0gcmVmZXJlbmNpbmcgZGlkbuKAmXQgc3BlY2lmaWNhbGx5 IGludm9sdmUgQVMgbWV0YWRhdGEuIFdlIGhhZCBjbGllbnRzIGluIHRoZSB3aWxkIHRoYXQgYXNz dW1lZCB0aGF0IGFsbCB0aGUgcHJvcGVydGllcyBpbiB0aGUgSlNPTiBvYmplY3QgcmV0dXJuZWQg ZnJvbSBvdXIgdXNlcmluZm8gZW5kcG9pbnQNCiB3ZXJlIHNjYWxhciBzdHJpbmdzLiBUaGlzIGJy b2tlIHdoZW4gd2UgaW50cm9kdWNlZCBhIG5ldyBwcm9wZXJ0eSB3aG9zZSB2YWx1ZSB3YXMgYSBK U09OIG9iamVjdC4gSXQgd2FzIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkg aW5ub2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4g Zm9yY2UgbW9yZSB3b3JrIG9uIGNsaWVudHMgdGhhbiB3ZSBleHBlY3QuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IFdlZG5lc2RheSwgRmVi cnVhcnkgNiwgMjAxOSBhdCAxMTozMCBBTTxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7UmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7UmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBvYXV0aCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBbVU5WRVJJ RklFRCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRv a2VuIGVuZHBvaW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBJJ20gaG9uZXN0bHkgcmVhbGx5IHN0cnVn Z2xpbmcgdG8gc2VlIHdoYXQgY291bGQgaGF2ZSBnb25lIHdyb25nIHdpdGggb3IgaG93IHRva2Vu X2VuZHBvaW50X2F1dGhfbWV0aG9kcyBicm9rZSBzb21ldGhpbmcgd2l0aCB0aGUgdXNlciBpbmZv IGVuZHBvaW50LiBJZiB5b3UgaGF2ZSB0aGUgdGltZSBhbmQvb3INCiBpdCdkIGJlIGluZm9ybWF0 aXZlIHRvIHRoaXMgaGVyZSBsaXR0bGUgZGlzY3Vzc2lvbiwgcGxlYXNlIGV4cGxhaW4gdGhhdCBv bmUgYSBiaXQgbW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBXZWQsIEZlYiA2LCAyMDE5IGF0IDEyOjE1IFBNIEJyaWFuIENhbXBiZWxsICZs dDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2Js YW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0O2JvcmRlci10b3A6Y3VycmVudGNvbG9yO2JvcmRlci1yaWdodDpjdXJyZW50Y29sb3I7Ym9y ZGVyLWJvdHRvbTpjdXJyZW50Y29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mcXVvdDtmYXImcXVvdDsgc2hvdWxkIGhhdmUgc2FpZCAmcXVvdDtmYWly JnF1b3Q7IGluIHRoZSBwcmV2aW91cyBtZXNzYWdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBG ZWIgNSwgMjAxOSBhdCA0OjM1IFBNIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci10b3A6Y3Vy cmVudGNvbG9yO2JvcmRlci1yaWdodDpjdXJyZW50Y29sb3I7Ym9yZGVyLWJvdHRvbTpjdXJyZW50 Y29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBt YXkgd2VsbCBiZSBkdWUgdG8gbXkgb3duIGludGVsbGVjdHVhbCBzaG9ydGNvbWluZ3MgYnV0IHRo ZXNlIGlzc3Vlcy9xdWVzdGlvbnMvY29uZnVzaW9uLXBvaW50cyBhcmUgbm90IHJlc29uYXRpbmcg Zm9yIG1lIGFzIGJlaW5nIHByb2JsZW1hdGljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG1vcmUgZ2VuZXJhbCBzdGFuY2Ugb2Yg JnF1b3Q7dGhpcyBpc24ndCBuZWVkZWQgb3Igd29ydGggaXQgaW4gdGhpcyBkb2N1bWVudCZxdW90 OyAoSSB0aGluayB0aGF0J3MgZmFyPykgaXMgYmVpbmcgaGVhcmQgdGhvdWdoLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDE6NDIgUE0gUmljaGFyZCBCYWNr bWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21A ZG1hcmMuaWV0Zi4uLi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItdG9wOmN1cnJlbnRjb2xv cjtib3JkZXItcmlnaHQ6Y3VycmVudGNvbG9yO2JvcmRlci1ib3R0b206Y3VycmVudGNvbG9yIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oVEw7RFI6IHB1bnQgQVMgbWV0 YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCk8YnI+DQo8YnI+DQpBUyBwb2ludHMgIzEtMyBhcmUg YWxsIHF1ZXN0aW9ucyBJIHdvdWxkIGhhdmUgYXMgYW4gaW1wbGVtZW50ZXI6PG86cD48L286cD48 L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJtMTk5MzI4ODEzNzA4NTA5 MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdt YWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwt bTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzcz MjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4 Mjg4ODc0MSIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDE0I3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsi PlNlY3Rpb24gMiBvZiBSRkM4NDE0PC9hPiBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJ UkVEIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0g U28gd2hhdCBkb2VzIHRoZSBtVExTLW9ubHkgQVMgcHV0IGhlcmU/DQo8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVn bWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwt bS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4 MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgy NDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MSIgc3R5bGU9Im1zby1saXN0OmwyIGxl dmVsMSBsZm8xIj4NClRoZSBjbGFpbXMgZm9yIHRoZXNlIG90aGVyIGVuZHBvaW50cyBhcmUgT1BU SU9OQUwsIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8gaW5jb25zaXN0ZW5jeSBkZXBlbmRpbmcgb24g aG93ICMxIGdldHMgZGVjaWRlZC4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Im0xOTkzMjg4 MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3 NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1 MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdtYWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dt YWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwtbTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1t NzU5MzAzMzgyODg4NzQxIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPg0KVGhlIGV4 YW1wbGUgdXNhZ2Ugb2YgdGhlIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBwcm9wZXJ0eSBn aXZlbiBlYXJsaWVyIGlzIGluY29tcGF0aWJsZSB3aXRoIFJGQzg0MTQsIHNpbmNlIHNvbWUgb2Yg aXRzIGNvbnRlbnRzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbm9uLW1UTFMgZW5kcG9pbnRzLCBh bmQgb3RoZXJzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbVRMUyBlbmRwb2ludHMuIEhlbmNlIHRo aXMgcXVlc3Rpb24uDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJtMTk5MzI4ODEzNzA4NTA5 MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdt YWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwt bTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNnbWFpbC1tMzcz MjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwtbTc1OTMwMzM4 Mjg4ODc0MSIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NClRoaXMgaW50cm9kdWNl cyBhIG5ldyBtZXRhZGF0YSBwcm9wZXJ0eSB0aGF0IGNvdWxkIGltcGFjdCBob3cgb3RoZXIgc3Bl Y3Mgc2hvdWxkIGV4dGVuZCBBUyBtZXRhZGF0YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQu DQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgY291bGQgZ28gb24gZm9yIGNs aWVudCBwb2ludHMgYnV0IHlvdSBhbHJlYWR5IGdldCB0aGUgcG9pbnQuIFRob3VnaCBJ4oCZbGwg c2hhcmUgdGhhdCAjMyBpcyByZWFsIGFuZCBvbmNlIGZvcmNlZCBtZSB0byByb2xsIGJhY2sgYW4g dXBkYXRlIHRvIHRoZSBMb2dpbiB3aXRoIEFtYXpvbiB1c2VyaW5mbyBlbmRwb2ludOKApmdvb2QN CiB0aW1lcy4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2pp JnF1b3Q7Ij4mIzEyODUxNTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRv buKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEgcHJvcGVydHkgaXMgd3Jvbmcg cGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJvbHRpbmcgYSBsYXllciBvZiBm bGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZdCBkZXNpZ25lZCBmb3IgdGhh dCwgYW5kIEkNCiBkb27igJl0IHRoaW5rIHRoZSBtZXRhZGF0YSBwcm9wb3NhbCBhcyBpdOKAmXMg YmVlbiBkaXNjdXNzZWQgaGVyZSBzdWZmaWNpZW50bHkgZGVhbHMgd2l0aCB0aGUgZmFsbG91dCBm cm9tIHRoYXQuIEluIG15IHZpZXcgdGhpcyBpcyBhIGNvbXBsZXggZW5vdWdoIGlzc3VlIGFuZCBp dOKAmXMgZm9yIGEgbnVhbmNlZCBlbm91Z2ggdXNlIGNhc2UgKGFzIGZhciBhcyBJIGNhbiB0ZWxs IGZyb20gZGlzY3Vzc2lvbj8gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSeKAmW0gd3JvbmcpDQogdGhh dCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFyYXRlIGRyYWZ0IChlLmcuLCDigJxBdXRob3Jp emF0aW9uIFNlcnZlciBNZXRhZGF0YSBFeHRlbnNpb25zIGZvciBtVExTIEh5YnJpZHPigJ0pIGFu ZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPk9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYg b2YgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRl bnRpdHkuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBwaW5naWRlbnRpdHku Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjwvYj4gTW9uZGF5LCBGZWJy dWFyeSA0LCAyMDE5IGF0IDU6MjggQU08YnI+DQo8Yj5Ubzo8L2I+ICZxdW90O1JpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6 b24uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRFUl0g UmU6IE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhvc2UgcG9pbnRzIG9mIGNvbmZ1 c2lvbiBzdHJpa2UgbWUgYXMgc29tZXdoYXQgaHlwb3RoZXRpY2FsIG9yIGh5cGVyYm9saWMuIEJ1 dCB5b3VyIGdlbmVyYWwgcG9pbnQgaXMgdGFrZW4gYW5kIHlvdXIgcG9zaXRpb24gb2YgYmVpbmcg YW50aSBhZGRpdGlvbmFsIG1ldGFkYXRhIG9uIHRoaXMgaXNzdWUgaXMNCiBub3RlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsbCBv ZiB3aGljaCBsZWF2ZXMgbWUgYSBiaXQgdW5jZXJ0YWluIGFib3V0IGhvdyB0byBwcm9jZWVkLiBU aGVyZSBzZWVtIHRvIGJlIGEgcmFuZ2Ugb2Ygb3BpbmlvbnMgb24gdGhpcyBwb2ludCBhbmQgZ2F1 Z2luZyBjb25zZW5zdXMgaXMgcHJvdmluZyBlbHVzaXZlIGZvciBtZS4gVGhhdCdzIGNvbmZvdW5k ZWQNCiBieSBteSBvd24gb3BpbmlvbiBvbiBpdCBiZWluZyBzb21ld2hhdCBmbHVpZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBJ J2QgcmVhbGx5IGxpa2UgdG8gcG9zdCBhbiB1cGRhdGUgdG8gdGhpcyBkcmFmdCBhYm91dCBhIG1v bnRoIG9yIHR3byBhZ28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgNTowMyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRm Li4uLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci10b3A6Y3VycmVudGNvbG9yO2JvcmRlci1y aWdodDpjdXJyZW50Y29sb3I7Ym9yZGVyLWJvdHRvbTpjdXJyZW50Y29sb3IiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBBU+KAmXMgcGVy c3BlY3RpdmU6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1t MjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2 NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2 MzE3MzI2NDk5OTNnbWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3 ODk0MDE1Z21haWwtbTc1OTMwMzM4Mjg4ODc0MSIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCklmIEkgb25seSBzdXBwb3J0IG1UTFMsIGRvIEkgbmVlZCB0byBpbmNsdWRlIGJvdGgg dG9rZW5fZW5kcG9pbnRfdXJpIGFuZCBtdGxzX2VuZHBvaW50cz8gU2hvdWxkIEkgb21pdCB0b2tl bl9lbmRwb2ludF91cmk/IE9yIHNldCBpdCB0byB0aGUgZW1wdHkgc3RyaW5nPw0KPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0ibTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5 MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcy MmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21h aWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1t NTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEiIHN0eWxlPSJtc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQpXaGF0IGlmIEkgb25seSBzdXBwb3J0IG1UTFMgZm9yIHRoZSB0 b2tlbiBlbmRwb2ludCwgYnV0IG5vdCByZXZvY2F0aW9uIG9yIHVzZXIgaW5mbz8NCjxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Im0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTcz OTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3 MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzExODM2MjEzMWdt YWlsLW0tMzgwMDQxNzYzMTczMjY0OTk5M2dtYWlsLW0zNzMyNDI4MDMwNTI5MTE4NzcxZ21haWwt bTUxNDc1ODI0MjcwNTc4OTQwMTVnbWFpbC1tNzU5MzAzMzgyODg4NzQxIiBzdHlsZT0ibXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPg0KSG93IGRvIEkgc3BlY2lmeSBhdXRoZW50aWNhdGlvbiBtZXRo b2RzIGZvciB0aGUgbVRMUyB0b2tlbiBlbmRwb2ludD8gRG9lcyB0b2tlbl9lbmRwb2ludF9hdXRo X21ldGhvZHMgYXBwbHkgdG8gYm90aCB0aGUgbVRMUyBhbmQgbm9uLW1UTFMgZW5kcG9pbnRzPw0K PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0ibTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEz NDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgw NTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4 MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3 NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEiIHN0eWxl PSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpJ4oCZbSB1c2luZyB0aGUgT0F1dGggMi4wIERl dmljZSBGbG93LiBEbyBJIGluY2x1ZGUgYSBtVExTLWVuYWJsZWQgZGV2aWNlX2F1dGhvcml6YXRp b25fZW5kcG9pbnQgdW5kZXIgbXRsc19lbmRwb2ludHM/DQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBjbGllbnTigJlzIHBlcnNwZWN0aXZlOjxv OnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0ibTE5OTMy ODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3 OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0 NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkz Z21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWls LW03NTkzMDMzODI4ODg3NDEiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpBcyBm YXIgYXMgSSBrbm93LCBJ4oCZbSBhIHB1YmxpYyBjbGllbnQsIGFuZCBkb27igJl0IGtub3cgYW55 dGhpbmcgYWJvdXQgbVRMUywgYnV0IHRoZSBJVCBhZG1pbnMgaW5zdGFsbGVkIGNsaWVudCBjZXJ0 cyBpbiB0aGVpciB1c2Vyc+KAmSBicm93c2VycyBhbmQgdGhlIEFTIGV4cGVjdHMgdG8gdXNlIHRo YXQgdG8gYXV0aGVudGljYXRlIG1lLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0ibTE5OTMy ODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3 OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0 NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3NjMxNzMyNjQ5OTkz Z21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1Nzg5NDAxNWdtYWls LW03NTkzMDMzODI4ODg3NDEiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpNeSBB UyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRl ZCB0b2tlbl9lbmRwb2ludF91cmkuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJtMTk5MzI4 ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5 NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0 NTA5Z21haWwtbTIxOTY1MzI1NDMxMTgzNjIxMzFnbWFpbC1tLTM4MDA0MTc2MzE3MzI2NDk5OTNn bWFpbC1tMzczMjQyODAzMDUyOTExODc3MWdtYWlsLW01MTQ3NTgyNDI3MDU3ODk0MDE1Z21haWwt bTc1OTMwMzM4Mjg4ODc0MSIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCk15IEFT IG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRvIGVu Y291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLg0KPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0ibTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3 Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdt YWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwt bS0zODAwNDE3NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0 NzU4MjQyNzA1Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEiIHN0eWxlPSJtc28tbGlzdDps MSBsZXZlbDEgbGZvMyI+DQpUaGUgbVRMUy1vbmx5IEFTIGRpZG7igJl0IHByb3ZpZGUgYSB2YWx1 ZSBmb3IgbXRsc19lbmRwb2ludHMsIHdoYXQgZG8gSSBkbz8gPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0ibTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwt bTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4 NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMTE4MzYyMTMxZ21haWwtbS0zODAwNDE3 NjMxNzMyNjQ5OTkzZ21haWwtbTM3MzI0MjgwMzA1MjkxMTg3NzFnbWFpbC1tNTE0NzU4MjQyNzA1 Nzg5NDAxNWdtYWlsLW03NTkzMDMzODI4ODg3NDEiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEg bGZvMyI+DQpJIGRvbuKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKAnSBtZWFucywgYnV0IHRoZXkg dG9sZCBtZSB0byB1c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0aGUgb25lIHdpdGgg4oCcdGxz 4oCdIGluIGl0cyBuYW1lLCByaWdodD8NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+WWVzLCB5b3UgY2FuIHdyaXRlIG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5zd2VycyBtb3N0IG9m IHRoZXNlLiBCdXQgeW914oCZbGwgaGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEgbG90IG9mIHNpbWls YXItYnV0LXNsaWdodGx5LWRpZmZlcmVudCBzY2VuYXJpb3MgYW5kIGJlIHZlcnkgZXhwbGljaXQu IEFuZCBpbXBsZW1lbnRlcnMNCiB3aWxsIHN0aWxsIGdldCBpdCB3cm9uZy4gVGhlIG1ldGFkYXRh IGNoYW5nZSBpbnRyb2R1Y2VzIG9wcG9ydHVuaXRpZXMgZm9yIGNvbmZ1c2lvbiBhbmQgZmFpbHVy ZSB0aGF0IGRvIG5vdCBleGlzdCBub3csIGFuZCBmb3JjZXMgdGhlbSBvbiBldmVyeW9uZSB3aG8g c3VwcG9ydHMgbVRMUy4gSW4gY29udHJhc3QsIHRoZSAzMDcgcmVkaXJlY3QgaXMgb25seSByZXF1 aXJlZCB3aGVuIGFuIEFTIHdhbnRzIHRvIHN1cHBvcnQgYm90aCwgYW5kIGlzIHVuYW1iaWd1b3Vz DQogaW4gaXRzIGJlaGF2aW9yIGFuZCBtZWFuaW5nLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1Mg SWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5CcmlhbiBDYW1wYmVsbCAm bHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMzox NyBQTTxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBHZW9yZ2UgRmxl dGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIiB0YXJnZXQ9Il9ibGFu ayI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7LCBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBbT0FVVEgtV0ddIE1UTFMg YW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxhcmdl IG9mIGEgY2hhbmdlIHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0aGUg Z2l2ZW4gZW5kcG9pbnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0IHVz ZXMgdGhhdCBvbmUuJm5ic3A7IE90aGVyd2lzZQ0KIGl0IHVzZXMgdGhlIHJlZ3VsYXIgZW5kcG9p bnQuIEl0IGdpdmVzIGFuIEFTIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQgb3B0 aW9ucy4gSSBwZXJzb25hbGx5IHRoaW5rIGdldHRpbmcgYSAzMDcgYXBwcm9hY2ggZGVwbG95ZWQg YW5kIHdvcmtpbmcgd291bGQgYmUgbW9yZSBjb21wbGljYXRlZCBhbmQgZXJyb3IgcHJvbmUuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNlIGF0IHRoZSBtb21lbnQgYnV0IHRoZXJlIGFy ZSBmb3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVzaCBmb3IgaW5jcmVhc2VkIHNlY3VyaXR5IGlu IGdlbmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlwdCBjbGllbnRzIHVzZSB0aGUgY29kZSBmbG93 LCB0aGF0IHN1Z2dlc3QNCiBpdCB3b24ndCBiZSB0ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBB UyB0aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBjbGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBj bGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ3ZlIHBlcnNvbmFsbHkgd2F2ZXJlZCBiYWNrIGFu ZCBmb3J0aCBpbiB0aGlzIHRocmVhZCBvbiB3aGV0aGVyIG9yIG5vdCB0byBhZGQgdGhlIG5ldyBt ZXRhZGF0YSAob3Igc29tZXRoaW5nIGxpa2UgaXQpLiBXaXRoIG15IHJlYXNvbmluZyBlYWNoIHdh eSBraW5kYSBleHBsYWluZWQgc29tZXdoZXJlIGJhY2sNCiBpbiB0aGUgNDAgb3Igc28gbWVzc2Fn ZXMgdGhhdCBtYWtlIHVwIHRoaXMgdGhyZWFkLiZuYnNwOyBCdXQgaXQgc2VlbXMgbGlrZSB0aGUg cm91Z2ggY29uc2Vuc3VzIG9mIHRoZSBncm91cCBoZXJlIGlzIGluIGZhdm9yIG9mIGl0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6MTggUE0gUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5j b21AZG1hcmMuaWV0Zi4uLi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItdG9wOmN1cnJlbnRj b2xvcjtib3JkZXItcmlnaHQ6Y3VycmVudGNvbG9yO2JvcmRlci1ib3R0b206Y3VycmVudGNvbG9y Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHN0cmlrZXMgbWUg YXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVzaW5nIGNoYW5nZSB0byBzdXBwb3J0IHdoYXQg c2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2FzZS4gSeKAmW0gZ2V0dGluZyBhIGhlYWRhY2hl IGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQgbmVlZGVkIHRvIGNsYXJpZnkgd2hlbg0KIHRo ZSBBUyBzaG91bGQgcHJvdmlkZSBgbXRsc19lbmRwb2ludHNgIGFuZCB3aGVuIHRoZSBjbGllbnQg c2hvdWxkIHVzZSB0aGF0IHZlcnN1cyB1c2luZyBgdG9rZW5fZW5kcG9pbnQuYCBXaHkgaXMgdGhl IDMwNyBzdGF0dXMgY29kZSBpbnN1ZmZpY2llbnQgdG8gY292ZXIgdGhlIGNhc2Ugd2hlcmUgYSBz aW5nbGUgQVMgc3VwcG9ydHMgYm90aCBtVExTIGFuZCBub24tbVRMUz88bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50aXR5PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9 Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMTozMSBQTTxicj4NCjxiPlRvOjwvYj4g R2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86NDBhb2wuY29tQGRt YXJjLi4uLi4uLi4uaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGll bnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgdGhhdCB3b3VsZCB3b3Jr LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBHZW9yZ2UgRmxldGNoZXIgJmx0O2dmZmxl dGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dDtib3JkZXItdG9wOmN1cnJlbnRjb2xvcjtib3JkZXItcmlnaHQ6Y3VycmVudGNvbG9yO2JvcmRl ci1ib3R0b206Y3VycmVudGNvbG9yIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPldoYXQgaWYgdGhlIEFTIHdhbnRzIHRvIE9OTFkg c3VwcG9ydCBNVExTIGNvbm5lY3Rpb25zLiBEb2VzIGl0IG5vdCBzcGVjaWZ5IHRoZSBvcHRpb25h bCAmcXVvdDttdGxzX2VuZHBvaW50cyZxdW90OyBhbmQganVzdCB1c2UgdGhlIG5vcm1hbCBtZXRh ZGF0YSB2YWx1ZXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gMS8xNS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkl0IHdvdWxkIGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0 IHdhc24ndCBtYWRlIGNsZWFyLiBJdCdkIGJlIHNvbWV0aGluZyB0byB0aGUgZWZmZWN0IG9mIG9w dGlvbmFsIGZvciB0aGUgQVMgdG8gaW5jbHVkZSBhbmQgY2xpZW50cyBkb2luZyBNVExTIHdvdWxk IHVzZSBpdCB3aGVuDQogcHJlc2VudCBpbiBBUyBtZXRhZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAy OjA0IEFNIERhdmUgVG9uZ2UgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZlLnRvbmdlQG1vbWVudHVt ZnQuY28udWsiIHRhcmdldD0iX2JsYW5rIj5kYXZlLnRvbmdlQG1vbWVudHVtZnQuY28udWs8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkknbSBpbiBmYXZvdXIgb2YgdGhl IGBtdGxzX2VuZHBvaW50c2AgbWV0YWRhdGEgcGFyYW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxk IGJlIG9wdGlvbmFsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q09ORklE RU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5k IHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUNCiByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZp bGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48 bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1 O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFj aG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2Jv cmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBO T1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk IG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g QW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1 NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBv dGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0 dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1 O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywNCiB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFj aG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPg0KIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywNCiB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzU1NTU1NTti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku IEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2ht ZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyA8YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3QgPGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_141CD215A86A49269FD6F58DD966F40Famazoncom_-- From nobody Wed Feb 13 15:01:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B89130E6E for ; Wed, 13 Feb 2019 15:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xmlgrrl-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWJNTju6h4Kg for ; Wed, 13 Feb 2019 15:01:38 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E984130DC4 for ; Wed, 13 Feb 2019 15:01:38 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id t18so4447453wrx.2 for ; Wed, 13 Feb 2019 15:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xmlgrrl-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8PzdPK2nhrGX7kJRqV1jP+SqZl9uuBEdsLa6LFFBHgs=; b=eUO6iXqlEBxdEbtYdZA6D7stRHQhbaRkaTXu5a1+HCEeDaNZVdcGUtGOaQrQ5w7iz1 MbS3R03o2iMZhWHyVzP+0fp1Y8C1VYlRik3F1K0Q23BDXIchyPmGjpv/x5O5T8RKzNld +In+4STwfxvL29sF8+QQG3BfYc1lh/BmpNZXLiQFebczcsqeIrL8sI5DHM0HVcwIw+mQ L9+cilzHJ6FE6Gbxolh/sYC0I3pzIhekYRVk+KHCg8aClz7dfWCp6ukf9VWkmbAMlJXi WvJp/S2K077YIkrIUCizKF/FJMi3ErYz8tr3TN0CdwYI3CfNYm/7Pw043kIbNvz8AWZF naRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8PzdPK2nhrGX7kJRqV1jP+SqZl9uuBEdsLa6LFFBHgs=; b=sNeaOlO+YtboDDB375NhFZcNg5U+2480E11U2WktLbQFbrf4bqbE2clNOGV6lzY3yt mSmA1NsqY99Edk2lh/q8pUNMpTxNASJOdn+vMEUFZ1m7E6MMFPSSFhjKslV5S/lvEo1A RT4OYScFnWFk6U9k/QjnsNbQqfj91tFh1W6YsJOvu9e9BWBv1qam3TgYahKqNvTIOGiB JFDJTUuT+L88ckxQ1lPHKqv0ZzJ9OJmpHhaM0wlOmO57loIX40iGQG2aHnOTgsPikdoM doMu1h3MI/6mdhq5UbwpO7LsP2Z2shIeHunNtIZJKBLQtaU6XGhrDjHuonf4D7nIKiFG BsWw== X-Gm-Message-State: AHQUAuaRTuIxal2eZAp6m23pK6CxNiJzbW9xTvJ7RILauFM9y9jeL23d rCQKGGOS+6JSCxHeGUqlaSZdyXn0WpEqduiOddXOwcQsNHo= X-Google-Smtp-Source: AHgI3IYm0G3u3B71QcjU+ZioaBAZ8XSmm9jTlaGVVnk8t4ZLCw7uMSVL78P1Qt7/7jodKDGGdGQG8ulxFIjzxBGviUI= X-Received: by 2002:adf:e8ca:: with SMTP id k10mr325781wrn.191.1550098896523; Wed, 13 Feb 2019 15:01:36 -0800 (PST) MIME-Version: 1.0 From: Eve Maler Date: Wed, 13 Feb 2019 17:01:25 -0600 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000182cea0581ce86dd" Archived-At: Subject: [OAUTH-WG] New User-Managed Access (UMA) drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 23:01:41 -0000 --000000000000182cea0581ce86dd Content-Type: text/plain; charset="UTF-8" Howdy folks-- Since UMA2 concepts and flows have been coming up here from time to time related to ongoing discussions and drafts, and there's an increasing number of implementers[1], the UMA group at Kantara decided to contribute the specs (known colloquially as "UMA Grant"[2] and "UMA Federated Authorization"[3]) in the hope they may be of interest as work items. We've been in touch with the chairs about doing a presentation in Prague. If you're not familiar at all with UMA2, the Introduction section of each spec gives a concise description. [1] https://kantarainitiative.org/confluence/display/uma/UMA+Implementations [2] https://tools.ietf.org/html/draft-maler-oauth-umagrant [3] https://tools.ietf.org/html/draft-maler-oauth-umafedauthz *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl --000000000000182cea0581ce86dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy folks-- Since UMA2 concep= ts and flows have been coming up here from time to time related to ongoing = discussions and drafts, and there's an increasing number of implementer= s[1], the UMA group at Kantara decided to contribute the specs (known collo= quially as "UMA Grant"[2] and "UMA Federated Authorization&q= uot;[3]) in the hope they may be of interest as work items.

We've been in touch with the chairs= about doing a presentation in Prague. If you're not familiar at all wi= th UMA2, the Introduction section of each spec gives a concise description.=


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<= br>

<= /div>
--000000000000182cea0581ce86dd-- From nobody Thu Feb 14 02:50:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8A128D0B for ; Thu, 14 Feb 2019 02:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhwyVLCg35h4 for ; Thu, 14 Feb 2019 02:50:20 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::60e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916EE131050 for ; Thu, 14 Feb 2019 02:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c5rbQd4LhhMM6WWazckPCNv59sZ1Vw5EbX1IMHGrFhc=; b=QnhSRzrfVzbjRtxSt89faRceb5vuAfRuUhNkij1n6zKNyTy2vJ9smwzralgk+jrnIexBvipz6XITPaG5cAhC0cpmbKBZqhA3bapVGSOwxVcGuvfGg4uhXZXIiZ8tIp+TEf8ZGQWBn671NdDbCpBgZuYtYFBNHYL6FxXvonW8eDg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1519.eurprd08.prod.outlook.com (10.167.210.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 10:50:16 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 10:50:16 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Reminder - FW: [OAUTH-WG] 4th OAuth Security Workshop - Registration now open! Thread-Index: AdTDuhzG4FVfPOkQSUeONaQIeOkYdg== Date: Thu, 14 Feb 2019 10:50:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.106.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eac08973-3303-4453-7df9-08d6926a34cd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1519; x-ms-traffictypediagnostic: VI1PR0801MB1519: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1519; 20:Gi02Av6RL8vSa9NRadL/y5tuHf4UP3KxObh3D/R/GlieY4PSU1qAk+Ots4e8ac30UckYo6w39FM3zb5FIIPKflOsWWRyGjxT7hVuNbUDpIpQB8clALP7zOQH68ZAyVSW7HCzKK4RO+SD36aZxdqy1GU35Rd1c7DD79/QXvXku4M= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(366004)(39860400002)(136003)(40434004)(12213003)(189003)(199004)(2351001)(8936002)(2420400007)(2501003)(26005)(105586002)(606006)(99286004)(66066001)(86362001)(6436002)(5640700003)(74316002)(6916009)(106356001)(15650500001)(14454004)(7110500001)(7736002)(6506007)(97736004)(14444005)(5024004)(256004)(68736007)(53936002)(486006)(25786009)(186003)(478600001)(1730700003)(8676002)(476003)(3846002)(54896002)(71190400001)(236005)(966005)(102836004)(55016002)(72206003)(33656002)(6306002)(7696005)(2906002)(71200400001)(561944003)(316002)(81156014)(6116002)(81166006)(790700001)(9686003)(53546011)(10710500007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1519; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pq2KLfv8xzRE7QjqjTKsmNVHAFiKBNEOf63199lYaYBDQjdP9PZyGG2cU8fEsJdM8SHymkFIO8Wm3Eo5y7lKaHW1ULQo44QFf6g23gFLuTvAhED6Nzm9UPFjE3d0FwCSuvvwky/ahBu8oC1ERbjouyZByQETtYt7ewIcP7duL+Islcmc8i4Gb6NhQmJFz/sK68S4nG1mWpHsMrls0fyaY1asz3qJeUkhYRu8l81+Wp7qM+wZNwSo+sc1MhYZYPL5dardok7rlZoYKcnkJAGlE1CDHOO8GM4WHfONOyL2mX/4IvHT/haQKXl/O7SLgG5QI3Rl6l1+OSP2n/AZSI3/nPJ+PoqLE4M2m1Kh2xapm2yrVFIYKxrQXr12RsC3NEoNZA2hEItkDKZoW0Z4bYC6NKaGXVGAOdMOvtRjbEyp0As= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211281CAB129E05885FEC9FBFA670VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: eac08973-3303-4453-7df9-08d6926a34cd X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 10:50:16.7743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1519 Archived-At: Subject: [OAUTH-WG] Reminder - FW: 4th OAuth Security Workshop - Registration now open! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 10:50:27 -0000 --_000_VI1PR0801MB211281CAB129E05885FEC9FBFA670VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBzaG9ydCByZW1pbmRlciB0byBzdWJtaXQgeW91ciBwYXBlciBhbmQvb3IgdHV0b3JpYWwgZm9y IHRoZSB1cGNvbWluZyBPQXV0aCBTZWN1cml0eSB3b3Jrc2hvcC4NCg0KRnJvbTogT0F1dGggPG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBEYW5pZWwgRmV0dA0KU2VudDogRG9u bmVyc3RhZywgNy4gRmVicnVhciAyMDE5IDE2OjAzDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1Ympl Y3Q6IFtPQVVUSC1XR10gNHRoIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIC0gUmVnaXN0cmF0aW9u IG5vdyBvcGVuIQ0KDQoNCkFsbCwNCg0KVGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIDR0aCBPQXV0 aCBTZWN1cml0eSBXb3Jrc2hvcCAoTWFyY2ggMjAtMjIsIFN0dXR0Z2FydCkgaXMgbm93IG9wZW4u DQoNCkFzIHVzdWFsLCB0aGUgd29ya3Nob3Agd2lsbCBmZWF0dXJlIGludGVyZXN0aW5nIHRhbGtz IGFuZCBkaXNjdXNzaW9ucyBhcm91bmQgT0F1dGgsIE9wZW5JRCBDb25uZWN0LCBhbmQgcmVsYXRl ZCBzdGFuZGFyZHMgYW5kIHRlY2hub2xvZ2llcy4gVGhpcyB0aW1lLCB3ZSBhbHNvIGFpbSB0byBv ZmZlciB0dXRvcmlhbHMgb24gdGhlIG1vcm5pbmcgb2YgdGhlIGZpcnN0IGRheSBhbmQgYW4gdW5j b25mZXJlbmNlLXN0eWxlIHNlY29uZCBkYXkuDQoNClBsZWFzZSByZWdpc3RlciBhdCBodHRwczov L3NlYy51bmktc3R1dHRnYXJ0LmRlL2V2ZW50cy9vc3cyMDE5IC0gZWFybHkgYmlyZCBwcmljaW5n IGlzIGF2YWlsYWJsZSB1bnRpbCBNYXJjaCA1Lg0KDQpQbGVhc2UgYWxzbyBjb25zaWRlciBzdWJt aXR0aW5nIGEgcHJvcG9zYWwgZm9yIGEgc2Vzc2lvbiAodGFsay9kaXNjdXNzaW9uLy4uLikgb3Ig dHV0b3JpYWwgdW50aWwgRmVicnVhcnkgMTggKHNlZSBsaW5rIGFib3ZlKS4NCg0KLURhbmllbA0K DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB211281CAB129E05885FEC9FBFA670VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgc2hvcnQgcmVt aW5kZXIgdG8gc3VibWl0IHlvdXIgcGFwZXIgYW5kL29yIHR1dG9yaWFsIGZvciB0aGUgdXBjb21p bmcgT0F1dGggU2VjdXJpdHkgd29ya3Nob3AuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGFuaWVsIEZldHQ8YnI+DQo8Yj5TZW50 OjwvYj4gRG9ubmVyc3RhZywgNy4gRmVicnVhciAyMDE5IDE2OjAzPGJyPg0KPGI+VG86PC9iPiBv YXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIDR0aCBPQXV0aCBT ZWN1cml0eSBXb3Jrc2hvcCAtIFJlZ2lzdHJhdGlvbiBub3cgb3BlbiE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cD5BbGwsPG86cD48L286cD48L3A+DQo8cD5UaGUgcmVnaXN0cmF0aW9uIGZv ciB0aGUgNHRoIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIChNYXJjaCAyMC0yMiwgU3R1dHRnYXJ0 KSBpcyBub3cgb3Blbi48bzpwPjwvbzpwPjwvcD4NCjxwPkFzIHVzdWFsLCB0aGUgd29ya3Nob3Ag d2lsbCBmZWF0dXJlIGludGVyZXN0aW5nIHRhbGtzIGFuZCBkaXNjdXNzaW9ucyBhcm91bmQgT0F1 dGgsIE9wZW5JRCBDb25uZWN0LCBhbmQgcmVsYXRlZCBzdGFuZGFyZHMgYW5kIHRlY2hub2xvZ2ll cy4gVGhpcyB0aW1lLCB3ZSBhbHNvIGFpbSB0byBvZmZlciB0dXRvcmlhbHMgb24gdGhlIG1vcm5p bmcgb2YgdGhlIGZpcnN0IGRheSBhbmQgYW4gdW5jb25mZXJlbmNlLXN0eWxlIHNlY29uZCBkYXku PG86cD48L286cD48L3A+DQo8cD5QbGVhc2UgcmVnaXN0ZXIgYXQgPGEgaHJlZj0iaHR0cHM6Ly9z ZWMudW5pLXN0dXR0Z2FydC5kZS9ldmVudHMvb3N3MjAxOSI+aHR0cHM6Ly9zZWMudW5pLXN0dXR0 Z2FydC5kZS9ldmVudHMvb3N3MjAxOTwvYT4gLSBlYXJseSBiaXJkIHByaWNpbmcgaXMgYXZhaWxh YmxlIHVudGlsIE1hcmNoIDUuPG86cD48L286cD48L3A+DQo8cD5QbGVhc2UgYWxzbyBjb25zaWRl ciBzdWJtaXR0aW5nIGEgcHJvcG9zYWwgZm9yIGEgc2Vzc2lvbiAodGFsay9kaXNjdXNzaW9uLy4u Likgb3IgdHV0b3JpYWwgdW50aWwgRmVicnVhcnkgMTggKHNlZSBsaW5rIGFib3ZlKS48bzpwPjwv bzpwPjwvcD4NCjxwPi1EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwg dXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB211281CAB129E05885FEC9FBFA670VI1PR0801MB2112_-- From nobody Thu Feb 14 04:15:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5059013106D for ; Thu, 14 Feb 2019 04:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7n-qjox1KXO for ; Thu, 14 Feb 2019 04:15:37 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10054.outbound.protection.outlook.com [40.107.1.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2BC12D84D for ; Thu, 14 Feb 2019 04:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TSjInPn6I6KDs4xOW2c+ZPROk5UzgXTDdv8OcEP9hrg=; b=XD/64WVhKWzPMZy7z4ufiqxgYGa5deBYweVUbFIWX9CGSr8+IYRC+BNKOnUrCzP1y4PeSau6EO86DZaVHVUNiPL4i7WrboTCUsv/1inSVCugAx9nU50DYfEpk9zsyQ8WL9gGQBY9D0wUOZNoBpjyL9yO/Q8ykkDitgjaVm9kZXU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1774.eurprd08.prod.outlook.com (10.168.67.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Thu, 14 Feb 2019 12:15:33 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 12:15:33 +0000 From: Hannes Tschofenig To: Eve Maler , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] New User-Managed Access (UMA) drafts Thread-Index: AQHUw/AaJnl0M2NvHkuGAeiAuGhVUKXfNcJQ Date: Thu, 14 Feb 2019 12:15:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.106.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df8995b1-8ac4-4c5e-9d3d-08d692761e42 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1774; x-ms-traffictypediagnostic: VI1PR0801MB1774: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1774; 20:X1VWGjVDekjZr5hTYNXdV8X23yb+LBtF6LRRj2OXqemMS/TBQstR2YWTCd1mxAqCC2Fs0SGs+4GMd5D5ZhVRIr+Ht+IswOOv5oxzYIZ7iZ/fGHzEWCt3g7aV2LNHO1mP+qstTKKASvUqQ6nMAD0X2HZzeLEXPSsO6jvQDOcr0k4= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(396003)(366004)(199004)(189003)(40434004)(71190400001)(68736007)(606006)(2906002)(8676002)(446003)(55016002)(97736004)(11346002)(478600001)(81156014)(486006)(81166006)(236005)(71200400001)(105586002)(9686003)(6436002)(229853002)(106356001)(6306002)(2501003)(476003)(54896002)(33656002)(5024004)(14444005)(7696005)(790700001)(99286004)(554214002)(86362001)(66066001)(186003)(6506007)(53546011)(256004)(966005)(25786009)(72206003)(8936002)(110136005)(14454004)(76176011)(53936002)(316002)(74316002)(7736002)(102836004)(26005)(6246003)(3846002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1774; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4LZMtiZMMwGwXfKXGhOEnOR0twAapDI6X1KtwIddovaCd8t7Fl3IWsEBHqJ3n7FBh1nrcAZ7tOM40QPgCfzrMmrR84KHeSKp5R47tpSDT52WLOfAfuhj/4opHvfcw4zCRuFZMKMAgjJWfq57MOm6/Pp4gcjVtrRLjkma306jhm9umf5o9GMZPh+0bQNgUN7qkVWRuii0+drOD6EGOyBA0ue8eYI3h+7s/WB2Dv4XE+boDT3LZjaoHVwFL79BPw0MFJro4j0yKLCvvsZCXx/vDNBkfx2cTi4q65gyob3K1cAtnrD+1jKNpw5gL80OrgSm2wgYkwFJvjiuM0tpY0oTLbx9mWkeq4VNhA+46UxL7jibzPAu0XZLTJK378+eQqsuR/VQIkqpr2HsK0SgGTYbsX0SZOKdO6Q45YeZ+qLYwHg= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211255C9494ED5C0A6308168FA670VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: df8995b1-8ac4-4c5e-9d3d-08d692761e42 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 12:15:32.9801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1774 Archived-At: Subject: Re: [OAUTH-WG] New User-Managed Access (UMA) drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 12:15:40 -0000 --_000_VI1PR0801MB211255C9494ED5C0A6308168FA670VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBiaWcgdGhhbmtzIHRvIHRoZSBVTUEgdGVhbSBmb3IgdGhpcyBjb250cmlidXRpb24uIEkgYW0g bG9va2luZyBmb3J3YXJkIHRvIHRoZSBwcmVzZW50YXRpb24gYW5kIGRpc2N1c3Npb24gYXQgdGhl IG5leHQgSUVURiBtZWV0aW5nLg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogT0F1dGggPG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBFdmUgTWFsZXINClNlbnQ6IE1pdHR3b2No LCAxMy4gRmVicnVhciAyMDE5IDIzOjAxDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtP QVVUSC1XR10gTmV3IFVzZXItTWFuYWdlZCBBY2Nlc3MgKFVNQSkgZHJhZnRzDQoNCkhvd2R5IGZv bGtzLS0gU2luY2UgVU1BMiBjb25jZXB0cyBhbmQgZmxvd3MgaGF2ZSBiZWVuIGNvbWluZyB1cCBo ZXJlIGZyb20gdGltZSB0byB0aW1lIHJlbGF0ZWQgdG8gb25nb2luZyBkaXNjdXNzaW9ucyBhbmQg ZHJhZnRzLCBhbmQgdGhlcmUncyBhbiBpbmNyZWFzaW5nIG51bWJlciBvZiBpbXBsZW1lbnRlcnNb MV0sIHRoZSBVTUEgZ3JvdXAgYXQgS2FudGFyYSBkZWNpZGVkIHRvIGNvbnRyaWJ1dGUgdGhlIHNw ZWNzIChrbm93biBjb2xsb3F1aWFsbHkgYXMgIlVNQSBHcmFudCJbMl0gYW5kICJVTUEgRmVkZXJh dGVkIEF1dGhvcml6YXRpb24iWzNdKSBpbiB0aGUgaG9wZSB0aGV5IG1heSBiZSBvZiBpbnRlcmVz dCBhcyB3b3JrIGl0ZW1zLg0KDQpXZSd2ZSBiZWVuIGluIHRvdWNoIHdpdGggdGhlIGNoYWlycyBh Ym91dCBkb2luZyBhIHByZXNlbnRhdGlvbiBpbiBQcmFndWUuIElmIHlvdSdyZSBub3QgZmFtaWxp YXIgYXQgYWxsIHdpdGggVU1BMiwgdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIG9mIGVhY2ggc3Bl YyBnaXZlcyBhIGNvbmNpc2UgZGVzY3JpcHRpb24uDQoNClsxXSBodHRwczovL2thbnRhcmFpbml0 aWF0aXZlLm9yZy9jb25mbHVlbmNlL2Rpc3BsYXkvdW1hL1VNQStJbXBsZW1lbnRhdGlvbnMNClsy XSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFsZXItb2F1dGgtdW1hZ3JhbnQN ClszXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFsZXItb2F1dGgtdW1hZmVk YXV0aHoNCg0KRXZlIE1hbGVyDQpDZWxsICsxIDQyNS4zNDUuNjc1NiB8IFNreXBlOiB4bWxncnJs IHwgVHdpdHRlcjogQHhtbGdycmwNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsg eW91Lg0K --_000_VI1PR0801MB211255C9494ED5C0A6308168FA670VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkEgYmlnIHRoYW5rcyB0byB0aGUgVU1BIHRlYW0gZm9yIHRoaXMgY29u dHJpYnV0aW9uLiBJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgcHJlc2VudGF0aW9uIGFuZCBk aXNjdXNzaW9uIGF0IHRoZSBuZXh0IElFVEYgbWVldGluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaWFvPGJyPg0KSGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBPQXV0aCAmbHQ7 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXZlIE1hbGVy PGJyPg0KPGI+U2VudDo8L2I+IE1pdHR3b2NoLCAxMy4gRmVicnVhciAyMDE5IDIzOjAxPGJyPg0K PGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0dd IE5ldyBVc2VyLU1hbmFnZWQgQWNjZXNzIChVTUEpIGRyYWZ0czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhvd2R5IGZvbGtzLS0gU2luY2UgVU1BMiBjb25jZXB0cyBhbmQgZmxvd3MgaGF2ZSBiZWVu IGNvbWluZyB1cCBoZXJlIGZyb20gdGltZSB0byB0aW1lIHJlbGF0ZWQgdG8gb25nb2luZyBkaXNj dXNzaW9ucyBhbmQgZHJhZnRzLCBhbmQgdGhlcmUncyBhbiBpbmNyZWFzaW5nIG51bWJlciBvZiBp bXBsZW1lbnRlcnNbMV0sIHRoZSBVTUEgZ3JvdXAgYXQgS2FudGFyYSBkZWNpZGVkIHRvIGNvbnRy aWJ1dGUgdGhlIHNwZWNzDQogKGtub3duIGNvbGxvcXVpYWxseSBhcyAmcXVvdDtVTUEgR3JhbnQm cXVvdDtbMl0gYW5kICZxdW90O1VNQSBGZWRlcmF0ZWQgQXV0aG9yaXphdGlvbiZxdW90O1szXSkg aW4gdGhlIGhvcGUgdGhleSBtYXkgYmUgb2YgaW50ZXJlc3QgYXMgd29yayBpdGVtcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UndmUgYmVl biBpbiB0b3VjaCB3aXRoIHRoZSBjaGFpcnMgYWJvdXQgZG9pbmcgYSBwcmVzZW50YXRpb24gaW4g UHJhZ3VlLiBJZiB5b3UncmUgbm90IGZhbWlsaWFyIGF0IGFsbCB3aXRoIFVNQTIsIHRoZSBJbnRy b2R1Y3Rpb24gc2VjdGlvbiBvZiBlYWNoIHNwZWMgZ2l2ZXMgYSBjb25jaXNlIGRlc2NyaXB0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b MV0mbmJzcDs8YSBocmVmPSJodHRwczovL2thbnRhcmFpbml0aWF0aXZlLm9yZy9jb25mbHVlbmNl L2Rpc3BsYXkvdW1hL1VNQSYjNDM7SW1wbGVtZW50YXRpb25zIj5odHRwczovL2thbnRhcmFpbml0 aWF0aXZlLm9yZy9jb25mbHVlbmNlL2Rpc3BsYXkvdW1hL1VNQSYjNDM7SW1wbGVtZW50YXRpb25z PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlsyXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFs ZXItb2F1dGgtdW1hZ3JhbnQiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1h bGVyLW9hdXRoLXVtYWdyYW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WzNdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1tYWxlci1vYXV0aC11bWFmZWRhdXRoeiI+DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbWFsZXItb2F1dGgtdW1hZmVkYXV0aHo8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5F dmUgTWFsZXI8YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkNl bGwgJiM0MzsxIDQyNS4zNDUuNjc1NiB8IFNreXBlOiB4bWxncnJsIHwgVHdpdHRlcjogQHhtbGdy cmw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB211255C9494ED5C0A6308168FA670VI1PR0801MB2112_-- From nobody Thu Feb 14 08:57:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34CB128CE4 for ; Thu, 14 Feb 2019 08:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXQmB_S-CMNr for ; Thu, 14 Feb 2019 08:56:56 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592EC1271FF for ; Thu, 14 Feb 2019 08:56:55 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id 2so7630060qtb.5 for ; Thu, 14 Feb 2019 08:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=iGRKy1q3l1FowpMP1uMo8sqp2H6VQuN5A7qM9dTdstY=; b=yt9BMIIredQLqh/l63Gv4TwXnqZEO3/+9trh593a6dNLFRMuztUYTDNXd0DxPGyvAh dbU/jTAcACCQ8xrkA0l6QTlnvP5ee4h7LYz9LEFlbynIqTccUmYepax0d1UPcPzP3B2a wbGJENh9kPC2eo0LkL6d3ekvQSEJqrVRvTXcPEXQVI8Z1/6f2ZNYteKXrWCf7YCRwf20 +YZIDLESVOfW76GbHksP8F1j+zrBVzQLrcyiNzdgBiadbexqY1Pwg+K9DZy65bGRii/n OegFM+OOTALjrpuvIydyBV2qsjpc7dAxYOAdiIbz2bP8+l0I2KWYWdfWO17Fy8Lnkw6f lG6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=iGRKy1q3l1FowpMP1uMo8sqp2H6VQuN5A7qM9dTdstY=; b=SQvwr/asSAnY7G5CDqr5w1vrKHxaoEhGY/GFx+aeR/LV4OBZeGMH1Wfh+5kMTpKvIL asf5LWlc01KiKM65aTJKc30oX8usrQYB5o6E5+YPQbvf+beUvAWrz6ihtPcD12DDhjnT fmlUXiqshJLWVTHyOjF8vCKM6rR8/4ybYNJQ9L6WFCq0ctse3wLXlHksBpGwkXqZbBZY tt9HqOKgfXyYkNCkkGRKe4V/kXECZc/40YzrfVmUGicdM6jdxmR2J+TqDlR6J8tgTLVg BC+/SY3xpZjLU8M5gS4CuQa0hDz+RE0kdYiKhv2a8A7IvcFL1vhCamFs7mbCJ0uVtgjv yE7w== X-Gm-Message-State: AHQUAubtYSQYPLITS1GmBP7Xjbb4oO33jkpcUdrGgJ3V4VQwNReJojEj bkilqR4HtHbJUvq4E3yNFiQYHkukdgf14gWtAgYq X-Google-Smtp-Source: AHgI3IZSEbjYSTLOfMzCisD/zrmdX7mTWH2ALCObGzghX5AhsfeLMoIEQAK9aCItpXCQPHBQM6aUn54MOopM4641uCc= X-Received: by 2002:a0c:9144:: with SMTP id q62mr3749304qvq.87.1550163413250; Thu, 14 Feb 2019 08:56:53 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 14 Feb 2019 08:56:51 -0800 From: Dominick Baier In-Reply-To: <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> MIME-Version: 1.0 Date: Thu, 14 Feb 2019 08:56:51 -0800 Message-ID: To: Filip Skokan , "Richard Backman, Annabelle" Cc: oauth , Brian Campbell Content-Type: multipart/alternative; boundary="000000000000974c1c0581dd8bf6" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 16:57:03 -0000 --000000000000974c1c0581dd8bf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry - this was not meant to be snide at all. It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security. Cheers =E2=80=94=E2=80=94=E2=80=94 Dominick On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ( richanna@amazon.com) wrote: The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard. This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn=E2=80=99t exist before. As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that=E2=80=99s just my experience as, you kn= ow, an actual developer. Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80=99 = backgrounds off the list, please. --=20 Annabelle Richard Backman AWS Identity *From: *Dominick Baier *Date: *Wednesday, February 13, 2019 at 4:18 AM *To: *"Richard Backman, Annabelle" , Filip Skokan < panva.ip@gmail.com> *Cc: *Brian Campbell , "Richard Backman, Annabelle" , oauth *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discover= y I am for keeping it simple and not introducing another link to follow. I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;) =E2=80=94=E2=80=94=E2=80=94 Dominick On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote: Hello, Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant typ= e is supported.=E2=80=9D mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a= list of client authentication methods supported by this token endpoint.=E2=80=9D If= that array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified= in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to a= n alternate document. Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present. I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints. S pozdravem, *Filip Skokan* On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle < richanna@amazon.com> wrote: Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a= list of client authentication methods supported by this token endpoint.=E2=80=9D If= that array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified= in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to a= n alternate document. Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant typ= e is supported.=E2=80=9D It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past= all of these issues, because it brings us back to just parsing the same metadata that we do today. --=20 Annabelle Richard Backman AWS Identity *From:* OAuth on behalf of Filip Skokan < panva.ip@gmail.com> *Date:* Tuesday, February 12, 2019 at 1:13 PM *To:* "Richard Backman, Annabelle" *Cc:* Brian Campbell , oauth= < oauth@ietf.org> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery Hi Annabelle, can you elaborate what would be the violation / negative impact of usage of RFC8414? As it already makes use of `signed_metadata` and this language is present ... > Consumers of the metadata MAY ignore the signed metadata if they do not support this feature. If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements= . ... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process. Best, *Filip* On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle wrote: I=E2=80=99m not opposed to introducing a metadata change, if the scenario i= s relevant and other approaches can=E2=80=99t adequately address it =E2=80=93= and I=E2=80=99ll readily grant that we probably don=E2=80=99t want to depend on consistency = of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414. Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D me= tadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D parame= ter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rig= id parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported). --=20 Annabelle Richard Backman AWS Identity *From:* OAuth on behalf of Brian Campbell *Date:* Tuesday, February 12, 2019 at 10:58 AM *To:* Dominick Baier *Cc:* oauth *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery Thanks for the input, Dominick. I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action. On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier wrote: IMHO that=E2=80=99s a reasonable and pragmatic option. Thanks =E2=80=94=E2=80=94=E2=80=94 Dominick On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.co= m) wrote: It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So, at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints. A straw-man example might look like this { "issuer":"https://server.example.com", "authorization_endpoint":"https://server.example.com/authz", "token_endpoint":"https://server.example.com/token", "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_client_auth", "none"], "userinfo_endpoint":"https://server.example.com/userinfo", "revocation_endpoint":"https://server.example.com/revo", "jwks_uri":"https://server.example.com/jwks.json", *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token ", "userinfo_endpoint":"https://mtls.example.com/userinfo ", "revocation_endpoint":"https://mtls.example.com/revo " }* } A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints". The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user. I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: We are currently implementing MTLS in IdentityServer. Our approach will be that we=E2=80=99ll offer a separate token endpoint tha= t supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D= . Thanks =E2=80=94=E2=80=94=E2=80=94 Dominick On 7. February 2019 at 22:36:55, Brian Campbell ( bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly.. On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS met= adata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect. --=20 Annabelle Richard Backman AWS Identity *From:* Brian Campbell *Date:* Wednesday, February 6, 2019 at 11:30 AM *To:* "Richard Backman, Annabelle" *Cc:* "Richard Backman, Annabelle" , oauth < oauth@ietf.org> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more. On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell wrote: "far" should have said "fair" in the previous message On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic. The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though. On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle > wrote: (TL;DR: punt AS metadata to a separate draft) AS points #1-3 are all questions I would have as an implementer: 1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant = type is supported.=E2=80=9D So what does the mTLS-only AS put here? 2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided. 3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are onl= y valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question. 4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed. I could go on for client points but you already get the point. Though I=E2= =80=99ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 I don=E2=80=99t necessarily think an AS metadata property is wrong per se, = but understand that you=E2=80=99re bolting a layer of flexibility onto a standa= rd that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata pr= oposal as it=E2=80=99s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80=99s for a nuanced enough u= se case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wro= ng) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Server = Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. --=20 Annabelle Richard Backman AWS Identity *From:* OAuth on behalf of Brian Campbell *Date:* Monday, February 4, 2019 at 5:28 AM *To:* "Richard Backman, Annabelle" *Cc:* oauth *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted. All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid. And I'd really like to post an update to this draft about a month or two ago. On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle > wrote: Confusion from the AS=E2=80=99s perspective: 1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string? 2. What if I only support mTLS for the token endpoint, but not revocation or user info? 3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints? 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enab= led device_authorization_endpoint under mtls_endpoints? Confusion from the client=E2=80=99s perspective: 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know= anything about mTLS, but the IT admins installed client certs in their users=E2=80=99 b= rowsers and the AS expects to use that to authenticate me. 2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri. 3. My AS metadata parser crashed because it didn=E2=80=99t expect to enc= ounter a JSON object as a parameter value. 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, w= hat do I do? 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they to= ld me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? Yes, you can write normative text that answers most of these. But you=E2=80= =99ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning. --=20 Annabelle Richard Backman AWS Identity *From:* Brian Campbell *Date:* Friday, February 1, 2019 at 3:17 PM *To:* "Richard Backman, Annabelle" *Cc:* George Fletcher , oauth *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one. Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time. I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread. But it seems like the rough consensus of the group here is in favor of it. On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle > wrote: This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinki= ng about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS? --=20 Annabelle Richard Backman AWS Identity *From:* OAuth on behalf of Brian Campbell *Date:* Friday, February 1, 2019 at 1:31 PM *To:* George Fletcher > *Cc:* oauth *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint Yes, that would work. On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values? On 1/15/19 8:48 AM, Brian Campbell wrote: It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata. On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge wrote: I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional. *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf..org/mailman/listinfo/oauth *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --000000000000974c1c0581dd8bf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Sorr= y - this was not meant to be snide at all.

It was honest feedback that you also need to keep s= oftware complexity in mind when creating a spec. Every MAY or OPTIONAL, or = do it like this OR that, or send values in arbitrary order adds to complexi= ty. Complexity is the natural enemy of security.

Cheers=C2=A0
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard= by changing the semantics of a parameter it defines. We should be very, ve= ry, VERY careful about telling implementers to violate an existing standard= . This change might prove incompatible with existing or future implementations of 8414, it might not, but by viol= ating the standard the proposal creates an opportunity for incompatibility = that didn=E2=80=99t exist before.

=C2=A0

As far as simplicity is concerned, I find a solution= that reuses the existing data model and naturally supports existing and fu= ture extensions to be far simpler than one that introduces ambiguous semant= ics to existing parameters. Generally speaking, data models with properties that mean different things in differ= ent contexts tend to be fragile and require more complex code to work with.= But that=E2=80=99s just my experience as, you know, an actual developer.

=C2=A0

Let=E2=80=99s keep the assumptions and snide remarks= about others=E2=80=99 backgrounds off the list, please.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From= : Dominick Baier &l= t;dbaier@leastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annabelle"= <richanna@amazon.com>, oa= uth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint &= discovery

=C2=A0

I am for keeping it simple and not introducing another link to follow.

=C2=A0

I sometimes wonder how many of the spec authors are actually developers = - these suggestions make software unnecessary complex ;)

=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

=C2=A0

Additionally, a metadata document that omits token_e= ndpoint in favor of mtls_endpoints since only mTLS is supported would viola= te 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the i= mplicit grant type is supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use = should not be recommended for such AS and regular endpoints will be used, t= his satisfies the requirement

Here is one example, based on my understanding of th= e =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 defi= nes the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON a= rray containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_clien= t_auth=E2=80=9D and the endpoint specified in token_endpoint does not suppo= rt mTLS, then that metadata violates 8414. You could address this by adding= a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth metho= ds. If you take that to its logical conclusion, you end up with a complete = metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of = thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's t= he issue? Clients not having mtls capabilities won't care about the add= itional method members being present. Clients that do implement mtls by the= specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints r= oot property is not present.

=C2=A0

I gave `mtls_alternate_metadata` route a thought and= don't see how it helps, given the two above are non-issues (my $.02) a= nother discovery document only brings more of them since every property can= now be different, not just the endpoints.


S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annab= elle <richanna@= amazon.com> wrote:

Here is one example, based on my understanding of the =E2=80=9Cstr= aw man=E2=80=9D format presented in this thread: RFC8414 defines the value = of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this= token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth= =E2=80=9D and the endpoint specified in token_endpoint does not support mTL= S, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_en= dpoints object, and likewise for the other endpoints and auth methods. If y= ou take that to its logical conclusion, you end up with a complete metadata= document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to = an alternate document.

=C2=A0

Additionally, a metadata document that omits token_endpoint in fav= or of mtls_endpoints since only mTLS is supported would violate 8414, as 84= 14 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

=C2=A0

It is possible to define the mtls_endpoints parameter such that th= e above use cases are invalid, but that does make the document more complic= ated. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to = just parsing the same metadata that we do today.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on b= ehalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >, oauth <oauth@i= etf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

Hi Annabelle,

=C2=A0

can you elaborate what would be the violation / negative impact of= usage of RFC8414?

=C2=A0

As it already makes use of `signed_metadata` and this language is = present ...

=C2=A0

>=C2=A0Consumers of the metadata MAY ignore the signed metadata= if they do not support this feature.=C2=A0 If the consumer of the metadata= supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values = conveyed using plain JSON elements.

=C2=A0

... would mtls_endpoints be any different? Clients are free to ign= ore this if they don't support/use mtls, and if they do those values mu= st take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recomm= ended for one with both mtls/regular authentication methods. token_endpoint= remains required for all intents and purposes. And as for the usable clien= t authentication methods - they should all be listed, or do you think we should separate the ones for each= hostname/port location? To what end? Is there a risk having the mtls hostn= ame/port accepting regular requests? Other then secret/key _jwt auth method= s assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

=C2=A0

=C2=A0

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richa= nna=3D40am= azon.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the s= cenario is relevant and other approaches can=E2=80=99t adequately address i= t =E2=80=93 and I=E2=80=99ll readily grant that we probably don=E2=80=99t w= ant to depend on consistency of browser behavior at the intersection of client= certificates and Access-Control-Allow-Credentials. But care needs to be ta= ken in designing that metadata to avoid violating or otherwise negatively i= mpacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2= =80=9D metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata= =E2=80=9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have t= wo different metadata documents for mTLS and non-mTLS clients, reducing the= mTLS-optional scenario to the mTLS-only scenario. This sidesteps the chall= enges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in= RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on b= ehalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble adequately gaugi= ng whether or not there's sufficient consensus to go ahead with the upd= ate. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it g= ot canceled. And looking again back over the discussion, I don't believ= e a consensus call is necessary. There's been a lot of general discussi= on over the last several weeks during which several folks have stated support for the proposal while there's been = only one voice of direct dissent. That seems like rough enough consensus an= d, as such, I plan to make the change in the next revision of the document = (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different cour= se of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com<= /a>> wrote:

IMHO that= =E2=80=99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrot= e:

It's been pointed= out that the potential issue is not isolated to the just token endpoint bu= t that revocation, introspection, etc. could be impacted as well. So,=C2=A0= at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtl= s_endpoints' that's value we be a JSON object which itself contains= endpoints that, when present, a client doing MTLS would use rather than th= e regular endpoints.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"clie= nt_secret_basic","tls_client_auth", "none"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo&= quot;
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give precedence to an endpo= int under "mtls_endpoints" while falling back to use the normal e= ndpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will= use the regular endpoints. And only the host/port of the endpoints listed = in mtls_endpoints will be set up to request TLS client certificates during = handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided = for all the other regular clients that are not going to do MTLS - including= and most importantly in-browser javascript clients where there can be less= than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whether or not th= ere's sufficient consensus to go ahead with the update. There's bee= n some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And al= so some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

We are curr= ently implementing MTLS in IdentityServer.

=C2=A0

Our approac= h will be that we=E2=80=99ll offer a separate token endpoint that supports = client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_en= dpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed = a good reminder that even a seemingly innocuous change that should be backw= ards compatible can break things unexpectedly..

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t specifically invol= ve AS metadata. We had clients in the wild that assumed that all the proper= ties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose va= lue was a JSON object. It was a good reminder that even a seemingly innocuo= us change that should be backwards compatible can force more work on client= s than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bcampbell@pingidentity= .com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone= wrong with or how token_endpoint_auth_methods broke something with the use= r info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain tha= t one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com= > wrote:

"far" should have said "fair" in the previous = message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com<= /a>> wrote:

It may well be due to my own intellectual shortcomings but these i= ssues/questions/confusion-points are not resonating for me as being problem= atic.

=C2=A0

The more general stance of "this isn't needed or worth it= in this document" (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless o= nly the implicit grant type is supported.=E2=80=9D So what does the mTLS-on= ly AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier= is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question.
  4. This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Tho= ugh I=E2=80=99ll share that #3 is real and once forced me to roll back an u= pdate to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98= =83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong= per se, but understand that you=E2=80=99re bolting a layer of flexibility = onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed h= ere sufficiently deals with the fallout from that. In my view this is a com= plex enough issue and it=E2=80=99s for a nuanced enough use case (as far as= I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization S= erver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the d= oor.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on b= ehalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hy= perbolic. But your general point is taken and your position of being anti a= dditional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There= seem to be a range of opinions on this point and gauging consensus is prov= ing elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a mo= nth or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <rich= anna=3D= 40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most of these. But = you=E2=80=99ll have to clearly cover a lot of similar-but-slightly-differen= t scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bcampbell= =3D4= 0pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me= - if the client is doing MTLS and the given endpoint is present in `mtls_e= ndpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in pl= ay, like the push for increased security in general and to have javascript = clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on wheth= er or not to add the new metadata (or something like it). With my reasoning= each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <rich= anna=3D= 40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to suppor= t what seems to be a minority use case. I=E2=80=99m getting a headache just= thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> on b= ehalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.i= etf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Doe= s it not specify the optional "mtls_endpoints" and just use the n= ormal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made= clear. It'd be something to the effect of optional for the AS to inclu= de and clients doing MTLS would use it when present in AS metadata.

=C2=A0


CONFIDENTIALITY NOTICE: This email may = contain confidential and privileged material for the sole use of the intend= ed recipient(s). Any review, use, distribution or disclosure by others is s= trictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the = sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.

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

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

--000000000000974c1c0581dd8bf6-- From nobody Thu Feb 14 09:20:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3C130E2F for ; Thu, 14 Feb 2019 09:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPrd0xb2xuf5 for ; Thu, 14 Feb 2019 09:20:26 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA05512426A for ; Thu, 14 Feb 2019 09:20:25 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1EHEYFc134141; Thu, 14 Feb 2019 17:20:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=WeifgvlZmHp9C5c/Rhgodkof1fGbqDcF6Q/5KHxmReU=; b=STzTxf1cZSNlSrWEWClBwmtKblIjIWBfom3AdBeIr0FQrwVlZ+i7HxfE76mbPTajIbYA 5C8VQfX9RMfYGEd29Z95h4TgqUq3nj/Hn+RZ9dqMmCBMGFwf1bXjHfsLG4dWwTTGFmVQ xBkWifNJR6vaHVwxZICFBtLYmdG9qOzCpn1rBdcXfNiwj1FwVBtf+zRAqyAUcn7QtJKo gmrKktFglvVIdWppc+8hCddBuoQjh9r/bFq/HY1IeDbLOh4XZ32fmB/Q+j0rqpXZw7eS gFz18A67KaCubNc885z04lvWZHWDwdwfLwzQ2qxjQtbCTzEDAnYX4oSFrkZXLAt/OLQc Lg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2qhre5sb0d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Feb 2019 17:20:20 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1EHKKVI003287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Feb 2019 17:20:20 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1EHKJZF028786; Thu, 14 Feb 2019 17:20:19 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Feb 2019 17:20:18 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-FCE5E301-4A4A-48DD-93A1-D2F5C6BA32A0 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Thu, 14 Feb 2019 09:20:16 -0800 Cc: Filip Skokan , "Richard Backman, Annabelle" , oauth Content-Transfer-Encoding: 7bit Message-Id: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com! > <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> To: Dominick Baier X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9167 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902140117 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:20:31 -0000 --Apple-Mail-FCE5E301-4A4A-48DD-93A1-D2F5C6BA32A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I feel I have to disagree. I agree that optionality is often complexity and= should be avoided. But, I think the optionality here is an agility feature a= llowing mtls to work across a diversified market of different types of tls t= erminators with varying capability. Lack of appropriate discovery/options co= uld serve to make the spec unusable in many cases. =20 A complicating factor with tls is that a tls layer failure prevents the AS f= rom issuing a correcting directive like an http error or http redirect.=20 We have to be sure not to break existing clients so we may in some cases nee= d mtls only endpoints. I am not far enough along to know for sure. But I ten= d to agree with Brian on this.=20 This may be a sign we need more implementation data (including from tls wg) t= o make the right call.=20 Phil > On Feb 14, 2019, at 8:56 AM, Dominick Baier wr= ote: >=20 > Sorry - this was not meant to be snide at all. >=20 > It was honest feedback that you also need to keep software complexity in m= ind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that,= or send values in arbitrary order adds to complexity. Complexity is the nat= ural enemy of security. >=20 > Cheers=20 > =E2=80=94=E2=80=94=E2=80=94 > Dominick >=20 >> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@am= azon.com) wrote: >>=20 >> The issue is that the proposal violates the standard by changing the sema= ntics of a parameter it defines. We should be very, very, VERY careful about= telling implementers to violate an existing standard.. This change might pr= ove incompatible with existing or future implementations of 8414, it might n= ot, but by violating the standard the proposal creates an opportunity for in= compatibility that didn=E2=80=99t exist before. >>=20 >> =20 >>=20 >> As far as simplicity is concerned, I find a solution that reuses the exis= ting data model and naturally supports existing and future extensions to be f= ar simpler than one that introduces ambiguous semantics to existing paramete= rs. Generally speaking, data models with properties that mean different thin= gs in different contexts tend to be fragile and require more complex code to= work with. But that=E2=80=99s just my experience as, you know, an actual de= veloper. >>=20 >> =20 >>=20 >> Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80=99= backgrounds off the list, please. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Dominick Baier >> Date: Wednesday, February 13, 2019 at 4:18 AM >> To: "Richard Backman, Annabelle" , Filip Skokan >> Cc: Brian Campbell , "Richard Backman, Annabe= lle" , oauth >> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discover= y >>=20 >> =20 >>=20 >> I am for keeping it simple and not introducing another link to follow. >>=20 >> =20 >>=20 >> I sometimes wonder how many of the spec authors are actually developers -= these suggestions make software unnecessary complex ;) >>=20 >> =20 >>=20 >> =E2=80=94=E2=80=94=E2=80=94 >>=20 >> Dominick >>=20 >> =20 >>=20 >> On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote= : >>=20 >> Hello, >>=20 >> =20 >>=20 >> Additionally, a metadata document that omits token_endpoint in favor of m= tls_endpoints since only mTLS is supported would violate 8414, as 8414 says t= oken_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is su= pported.=E2=80=9D >>=20 >>=20 >> mtls only AS doesn't get anything out of using mtls_endpoints, its use sh= ould not be recommended for such AS and regular endpoints will be used, this= satisfies the requirement >>=20 >> Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format presented in this thread: RFC8414 defines the value of token_e= ndpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of= client authentication methods supported by this token endpoint.=E2=80=9D If= that array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint spec= ified in token_endpoint does not support mTLS, then that metadata violates 8= 414. You could address this by adding a token_endpoint_auth_methods_supporte= d parameter to the mtls_endpoints object, and likewise for the other endpoin= ts and auth methods. If you take that to its logical conclusion, you end up w= ith a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s= that line of thought that led me to suggest just pointing to an alternate d= ocument. >>=20 >>=20 >> Assuming we go with using the same root auth methods property, what's the= issue? Clients not having mtls capabilities won't care about the additional= method members being present. Clients that do implement mtls by the specifi= cation will know to look for mtls_endpoints and fall back to regular ones if= the specific endpoint or mtls_endpoints root property is not present. >>=20 >> =20 >>=20 >> I gave `mtls_alternate_metadata` route a thought and don't see how it hel= ps, given the two above are non-issues (my $.02) another discovery document o= nly brings more of them since every property can now be different, not just t= he endpoints. >>=20 >>=20 >>=20 >> S pozdravem, >> Filip Skokan >>=20 >> =20 >>=20 >> =20 >>=20 >> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle wrote: >>=20 >> Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format presented in this thread: RFC8414 defines the value of token_e= ndpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of= client authentication methods supported by this token endpoint.=E2=80=9D If= that array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint spec= ified in token_endpoint does not support mTLS, then that metadata violates 8= 414. You could address this by adding a token_endpoint_auth_methods_supporte= d parameter to the mtls_endpoints object, and likewise for the other endpoin= ts and auth methods. If you take that to its logical conclusion, you end up w= ith a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s= that line of thought that led me to suggest just pointing to an alternate d= ocument. >>=20 >> =20 >>=20 >> Additionally, a metadata document that omits token_endpoint in favor of m= tls_endpoints since only mTLS is supported would violate 8414, as 8414 says t= oken_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is su= pported.=E2=80=9D >>=20 >> =20 >>=20 >> It is possible to define the mtls_endpoints parameter such that the above= use cases are invalid, but that does make the document more complicated. If= we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past= all of these issues, because it brings us back to just parsing the same met= adata that we do today. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: OAuth on behalf of Filip Skokan >> Date: Tuesday, February 12, 2019 at 1:13 PM >> To: "Richard Backman, Annabelle" = >> Cc: Brian Campbell , oauth= >> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>=20 >> =20 >>=20 >> Hi Annabelle, >>=20 >> =20 >>=20 >> can you elaborate what would be the violation / negative impact of usage o= f RFC8414? >>=20 >> =20 >>=20 >> As it already makes use of `signed_metadata` and this language is present= ... >>=20 >> =20 >>=20 >> > Consumers of the metadata MAY ignore the signed metadata if they do not= support this feature. If the consumer of the metadata supports signed meta= data, metadata values conveyed in the signed metadata MUST take precedence o= ver the corresponding values conveyed using plain JSON elements. >>=20 >> =20 >>=20 >> ... would mtls_endpoints be any different? Clients are free to ignore thi= s if they don't support/use mtls, and if they do those values must take prec= edence over the root ones. the use of mtls_endpoints would not be recommende= d for mtls-only AS but recommended for one with both mtls/regular authentica= tion methods. token_endpoint remains required for all intents and purposes. A= nd as for the usable client authentication methods - they should all be list= ed, or do you think we should separate the ones for each hostname/port locat= ion? To what end? Is there a risk having the mtls hostname/port accepting re= gular requests? Other then secret/key _jwt auth methods assertion aud claim t= he endpoint location doesn't play a role in the authentication process. >>=20 >>=20 >>=20 >> Best, >> Filip >>=20 >> =20 >>=20 >> =20 >>=20 >> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle wrote: >>=20 >> I=E2=80=99m not opposed to introducing a metadata change, if the scenario= is relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll readily grant that we probably don=E2=80=99t want to de= pend on consistency of browser behavior at the intersection of client certif= icates and Access-Control-Allow-Credentials. But care needs to be taken in d= esigning that metadata to avoid violating or otherwise negatively impacting u= sage of RFC8414. >>=20 >> =20 >>=20 >> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D m= etadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D= parameter whose value is the URL of an alternate metadata document intended= for clients using mTLS. An mTLS-optional AS could have two different metada= ta documents for mTLS and non-mTLS clients, reducing the mTLS-optional scena= rio to the mTLS-only scenario. This sidesteps the challenges of aligning the= =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rig= id parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_aut= h_methods_supported). >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: OAuth on behalf of Brian Campbell >> Date: Tuesday, February 12, 2019 at 10:58 AM >> To: Dominick Baier >> Cc: oauth >> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>=20 >> =20 >>=20 >> Thanks for the input, Dominick. >>=20 >> =20 >>=20 >> I'd said previously that I was having trouble adequately gauging whether o= r not there's sufficient consensus to go ahead with the update. I was even t= hinking of asking the chairs about a consensus call during the office hours m= eeting yesterday. But it got canceled. And looking again back over the discu= ssion, I don't believe a consensus call is necessary. There's been a lot of g= eneral discussion over the last several weeks during which several folks hav= e stated support for the proposal while there's been only one voice of direc= t dissent. That seems like rough enough consensus and, as such, I plan to ma= ke the change in the next revision of the document (which should be done soo= n). Chairs, please let me know, if you believe the situation warrants a diff= erent course of action. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier wrote: >>=20 >> IMHO that=E2=80=99s a reasonable and pragmatic option. >>=20 >> =20 >>=20 >> Thanks >>=20 >> =E2=80=94=E2=80=94=E2=80=94 >>=20 >> Dominick >>=20 >> =20 >>=20 >> On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.= com) wrote: >>=20 >> It's been pointed out that the potential issue is not isolated to the jus= t token endpoint but that revocation, introspection, etc. could be impacted a= s well. So, at this point, the proposal on the table is to add a new option= al AS metadata parameter named 'mtls_endpoints' that's value we be a JSON ob= ject which itself contains endpoints that, when present, a client doing MTLS= would use rather than the regular endpoints. A straw-man example might loo= k like this >>=20 >> { >> "issuer":"https://server.example.com", >> "authorization_endpoint":"https://server.example.com/authz", >> "token_endpoint":"https://server.example.com/token", >> "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_c= lient_auth", "none"], >> "userinfo_endpoint":"https://server.example.com/userinfo", >> "revocation_endpoint":"https://server.example.com/revo", >> "jwks_uri":"https://server.example.com/jwks.json", >> "mtls_endpoints":{ >> "token_endpoint":"https://mtls.example.com/token", >> "userinfo_endpoint":"https://mtls.example.com/userinfo", >> "revocation_endpoint":"https://mtls.example.com/revo" >> } >> } >>=20 >> =20 >>=20 >> A client doing MTLS would look for and give precedence to an endpoint und= er "mtls_endpoints" while falling back to use the normal endpoint from the t= op level of metadata when/if its not in "mtls_endpoints". >>=20 >>=20 >> The idea being that "regular" clients (those not doing MTLS) will use the= regular endpoints. And only the host/port of the endpoints listed in mtls_e= ndpoints will be set up to request TLS client certificates during handshake.= Thus any potential impact of the CertificateRequest message being sent in t= he TLS handshake can be avoided for all the other regular clients that are n= ot going to do MTLS - including and most importantly in-browser javascript c= lients where there can be less than desirable UI presented to the end-user. >>=20 >> =20 >>=20 >> I'm struggling, however, to adequately gauge whether or not there's suffi= cient consensus to go ahead with the update. There's been some support for i= t voiced. As well as talk of other approaches that could be alternatives or a= dditional measures. And also some vocal opposition to it.=20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier = wrote: >>=20 >> We are currently implementing MTLS in IdentityServer. >>=20 >> =20 >>=20 >> Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat supports client certs. Are you planning on adding an official endpoint n= ame for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. >>=20 >> =20 >>=20 >> Thanks >>=20 >> =E2=80=94=E2=80=94=E2=80=94 >>=20 >> Dominick >>=20 >> =20 >>=20 >> On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingidenti= ty.com@dmarc.ietf.org) wrote: >>=20 >> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good r= eminder that even a seemingly innocuous change that should be backwards comp= atible can break things unexpectedly.. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle wrote: >>=20 >> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had clients in the wild that assumed that all the properties in t= he JSON object returned from our userinfo endpoint were scalar strings. This= broke when we introduced a new property whose value was a JSON object. It w= as a good reminder that even a seemingly innocuous change that should be bac= kwards compatible can force more work on clients than we expect. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Brian Campbell >> Date: Wednesday, February 6, 2019 at 11:30 AM >> To: "Richard Backman, Annabelle" = >> Cc: "Richard Backman, Annabelle" , oauth >> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clien= ts using the token endpoint >>=20 >> =20 >>=20 >> And I'm honestly really struggling to see what could have gone wrong with= or how token_endpoint_auth_methods broke something with the user info endpo= int. If you have the time and/or it'd be informative to this here little dis= cussion, please explain that one a bit more. >>=20 >> =20 >>=20 >> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell wrote: >>=20 >> "far" should have said "fair" in the previous message >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: >>=20 >> It may well be due to my own intellectual shortcomings but these issues/q= uestions/confusion-points are not resonating for me as being problematic. >>=20 >> =20 >>=20 >> The more general stance of "this isn't needed or worth it in this documen= t" (I think that's far?) is being heard though. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle wrote: >>=20 >> (TL;DR: punt AS metadata to a separate draft) >>=20 >> AS points #1-3 are all questions I would have as an implementer: >>=20 >> Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only= the implicit grant type is supported.=E2=80=9D So what does the mTLS-only A= S put here? >> The claims for these other endpoints are OPTIONAL, potentially leading to= inconsistency depending on how #1 gets decided. >> The example usage of the token_endpoint_auth_methods property given earli= er is incompatible with RFC8414, since some of its contents are only valid f= or the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question. >> This introduces a new metadata property that could impact how other specs= should extend AS metadata. That needs to be addressed. >> =20 >>=20 >> I could go on for client points but you already get the point. Though I=E2= =80=99ll share that #3 is real and once forced me to roll back an update to t= he Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>=20 >> =20 >>=20 >> I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but understand that you=E2=80=99re bolting a layer of flexibility onto a s= tandard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the= metadata proposal as it=E2=80=99s been discussed here sufficiently deals wi= th the fallout from that. In my view this is a complex enough issue and it=E2= =80=99s for a nuanced enough use case (as far as I can tell from discussion?= Please correct me if I=E2=80=99m wrong) that we should punt it to a separat= e draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hy= brids=E2=80=9D) and get mTLS out the door. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: OAuth on behalf of Brian Campbell >> Date: Monday, February 4, 2019 at 5:28 AM >> To: "Richard Backman, Annabelle" = >> Cc: oauth >> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clien= ts using the token endpoint >>=20 >> =20 >>=20 >> Those points of confusion strike me as somewhat hypothetical or hyperboli= c. But your general point is taken and your position of being anti additiona= l metadata on this issue is noted. >>=20 >> =20 >>=20 >> All of which leaves me a bit uncertain about how to proceed. There seem t= o be a range of opinions on this point and gauging consensus is proving elus= ive for me. That's confounded by my own opinion on it being somewhat fluid. >>=20 >> =20 >>=20 >> And I'd really like to post an update to this draft about a month or two a= go. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle wrote: >>=20 >> Confusion from the AS=E2=80=99s perspective: >>=20 >> If I only support mTLS, do I need to include both token_endpoint_uri and m= tls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng? >> What if I only support mTLS for the token endpoint, but not revocation or= user info? >> How do I specify authentication methods for the mTLS token endpoint? Does= token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints? >> I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled d= evice_authorization_endpoint under mtls_endpoints? >> =20 >>=20 >> Confusion from the client=E2=80=99s perspective: >>=20 >> As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know any= thing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.=20 >> My AS metadata parser crashed because the mTLS-only AS omitted token_endp= oint_uri. >> My AS metadata parser crashed because it didn=E2=80=99t expect to encount= er a JSON object as a parameter value. >> The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what d= o I do? >> I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told m= e to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its na= me, right? >> =20 >>=20 >> Yes, you can write normative text that answers most of these. But you=E2=80= =99ll have to clearly cover a lot of similar-but-slightly-different scenario= s and be very explicit. And implementers will still get it wrong. The metada= ta change introduces opportunities for confusion and failure that do not exi= st now, and forces them on everyone who supports mTLS. In contrast, the 307 r= edirect is only required when an AS wants to support both, and is unambiguou= s in its behavior and meaning. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Brian Campbell >> Date: Friday, February 1, 2019 at 3:17 PM >> To: "Richard Backman, Annabelle" >> Cc: George Fletcher , oauth >> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients u= sing the token endpoint >>=20 >> =20 >>=20 >> It doesn't seem like that confusing or large of a change to me - if the c= lient is doing MTLS and the given endpoint is present in `mtls_endpoints`, t= hen it uses that one. Otherwise it uses the regular endpoint. It gives an A= S a lot of flexibility in deployment options. I personally think getting a 3= 07 approach deployed and working would be more complicated and error prone.=20= >>=20 >> =20 >>=20 >> It is a minority use case at the moment but there are forces in play, lik= e the push for increased security in general and to have javascript clients u= se the code flow, that suggest it won't be terribly unusual to see an AS tha= t wants to support MTLS clients and javascript/spa clients at the same time.= >>=20 >> =20 >>=20 >> I've personally wavered back and forth in this thread on whether or not t= o add the new metadata (or something like it). With my reasoning each way ki= nda explained somewhere back in the 40 or so messages that make up this thre= ad. But it seems like the rough consensus of the group here is in favor of i= t. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: >>=20 >> This strikes me as a very prominent and confusing change to support what s= eems to be a minority use case. I=E2=80=99m getting a headache just thinking= about the text needed to clarify when the AS should provide `mtls_endpoints= ` and when the client should use that versus using `token_endpoint.` Why is t= he 307 status code insufficient to cover the case where a single AS supports= both mTLS and non-mTLS? >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: OAuth on behalf of Brian Campbell >> Date: Friday, February 1, 2019 at 1:31 PM >> To: George Fletcher >> Cc: oauth >> Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpo= int >>=20 >> =20 >>=20 >> Yes, that would work.=20 >>=20 >> =20 >>=20 >> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: >>=20 >> What if the AS wants to ONLY support MTLS connections. Does it not specif= y the optional "mtls_endpoints" and just use the normal metadata values? >>=20 >> On 1/15/19 8:48 AM, Brian Campbell wrote: >>=20 >> It would definitely be optional, apologies if that wasn't made clear. It'= d be something to the effect of optional for the AS to include and clients d= oing MTLS would use it when present in AS metadata. >>=20 >> =20 >>=20 >> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge w= rote: >>=20 >> I'm in favour of the `mtls_endpoints` metadata parameter - although it sh= ould be optional. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf..org/mailman/listinfo/oauth >> =20 >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________=20 >> OAuth mailing list=20 >> OAuth@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FCE5E301-4A4A-48DD-93A1-D2F5C6BA32A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I feel I have to disagree.  I agree th= at optionality is often complexity and should be avoided. But, I think the o= ptionality here is an agility feature allowing mtls to work across a diversi= fied market of different types of tls terminators with varying capability. L= ack of appropriate discovery/options could serve to make the spec unusable i= n many cases.  

A complicating factor with tls is th= at a tls layer failure prevents the AS from issuing a correcting directive l= ike an http error or http redirect. 

We have t= o be sure not to break existing clients so we may in some cases need mtls on= ly endpoints. I am not far enough along to know for sure. But I tend to agre= e with Brian on this. 

This may be a sign we n= eed more implementation data (including from tls wg) to make the right call.=  

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:<= br>
Sorry - this was not meant to be snide at all.

It was honest feedback th= at you also need to keep software complexity in mind when creating a spec. E= very MAY or OPTIONAL, or do it like this OR that, or send values in arbitrar= y order adds to complexity. Complexity is the natural enemy of security.

Cheers 
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Back= man, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard b= y changing the semantics of a parameter it defines. We should be very, very,= VERY careful about telling implementers to violate an existing standard.. T= his change might prove incompatible with existing or future implementations of 8414, it might not, but by viola= ting the standard the proposal creates an opportunity for incompatibility th= at didn=E2=80=99t exist before.

 

As far as simplicity is concerned, I find a solution t= hat reuses the existing data model and naturally supports existing and futur= e extensions to be far simpler than one that introduces ambiguous semantics t= o existing parameters. Generally speaking, data models with properties that mean different things in differe= nt contexts tend to be fragile and require more complex code to work with. B= ut that=E2=80=99s just my experience as, you know, an actual developer.

 

Let=E2=80=99s keep the assumptions and snide remarks a= bout others=E2=80=99 backgrounds off the list, please.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From:= Dominick Baier <= dbaier@leastprivilege.com&g= t;
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <= bcampbell@pingidentity.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & d= iscovery

 

I am for keeping it simple and not introducing another link to follow.

 

I sometimes wonder how many of the spec authors are actually developers - t= hese suggestions make software unnecessary complex ;)

 

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

 

Additionally, a metadata document that omits token_en= dpoint in favor of mtls_endpoints since only mTLS is supported would violate= 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the impl= icit grant type is supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use shoul= d not be recommended for such AS and regular endpoints will be used, this sa= tisfies the requirement

Here is one example, based on my understanding of the= =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 define= s the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON arra= y containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client= _auth=E2=80=9D and the endpoint specified in token_endpoint does not support= mTLS, then that metadata violates 8414. You could address this by adding a t= oken_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth method= s. If you take that to its logical conclusion, you end up with a complete me= tadata document hanging off of mtls_endpoints. It=E2=80=99s that line of tho= ught that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the is= sue? Clients not having mtls capabilities won't care about the additional me= thod members being present. Clients that do implement mtls by the specificat= ion will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints ro= ot property is not present.

 

I gave `mtls_alternate_metadata` route a thought and d= on't see how it helps, given the two above are non-issues (my $.02) another d= iscovery document only brings more of them since every property can now be d= ifferent, not just the endpoints.


S pozdravem,
Filip Skokan

 

 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabe= lle <richanna@am= azon.com> wrote:

Here is one example, based on my understanding of the =E2=80=9Cstraw= man=E2=80=9D format presented in this thread: RFC8414 defines the value of t= oken_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this t= oken endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2=80= =9D and the endpoint specified in token_endpoint does not support mTLS, then= that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_end= points object, and likewise for the other endpoints and auth methods. If you= take that to its logical conclusion, you end up with a complete metadata do= cument hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to a= n alternate document.

 

Additionally, a metadata document that omits token_endpoint in favor= of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 s= ays token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

 

It is possible to define the mtls_endpoints parameter such that the a= bove use cases are invalid, but that does make the document more complicated= . If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to j= ust parsing the same metadata that we do today.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on beh= alf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&= gt;
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;, oauth <oauth@ietf= .org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=

 

Hi Annabelle,

 

can you elaborate what would be the violation / negative impact of u= sage of RFC8414?

 

As it already makes use of `signed_metadata` and this language is pr= esent ...

 

> Consumers of the metadata MAY ignore the signed metadata i= f they do not support this feature.  If the consumer of the metadata su= pports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values c= onveyed using plain JSON elements.

 

... would mtls_endpoints be any different? Clients are free to ignor= e this if they don't support/use mtls, and if they do those values must take= precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recomme= nded for one with both mtls/regular authentication methods. token_endpoint r= emains required for all intents and purposes. And as for the usable client a= uthentication methods - they should all be listed, or do you think we should separate the ones for each h= ostname/port location? To what end? Is there a risk having the mtls hostname= /port accepting regular requests? Other then secret/key _jwt auth methods as= sertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

 

 

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richann= a=3D40amazo= n.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the sce= nario is relevant and other approaches can=E2=80=99t adequately address it =E2= =80=93 and I=E2=80=99ll readily grant that we probably don=E2=80=99t want to depend on consistency of browser behavior at the intersection of client c= ertificates and Access-Control-Allow-Credentials. But care needs to be taken= in designing that metadata to avoid violating or otherwise negatively impac= ting usage of RFC8414.

 

Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80= =9D metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80= =9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have tw= o different metadata documents for mTLS and non-mTLS clients, reducing the m= TLS-optional scenario to the mTLS-only scenario. This sidesteps the challeng= es of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in R= FC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whe= ther or not there's sufficient consensus to go ahead with the update. I was e= ven thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it go= t canceled. And looking again back over the discussion, I don't believe a co= nsensus call is necessary. There's been a lot of general discussion over the= last several weeks during which several folks have stated support for the proposal while there's been only o= ne voice of direct dissent. That seems like rough enough consensus and, as s= uch, I plan to make the change in the next revision of the document (which s= hould be done soon). Chairs, please let me know, if you believe the situation warrants a different cours= e of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com= > wrote:

IMHO that=E2=80= =99s a reasonable and pragmatic option.

 =

Thanks=

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:=

It's been pointed out t= hat the potential issue is not isolated to the just token endpoint but that r= evocation, introspection, etc. could be impacted as well. So,  at this p= oint, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_end= points' that's value we be a JSON object which itself contains endpoints tha= t, when present, a client doing MTLS would use rather than the regular endpo= ints.  A straw-man example might look like this

{
  "issuer":"ht= tps://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic"= ,"tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoin= t under "mtls_endpoints" while falling back to use the normal endpoint from t= he top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the re= gular endpoints. And only the host/port of the endpoints listed in mtls_endp= oints will be set up to request TLS client certificates during handshake. Th= us any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided f= or all the other regular clients that are not going to do MTLS - including a= nd most importantly in-browser javascript clients where there can be less th= an desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's s= ufficient consensus to go ahead with the update. There's been some support f= or it voiced. As well as talk of other approaches that could be alternatives or additional measures. And als= o some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com&g= t; wrote:

We are curren= tly implementing MTLS in IdentityServer.

 =

Our approach w= ill be that we=E2=80=99ll offer a separate token endpoint that supports clie= nt certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_end= point=E2=80=9D.

 =

Thanks=

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingid= entity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a g= ood reminder that even a seemingly innocuous change that should be backwards= compatible can break things unexpectedly..

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com&g= t; wrote:

The case I=E2=80=99m referencing didn=E2=80=99t specifically involve= AS metadata. We had clients in the wild that assumed that all the propertie= s in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose val= ue was a JSON object. It was a good reminder that even a seemingly innocuous= change that should be backwards compatible can force more work on clients t= han we expect.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity..= com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&= gt;
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong= with or how token_endpoint_auth_methods broke something with the user info e= ndpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one= a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

It may well be due to my own intellectual shortcomings but these iss= ues/questions/confusion-points are not resonating for me as being problemati= c.

 

The more general stance of "this isn't needed or worth it in this do= cument" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richan= na=3D40a= mazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. = Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless onl= y the implicit grant type is supported.=E2=80=9D So what does the mTLS-only A= S put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to in= consistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier i= s incompatible with RFC8414, since some of its contents are only valid for t= he non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hen= ce this question.
  4. This introduces a new metadata property that could impact how other specs sh= ould extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Thoug= h I=E2=80=99ll share that #3 is real and once forced me to roll back an upda= te to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83=

 

I don=E2=80=99t necessarily think an AS metadata property is wrong p= er se, but understand that you=E2=80=99re bolting a layer of flexibility ont= o a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed he= re sufficiently deals with the fallout from that. In my view this is a compl= ex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I c= an tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Se= rver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the doo= r.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&= gt;
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hype= rbolic. But your general point is taken and your position of being anti addi= tional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There s= eem to be a range of opinions on this point and gauging consensus is proving= elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or= two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richan= na=3D40a= mazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtl= s_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string= ?
  2. What if I only support mTLS for the token endpoint, but not revocation or us= er info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does to= ken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled dev= ice_authorization_endpoint under mtls_endpoints?

 

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anythi= ng about mTLS, but the IT admins installed client certs in their users=E2=80= =99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoin= t_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a= JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I= do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me t= o use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name,= right?

 

Yes, you can write normative text that answers most of these. But yo= u=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different s= cenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for c= onfusion and failure that do not exist now, and forces them on everyone who s= upports mTLS. In contrast, the 307 redirect is only required when an AS want= s to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell=3D= 40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clien= ts using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if t= he client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deploy= ment options. I personally think getting a 307 approach deployed and working= would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play= , like the push for increased security in general and to have javascript cli= ents use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS client= s and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or n= ot to add the new metadata (or something like it). With my reasoning each wa= y kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like t= he rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richan= na=3D40a= mazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support w= hat seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that v= ersus using `token_endpoint.` Why is the 307 status code insufficient to cov= er the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token e= ndpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf= .org> wrote:

What if the AS wants to ONLY support MTLS connections. Does i= t not specify the optional "mtls_endpoints" and just use the normal metadata= values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear= . It'd be something to the effect of optional for the AS to include and clie= nts doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk&= gt; wrote:

I'm i= n favour of the `mtls_endpoints` metadata parameter - although it should be o= ptional.


CONFIDENTIALITY NOTICE: This email may c= ontain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is stri= ctly prohibited..  If you have received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org<=
/pre>

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

 


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.


CONFIDENTIALITY NOT= ICE: This email may contain confidential and privileged material for the sol= e use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.

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

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

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-FCE5E301-4A4A-48DD-93A1-D2F5C6BA32A0-- From nobody Thu Feb 14 15:08:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0B12F1A5 for ; Thu, 14 Feb 2019 15:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8HnrazbJ5UZ for ; Thu, 14 Feb 2019 15:08:37 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61981289FA for ; Thu, 14 Feb 2019 15:08:36 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id i2so18835165ite.5 for ; Thu, 14 Feb 2019 15:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0sqJCRPr9EECQvQ64QQTEbvPDkHI4t3jBXWcPKS2Rg0=; b=nV2CFRq5iNpWyjiSL6zCaOF6WY9QUvXljKU7KoE59j+D5/SIpx8IOgM6VzlrmPtFK9 QtSWgVo1ZU8i1AKnomp91RvLvTPMwyLw1ehhj9ym8e2YV+vZgyqLdKkYB4RBlSPrz77W qSO88sGbVDdNpX2vYSX8kzJdPJB5FZsYEWdRo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0sqJCRPr9EECQvQ64QQTEbvPDkHI4t3jBXWcPKS2Rg0=; b=Mmzz4QVn3kK/McaD9oeOnwi9J87i//iT2jHGh4avZOerYK/GhQ9AqfmHYFAFGW2Nyx 7hU+5M+M8jUKwfDLQfyef04DovXFsyyQo6SpCDCl2KCPPSRDrSIxCARgMFt+WtZLomhG YSCJ50QJkfDwa149F00TB3COfjoUBbMTK6y8P192rX7gguDHEN6hE8mSuFQXNhcf0pa3 9E9ocTUHIkRDn7IXRYvMAiGw2uNXhJ/u1keoK9TSP9BBpDWE34d03z2Lxia0myOwuNml ZBRjgD50AlM/0/wSnC+5QpHrWVFq1vPLdiGnLTfxxWVVBNPAPSgyztdMylyRga4IpykD j/Xg== X-Gm-Message-State: AHQUAubYNuutvx89tBnKWl9gAhc6tLCmE/7D+LSr7063Hfw+xZpWCfy4 4YDRJWsA15orkrY+YH1WYSpeUt7yFH3QgloGTan8MnwSm6h0+vYemWSQXbW4m/ZHcr9WsKKcFXB ZkzSDUR4YGjyR/g== X-Google-Smtp-Source: AHgI3IYLeN7piNMx7qept8v1H+skUkcS8OUvWTzmB+hon+3xSP4KYssTwUUCRGyAsC7qzqKE7ndHiuMUMlp3SGObC/8= X-Received: by 2002:a6b:b408:: with SMTP id d8mr3373141iof.138.1550185715739; Thu, 14 Feb 2019 15:08:35 -0800 (PST) MIME-Version: 1.0 References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> In-Reply-To: From: Brian Campbell Date: Thu, 14 Feb 2019 16:08:08 -0700 Message-ID: To: Phil Hunt Cc: Dominick Baier , oauth Content-Type: multipart/alternative; boundary="000000000000ec448d0581e2bc71" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 23:08:42 -0000 --000000000000ec448d0581e2bc71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact. On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wrote: > I feel I have to disagree. I agree that optionality is often complexity > and should be avoided. But, I think the optionality here is an agility > feature allowing mtls to work across a diversified market of different > types of tls terminators with varying capability. Lack of appropriate > discovery/options could serve to make the spec unusable in many cases. > > A complicating factor with tls is that a tls layer failure prevents the A= S > from issuing a correcting directive like an http error or http redirect. > > We have to be sure not to break existing clients so we may in some cases > need mtls only endpoints. I am not far enough along to know for sure. But= I > tend to agree with Brian on this. > > This may be a sign we need more implementation data (including from tls > wg) to make the right call. > > Phil > > On Feb 14, 2019, at 8:56 AM, Dominick Baier > wrote: > > Sorry - this was not meant to be snide at all. > > It was honest feedback that you also need to keep software complexity in > mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR > that, or send values in arbitrary order adds to complexity. Complexity is > the natural enemy of security. > > Cheers > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ( > richanna@amazon.com) wrote: > > The issue is that the proposal violates the standard by changing the > semantics of a parameter it defines. We should be very, very, VERY carefu= l > about telling implementers to violate an existing standard.. This change > might prove incompatible with existing or future implementations of 8414, > it might not, but by violating the standard the proposal creates an > opportunity for incompatibility that didn=E2=80=99t exist before. > > > > As far as simplicity is concerned, I find a solution that reuses the > existing data model and naturally supports existing and future extensions > to be far simpler than one that introduces ambiguous semantics to existin= g > parameters. Generally speaking, data models with properties that mean > different things in different contexts tend to be fragile and require mor= e > complex code to work with. But that=E2=80=99s just my experience as, you = know, an > actual developer. > > > > Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80= =99 backgrounds off > the list, please. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Dominick Baier > *Date: *Wednesday, February 13, 2019 at 4:18 AM > *To: *"Richard Backman, Annabelle" , Filip Skokan < > panva.ip@gmail.com > > *Cc: *Brian Campbell , "Richard Backman, > Annabelle" , oauth > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & > discovery > > > > I am for keeping it simple and not introducing another link to follow. > > > > I sometimes wonder how many of the spec authors are actually developers - > these suggestions make software unnecessary complex ;) > > > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote= : > > Hello, > > > > Additionally, a metadata document that omits token_endpoint in favor of > mtls_endpoints since only mTLS is supported would violate 8414, as 8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is > supported.=E2=80=9D > > > mtls only AS doesn't get anything out of using mtls_endpoints, its use > should not be recommended for such AS and regular endpoints will be used, > this satisfies the requirement > > Here is one example, based on my understanding of the =E2=80=9Cstraw man= =E2=80=9D format > presented in this thread: RFC8414 defines the value of > token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing= a list of > client authentication methods supported by this token endpoint.=E2=80=9D = If that > array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specifi= ed in > token_endpoint does not support mTLS, then that metadata violates 8414. Y= ou > could address this by adding a token_endpoint_auth_methods_supported > parameter to the mtls_endpoints object, and likewise for the other > endpoints and auth methods. If you take that to its logical conclusion, y= ou > end up with a complete metadata document hanging off of mtls_endpoints. > It=E2=80=99s that line of thought that led me to suggest just pointing to= an > alternate document. > > > Assuming we go with using the same root auth methods property, what's the > issue? Clients not having mtls capabilities won't care about the addition= al > method members being present. Clients that do implement mtls by the > specification will know to look for mtls_endpoints and fall back to regul= ar > ones if the specific endpoint or mtls_endpoints root property is not > present. > > > > I gave `mtls_alternate_metadata` route a thought and don't see how it > helps, given the two above are non-issues (my $.02) another discovery > document only brings more of them since every property can now be > different, not just the endpoints. > > > S pozdravem, > *Filip Skokan* > > > > > > On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Here is one example, based on my understanding of the =E2=80=9Cstraw man= =E2=80=9D format > presented in this thread: RFC8414 defines the value of > token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing= a list of > client authentication methods supported by this token endpoint.=E2=80=9D = If that > array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specifi= ed in > token_endpoint does not support mTLS, then that metadata violates 8414. Y= ou > could address this by adding a token_endpoint_auth_methods_supported > parameter to the mtls_endpoints object, and likewise for the other > endpoints and auth methods. If you take that to its logical conclusion, y= ou > end up with a complete metadata document hanging off of mtls_endpoints. > It=E2=80=99s that line of thought that led me to suggest just pointing to= an > alternate document. > > > > Additionally, a metadata document that omits token_endpoint in favor of > mtls_endpoints since only mTLS is supported would violate 8414, as 8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is > supported.=E2=80=9D > > > > It is possible to define the mtls_endpoints parameter such that the above > use cases are invalid, but that does make the document more complicated.. > If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip= past all of these > issues, because it brings us back to just parsing the same metadata that = we > do today. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Filip Skokan < > panva.ip@gmail.com> > *Date:* Tuesday, February 12, 2019 at 1:13 PM > *To:* "Richard Backman, Annabelle" > *Cc:* Brian Campbell , oau= th > > > *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Hi Annabelle, > > > > can you elaborate what would be the violation / negative impact of usage > of RFC8414? > > > > As it already makes use of `signed_metadata` and this language is present > ... > > > > > Consumers of the metadata MAY ignore the signed metadata if they do not > support this feature. If the consumer of the metadata supports signed > metadata, metadata values conveyed in the signed metadata MUST take > precedence over the corresponding values conveyed using plain JSON elemen= ts. > > > > ... would mtls_endpoints be any different? Clients are free to ignore thi= s > if they don't support/use mtls, and if they do those values must take > precedence over the root ones. the use of mtls_endpoints would not be > recommended for mtls-only AS but recommended for one with both mtls/regul= ar > authentication methods. token_endpoint remains required for all intents a= nd > purposes. And as for the usable client authentication methods - they shou= ld > all be listed, or do you think we should separate the ones for each > hostname/port location? To what end? Is there a risk having the mtls > hostname/port accepting regular requests? Other then secret/key _jwt auth > methods assertion aud claim the endpoint location doesn't play a role in > the authentication process. > > > Best, > *Filip* > > > > > > On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > I=E2=80=99m not opposed to introducing a metadata change, if the scenario= is > relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll > readily grant that we probably don=E2=80=99t want to depend on consistenc= y of > browser behavior at the intersection of client certificates and > Access-Control-Allow-Credentials. But care needs to be taken in designing > that metadata to avoid violating or otherwise negatively impacting usage = of > RFC8414. > > > > Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D = metadata > parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D para= meter whose value > is the URL of an alternate metadata document intended for clients using > mTLS. An mTLS-optional AS could have two different metadata documents for > mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the > mTLS-only scenario. This sidesteps the challenges of aligning the > =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the r= igid parameter > definitions in RFC8414 (see: token_endpoint, > token_endpoint_auth_methods_supported). > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Tuesday, February 12, 2019 at 10:58 AM > *To:* Dominick Baier > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery > > > > Thanks for the input, Dominick. > > > > I'd said previously that I was having trouble adequately gauging whether > or not there's sufficient consensus to go ahead with the update. I was ev= en > thinking of asking the chairs about a consensus call during the office > hours meeting yesterday. But it got canceled. And looking again back over > the discussion, I don't believe a consensus call is necessary. There's be= en > a lot of general discussion over the last several weeks during which > several folks have stated support for the proposal while there's been onl= y > one voice of direct dissent. That seems like rough enough consensus and, = as > such, I plan to make the change in the next revision of the document (whi= ch > should be done soon). Chairs, please let me know, if you believe the > situation warrants a different course of action. > > > > > > > > On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier > wrote: > > IMHO that=E2=80=99s a reasonable and pragmatic option. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 11. February 2019 at 13:26:37, Brian Campbell ( > bcampbell@pingidentity.com) wrote: > > It's been pointed out that the potential issue is not isolated to the jus= t > token endpoint but that revocation, introspection, etc. could be impacted > as well. So, at this point, the proposal on the table is to add a new > optional AS metadata parameter named 'mtls_endpoints' that's value we be = a > JSON object which itself contains endpoints that, when present, a client > doing MTLS would use rather than the regular endpoints. A straw-man > example might look like this > > { > "issuer":"https://server.example.com", > "authorization_endpoint":"https://server.example.com/authz", > "token_endpoint":"https://server.example.com/token", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server.example.com/userinfo", > "revocation_endpoint":"https://server.example.com/revo", > "jwks_uri":"https://server.example.com/jwks.json", > > > > > *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token > ", > "userinfo_endpoint":"https://mtls.example.com/userinfo > ", > "revocation_endpoint":"https://mtls.example.com/revo > " }* > } > > > > A client doing MTLS would look for and give precedence to an endpoint > under "mtls_endpoints" while falling back to use the normal endpoint from > the top level of metadata when/if its not in "mtls_endpoints". > > > The idea being that "regular" clients (those not doing MTLS) will use the > regular endpoints. And only the host/port of the endpoints listed in > mtls_endpoints will be set up to request TLS client certificates during > handshake. Thus any potential impact of the CertificateRequest message > being sent in the TLS handshake can be avoided for all the other regular > clients that are not going to do MTLS - including and most importantly > in-browser javascript clients where there can be less than desirable UI > presented to the end-user. > > > > I'm struggling, however, to adequately gauge whether or not there's > sufficient consensus to go ahead with the update. There's been some suppo= rt > for it voiced. As well as talk of other approaches that could be > alternatives or additional measures. And also some vocal opposition to it= . > > > > > > On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier > wrote: > > We are currently implementing MTLS in IdentityServer. > > > > Our approach will be that we=E2=80=99ll offer a separate token endpoint t= hat > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. > > > > Thanks > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick > > > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had > clients in the wild that assumed that all the properties in the JSON obje= ct > returned from our userinfo endpoint were scalar strings. This broke when = we > introduced a new property whose value was a JSON object. It was a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > > *Date:* Wednesday, February 6, 2019 at 11:30 AM > *To:* "Richard Backman, Annabelle" > *Cc:* "Richard Backman, Annabelle" , oauth < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > And I'm honestly really struggling to see what could have gone wrong with > or how token_endpoint_auth_methods broke something with the user info > endpoint. If you have the time and/or it'd be informative to this here > little discussion, please explain that one a bit more. > > > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > wrote: > > "far" should have said "fair" in the previous message > > > > > > > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: > > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Monday, February 4, 2019 at 5:28 AM > *To:* "Richard Backman, Annabelle" > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Friday, February 1, 2019 at 3:17 PM > *To:* "Richard Backman, Annabelle" > *Cc:* George Fletcher , oauth > *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Friday, February 1, 2019 at 1:31 PM > *To:* George Fletcher <40aol.com@dmarc...........ietf.org>> > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf..org <40aol.com@dmarc.ietf.org>> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear.. > It'd be something to the effect of optional for the AS to include and > clients doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* ______________________________________________= _ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing 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 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ec448d0581e2bc71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ma= ybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generall= y anyway) of the proposal with the optional "mtls_endpoints" para= meter. While I believe that the comment about optionality and complexity wa= s meant to be a more general remark.= While I can certainly appreciate a desire to keep things simple, I do regr= et that this thread took a turn towards personal. Whether it was the intent= or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> = wrote:
I feel I have to disagree.=C2=A0 I agree that optionality is ofte= n complexity and should be avoided. But, I think the optionality here is an= agility feature allowing mtls to work across a diversified market of diffe= rent types of tls terminators with varying capability. Lack of appropriate = discovery/options could serve to make the spec unusable in many cases. =C2= =A0

A complicating factor with tls is that a tls layer f= ailure prevents the AS from issuing a correcting directive like an http err= or or http redirect.=C2=A0

We have to be sure not = to break existing clients so we may in some cases need mtls only endpoints.= I am not far enough along to know for sure. But I tend to agree with Brian= on this.=C2=A0

This may be a sign we need more im= plementation data (including from tls wg) to make the right call.=C2=A0

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivile= ge.com> wrote:

Sorry - this w= as not meant to be snide at all.

It was honest feedback that you also need to keep software co= mplexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like= this OR that, or send values in arbitrary order adds to complexity. Comple= xity is the natural enemy of security.

Cheers=C2=A0
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabel= le (richanna@amazo= n.com) wrote:

=

The issue is that the proposal violates the standard= by changing the semantics of a parameter it defines. We should be very, ve= ry, VERY careful about telling implementers to violate an existing standard= .. This change might prove incompatible with existing or future implementations of 8414, it might not, but by viol= ating the standard the proposal creates an opportunity for incompatibility = that didn=E2=80=99t exist before.

=C2=A0

As far as simplicity is concerned, I find a solution= that reuses the existing data model and naturally supports existing and fu= ture extensions to be far simpler than one that introduces ambiguous semant= ics to existing parameters. Generally speaking, data models with properties that mean different things in differ= ent contexts tend to be fragile and require more complex code to work with.= But that=E2=80=99s just my experience as, you know, an actual developer.

=C2=A0

Let=E2=80=99s keep the assumptions and snide remarks= about others=E2=80=99 backgrounds off the list, please.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = Dominick Baier <dbaier@leastpr= ivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skok= an <panva.ip@gm= ail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backma= n, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint &= discovery

=C2=A0

I am for keeping it simple and not introducing another link to follow.

=C2=A0

I sometimes wonder how many of the spec authors are actually developers - = these suggestions make software unnecessary complex ;)

=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 13. February 2019 at 12:25:13, Filip Skok= an (panva.ip@gmail.= com) wrote:

Hello,

=C2=A0

Additionally, a metadata document that omits token_e= ndpoint in favor of mtls_endpoints since only mTLS is supported would viola= te 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the i= mplicit grant type is supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use = should not be recommended for such AS and regular endpoints will be used, t= his satisfies the requirement

Here is one example, based on my understanding of th= e =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 defi= nes the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON a= rray containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_clien= t_auth=E2=80=9D and the endpoint specified in token_endpoint does not suppo= rt mTLS, then that metadata violates 8414. You could address this by adding= a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth metho= ds. If you take that to its logical conclusion, you end up with a complete = metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of = thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's t= he issue? Clients not having mtls capabilities won't care about the add= itional method members being present. Clients that do implement mtls by the= specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints r= oot property is not present.

=C2=A0

I gave `mtls_alternate_metadata` route a thought and= don't see how it helps, given the two above are non-issues (my $.02) a= nother discovery document only brings more of them since every property can= now be different, not just the endpoints.


S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annab= elle <richanna@= amazon.com> wrote:

Here is one example, based on my understanding of th= e =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 defi= nes the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this= token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth= =E2=80=9D and the endpoint specified in token_endpoint does not support mTL= S, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_en= dpoints object, and likewise for the other endpoints and auth methods. If y= ou take that to its logical conclusion, you end up with a complete metadata= document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to = an alternate document.

=C2=A0

Additionally, a metadata document that omits token_e= ndpoint in favor of mtls_endpoints since only mTLS is supported would viola= te 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

=C2=A0

It is possible to define the mtls_endpoints paramete= r such that the above use cases are invalid, but that does make the documen= t more complicated.. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to = just parsing the same metadata that we do today.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= >, oauth <oauth@i= etf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

Hi Annabelle,

=C2=A0

can you elaborate what would be the violation / nega= tive impact of usage of RFC8414?

=C2=A0

As it already makes use of `signed_metadata` and thi= s language is present ...

=C2=A0

>=C2=A0Consumers of the metadata MAY ignore the s= igned metadata if they do not support this feature.=C2=A0 If the consumer o= f the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values = conveyed using plain JSON elements.

=C2=A0

... would mtls_endpoints be any different? Clients a= re free to ignore this if they don't support/use mtls, and if they do t= hose values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recomm= ended for one with both mtls/regular authentication methods. token_endpoint= remains required for all intents and purposes. And as for the usable clien= t authentication methods - they should all be listed, or do you think we should separate the ones for each= hostname/port location? To what end? Is there a risk having the mtls hostn= ame/port accepting regular requests? Other then secret/key _jwt auth method= s assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

=C2=A0

=C2=A0

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annab= elle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata ch= ange, if the scenario is relevant and other approaches can=E2=80=99t adequa= tely address it =E2=80=93 and I=E2=80=99ll readily grant that we probably d= on=E2=80=99t want to depend on consistency of browser behavior at the intersection of client= certificates and Access-Control-Allow-Credentials. But care needs to be ta= ken in designing that metadata to avoid violating or otherwise negatively i= mpacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtl= s_endpoints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alte= rnate_metadata=E2=80=9D parameter whose value is the URL of an alternate me= tadata document intended for clients using mTLS. An mTLS-optional AS could have t= wo different metadata documents for mTLS and non-mTLS clients, reducing the= mTLS-optional scenario to the mTLS-only scenario. This sidesteps the chall= enges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in= RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble ad= equately gauging whether or not there's sufficient consensus to go ahea= d with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it g= ot canceled. And looking again back over the discussion, I don't believ= e a consensus call is necessary. There's been a lot of general discussi= on over the last several weeks during which several folks have stated support for the proposal while there's been = only one voice of direct dissent. That seems like rough enough consensus an= d, as such, I plan to make the change in the next revision of the document = (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different cour= se of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <= dbaier@least= privilege.com> wrote:

IMHO that=E2=80=99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrot= e:

It's been pointed o= ut that the potential issue is not isolated to the just token endpoint but = that revocation, introspection, etc. could be impacted as well. So,=C2=A0 a= t this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtl= s_endpoints' that's value we be a JSON object which itself contains= endpoints that, when present, a client doing MTLS would use rather than th= e regular endpoints.=C2=A0 A straw-man example might look like this

{
=C2=A0 "issuer":"https://server.example.com",
=C2=A0 "authorization_endpoint":"https://server.example.com/authz&qu= ot;,
=C2=A0 "token_endpoint":"https://server.example.com/token",
=C2=A0 "token_endpoint_auth_methods_supported":[ =C2=A0"clie= nt_secret_basic","tls_client_auth", "none"],
=C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo&q= uot;,
=C2=A0 "revocation_endpoint":"https://server.example.com/revo",<= br> =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", =C2=A0 "mtls_endpoints":{
=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com/token",<= br> =C2=A0 =C2=A0 "userinfo_endpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_endpoint":"https://mtls.example.com/revo= "
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give preceden= ce to an endpoint under "mtls_endpoints" while falling back to us= e the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will= use the regular endpoints. And only the host/port of the endpoints listed = in mtls_endpoints will be set up to request TLS client certificates during = handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided = for all the other regular clients that are not going to do MTLS - including= and most importantly in-browser javascript clients where there can be less= than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whe= ther or not there's sufficient consensus to go ahead with the update. T= here's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And al= so some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastpr= ivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

=C2=A0

Our approach will be that we=E2=80=99ll offer a separate token endpoint th= at supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_en= dpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And= it is indeed a good reminder that even a seemingly innocuous change that s= hould be backwards compatible can break things unexpectedly..

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Anna= belle <richanna= @amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that = all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose va= lue was a JSON object. It was a good reminder that even a seemingly innocuo= us change that should be backwards compatible can force more work on client= s than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pingidentity..= com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what c= ould have gone wrong with or how token_endpoint_auth_methods broke somethin= g with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain tha= t one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pin= gidentity.com> wrote:

It may well be due to my own intellectual shortcomin= gs but these issues/questions/confusion-points are not resonating for me as= being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being he= ard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless o= nly the implicit grant type is supported.=E2=80=9D So what does the mTLS-on= ly AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier= is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question.
  4. This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98= =83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed h= ere sufficiently deals with the fallout from that. In my view this is a com= plex enough issue and it=E2=80=99s for a nuanced enough use case (as far as= I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization S= erver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the d= oor.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this dr= aft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
  2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

=C2=A0

Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org> on beh= alf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that w= asn't made clear.. It'd be something to the effect of optional for = the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.

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

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ec448d0581e2bc71-- From nobody Thu Feb 14 17:00:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AE9130E3F for ; Thu, 14 Feb 2019 17:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGsUc06kNVWH for ; Thu, 14 Feb 2019 17:00:33 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB60130E1C for ; Thu, 14 Feb 2019 17:00:32 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1F102f3098341; Fri, 15 Feb 2019 01:00:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=PPQKUGsR9C61LRt1QciabkquCFy/NRXsR2mFMe+PnLU=; b=K5rXlkvDKhbbZWPHeL1tig7G6UPupVj0V3XGas6HqZUPI+y23MUSGnU1hBuX+jO8YxX+ HW1d/J5a8BbOT5o57VH1W4cpybEn4W+7uDd1bx2bCCy7/qkO2Mztp50X0bETssAzaLAJ gKDznGu71/Pgvvoz37aAQshOzjcevYnDC6tmAzoq4ymm3nMvLH4oqAIESTob92aWMA8r 6G+G6IRI49lDaCQ6ozlwJEyWYTDQPTdhUy1Wn8V7RkS+JXUI3rbvdEGoBjdNVbIbVJ/S RpxhCNUPttn+W1KcB185ERll8DxMf4cA7k5yhDJ1dEl6vaQO/IcW26YJbBDJrPKvCXzs Iw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2qhreku44j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 01:00:30 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1F10Pv7030782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 01:00:25 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1F10O8J014457; Fri, 15 Feb 2019 01:00:24 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Feb 2019 17:00:24 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-C9EA1723-94F2-4551-8E82-A0C61861A0E9 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Thu, 14 Feb 2019 17:00:22 -0800 Cc: Dominick Baier , oauth Content-Transfer-Encoding: 7bit Message-Id: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> To: Brian Campbell X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9167 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902150005 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:00:40 -0000 --Apple-Mail-C9EA1723-94F2-4551-8E82-A0C61861A0E9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian Apologies for any confusion. I agree with you totally.=20 I was trying to say the pointer is necessary for tls infrastructure agility.= =20 I disagreed with Dominick in this case. The supposed complexity reflects rea= l world variability we have to deal with in both browsers and serverless clo= ud infrastructure components.=20 That said Dominick I agree with the principle that optionality often creates= complexity and security risks.=20 Phil > On Feb 14, 2019, at 3:08 PM, Brian Campbell w= rote: >=20 > Maybe I'm wrong here (it's never out of the question) but based on this pr= evious message and this one I believe that actually you are both in favor (g= enerally anyway) of the proposal with the optional "mtls_endpoints" paramete= r. While I believe that the comment about optionality and complexity was mea= nt to be a more general remark. While I can certainly appreciate a desire to= keep things simple, I do regret that this thread took a turn towards person= al. Whether it was the intent or not, there's an impact.=20 >=20 >=20 >=20 >> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wrote: >> I feel I have to disagree. I agree that optionality is often complexity a= nd should be avoided. But, I think the optionality here is an agility featur= e allowing mtls to work across a diversified market of different types of tl= s terminators with varying capability. Lack of appropriate discovery/options= could serve to make the spec unusable in many cases. =20 >>=20 >> A complicating factor with tls is that a tls layer failure prevents the A= S from issuing a correcting directive like an http error or http redirect.=20= >>=20 >> We have to be sure not to break existing clients so we may in some cases n= eed mtls only endpoints. I am not far enough along to know for sure. But I t= end to agree with Brian on this.=20 >>=20 >> This may be a sign we need more implementation data (including from tls w= g) to make the right call.=20 >>=20 >> Phil >>=20 >>> On Feb 14, 2019, at 8:56 AM, Dominick Baier w= rote: >>>=20 >>> Sorry - this was not meant to be snide at all. >>>=20 >>> It was honest feedback that you also need to keep software complexity in= mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR tha= t, or send values in arbitrary order adds to complexity. Complexity is the n= atural enemy of security. >>>=20 >>> Cheers=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>> Dominick >>>=20 >>>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@= amazon.com) wrote: >>>>=20 >>>> The issue is that the proposal violates the standard by changing the se= mantics of a parameter it defines. We should be very, very, VERY careful abo= ut telling implementers to violate an existing standard.. This change might p= rove incompatible with existing or future implementations of 8414, it might n= ot, but by violating the standard the proposal creates an opportunity for in= compatibility that didn=E2=80=99t exist before. >>>>=20 >>>> =20 >>>>=20 >>>> As far as simplicity is concerned, I find a solution that reuses the ex= isting data model and naturally supports existing and future extensions to b= e far simpler than one that introduces ambiguous semantics to existing param= eters. Generally speaking, data models with properties that mean different t= hings in different contexts tend to be fragile and require more complex code= to work with. But that=E2=80=99s just my experience as, you know, an actual= developer. >>>>=20 >>>> =20 >>>>=20 >>>> Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80= =99 backgrounds off the list, please. >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: Dominick Baier >>>> Date: Wednesday, February 13, 2019 at 4:18 AM >>>> To: "Richard Backman, Annabelle" , Filip Skokan >>>> Cc: Brian Campbell , "Richard Backman, Anna= belle" , oauth >>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discov= ery >>>>=20 >>>> =20 >>>>=20 >>>> I am for keeping it simple and not introducing another link to follow. >>>>=20 >>>> =20 >>>>=20 >>>> I sometimes wonder how many of the spec authors are actually developers= - these suggestions make software unnecessary complex ;) >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94=E2=80=94=E2=80=94 >>>>=20 >>>> Dominick >>>>=20 >>>> =20 >>>>=20 >>>> On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wro= te: >>>>=20 >>>> Hello, >>>>=20 >>>> =20 >>>>=20 >>>> Additionally, a metadata document that omits token_endpoint in favor of= mtls_endpoints since only mTLS is supported would violate 8414, as 8414 say= s token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is= supported.=E2=80=9D >>>>=20 >>>>=20 >>>> mtls only AS doesn't get anything out of using mtls_endpoints, its use s= hould not be recommended for such AS and regular endpoints will be used, thi= s satisfies the requirement >>>>=20 >>>> Here is one example, based on my understanding of the =E2=80=9Cstraw ma= n=E2=80=9D format presented in this thread: RFC8414 defines the value of tok= en_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a lis= t of client authentication methods supported by this token endpoint.=E2=80=9D= If that array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint s= pecified in token_endpoint does not support mTLS, then that metadata violate= s 8414. You could address this by adding a token_endpoint_auth_methods_suppo= rted parameter to the mtls_endpoints object, and likewise for the other endp= oints and auth methods. If you take that to its logical conclusion, you end u= p with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99= s that line of thought that led me to suggest just pointing to an alternate d= ocument. >>>>=20 >>>>=20 >>>> Assuming we go with using the same root auth methods property, what's t= he issue? Clients not having mtls capabilities won't care about the addition= al method members being present. Clients that do implement mtls by the speci= fication will know to look for mtls_endpoints and fall back to regular ones i= f the specific endpoint or mtls_endpoints root property is not present. >>>>=20 >>>> =20 >>>>=20 >>>> I gave `mtls_alternate_metadata` route a thought and don't see how it h= elps, given the two above are non-issues (my $.02) another discovery documen= t only brings more of them since every property can now be different, not ju= st the endpoints. >>>>=20 >>>>=20 >>>>=20 >>>> S pozdravem, >>>> Filip Skokan >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle wrote: >>>>=20 >>>> Here is one example, based on my understanding of the =E2=80=9Cstraw ma= n=E2=80=9D format presented in this thread: RFC8414 defines the value of tok= en_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a lis= t of client authentication methods supported by this token endpoint.=E2=80=9D= If that array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint s= pecified in token_endpoint does not support mTLS, then that metadata violate= s 8414. You could address this by adding a token_endpoint_auth_methods_suppo= rted parameter to the mtls_endpoints object, and likewise for the other endp= oints and auth methods. If you take that to its logical conclusion, you end u= p with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99= s that line of thought that led me to suggest just pointing to an alternate d= ocument. >>>>=20 >>>> =20 >>>>=20 >>>> Additionally, a metadata document that omits token_endpoint in favor of= mtls_endpoints since only mTLS is supported would violate 8414, as 8414 say= s token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is= supported.=E2=80=9D >>>>=20 >>>> =20 >>>>=20 >>>> It is possible to define the mtls_endpoints parameter such that the abo= ve use cases are invalid, but that does make the document more complicated..= If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip p= ast all of these issues, because it brings us back to just parsing the same m= etadata that we do today. >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth on behalf of Filip Skokan >>>> Date: Tuesday, February 12, 2019 at 1:13 PM >>>> To: "Richard Backman, Annabelle" >>>> Cc: Brian Campbell , oau= th >>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>=20 >>>> =20 >>>>=20 >>>> Hi Annabelle, >>>>=20 >>>> =20 >>>>=20 >>>> can you elaborate what would be the violation / negative impact of usag= e of RFC8414? >>>>=20 >>>> =20 >>>>=20 >>>> As it already makes use of `signed_metadata` and this language is prese= nt ... >>>>=20 >>>> =20 >>>>=20 >>>> > Consumers of the metadata MAY ignore the signed metadata if they do n= ot support this feature. If the consumer of the metadata supports signed me= tadata, metadata values conveyed in the signed metadata MUST take precedence= over the corresponding values conveyed using plain JSON elements. >>>>=20 >>>> =20 >>>>=20 >>>> ... would mtls_endpoints be any different? Clients are free to ignore t= his if they don't support/use mtls, and if they do those values must take pr= ecedence over the root ones. the use of mtls_endpoints would not be recommen= ded for mtls-only AS but recommended for one with both mtls/regular authenti= cation methods. token_endpoint remains required for all intents and purposes= . And as for the usable client authentication methods - they should all be l= isted, or do you think we should separate the ones for each hostname/port lo= cation? To what end? Is there a risk having the mtls hostname/port accepting= regular requests? Other then secret/key _jwt auth methods assertion aud cla= im the endpoint location doesn't play a role in the authentication process. >>>>=20 >>>>=20 >>>>=20 >>>> Best, >>>> Filip >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle wrote: >>>>=20 >>>> I=E2=80=99m not opposed to introducing a metadata change, if the scenar= io is relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll readily grant that we probably don=E2=80=99t want to de= pend on consistency of browser behavior at the intersection of client certif= icates and Access-Control-Allow-Credentials. But care needs to be taken in d= esigning that metadata to avoid violating or otherwise negatively impacting u= sage of RFC8414. >>>>=20 >>>> =20 >>>>=20 >>>> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D= metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D= parameter whose value is the URL of an alternate metadata document intended= for clients using mTLS. An mTLS-optional AS could have two different metada= ta documents for mTLS and non-mTLS clients, reducing the mTLS-optional scena= rio to the mTLS-only scenario. This sidesteps the challenges of aligning the= =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rig= id parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_aut= h_methods_supported). >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth on behalf of Brian Campbell >>>> Date: Tuesday, February 12, 2019 at 10:58 AM >>>> To: Dominick Baier >>>> Cc: oauth >>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>=20 >>>> =20 >>>>=20 >>>> Thanks for the input, Dominick. >>>>=20 >>>> =20 >>>>=20 >>>> I'd said previously that I was having trouble adequately gauging whethe= r or not there's sufficient consensus to go ahead with the update. I was eve= n thinking of asking the chairs about a consensus call during the office hou= rs meeting yesterday. But it got canceled. And looking again back over the d= iscussion, I don't believe a consensus call is necessary. There's been a lot= of general discussion over the last several weeks during which several folk= s have stated support for the proposal while there's been only one voice of d= irect dissent. That seems like rough enough consensus and, as such, I plan t= o make the change in the next revision of the document (which should be done= soon). Chairs, please let me know, if you believe the situation warrants a d= ifferent course of action. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier wrote: >>>>=20 >>>> IMHO that=E2=80=99s a reasonable and pragmatic option. >>>>=20 >>>> =20 >>>>=20 >>>> Thanks >>>>=20 >>>> =E2=80=94=E2=80=94=E2=80=94 >>>>=20 >>>> Dominick >>>>=20 >>>> =20 >>>>=20 >>>> On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentit= y.com) wrote: >>>>=20 >>>> It's been pointed out that the potential issue is not isolated to the j= ust token endpoint but that revocation, introspection, etc. could be impacte= d as well. So, at this point, the proposal on the table is to add a new opt= ional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON= object which itself contains endpoints that, when present, a client doing M= TLS would use rather than the regular endpoints. A straw-man example might l= ook like this >>>>=20 >>>> { >>>> "issuer":"https://server.example.com", >>>> "authorization_endpoint":"https://server.example.com/authz", >>>> "token_endpoint":"https://server.example.com/token", >>>> "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls= _client_auth", "none"], >>>> "userinfo_endpoint":"https://server.example.com/userinfo", >>>> "revocation_endpoint":"https://server.example.com/revo", >>>> "jwks_uri":"https://server.example.com/jwks.json", >>>> "mtls_endpoints":{ >>>> "token_endpoint":"https://mtls.example.com/token", >>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>> "revocation_endpoint":"https://mtls.example.com/revo" >>>> } >>>> } >>>>=20 >>>> =20 >>>>=20 >>>> A client doing MTLS would look for and give precedence to an endpoint u= nder "mtls_endpoints" while falling back to use the normal endpoint from the= top level of metadata when/if its not in "mtls_endpoints". >>>>=20 >>>>=20 >>>> The idea being that "regular" clients (those not doing MTLS) will use t= he regular endpoints. And only the host/port of the endpoints listed in mtls= _endpoints will be set up to request TLS client certificates during handshak= e. Thus any potential impact of the CertificateRequest message being sent in= the TLS handshake can be avoided for all the other regular clients that are= not going to do MTLS - including and most importantly in-browser javascript= clients where there can be less than desirable UI presented to the end-user= . >>>>=20 >>>> =20 >>>>=20 >>>> I'm struggling, however, to adequately gauge whether or not there's suf= ficient consensus to go ahead with the update. There's been some support for= it voiced. As well as talk of other approaches that could be alternatives o= r additional measures. And also some vocal opposition to it.=20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: >>>>=20 >>>> We are currently implementing MTLS in IdentityServer. >>>>=20 >>>> =20 >>>>=20 >>>> Our approach will be that we=E2=80=99ll offer a separate token endpoint= that supports client certs. Are you planning on adding an official endpoint= name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. >>>>=20 >>>> =20 >>>>=20 >>>> Thanks >>>>=20 >>>> =E2=80=94=E2=80=94=E2=80=94 >>>>=20 >>>> Dominick >>>>=20 >>>> =20 >>>>=20 >>>> On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingiden= tity.com@dmarc.ietf.org) wrote: >>>>=20 >>>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a goo= d reminder that even a seemingly innocuous change that should be backwards c= ompatible can break things unexpectedly.. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle wrote: >>>>=20 >>>> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS= metadata. We had clients in the wild that assumed that all the properties i= n the JSON object returned from our userinfo endpoint were scalar strings. T= his broke when we introduced a new property whose value was a JSON object. I= t was a good reminder that even a seemingly innocuous change that should be b= ackwards compatible can force more work on clients than we expect. >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: Brian Campbell >>>> Date: Wednesday, February 6, 2019 at 11:30 AM >>>> To: "Richard Backman, Annabelle" >>>> Cc: "Richard Backman, Annabelle" , oauth >>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser cli= ents using the token endpoint >>>>=20 >>>> =20 >>>>=20 >>>> And I'm honestly really struggling to see what could have gone wrong wi= th or how token_endpoint_auth_methods broke something with the user info end= point. If you have the time and/or it'd be informative to this here little d= iscussion, please explain that one a bit more. >>>>=20 >>>> =20 >>>>=20 >>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell wrote: >>>>=20 >>>> "far" should have said "fair" in the previous message >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: >>>>=20 >>>> It may well be due to my own intellectual shortcomings but these issues= /questions/confusion-points are not resonating for me as being problematic. >>>>=20 >>>> =20 >>>>=20 >>>> The more general stance of "this isn't needed or worth it in this docum= ent" (I think that's far?) is being heard though. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle wrote: >>>>=20 >>>> (TL;DR: punt AS metadata to a separate draft) >>>>=20 >>>> AS points #1-3 are all questions I would have as an implementer: >>>>=20 >>>> Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless on= ly the implicit grant type is supported.=E2=80=9D So what does the mTLS-only= AS put here? >>>> The claims for these other endpoints are OPTIONAL, potentially leading t= o inconsistency depending on how #1 gets decided. >>>> The example usage of the token_endpoint_auth_methods property given ear= lier is incompatible with RFC8414, since some of its contents are only valid= for the non-mTLS endpoints, and others are only valid for the mTLS endpoint= s. Hence this question. >>>> This introduces a new metadata property that could impact how other spe= cs should extend AS metadata. That needs to be addressed. >>>> =20 >>>>=20 >>>> I could go on for client points but you already get the point. Though I= =E2=80=99ll share that #3 is real and once forced me to roll back an update t= o the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>>>=20 >>>> =20 >>>>=20 >>>> I don=E2=80=99t necessarily think an AS metadata property is wrong per s= e, but understand that you=E2=80=99re bolting a layer of flexibility onto a s= tandard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the= metadata proposal as it=E2=80=99s been discussed here sufficiently deals wi= th the fallout from that. In my view this is a complex enough issue and it=E2= =80=99s for a nuanced enough use case (as far as I can tell from discussion?= Please correct me if I=E2=80=99m wrong) that we should punt it to a separat= e draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hy= brids=E2=80=9D) and get mTLS out the door. >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth on behalf of Brian Campbell >>>> Date: Monday, February 4, 2019 at 5:28 AM >>>> To: "Richard Backman, Annabelle" >>>> Cc: oauth >>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser cli= ents using the token endpoint >>>>=20 >>>> =20 >>>>=20 >>>> Those points of confusion strike me as somewhat hypothetical or hyperbo= lic. But your general point is taken and your position of being anti additio= nal metadata on this issue is noted. >>>>=20 >>>> =20 >>>>=20 >>>> All of which leaves me a bit uncertain about how to proceed. There seem= to be a range of opinions on this point and gauging consensus is proving el= usive for me. That's confounded by my own opinion on it being somewhat fluid= . >>>>=20 >>>> =20 >>>>=20 >>>> And I'd really like to post an update to this draft about a month or tw= o ago. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle wrote: >>>>=20 >>>> Confusion from the AS=E2=80=99s perspective: >>>>=20 >>>> If I only support mTLS, do I need to include both token_endpoint_uri an= d mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty s= tring? >>>> What if I only support mTLS for the token endpoint, but not revocation o= r user info? >>>> How do I specify authentication methods for the mTLS token endpoint? Do= es token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints= ? >>>> I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enable= d device_authorization_endpoint under mtls_endpoints? >>>> =20 >>>>=20 >>>> Confusion from the client=E2=80=99s perspective: >>>>=20 >>>> As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know a= nything about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me. >>>> My AS metadata parser crashed because the mTLS-only AS omitted token_en= dpoint_uri. >>>> My AS metadata parser crashed because it didn=E2=80=99t expect to encou= nter a JSON object as a parameter value. >>>> The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, wha= t do I do? >>>> I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told= me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its n= ame, right? >>>> =20 >>>>=20 >>>> Yes, you can write normative text that answers most of these. But you=E2= =80=99ll have to clearly cover a lot of similar-but-slightly-different scena= rios and be very explicit. And implementers will still get it wrong. The met= adata change introduces opportunities for confusion and failure that do not e= xist now, and forces them on everyone who supports mTLS. In contrast, the 30= 7 redirect is only required when an AS wants to support both, and is unambig= uous in its behavior and meaning. >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: Brian Campbell >>>> Date: Friday, February 1, 2019 at 3:17 PM >>>> To: "Richard Backman, Annabelle" >>>> Cc: George Fletcher , oauth >>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients= using the token endpoint >>>>=20 >>>> =20 >>>>=20 >>>> It doesn't seem like that confusing or large of a change to me - if the= client is doing MTLS and the given endpoint is present in `mtls_endpoints`,= then it uses that one. Otherwise it uses the regular endpoint. It gives a= n AS a lot of flexibility in deployment options. I personally think getting a= 307 approach deployed and working would be more complicated and error prone= .=20 >>>>=20 >>>> =20 >>>>=20 >>>> It is a minority use case at the moment but there are forces in play, l= ike the push for increased security in general and to have javascript client= s use the code flow, that suggest it won't be terribly unusual to see an AS t= hat wants to support MTLS clients and javascript/spa clients at the same tim= e. >>>>=20 >>>> =20 >>>>=20 >>>> I've personally wavered back and forth in this thread on whether or not= to add the new metadata (or something like it). With my reasoning each way k= inda explained somewhere back in the 40 or so messages that make up this thr= ead. But it seems like the rough consensus of the group here is in favor of= it. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: >>>>=20 >>>> This strikes me as a very prominent and confusing change to support wha= t seems to be a minority use case. I=E2=80=99m getting a headache just think= ing about the text needed to clarify when the AS should provide `mtls_endpoi= nts` and when the client should use that versus using `token_endpoint.` Why i= s the 307 status code insufficient to cover the case where a single AS suppo= rts both mTLS and non-mTLS? >>>>=20 >>>> =20 >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth on behalf of Brian Campbell >>>> Date: Friday, February 1, 2019 at 1:31 PM >>>> To: George Fletcher >>>> Cc: oauth >>>> Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token end= point >>>>=20 >>>> =20 >>>>=20 >>>> Yes, that would work.=20 >>>>=20 >>>> =20 >>>>=20 >>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: >>>>=20 >>>> What if the AS wants to ONLY support MTLS connections. Does it not spec= ify the optional "mtls_endpoints" and just use the normal metadata values? >>>>=20 >>>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>>>=20 >>>> It would definitely be optional, apologies if that wasn't made clear.. I= t'd be something to the effect of optional for the AS to include and clients= doing MTLS would use it when present in AS metadata. >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge wrote: >>>>=20 >>>> I'm in favour of the `mtls_endpoints` metadata parameter - although it s= hould be optional. >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf..org/mailman/listinfo/oauth >>>> =20 >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________=20 >>>> OAuth mailing list=20 >>>> OAuth@ietf.org=20 >>>> 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 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. --Apple-Mail-C9EA1723-94F2-4551-8E82-A0C61861A0E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian

Apologies for any c= onfusion. I agree with you totally. 

I was try= ing to say the pointer is necessary for tls infrastructure agility.  

I disagreed with Dominick in this case. The supposed= complexity reflects real world variability we have to deal with in both bro= wsers and serverless cloud infrastructure components. 

That said Dominick I agree with the principle that optionality ofte= n creates complexity and security risks. 

Phil

On Feb 14, 2019, at 3:08= PM, Brian Campbell <bcampb= ell@pingidentity.com> wrote:

<= div dir=3D"ltr">
Maybe I'm wrong here (it's never out of the question) but based o= n this previous message and this one I believe that actually= you are both in favor (generally anyway) of the proposal with the optional "= mtls_endpoints" parameter. While I believe that the comment about optionalit= y and complexity was meant to be a more general r= emark. While I can certainly appreciate a desire to keep things simpl= e, I do regret that this thread took a turn towards personal. Whether it was= the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com>= wrote:
I feel I have to disagree.  I agree that optionality is often co= mplexity and should be avoided. But, I think the optionality here is an agil= ity feature allowing mtls to work across a diversified market of different t= ypes of tls terminators with varying capability. Lack of appropriate discove= ry/options could serve to make the spec unusable in many cases.  
<= br>
A complicating factor with tls is that a tls layer failure pre= vents the AS from issuing a correcting directive like an http error or http r= edirect. 

We have to be sure not to break exis= ting clients so we may in some cases need mtls only endpoints. I am not far e= nough along to know for sure. But I tend to agree with Brian on this. <= /div>

This may be a sign we need more implementation data= (including from tls wg) to make the right call. 

Phil

On= Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:
Sorry - this was not meant to be snide a= t all.

It was honest f= eedback that you also need to keep software complexity in mind when creating= a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values i= n arbitrary order adds to complexity. Complexity is the natural enemy of sec= urity.

Cheers 
=E2=80=94=E2=80=94=E2=80=94
D= ominick

On 13. February 2019 a= t 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard b= y changing the semantics of a parameter it defines. We should be very, very,= VERY careful about telling implementers to violate an existing standard.. T= his change might prove incompatible with existing or future implementations of 8414, it might not, but by viola= ting the standard the proposal creates an opportunity for incompatibility th= at didn=E2=80=99t exist before.

 

As far as simplicity is concerned, I find a solution t= hat reuses the existing data model and naturally supports existing and futur= e extensions to be far simpler than one that introduces ambiguous semantics t= o existing parameters. Generally speaking, data models with properties that mean different things in differe= nt contexts tend to be fragile and require more complex code to work with. B= ut that=E2=80=99s just my experience as, you know, an actual developer.

 

Let=E2=80=99s keep the assumptions and snide remarks a= bout others=E2=80=99 backgrounds off the list, please.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: <= /span>Dominick Baier <dbaier@leastprivi= lege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com&g= t;
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annab= elle" <richanna@= amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & d= iscovery

 

= I am for keeping it simple and not introducing another link to follow.

=  

= I sometimes wonder how many of the spec authors are actually developers - th= ese suggestions make software unnecessary complex ;)

 

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan= (panva.ip@gmail.com= ) wrote:

Hello,

 

Additionally, a metadata document that omits token_en= dpoint in favor of mtls_endpoints since only mTLS is supported would violate= 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the impl= icit grant type is supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use shoul= d not be recommended for such AS and regular endpoints will be used, this sa= tisfies the requirement

Here is one example, based on my understanding of the= =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 define= s the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON arra= y containing a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client= _auth=E2=80=9D and the endpoint specified in token_endpoint does not support= mTLS, then that metadata violates 8414. You could address this by adding a t= oken_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth method= s. If you take that to its logical conclusion, you end up with a complete me= tadata document hanging off of mtls_endpoints. It=E2=80=99s that line of tho= ught that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the is= sue? Clients not having mtls capabilities won't care about the additional me= thod members being present. Clients that do implement mtls by the specificat= ion will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints ro= ot property is not present.

 

I gave `mtls_alternate_metadata` route a thought and d= on't see how it helps, given the two above are non-issues (my $.02) another d= iscovery document only brings more of them since every property can now be d= ifferent, not just the endpoints.


S pozdravem,
Filip Skokan

 

 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabe= lle <richanna@am= azon.com> wrote:

Here is one example, based on my understanding of the= =E2=80=9Cstraw man=E2=80=9D format presented in this thread: RFC8414 define= s the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this t= oken endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2=80= =9D and the endpoint specified in token_endpoint does not support mTLS, then= that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_end= points object, and likewise for the other endpoints and auth methods. If you= take that to its logical conclusion, you end up with a complete metadata do= cument hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest just pointing to a= n alternate document.

 

Additionally, a metadata document that omits token_en= dpoint in favor of mtls_endpoints since only mTLS is supported would violate= 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

 

It is possible to define the mtls_endpoints parameter= such that the above use cases are invalid, but that does make the document m= ore complicated.. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to j= ust parsing the same metadata that we do today.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behal= f of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&= gt;
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org&g= t;, oauth <oauth@ietf= ..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=

 

Hi Annabelle,

 

can you elaborate what would be the violation / negat= ive impact of usage of RFC8414?

 

As it already makes use of `signed_metadata` and this= language is present ...

 

> Consumers of the metadata MAY ignore the si= gned metadata if they do not support this feature.  If the consumer of t= he metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values c= onveyed using plain JSON elements.

 

... would mtls_endpoints be any different? Clients ar= e free to ignore this if they don't support/use mtls, and if they do those v= alues must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recomme= nded for one with both mtls/regular authentication methods. token_endpoint r= emains required for all intents and purposes. And as for the usable client a= uthentication methods - they should all be listed, or do you think we should separate the ones for each h= ostname/port location? To what end? Is there a risk having the mtls hostname= /port accepting regular requests? Other then secret/key _jwt auth methods as= sertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

 

 

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabe= lle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata cha= nge, if the scenario is relevant and other approaches can=E2=80=99t adequate= ly address it =E2=80=93 and I=E2=80=99ll readily grant that we probably don=E2= =80=99t want to depend on consistency of browser behavior at the intersection of client c= ertificates and Access-Control-Allow-Credentials. But care needs to be taken= in designing that metadata to avoid violating or otherwise negatively impac= ting usage of RFC8414.

 

Along those lines, instead of adding an =E2=80=9Cmtls= _endpoints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_altern= ate_metadata=E2=80=9D parameter whose value is the URL of an alternate metad= ata document intended for clients using mTLS. An mTLS-optional AS could have tw= o different metadata documents for mTLS and non-mTLS clients, reducing the m= TLS-optional scenario to the mTLS-only scenario. This sidesteps the challeng= es of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in R= FC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behal= f of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
= Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequat= ely gauging whether or not there's sufficient consensus to go ahead with the= update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it go= t canceled. And looking again back over the discussion, I don't believe a co= nsensus call is necessary. There's been a lot of general discussion over the= last several weeks during which several folks have stated support for the proposal while there's been only o= ne voice of direct dissent. That seems like rough enough consensus and, as s= uch, I plan to make the change in the next revision of the document (which s= hould be done soon). Chairs, please let me know, if you believe the situation warrants a different cours= e of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <<= a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastpr= ivilege.com> wrote:

= IMHO that=E2=80=99s a reasonable and pragmatic option.

=  

= Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:=

It's been pointed out th= at the potential issue is not isolated to the just token endpoint but that r= evocation, introspection, etc. could be impacted as well. So,  at this p= oint, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_end= points' that's value we be a JSON object which itself contains endpoints tha= t, when present, a client doing MTLS would use rather than the regular endpo= ints.  A straw-man example might look like this

{
  "issuer":"ht= tps://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic"= ,"tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedenc= e to an endpoint under "mtls_endpoints" while falling back to use the normal= endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the re= gular endpoints. And only the host/port of the endpoints listed in mtls_endp= oints will be set up to request TLS client certificates during handshake. Th= us any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided f= or all the other regular clients that are not going to do MTLS - including a= nd most importantly in-browser javascript clients where there can be less th= an desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether o= r not there's sufficient consensus to go ahead with the update. There's been= some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And als= o some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivi= lege.com> wrote:

= We are currently implementing MTLS in IdentityServer.

=  

= Our approach will be that we=E2=80=99ll offer a separate token endpoint that= supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_end= point=E2=80=9D.

=  

= Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingid= entity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And i= t is indeed a good reminder that even a seemingly innocuous change that shou= ld be backwards compatible can break things unexpectedly..

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annab= elle <richanna@a= mazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t speci= fically involve AS metadata. We had clients in the wild that assumed that al= l the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose val= ue was a JSON object. It was a good reminder that even a seemingly innocuous= change that should be backwards compatible can force more work on clients t= han we expect.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity..co= m>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&= gt;
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint

 

And I'm honestly really struggling to see what could h= ave gone wrong with or how token_endpoint_auth_methods broke something with t= he user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one= a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@ping= identity.com> wrote:

"far" should have said "fair" in the previous message=

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingid= entity.com> wrote:

It may well be due to my own intellectual shortcoming= s but these issues/questions/confusion-points are not resonating for me as b= eing problematic.

 

The more general stance of "this isn't needed or wort= h it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annab= elle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414<= /a> says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant t= ype is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to in= consistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier i= s incompatible with RFC8414, since some of its contents are only valid for t= he non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hen= ce this question.
  4. This introduces a new metadata property that could impact how other specs sh= ould extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get t= he point. Though I=E2=80=99ll share that #3 is real and once forced me to ro= ll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83=

 

I don=E2=80=99t necessarily think an AS metadata prop= erty is wrong per se, but understand that you=E2=80=99re bolting a layer of f= lexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed he= re sufficiently deals with the fallout from that. In my view this is a compl= ex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I c= an tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Se= rver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the doo= r.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behal= f of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
= Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org&= gt;
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint

 

Those points of confusion strike me as somewhat hypot= hetical or hyperbolic. But your general point is taken and your position of b= eing anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to p= roceed. There seem to be a range of opinions on this point and gauging conse= nsus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft a= bout a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annab= elle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtl= s_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string= ?
  2. What if I only support mTLS for the token endpoint, but not revocation or us= er info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does to= ken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled dev= ice_authorization_endpoint under mtls_endpoints?

 

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anythi= ng about mTLS, but the IT admins installed client certs in their users=E2=80= =99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoin= t_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a= JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I= do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me t= o use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name,= right?

 

Yes, you can write normative text that answers most o= f these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sligh= tly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for c= onfusion and failure that do not exist now, and forces them on everyone who s= upports mTLS. In contrast, the 307 redirect is only required when an AS want= s to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clien= ts using the token endpoint

 

It doesn't seem like that confusing or large of a cha= nge to me - if the client is doing MTLS and the given endpoint is present in= `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deploy= ment options. I personally think getting a 307 approach deployed and working= would be more complicated and error prone. 

 

It is a minority use case at the moment but there are= forces in play, like the push for increased security in general and to have= javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS client= s and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread= on whether or not to add the new metadata (or something like it). With my r= easoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like t= he rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annab= elle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing cha= nge to support what seems to be a minority use case. I=E2=80=99m getting a h= eadache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that v= ersus using `token_endpoint.` Why is the 307 status code insufficient to cov= er the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behal= f of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
= Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token e= ndpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gf= fletch=3D40aol= .com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it= not specify the optional "mtls_endpoints" and just use the normal metadata v= alues?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wa= sn't made clear.. It'd be something to the effect of optional for the AS to i= nclude and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@moment= umft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - althou= gh it should be optional.


CONFIDENTIALITY NOTICE: This email may con= tain confidential and privileged material for the sole use of the intended r= ecipient(s). Any review, use, distribution or disclosure by others is strict= ly prohibited..  If you have received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org<=
/pre>

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

 


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman= /listinfo/oauth


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.


CONFIDENTIALITY N= OTICE: This email may contain confidential and privileged material for the s= ole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.

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

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

________= _______________________________________
OAuth mailing list
OAuth@iet= f.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.
= --Apple-Mail-C9EA1723-94F2-4551-8E82-A0C61861A0E9-- From nobody Fri Feb 15 11:28:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C64130FF6 for ; Fri, 15 Feb 2019 11:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-ljJEtOyQfl for ; Fri, 15 Feb 2019 11:28:09 -0800 (PST) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8E1130FC4 for ; Fri, 15 Feb 2019 11:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550258887; bh=GZqEvOJn+T67KryC/FAg1PMeAroJMIG5HpxbU6tadvE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=IA4vx/PTczvfxeeyXvl7TuiL9qgsk1D6mUNI3aWpoRmn7Ob2EZh94Gr/RQTDHE9fMhRsIIuHVsfeJncdX1Mcw7cM8vOW1PRws+DwGZbcR9CaWeRPUFzODGHPfCLwwLZ0bLUKI/lG6XIDpl9K1U1tI/MCkKD1sYMVzEz29pMn2LO2Wr2AAT+GxxlA13gbd41b5zDpQzsaqmwbNGbqhcFN54o9giiuJNgS2xbBsZoXfrd3AHXaIQmaipWAMqkggbt+Qyb+o4CZmziIhT6ZM2KrEc/a+i1+RnA7BET4S8PR4KLFwHWRt13BFbRmxWNUmd6Q0RO15jxSKahCdcIWTC8GUQ== X-YMail-OSG: a2HPVP4VM1l81tCqk2o9a_XhJdHW7R7Wndrdf1TS0HQ7MIQdEobynX62yD9qKWX NA9niaPmEbXmCfxj8y0jyRCT2SJy9KDgFbMKRiEybxzr.cFkmQe6DlckNdk19rUP8Jr9xxZzRwEF 9FDZRNYt6Xd.CXXGgb153eSKO7j9mlpFjY0I1.Ma.iRTEHI0h0NUlHMpT8iHr4V3p_wT73ICkrz0 _cwH2ahOYyMSlRlwQvz1RoA9LZxrmOzg4U4QyBsQxzCnr7GHSe8NDP7QR7DrPIjC8mljwM7Siwmx kL4B5FI4FUUkyr20ThUQWGWAccD3KHZ1AupGv3rS6Eyp0gguKmIpuEObKYimll.wq.yJF5rFDEDa kt.ZBPD_6IJcSJPT8fMV48aBWxPfUisHx1jMJc10FUOO7WRd_xRkeiuXoYmfvullEMsd0jk.4UQT 1WtyX_Cpopv1usaihb.fwSFUEkCCUUpk85Qm7gybvY5hy3X1y.GtrBx0QopXacbBbYcNfoOLXfKK clBFQwyNHf9Bt5sA1F.uwD2g1FXkdQe81BEh.nN91ibotAhl0wjJZwR3EjZOQwVBHoZBQYPsVFey dlzzf2iJovgznU7ovMT.5jebcRy1YSEoLUsDMGN0cIqeX0R0r2PNZl1CJzVUodSo6Y9aPTw5UNrt BVbb.Hn0AJ4w4jAZJYDPbeR.O.3r77IosCDpfiobFg6AaGJ9XHx7ravdlwrseHsSSj6NOisuqXZj o0Y1mK8EJebrlnoUzj8lNO2OxTHW_hMfvdoA5ijJn3IWNlMQi8gXNxOIAQOVVfuSuYKtJLfwf8Ao i0ZGtOCUbPBh_agmKi5mwf1QF9aBk7K8xXVcihbL5z8mVIDoEljW7w.A7L3NBpImn6b2P36w6AzO jdewWkhYAxl62D6wR8kso2GIDNxPhIc16GP3eiX9NATgdXqW1VY2k6pTmfyJABYdBLgx7NCO3Kay RMKqIe2qwAeckeAP0PTiKREAEdQrrfSQAFI7LJbPu3jr90EnUg8rx9Pl0ZzujVKNsYHfRdVSoJf4 QppXHNYTj2KtKFwwV1j8xv.XHOhpjV3TYyJonyrv7AKDkltfiU_asjcCw7KFph0o- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 19:28:07 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a368eaf977dd475249f5509467441587; Fri, 15 Feb 2019 19:28:05 +0000 (UTC) To: Brian Campbell , Phil Hunt Cc: oauth References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> From: George Fletcher Organization: AOL LLC Message-ID: <4027f7d3-bf02-b957-c169-b7842e5afe88@aol.com> Date: Fri, 15 Feb 2019 14:28:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2E908DCE85889D96673D7657" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 19:28:18 -0000 This is a multi-part message in MIME format. --------------2E908DCE85889D96673D7657 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I still don't see how we solve one of the use cases Annabelle brought up. If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS? Thanks, George On 2/14/19 6:08 PM, Brian Campbell wrote: > Maybe I'm wrong here (it's never out of the question) but based on > this previous message > > and this one > > I believe that actually you are both in favor (generally anyway) of > the proposal with the optional "mtls_endpoints" parameter. While I > believe that the comment about optionality and complexity was meant to > be a more general remark. While I can certainly appreciate a desire to > keep things simple, I do regret that this thread took a turn towards > personal. Whether it was the intent or not, there's an impact. > > > > On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt > wrote: > > I feel I have to disagree.  I agree that optionality is often > complexity and should be avoided. But, I think the optionality > here is an agility feature allowing mtls to work across a > diversified market of different types of tls terminators with > varying capability. Lack of appropriate discovery/options could > serve to make the spec unusable in many cases. > > A complicating factor with tls is that a tls layer failure > prevents the AS from issuing a correcting directive like an http > error or http redirect. > > We have to be sure not to break existing clients so we may in some > cases need mtls only endpoints. I am not far enough along to know > for sure. But I tend to agree with Brian on this. > > This may be a sign we need more implementation data (including > from tls wg) to make the right call. > > Phil > > On Feb 14, 2019, at 8:56 AM, Dominick Baier > > wrote: > >> Sorry - this was not meant to be snide at all. >> >> It was honest feedback that you also need to keep software >> complexity in mind when creating a spec. Every MAY or OPTIONAL, >> or do it like this OR that, or send values in arbitrary order >> adds to complexity. Complexity is the natural enemy of security. >> >> Cheers >> ——— >> Dominick >> >> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle >> (richanna@amazon.com ) wrote: >> >>> The issue is that the proposal violates the standard by changing >>> the semantics of a parameter it defines. We should be very, >>> very, VERY careful about telling implementers to violate an >>> existing standard... This change might prove incompatible with >>> existing or future implementations of 8414, it might not, but by >>> violating the standard the proposal creates an opportunity for >>> incompatibility that didn’t exist before. >>> >>> As far as simplicity is concerned, I find a solution that reuses >>> the existing data model and naturally supports existing and >>> future extensions to be far simpler than one that introduces >>> ambiguous semantics to existing parameters. Generally speaking, >>> data models with properties that mean different things in >>> different contexts tend to be fragile and require more complex >>> code to work with. But that’s just my experience as, you know, >>> an actual developer. >>> >>> Let’s keep the assumptions and snide remarks about others’ >>> backgrounds off the list, please. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> *From: *Dominick Baier >> > >>> *Date: *Wednesday, February 13, 2019 at 4:18 AM >>> *To: *"Richard Backman, Annabelle" >> >, Filip Skokan >> > >>> *Cc: *Brian Campbell >> >, "Richard Backman, >>> Annabelle" >, >>> oauth > >>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint >>> & discovery >>> >>> I am for keeping it simple and not introducing another link to >>> follow. >>> >>> I sometimes wonder how many of the spec authors are actually >>> developers - these suggestions make software unnecessary complex ;) >>> >>> ——— >>> >>> Dominick >>> >>> On 13. February 2019 at 12:25:13, Filip Skokan >>> (panva.ip@gmail.com ) wrote: >>> >>> Hello, >>> >>> Additionally, a metadata document that omits >>> token_endpoint in favor of mtls_endpoints since only >>> mTLS is supported would violate 8414, as 8414 says >>> token_endpoint “is REQUIRED unless only the implicit >>> grant type is supported.” >>> >>> >>> mtls only AS doesn't get anything out of using >>> mtls_endpoints, its use should not be recommended for such >>> AS and regular endpoints will be used, this satisfies the >>> requirement >>> >>> Here is one example, based on my understanding of the >>> “straw man” format presented in this thread: RFC8414 >>> defines the value of >>> token_endpoint_auth_methods_supported as a “JSON array >>> containing a list of client authentication methods >>> supported by this token endpoint.” If that array >>> contains “tls_client_auth” and the endpoint specified in >>> token_endpoint does not support mTLS, then that metadata >>> violates 8414. You could address this by adding a >>> token_endpoint_auth_methods_supported parameter to the >>> mtls_endpoints object, and likewise for the other >>> endpoints and auth methods. If you take that to its >>> logical conclusion, you end up with a complete metadata >>> document hanging off of mtls_endpoints. It’s that line >>> of thought that led me to suggest just pointing to an >>> alternate document. >>> >>> >>> Assuming we go with using the same root auth methods >>> property, what's the issue? Clients not having mtls >>> capabilities won't care about the additional method members >>> being present. Clients that do implement mtls by the >>> specification will know to look for mtls_endpoints and fall >>> back to regular ones if the specific endpoint or >>> mtls_endpoints root property is not present. >>> >>> I gave `mtls_alternate_metadata` route a thought and don't >>> see how it helps, given the two above are non-issues (my >>> $.02) another discovery document only brings more of them >>> since every property can now be different, not just the >>> endpoints. >>> >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle >>> > wrote: >>> >>> Here is one example, based on my understanding of the >>> “straw man” format presented in this thread: RFC8414 >>> defines the value of >>> token_endpoint_auth_methods_supported as a “JSON array >>> containing a list of client authentication methods >>> supported by this token endpoint.” If that array >>> contains “tls_client_auth” and the endpoint specified in >>> token_endpoint does not support mTLS, then that metadata >>> violates 8414. You could address this by adding a >>> token_endpoint_auth_methods_supported parameter to the >>> mtls_endpoints object, and likewise for the other >>> endpoints and auth methods. If you take that to its >>> logical conclusion, you end up with a complete metadata >>> document hanging off of mtls_endpoints. It’s that line >>> of thought that led me to suggest just pointing to an >>> alternate document. >>> >>> Additionally, a metadata document that omits >>> token_endpoint in favor of mtls_endpoints since only >>> mTLS is supported would violate 8414, as 8414 says >>> token_endpoint “is REQUIRED unless only the implicit >>> grant type is supported.” >>> >>> It is possible to define the mtls_endpoints parameter >>> such that the above use cases are invalid, but that does >>> make the document more complicated.. If we go the >>> “mtls_alternate_metadata” route, we can skip past all of >>> these issues, because it brings us back to just parsing >>> the same metadata that we do today. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> *From:* OAuth >> > on behalf of Filip >>> Skokan > >>> *Date:* Tuesday, February 12, 2019 at 1:13 PM >>> *To:* "Richard Backman, Annabelle" >>> >> > >>> *Cc:* Brian Campbell >>> >> >, oauth >>> > >>> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery >>> >>> Hi Annabelle, >>> >>> can you elaborate what would be the violation / negative >>> impact of usage of RFC8414? >>> >>> As it already makes use of `signed_metadata` and this >>> language is present ... >>> >>> > Consumers of the metadata MAY ignore the signed metadata if they >>> do not support this feature.  If the consumer of the >>> metadata supports signed metadata, metadata values >>> conveyed in the signed metadata MUST take precedence >>> over the corresponding values conveyed using plain JSON >>> elements. >>> >>> ... would mtls_endpoints be any different? Clients are >>> free to ignore this if they don't support/use mtls, and >>> if they do those values must take precedence over the >>> root ones. the use of mtls_endpoints would not be >>> recommended for mtls-only AS but recommended for one >>> with both mtls/regular authentication methods. >>> token_endpoint remains required for all intents and >>> purposes. And as for the usable client authentication >>> methods - they should all be listed, or do you think we >>> should separate the ones for each hostname/port >>> location? To what end? Is there a risk having the mtls >>> hostname/port accepting regular requests? Other then >>> secret/key _jwt auth methods assertion aud claim the >>> endpoint location doesn't play a role in the >>> authentication process. >>> >>> >>> Best, >>> *Filip* >>> >>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle >>> >> > wrote: >>> >>> I’m not opposed to introducing a metadata change, if >>> the scenario is relevant and other approaches can’t >>> adequately address it – and I’ll readily grant that >>> we probably don’t want to depend on consistency of >>> browser behavior at the intersection of client >>> certificates and Access-Control-Allow-Credentials. >>> But care needs to be taken in designing that >>> metadata to avoid violating or otherwise negatively >>> impacting usage of RFC8414. >>> >>> Along those lines, instead of adding an >>> “mtls_endpoints” metadata parameter, we could add an >>> “mtls_alternate_metadata” parameter whose value is >>> the URL of an alternate metadata document intended >>> for clients using mTLS. An mTLS-optional AS could >>> have two different metadata documents for mTLS and >>> non-mTLS clients, reducing the mTLS-optional >>> scenario to the mTLS-only scenario. This sidesteps >>> the challenges of aligning the “either/or” semantics >>> of mTLS-optional with some of the rigid parameter >>> definitions in RFC8414 (see: token_endpoint, >>> token_endpoint_auth_methods_supported). >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> *From:* OAuth >> > on behalf of Brian >>> Campbell >>> >> > >>> *Date:* Tuesday, February 12, 2019 at 10:58 AM >>> *To:* Dominick Baier >> > >>> *Cc:* oauth > >>> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery >>> >>> Thanks for the input, Dominick. >>> >>> I'd said previously that I was having trouble >>> adequately gauging whether or not there's sufficient >>> consensus to go ahead with the update. I was even >>> thinking of asking the chairs about a consensus call >>> during the office hours meeting yesterday. But it >>> got canceled. And looking again back over the >>> discussion, I don't believe a consensus call is >>> necessary. There's been a lot of general discussion >>> over the last several weeks during which several >>> folks have stated support for the proposal while >>> there's been only one voice of direct dissent. That >>> seems like rough enough consensus and, as such, I >>> plan to make the change in the next revision of the >>> document (which should be done soon). Chairs, please >>> let me know, if you believe the situation warrants a >>> different course of action. >>> >>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier >>> >> > wrote: >>> >>> IMHO that’s a reasonable and pragmatic option. >>> >>> Thanks >>> >>> ——— >>> >>> Dominick >>> >>> On 11. February 2019 at 13:26:37, Brian Campbell >>> (bcampbell@pingidentity.com >>> ) wrote: >>> >>> It's been pointed out that the potential >>> issue is not isolated to the just token >>> endpoint but that revocation, introspection, >>> etc. could be impacted as well. So,  at this >>> point, the proposal on the table is to add a >>> new optional AS metadata parameter named >>> 'mtls_endpoints' that's value we be a JSON >>> object which itself contains endpoints that, >>> when present, a client doing MTLS would use >>> rather than the regular endpoints.  A >>> straw-man example might look like this >>> >>> { >>>   "issuer":"https://server.example.com", >>> "authorization_endpoint":"https://server.example.com/authz", >>> "token_endpoint":"https://server.example.com/token", >>> "token_endpoint_auth_methods_supported":[ >>>  "client_secret_basic","tls_client_auth", >>> "none"], >>> "userinfo_endpoint":"https://server.example.com/userinfo", >>> "revocation_endpoint":"https://server.example.com/revo", >>>   >>> "jwks_uri":"https://server.example.com/jwks.json", >>> *"mtls_endpoints":{ >>> "token_endpoint":"https://mtls.example.com/token", >>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>> "revocation_endpoint":"https://mtls.example.com/revo >>> " >>>   }* >>> } >>> >>> A client doing MTLS would look for and give >>> precedence to an endpoint under >>> "mtls_endpoints" while falling back to use >>> the normal endpoint from the top level of >>> metadata when/if its not in "mtls_endpoints". >>> >>> >>> The idea being that "regular" clients (those >>> not doing MTLS) will use the regular >>> endpoints. And only the host/port of the >>> endpoints listed in mtls_endpoints will be >>> set up to request TLS client certificates >>> during handshake. Thus any potential impact >>> of the CertificateRequest message being sent >>> in the TLS handshake can be avoided for all >>> the other regular clients that are not going >>> to do MTLS - including and most importantly >>> in-browser javascript clients where there >>> can be less than desirable UI presented to >>> the end-user. >>> >>> I'm struggling, however, to adequately gauge >>> whether or not there's sufficient consensus >>> to go ahead with the update. There's been >>> some support for it voiced. As well as talk >>> of other approaches that could be >>> alternatives or additional measures. And >>> also some vocal opposition to it. >>> >>> On Sat, Feb 9, 2019 at 3:09 AM Dominick >>> Baier >> > wrote: >>> >>> We are currently implementing MTLS in >>> IdentityServer. >>> >>> Our approach will be that we’ll offer a >>> separate token endpoint that supports >>> client certs. Are you planning on adding >>> an official endpoint name for discovery? >>> Right now we are using >>> “mtls_token_endpoint”. >>> >>> Thanks >>> >>> ——— >>> >>> Dominick >>> >>> On 7. February 2019 at 22:36:55, Brian >>> Campbell >>> (bcampbell=40pingidentity.com@dmarc.ietf.org >>> ) >>> wrote: >>> >>> Ah yes, that makes sense. Thanks for >>> clarifying. And it is indeed a good >>> reminder that even a seemingly >>> innocuous change that should be >>> backwards compatible can break >>> things unexpectedly.. >>> >>> On Thu, Feb 7, 2019 at 8:57 AM >>> Richard Backman, Annabelle >>> >> > wrote: >>> >>> The case I’m referencing didn’t >>> specifically involve AS >>> metadata. We had clients in the >>> wild that assumed that all the >>> properties in the JSON object >>> returned from our userinfo >>> endpoint were scalar strings. >>> This broke when we introduced a >>> new property whose value was a >>> JSON object. It was a good >>> reminder that even a seemingly >>> innocuous change that should be >>> backwards compatible can force >>> more work on clients than we expect. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> *From:* Brian Campbell >>> >> > >>> *Date:* Wednesday, February 6, >>> 2019 at 11:30 AM >>> *To:* "Richard Backman, >>> Annabelle" >>> >> > >>> *Cc:* "Richard Backman, >>> Annabelle" >> >, >>> oauth >> > >>> *Subject:* Re: [OAUTH-WG] >>> [UNVERIFIED SENDER] Re: MTLS and >>> in-browser clients using the >>> token endpoint >>> >>> And I'm honestly really >>> struggling to see what could >>> have gone wrong with or how >>> token_endpoint_auth_methods >>> broke something with the user >>> info endpoint. If you have the >>> time and/or it'd be informative >>> to this here little discussion, >>> please explain that one a bit more. >>> >>> On Wed, Feb 6, 2019 at 12:15 PM >>> Brian Campbell >>> >> > >>> wrote: >>> >>> "far" should have said >>> "fair" in the previous message >>> >>> On Tue, Feb 5, 2019 at 4:35 >>> PM Brian Campbell >>> >> > >>> wrote: >>> >>> It may well be due to my >>> own intellectual >>> shortcomings but these >>> issues/questions/confusion-points >>> are not resonating for >>> me as being problematic. >>> >>> The more general stance >>> of "this isn't needed or >>> worth it in this >>> document" (I think >>> that's far?) is being >>> heard though. >>> >>> On Tue, Feb 5, 2019 at >>> 1:42 PM Richard Backman, >>> Annabelle >>> >> > >>> wrote: >>> >>> (TL;DR: punt AS >>> metadata to a >>> separate draft) >>> >>> AS points #1-3 are >>> all questions I >>> would have as an >>> implementer: >>> >>> 1. Section 2 of >>> RFC8414 >>> >>> says >>> token_endpoint >>> “is REQUIRED >>> unless only the >>> implicit grant >>> type is >>> supported.” So >>> what does the >>> mTLS-only AS put >>> here? >>> 2. The claims for >>> these other >>> endpoints are >>> OPTIONAL, >>> potentially >>> leading to >>> inconsistency >>> depending on how >>> #1 gets decided. >>> 3. The example >>> usage of the >>> token_endpoint_auth_methods >>> property given >>> earlier is >>> incompatible >>> with RFC8414, >>> since some of >>> its contents are >>> only valid for >>> the non-mTLS >>> endpoints, and >>> others are only >>> valid for the >>> mTLS endpoints. >>> Hence this >>> question. >>> 4. This introduces >>> a new metadata >>> property that >>> could impact how >>> other specs >>> should extend AS >>> metadata. That >>> needs to be >>> addressed. >>> >>> I could go on for >>> client points but >>> you already get the >>> point. Though I’ll >>> share that #3 is >>> real and once forced >>> me to roll back an >>> update to the Login >>> with Amazon userinfo >>> endpoint…good times. 😃 >>> >>> I don’t necessarily >>> think an AS metadata >>> property is wrong >>> per se, but >>> understand that >>> you’re bolting a >>> layer of flexibility >>> onto a standard that >>> wasn’t designed for >>> that, and I don’t >>> think the metadata >>> proposal as it’s >>> been discussed here >>> sufficiently deals >>> with the fallout >>> from that. In my >>> view this is a >>> complex enough issue >>> and it’s for a >>> nuanced enough use >>> case (as far as I >>> can tell from >>> discussion? Please >>> correct me if I’m >>> wrong) that we >>> should punt it to a >>> separate draft >>> (e.g., >>> “Authorization >>> Server Metadata >>> Extensions for mTLS >>> Hybrids”) and get >>> mTLS out the door. >>> >>> -- >>> >>> Annabelle Richard >>> Backman >>> >>> AWS Identity >>> >>> *From:* OAuth >>> >> > >>> on behalf of Brian >>> Campbell >>> >> > >>> *Date:* Monday, >>> February 4, 2019 at >>> 5:28 AM >>> *To:* "Richard >>> Backman, Annabelle" >>> >> > >>> *Cc:* oauth >>> >> > >>> *Subject:* Re: >>> [OAUTH-WG] >>> [UNVERIFIED SENDER] >>> Re: MTLS and >>> in-browser clients >>> using the token endpoint >>> >>> Those points of >>> confusion strike me >>> as somewhat >>> hypothetical or >>> hyperbolic. But your >>> general point is >>> taken and your >>> position of being >>> anti additional >>> metadata on this >>> issue is noted. >>> >>> All of which leaves >>> me a bit uncertain >>> about how to >>> proceed. There seem >>> to be a range of >>> opinions on this >>> point and gauging >>> consensus is proving >>> elusive for me. >>> That's confounded by >>> my own opinion on it >>> being somewhat fluid. >>> >>> And I'd really like >>> to post an update to >>> this draft about a >>> month or two ago. >>> >>> On Fri, Feb 1, 2019 >>> at 5:03 PM Richard >>> Backman, Annabelle >>> >> > >>> wrote: >>> >>> Confusion from >>> the AS’s >>> perspective: >>> >>> 1. If I only >>> support >>> mTLS, do I >>> need to >>> include both >>> token_endpoint_uri >>> and >>> mtls_endpoints? >>> Should I >>> omit >>> token_endpoint_uri? >>> Or set it to >>> the empty >>> string? >>> 2. What if I >>> only support >>> mTLS for the >>> token >>> endpoint, >>> but not >>> revocation >>> or user info? >>> 3. How do I >>> specify >>> authentication >>> methods for >>> the mTLS >>> token >>> endpoint? >>> Does >>> token_endpoint_auth_methods >>> apply to >>> both the >>> mTLS and >>> non-mTLS >>> endpoints? >>> 4. I’m using >>> the OAuth >>> 2.0 Device >>> Flow. Do I >>> include a >>> mTLS-enabled >>> device_authorization_endpoint >>> under >>> mtls_endpoints? >>> >>> Confusion from >>> the client’s >>> perspective: >>> >>> 1. As far as I >>> know, I’m a >>> public >>> client, and >>> don’t know >>> anything >>> about mTLS, >>> but the IT >>> admins >>> installed >>> client certs >>> in their >>> users’ >>> browsers and >>> the AS >>> expects to >>> use that to >>> authenticate >>> me. >>> 2. My AS >>> metadata >>> parser >>> crashed >>> because the >>> mTLS-only AS >>> omitted >>> token_endpoint_uri. >>> >>> 3. My AS >>> metadata >>> parser >>> crashed >>> because it >>> didn’t >>> expect to >>> encounter a >>> JSON object >>> as a >>> parameter >>> value. >>> 4. The >>> mTLS-only AS >>> didn’t >>> provide a >>> value for >>> mtls_endpoints, >>> what do I do? >>> 5. I don’t know >>> what that >>> “m” means, >>> but they >>> told me to >>> use HTTPS, >>> so I should >>> use the one >>> with “tls” >>> in its name, >>> right? >>> >>> Yes, you can >>> write normative >>> text that >>> answers most of >>> these. But >>> you’ll have to >>> clearly cover a >>> lot of >>> similar-but-slightly-different >>> scenarios and be >>> very explicit. >>> And implementers >>> will still get >>> it wrong. The >>> metadata change >>> introduces >>> opportunities >>> for confusion >>> and failure that >>> do not exist >>> now, and forces >>> them on everyone >>> who supports >>> mTLS. In >>> contrast, the >>> 307 redirect is >>> only required >>> when an AS wants >>> to support both, >>> and is >>> unambiguous in >>> its behavior and >>> meaning. >>> >>> -- >>> >>> Annabelle >>> Richard Backman >>> >>> AWS Identity >>> >>> *From:* Brian >>> Campbell >>> >> > >>> *Date:* Friday, >>> February 1, 2019 >>> at 3:17 PM >>> *To:* "Richard >>> Backman, >>> Annabelle" >>> >> > >>> *Cc:* George >>> Fletcher >>> >> >, >>> oauth >>> >> > >>> *Subject:* >>> [UNVERIFIED >>> SENDER] Re: >>> [OAUTH-WG] MTLS >>> and in-browser >>> clients using >>> the token endpoint >>> >>> It doesn't seem >>> like that >>> confusing or >>> large of a >>> change to me - >>> if the client is >>> doing MTLS and >>> the given >>> endpoint is >>> present in >>> `mtls_endpoints`, >>> then it uses >>> that one. >>> Otherwise it >>> uses the regular >>> endpoint. It >>> gives an AS a >>> lot of >>> flexibility in >>> deployment >>> options. I >>> personally think >>> getting a 307 >>> approach >>> deployed and >>> working would be >>> more complicated >>> and error prone. >>> >>> It is a minority >>> use case at the >>> moment but there >>> are forces in >>> play, like the >>> push for >>> increased >>> security in >>> general and to >>> have javascript >>> clients use the >>> code flow, that >>> suggest it won't >>> be terribly >>> unusual to see >>> an AS that wants >>> to support MTLS >>> clients and >>> javascript/spa >>> clients at the >>> same time. >>> >>> I've personally >>> wavered back and >>> forth in this >>> thread on >>> whether or not >>> to add the new >>> metadata (or >>> something like >>> it). With my >>> reasoning each >>> way kinda >>> explained >>> somewhere back >>> in the 40 or so >>> messages that >>> make up this >>> thread. But it >>> seems like the >>> rough consensus >>> of the group >>> here is in favor >>> of it. >>> >>> On Fri, Feb 1, >>> 2019 at 3:18 PM >>> Richard Backman, >>> Annabelle >>> >> > >>> wrote: >>> >>> This strikes >>> me as a very >>> prominent >>> and >>> confusing >>> change to >>> support what >>> seems to be >>> a minority >>> use case. >>> I’m getting >>> a headache >>> just >>> thinking >>> about the >>> text needed >>> to clarify >>> when the AS >>> should >>> provide >>> `mtls_endpoints` >>> and when the >>> client >>> should use >>> that versus >>> using >>> `token_endpoint.` >>> Why is the >>> 307 status >>> code >>> insufficient >>> to cover the >>> case where a >>> single AS >>> supports >>> both mTLS >>> and non-mTLS? >>> >>> -- >>> >>> Annabelle >>> Richard Backman >>> >>> AWS Identity >>> >>> *From:* >>> OAuth >>> >> > >>> on behalf of >>> Brian >>> Campbell >>> >> > >>> *Date:* >>> Friday, >>> February 1, >>> 2019 at 1:31 PM >>> *To:* George >>> Fletcher >>> >> > >>> *Cc:* oauth >>> >> > >>> *Subject:* >>> Re: >>> [OAUTH-WG] >>> MTLS and >>> in-browser >>> clients >>> using the >>> token endpoint >>> >>> Yes, that >>> would work. >>> >>> On Fri, Feb >>> 1, 2019 at >>> 2:28 PM >>> George >>> Fletcher >>> >> > >>> wrote: >>> >>> What if >>> the AS >>> wants to >>> ONLY >>> support >>> MTLS >>> connections. >>> Does it >>> not >>> specify >>> the >>> optional >>> "mtls_endpoints" >>> and just >>> use the >>> normal >>> metadata >>> values? >>> >>> On >>> 1/15/19 >>> 8:48 AM, >>> Brian >>> Campbell >>> wrote: >>> >>> It >>> would >>> definitely >>> be >>> optional, >>> apologies >>> if >>> that >>> wasn't >>> made >>> clear.. >>> It'd >>> be >>> something >>> to >>> the >>> effect >>> of >>> optional >>> for >>> the >>> AS >>> to >>> include >>> and >>> clients >>> doing >>> MTLS >>> would >>> use >>> it >>> when >>> present >>> in >>> AS >>> metadata. >>> >>> On >>> Tue, >>> Jan >>> 15, >>> 2019 >>> at >>> 2:04 >>> AM >>> Dave >>> Tonge >>> >> > >>> wrote: >>> >>> I'm >>> in >>> favour >>> of >>> the >>> `mtls_endpoints` >>> metadata >>> parameter >>> - >>> although >>> it >>> should >>> be >>> optional. >>> >>> >>> /CONFIDENTIALITY >>> NOTICE: >>> This >>> email >>> may >>> contain >>> confidential >>> and >>> privileged >>> material >>> for >>> the >>> sole >>> use >>> of >>> the >>> intended >>> recipient(s). >>> Any >>> review, >>> use, >>> distribution >>> or >>> disclosure >>> by >>> others >>> is >>> strictly >>> prohibited.. >>> If >>> you >>> have >>> received >>> this >>> communication >>> in >>> error, >>> please >>> notify >>> the >>> sender >>> immediately >>> by >>> e-mail >>> and >>> delete >>> the >>> message >>> and >>> any >>> file >>> attachments >>> from >>> your >>> computer. >>> Thank >>> you./ >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> >>> */CONFIDENTIALITY >>> NOTICE: This >>> email may >>> contain >>> confidential >>> and >>> privileged >>> material for >>> the sole use >>> of the >>> intended >>> recipient(s). >>> Any review, >>> use, >>> distribution >>> or >>> disclosure >>> by others is >>> strictly >>> prohibited.. >>> If you have >>> received >>> this >>> communication >>> in error, >>> please >>> notify the >>> sender >>> immediately >>> by e-mail >>> and delete >>> the message >>> and any file >>> attachments >>> from your >>> computer. >>> Thank you./* >>> >>> >>> */CONFIDENTIALITY >>> NOTICE: This >>> email may >>> contain >>> confidential and >>> privileged >>> material for the >>> sole use of the >>> intended >>> recipient(s). >>> Any review, use, >>> distribution or >>> disclosure by >>> others is >>> strictly >>> prohibited.. If >>> you have >>> received this >>> communication in >>> error, please >>> notify the >>> sender >>> immediately by >>> e-mail and >>> delete the >>> message and any >>> file attachments >>> from your >>> computer. Thank >>> you./* >>> >>> >>> */CONFIDENTIALITY >>> NOTICE: This email >>> may contain >>> confidential and >>> privileged material >>> for the sole use of >>> the intended >>> recipient(s). Any >>> review, use, >>> distribution or >>> disclosure by others >>> is strictly >>> prohibited.. If you >>> have received this >>> communication in >>> error, please notify >>> the sender >>> immediately by >>> e-mail and delete >>> the message and any >>> file attachments >>> from your computer. >>> Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This >>> email may contain confidential >>> and privileged material for the >>> sole use of the intended >>> recipient(s). Any review, use, >>> distribution or disclosure by >>> others is strictly prohibited. >>> If you have received this >>> communication in error, please >>> notify the sender immediately by >>> e-mail and delete the message >>> and any file attachments from >>> your computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email >>> may contain confidential and >>> privileged material for the sole use >>> of the intended recipient(s). Any >>> review, use, distribution or >>> disclosure by others is strictly >>> prohibited.. If you have received >>> this communication in error, please >>> notify the sender immediately by >>> e-mail and delete the message and >>> any file attachments from your >>> computer. Thank you./* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> */CONFIDENTIALITY NOTICE: This email may >>> contain confidential and privileged material >>> for the sole use of the intended >>> recipient(s). Any review, use, distribution >>> or disclosure by others is strictly >>> prohibited. If you have received this >>> communication in error, please notify the >>> sender immediately by e-mail and delete the >>> message and any file attachments from your >>> computer. Thank you./* >>> >>> >>> */CONFIDENTIALITY NOTICE: This email may contain >>> confidential and privileged material for the sole >>> use of the intended recipient(s). Any review, use, >>> distribution or disclosure by others is strictly >>> prohibited.. If you have received this communication >>> in error, please notify the sender immediately by >>> e-mail and delete the message and any file >>> attachments from your computer. Thank you./* >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2E908DCE85889D96673D7657 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.  

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect. 

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this. 

This may be a sign we need more implementation data (including from tls wg) to make the right call. 

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers 
———
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn’t exist before.

 

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that’s just my experience as, you know, an actual developer.

 

Let’s keep the assumptions and snide remarks about others’ backgrounds off the list, please.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Dominick Baier <dbaier@leastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

 

I am for keeping it simple and not introducing another link to follow.

 

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

 

———

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

 

I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.


S pozdravem,
Filip Skokan

 

 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”

 

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the “mtls_alternate_metadata” route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Hi Annabelle,

 

can you elaborate what would be the violation / negative impact of usage of RFC8414?

 

As it already makes use of `signed_metadata` and this language is present ...

 

> Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.  If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

 

... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

 

 

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

I’m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can’t adequately address it – and I’ll readily grant that we probably don’t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

 

Along those lines, instead of adding an “mtls_endpoints” metadata parameter, we could add an “mtls_alternate_metadata” parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the “either/or” semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO that’s a reasonable and pragmatic option.

 

Thanks

———

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A straw-man example might look like this

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

 

Our approach will be that we’ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using “mtls_token_endpoint”.

 

Thanks

———

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I’m referencing didn’t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Though I’ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint…good times. 😃

 

I don’t necessarily think an AS metadata property is wrong per se, but understand that you’re bolting a layer of flexibility onto a standard that wasn’t designed for that, and I don’t think the metadata proposal as it’s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it’s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I’m wrong) that we should punt it to a separate draft (e.g., “Authorization Server Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS’s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

 

Confusion from the client’s perspective:

  1. As far as I know, I’m a public client, and don’t know anything about mTLS, but the IT admins installed client certs in their users’ browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
  5. I don’t know what that “m” means, but they told me to use HTTPS, so I should use the one with “tls” in its name, right?

 

Yes, you can write normative text that answers most of these. But you’ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I’m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=40aol.com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

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

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------2E908DCE85889D96673D7657-- From nobody Fri Feb 15 11:33:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD95130FE6 for ; Fri, 15 Feb 2019 11:33:07 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaIPFqvSortK for ; Fri, 15 Feb 2019 11:33:01 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C017130FC4 for ; Fri, 15 Feb 2019 11:33:01 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 32so18363574ota.12 for ; Fri, 15 Feb 2019 11:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HhV1H0tGDmYsSvKumqL+dPlz0Hkcj2R6XLtTFfHYtWI=; b=DkKAK7QlbS2kOxBuswesBTa8/GoUcRhsAYr46PzalmkKyNAmEDZY8VaB+SFct0Cyud Y4414p9v/8VcYFuzCPZ2f1MGscfcm5ljYUnb7sb47gZJpu+ezlwI/wATqsjRslc1pQ2k n8bWhabqfyXz5uaPyOxsur0fEJV6OQI5PGFvkg/JqCZ5SI00xWW7hLi1BHgySTfP2rv/ AhDX/ipmk1pg1KXNDnh70A21oI1obyPcK3KVTpN2m/IVzvNq+kg0qmEK5VI6/2UBKQuz 5jVoiYutrtpoMPqxYyfq8+AgmKV4rF8xHQ5TDNtTYetRkw7oMzyEE1xbK5xCy2LwzFfA pS7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HhV1H0tGDmYsSvKumqL+dPlz0Hkcj2R6XLtTFfHYtWI=; b=rADJbOyvioQFHQJsYB2R5LySBpv/kUPWwQo/wCKeLKKHLFFh58f8xb22iF4JYkWx5n 8jTD88qVwLyMmHAwFJgxsufPpZwHVYSW4sVZO6uowPGaXgpT+bvxRDFFbicacLuW547K cHUxgQ4w4UyNpFP9jMghPBRFi6Ne7pHfaKt+DgRNpvkQJNnO84dQc/LtaVMbfTd2Xah6 7ln/zx0e+W3J8ALLl8z4goH8Xj95d4FsYosWzbj5xVURi0EFWl4zAfT5OuzM8TOxxVuL i5wPFbxjVMQGWB+SpOvsc5USMdMHBjDJ0Or3IPcWVeytTcaRU4f0VKA8g/kz0tjkRfcL pgjA== X-Gm-Message-State: AHQUAubFUH0jft/Csv5+Pm1uamqRHDmJuzxSrNbiQFLDhn6DSHrucPts PkT/JJqVr0YbmHeh3AaAbz3OSbd7OKJIrJqcrA== X-Google-Smtp-Source: AHgI3IZo1a0I4jSv79AwUxN18KoMx1Bl+L8dufVnTsxZVu6pfz6DfoSJAcsvlb3d2PoIz9Z2TWoNW6q58G04+HGoD98= X-Received: by 2002:aca:a9d7:: with SMTP id s206mr6579617oie.178.1550259180482; Fri, 15 Feb 2019 11:33:00 -0800 (PST) MIME-Version: 1.0 References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <4027f7d3-bf02-b957-c169-b7842e5afe88@aol.com> In-Reply-To: <4027f7d3-bf02-b957-c169-b7842e5afe88@aol.com> From: Filip Skokan Date: Fri, 15 Feb 2019 20:32:48 +0100 Message-ID: To: George Fletcher Cc: Brian Campbell , Phil Hunt , oauth Content-Type: multipart/alternative; boundary="000000000000c336020581f3d730" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 19:33:08 -0000 --000000000000c336020581f3d730 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello George, What do you think about what i wrote earlier? clients not having mtls capabilities won't care about the additional method > members being present. Clients that do implement mtls by the specificatio= n > will know to look for mtls_endpoints and fall back to regular ones if the > specific endpoint or mtls_endpoints root property is not present. S pozdravem, *Filip Skokan* On Fri, 15 Feb 2019 at 20:29, George Fletcher wrote: > I still don't see how we solve one of the use cases Annabelle brought up. > > If the 'mtls_endpoints' object just contains endpoints, then in the main > meta-data section, should 'token_endpoint_auth_methods_supported' include > an indication of 'tls_client_auth' even though the endpoint specified by > 'token_endpoint' does NOT support MTLS? > > Thanks, > George > > On 2/14/19 6:08 PM, Brian Campbell wrote: > > Maybe I'm wrong here (it's never out of the question) but based on this > previous message > > and this one > > I believe that actually you are both in favor (generally anyway) of the > proposal with the optional "mtls_endpoints" parameter. While I believe th= at > the comment about optionality and complexity was meant to be a more gener= al > remark. While I can certainly appreciate a desire to keep things simple, > I do regret that this thread took a turn towards personal. Whether it was > the intent or not, there's an impact. > > > > On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wrote: > >> I feel I have to disagree. I agree that optionality is often complexity >> and should be avoided. But, I think the optionality here is an agility >> feature allowing mtls to work across a diversified market of different >> types of tls terminators with varying capability. Lack of appropriate >> discovery/options could serve to make the spec unusable in many cases. >> >> A complicating factor with tls is that a tls layer failure prevents the >> AS from issuing a correcting directive like an http error or http redire= ct. >> >> We have to be sure not to break existing clients so we may in some cases >> need mtls only endpoints. I am not far enough along to know for sure. Bu= t I >> tend to agree with Brian on this. >> >> This may be a sign we need more implementation data (including from tls >> wg) to make the right call. >> >> Phil >> >> On Feb 14, 2019, at 8:56 AM, Dominick Baier >> wrote: >> >> Sorry - this was not meant to be snide at all. >> >> It was honest feedback that you also need to keep software complexity in >> mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR >> that, or send values in arbitrary order adds to complexity. Complexity i= s >> the natural enemy of security. >> >> Cheers >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick >> >> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ( >> richanna@amazon.com) wrote: >> >> The issue is that the proposal violates the standard by changing the >> semantics of a parameter it defines. We should be very, very, VERY caref= ul >> about telling implementers to violate an existing standard... This chang= e >> might prove incompatible with existing or future implementations of 8414= , >> it might not, but by violating the standard the proposal creates an >> opportunity for incompatibility that didn=E2=80=99t exist before. >> >> >> >> As far as simplicity is concerned, I find a solution that reuses the >> existing data model and naturally supports existing and future extension= s >> to be far simpler than one that introduces ambiguous semantics to existi= ng >> parameters. Generally speaking, data models with properties that mean >> different things in different contexts tend to be fragile and require mo= re >> complex code to work with. But that=E2=80=99s just my experience as, you= know, an >> actual developer. >> >> >> >> Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80= =99 backgrounds >> off the list, please. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *Dominick Baier >> *Date: *Wednesday, February 13, 2019 at 4:18 AM >> *To: *"Richard Backman, Annabelle" , Filip Skokan < >> panva.ip@gmail.com > >> *Cc: *Brian Campbell , "Richard Backman, >> Annabelle" , oauth >> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & >> discovery >> >> >> >> I am for keeping it simple and not introducing another link to follow. >> >> >> >> I sometimes wonder how many of the spec authors are actually developers = - >> these suggestions make software unnecessary complex ;) >> >> >> >> =E2=80=94=E2=80=94=E2=80=94 >> >> Dominick >> >> >> >> On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) >> wrote: >> >> Hello, >> >> >> >> Additionally, a metadata document that omits token_endpoint in favor of >> mtls_endpoints since only mTLS is supported would violate 8414, as 8414 >> says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant = type is >> supported.=E2=80=9D >> >> >> mtls only AS doesn't get anything out of using mtls_endpoints, its use >> should not be recommended for such AS and regular endpoints will be used= , >> this satisfies the requirement >> >> Here is one example, based on my understanding of the =E2=80=9Cstraw man= =E2=80=9D format >> presented in this thread: RFC8414 defines the value of >> token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containin= g a list of >> client authentication methods supported by this token endpoint.=E2=80=9D= If that >> array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specif= ied in >> token_endpoint does not support mTLS, then that metadata violates 8414. = You >> could address this by adding a token_endpoint_auth_methods_supported >> parameter to the mtls_endpoints object, and likewise for the other >> endpoints and auth methods. If you take that to its logical conclusion, = you >> end up with a complete metadata document hanging off of mtls_endpoints. >> It=E2=80=99s that line of thought that led me to suggest just pointing t= o an >> alternate document. >> >> >> Assuming we go with using the same root auth methods property, what's th= e >> issue? Clients not having mtls capabilities won't care about the additio= nal >> method members being present. Clients that do implement mtls by the >> specification will know to look for mtls_endpoints and fall back to regu= lar >> ones if the specific endpoint or mtls_endpoints root property is not >> present. >> >> >> >> I gave `mtls_alternate_metadata` route a thought and don't see how it >> helps, given the two above are non-issues (my $.02) another discovery >> document only brings more of them since every property can now be >> different, not just the endpoints. >> >> >> S pozdravem, >> *Filip Skokan* >> >> >> >> >> >> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Here is one example, based on my understanding of the =E2=80=9Cstraw man= =E2=80=9D format >> presented in this thread: RFC8414 defines the value of >> token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containin= g a list of >> client authentication methods supported by this token endpoint.=E2=80=9D= If that >> array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specif= ied in >> token_endpoint does not support mTLS, then that metadata violates 8414. = You >> could address this by adding a token_endpoint_auth_methods_supported >> parameter to the mtls_endpoints object, and likewise for the other >> endpoints and auth methods. If you take that to its logical conclusion, = you >> end up with a complete metadata document hanging off of mtls_endpoints. >> It=E2=80=99s that line of thought that led me to suggest just pointing t= o an >> alternate document. >> >> >> >> Additionally, a metadata document that omits token_endpoint in favor of >> mtls_endpoints since only mTLS is supported would violate 8414, as 8414 >> says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant = type is >> supported.=E2=80=9D >> >> >> >> It is possible to define the mtls_endpoints parameter such that the abov= e >> use cases are invalid, but that does make the document more complicated.= . >> If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can ski= p past all of these >> issues, because it brings us back to just parsing the same metadata that= we >> do today. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Filip Skokan < >> panva.ip@gmail.com> >> *Date:* Tuesday, February 12, 2019 at 1:13 PM >> *To:* "Richard Backman, Annabelle" >> *Cc:* Brian Campbell , >> oauth > >> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery >> >> >> >> Hi Annabelle, >> >> >> >> can you elaborate what would be the violation / negative impact of usage >> of RFC8414? >> >> >> >> As it already makes use of `signed_metadata` and this language is presen= t >> ... >> >> >> >> > Consumers of the metadata MAY ignore the signed metadata if they do no= t >> support this feature. If the consumer of the metadata supports signed >> metadata, metadata values conveyed in the signed metadata MUST take >> precedence over the corresponding values conveyed using plain JSON eleme= nts. >> >> >> >> ... would mtls_endpoints be any different? Clients are free to ignore >> this if they don't support/use mtls, and if they do those values must ta= ke >> precedence over the root ones. the use of mtls_endpoints would not be >> recommended for mtls-only AS but recommended for one with both mtls/regu= lar >> authentication methods. token_endpoint remains required for all intents = and >> purposes. And as for the usable client authentication methods - they sho= uld >> all be listed, or do you think we should separate the ones for each >> hostname/port location? To what end? Is there a risk having the mtls >> hostname/port accepting regular requests? Other then secret/key _jwt aut= h >> methods assertion aud claim the endpoint location doesn't play a role in >> the authentication process. >> >> >> Best, >> *Filip* >> >> >> >> >> >> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote: >> >> I=E2=80=99m not opposed to introducing a metadata change, if the scenari= o is >> relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll >> readily grant that we probably don=E2=80=99t want to depend on consisten= cy of >> browser behavior at the intersection of client certificates and >> Access-Control-Allow-Credentials. But care needs to be taken in designin= g >> that metadata to avoid violating or otherwise negatively impacting usage= of >> RFC8414. >> >> >> >> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80=9D= metadata >> parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D par= ameter whose value >> is the URL of an alternate metadata document intended for clients using >> mTLS. An mTLS-optional AS could have two different metadata documents fo= r >> mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the >> mTLS-only scenario. This sidesteps the challenges of aligning the >> =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the = rigid parameter >> definitions in RFC8414 (see: token_endpoint, >> token_endpoint_auth_methods_supported). >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Tuesday, February 12, 2019 at 10:58 AM >> *To:* Dominick Baier >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery >> >> >> >> Thanks for the input, Dominick. >> >> >> >> I'd said previously that I was having trouble adequately gauging whether >> or not there's sufficient consensus to go ahead with the update. I was e= ven >> thinking of asking the chairs about a consensus call during the office >> hours meeting yesterday. But it got canceled. And looking again back ove= r >> the discussion, I don't believe a consensus call is necessary. There's b= een >> a lot of general discussion over the last several weeks during which >> several folks have stated support for the proposal while there's been on= ly >> one voice of direct dissent. That seems like rough enough consensus and,= as >> such, I plan to make the change in the next revision of the document (wh= ich >> should be done soon). Chairs, please let me know, if you believe the >> situation warrants a different course of action. >> >> >> >> >> >> >> >> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier < >> dbaier@leastprivilege.com> wrote: >> >> IMHO that=E2=80=99s a reasonable and pragmatic option. >> >> >> >> Thanks >> >> =E2=80=94=E2=80=94=E2=80=94 >> >> Dominick >> >> >> >> On 11. February 2019 at 13:26:37, Brian Campbell ( >> bcampbell@pingidentity.com) wrote: >> >> It's been pointed out that the potential issue is not isolated to the >> just token endpoint but that revocation, introspection, etc. could be >> impacted as well. So, at this point, the proposal on the table is to ad= d a >> new optional AS metadata parameter named 'mtls_endpoints' that's value w= e >> be a JSON object which itself contains endpoints that, when present, a >> client doing MTLS would use rather than the regular endpoints. A straw-= man >> example might look like this >> >> { >> "issuer":"https://server.example.com", >> "authorization_endpoint":"https://server.example.com/authz", >> "token_endpoint":"https://server.example.com/token", >> "token_endpoint_auth_methods_supported":[ >> "client_secret_basic","tls_client_auth", "none"], >> "userinfo_endpoint":"https://server.example.com/userinfo", >> "revocation_endpoint":"https://server.example.com/revo", >> "jwks_uri":"https://server.example.com/jwks.json", >> >> >> >> >> *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token >> ", >> "userinfo_endpoint":"https://mtls.example.com/userinfo >> ", >> "revocation_endpoint":"https://mtls.example.com/revo >> " }* >> } >> >> >> >> A client doing MTLS would look for and give precedence to an endpoint >> under "mtls_endpoints" while falling back to use the normal endpoint fro= m >> the top level of metadata when/if its not in "mtls_endpoints". >> >> >> The idea being that "regular" clients (those not doing MTLS) will use th= e >> regular endpoints. And only the host/port of the endpoints listed in >> mtls_endpoints will be set up to request TLS client certificates during >> handshake. Thus any potential impact of the CertificateRequest message >> being sent in the TLS handshake can be avoided for all the other regular >> clients that are not going to do MTLS - including and most importantly >> in-browser javascript clients where there can be less than desirable UI >> presented to the end-user. >> >> >> >> I'm struggling, however, to adequately gauge whether or not there's >> sufficient consensus to go ahead with the update. There's been some supp= ort >> for it voiced. As well as talk of other approaches that could be >> alternatives or additional measures. And also some vocal opposition to i= t. >> >> >> >> >> >> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier >> wrote: >> >> We are currently implementing MTLS in IdentityServer. >> >> >> >> Our approach will be that we=E2=80=99ll offer a separate token endpoint = that >> supports client certs. Are you planning on adding an official endpoint n= ame >> for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80= =9D. >> >> >> >> Thanks >> >> =E2=80=94=E2=80=94=E2=80=94 >> >> Dominick >> >> >> >> On 7. February 2019 at 22:36:55, Brian Campbell ( >> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: >> >> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can break things unexpectedly.. >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS = metadata. We had >> clients in the wild that assumed that all the properties in the JSON obj= ect >> returned from our userinfo endpoint were scalar strings. This broke when= we >> introduced a new property whose value was a JSON object. It was a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can force more work on clients than we expect. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell > > >> *Date:* Wednesday, February 6, 2019 at 11:30 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* "Richard Backman, Annabelle" , oauth < >> oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> And I'm honestly really struggling to see what could have gone wrong wit= h >> or how token_endpoint_auth_methods broke something with the user info >> endpoint. If you have the time and/or it'd be informative to this here >> little discussion, please explain that one a bit more. >> >> >> >> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> "far" should have said "fair" in the previous message >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell >> wrote: >> >> It may well be due to my own intellectual shortcomings but these >> issues/questions/confusion-points are not resonating for me as being >> problematic. >> >> >> >> The more general stance of "this isn't needed or worth it in this >> document" (I think that's far?) is being heard though. >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: >> >> (TL;DR: punt AS metadata to a separate draft) >> >> AS points #1-3 are all questions I would have as an implementer: >> >> 1. Section 2 of RFC8414 >> says token_endpoint >> =E2=80=9Cis REQUIRED unless only the implicit grant type is supported= .=E2=80=9D So what >> does the mTLS-only AS put here? >> 2. The claims for these other endpoints are OPTIONAL, potentially >> leading to inconsistency depending on how #1 gets decided. >> 3. The example usage of the token_endpoint_auth_methods property >> given earlier is incompatible with RFC8414, since some of its content= s are >> only valid for the non-mTLS endpoints, and others are only valid for = the >> mTLS endpoints. Hence this question. >> 4. This introduces a new metadata property that could impact how >> other specs should extend AS metadata. That needs to be addressed. >> >> >> >> I could go on for client points but you already get the point. Though >> I=E2=80=99ll share that #3 is real and once forced me to roll back an up= date to the >> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >> >> >> >> I don=E2=80=99t necessarily think an AS metadata property is wrong per s= e, but >> understand that you=E2=80=99re bolting a layer of flexibility onto a sta= ndard that >> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata= proposal as it=E2=80=99s >> been discussed here sufficiently deals with the fallout from that. In my >> view this is a complex enough issue and it=E2=80=99s for a nuanced enoug= h use case >> (as far as I can tell from discussion? Please correct me if I=E2=80=99m = wrong) that >> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serv= er Metadata >> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Monday, February 4, 2019 at 5:28 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> Those points of confusion strike me as somewhat hypothetical or >> hyperbolic. But your general point is taken and your position of being a= nti >> additional metadata on this issue is noted. >> >> >> >> All of which leaves me a bit uncertain about how to proceed. There seem >> to be a range of opinions on this point and gauging consensus is proving >> elusive for me. That's confounded by my own opinion on it being somewhat >> fluid. >> >> >> >> And I'd really like to post an update to this draft about a month or two >> ago. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: >> >> Confusion from the AS=E2=80=99s perspective: >> >> 1. If I only support mTLS, do I need to include both >> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_u= ri? Or >> set it to the empty string? >> 2. What if I only support mTLS for the token endpoint, but not >> revocation or user info? >> 3. How do I specify authentication methods for the mTLS token >> endpoint? Does token_endpoint_auth_methods apply to both the mTLS and >> non-mTLS endpoints? >> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-e= nabled >> device_authorization_endpoint under mtls_endpoints? >> >> >> >> Confusion from the client=E2=80=99s perspective: >> >> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t k= now anything >> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >> browsers and the AS expects to use that to authenticate me. >> 2. My AS metadata parser crashed because the mTLS-only AS omitted >> token_endpoint_uri. >> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >> encounter a JSON object as a parameter value. >> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints= , what >> do I do? >> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they= told me to use HTTPS, >> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right= ? >> >> >> >> Yes, you can write normative text that answers most of these. But you=E2= =80=99ll >> have to clearly cover a lot of similar-but-slightly-different scenarios = and >> be very explicit. And implementers will still get it wrong. The metadata >> change introduces opportunities for confusion and failure that do not ex= ist >> now, and forces them on everyone who supports mTLS. In contrast, the 307 >> redirect is only required when an AS wants to support both, and is >> unambiguous in its behavior and meaning. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Friday, February 1, 2019 at 3:17 PM >> *To:* "Richard Backman, Annabelle" >> *Cc:* George Fletcher , oauth >> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >> clients using the token endpoint >> >> >> >> It doesn't seem like that confusing or large of a change to me - if the >> client is doing MTLS and the given endpoint is present in `mtls_endpoint= s`, >> then it uses that one. Otherwise it uses the regular endpoint. It gives= an >> AS a lot of flexibility in deployment options. I personally think gettin= g a >> 307 approach deployed and working would be more complicated and error >> prone. >> >> >> >> It is a minority use case at the moment but there are forces in play, >> like the push for increased security in general and to have javascript >> clients use the code flow, that suggest it won't be terribly unusual to = see >> an AS that wants to support MTLS clients and javascript/spa clients at t= he >> same time. >> >> >> >> I've personally wavered back and forth in this thread on whether or not >> to add the new metadata (or something like it). With my reasoning each w= ay >> kinda explained somewhere back in the 40 or so messages that make up thi= s >> thread. But it seems like the rough consensus of the group here is in >> favor of it. >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: >> >> This strikes me as a very prominent and confusing change to support what >> seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about >> the text needed to clarify when the AS should provide `mtls_endpoints` a= nd >> when the client should use that versus using `token_endpoint.` Why is th= e >> 307 status code insufficient to cover the case where a single AS support= s >> both mTLS and non-mTLS? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Friday, February 1, 2019 at 1:31 PM >> *To:* George Fletcher > <40aol.com@dmarc............ietf.org>> >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >> endpoint >> >> >> >> Yes, that would work. >> >> >> >> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher > 40aol.com@dmarc.ietf..org <40aol.com@dmarc.ietf.org>> wrote: >> >> What if the AS wants to ONLY support MTLS connections. Does it not >> specify the optional "mtls_endpoints" and just use the normal metadata >> values? >> >> On 1/15/19 8:48 AM, Brian Campbell wrote: >> >> It would definitely be optional, apologies if that wasn't made clear.. >> It'd be something to the effect of optional for the AS to include and >> clients doing MTLS would use it when present in AS metadata. >> >> >> >> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >> wrote: >> >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000c336020581f3d730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello George,

What do you think about w= hat i wrote earlier?

clients not having mtls= capabilities won't care about the additional method members being pres= ent. Clients that do implement mtls by the specification will know to look = for mtls_endpoints and fall back to regular ones if the specific endpoint o= r mtls_endpoints root property is not present.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch= =3D40aol.com@dmarc.ietf.org= > wrote:
=20 =20 =20
I still don't see how w= e solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then = in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication= of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6= :08 PM, Brian Campbell wrote:
=20
Maybe I'm wrong here (it's never out of the ques= tion) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that = the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to disagree.=C2=A0 I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases. =C2=A0

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect.=C2=A0

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this.=C2=A0

This may be a sign we need more implementation data (including from tls wg) to make the right call.=C2=A0

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.c= om> wrote:

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers=C2=A0
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn=E2=80=99t exist before.

=C2=A0

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that=E2=80=99s just my experie= nce as, you know, an actual developer.

=C2=A0

Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80=99 backgrounds off the list, ple= ase.

=C2=A0

--=C2=A0<= /p>

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Dominick Baier <dbaier@leastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity= .com>, "Richard Backman, Annabelle" &l= t;richanna@amazon.= com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

I am for keeping it simple and not introducing another link to follow.

=C2=A0

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

=C2=A0

=E2=80=94=E2=80=94=E2= =80=94

Dominick

=C2=A0

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

=C2=A0

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80= =9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the =E2=80=9Cstraw= man=E2=80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_support= ed as a =E2=80=9CJSON array containing= a list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth= =E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_support= ed parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that l= ine of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what'= s the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

=C2=A0

I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.


S pozdravem,
Filip Skokan

=C2=A0

=C2=A0

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2=80=9D= format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods= _supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this token endpoint.=E2=80= =9D If that array contains =E2=80=9Ctls_client_auth=E2= =80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods= _supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99= s that line of thought that led me to suggest just pointing to an alternate document.

=C2=A0=

Additi= onally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

=C2=A0=

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the =E2=80=9Cmtls_alternate_met= adata=E2=80=9D route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

=C2=A0=

--= =C2=A0

An= nabelle Richard Backman<= /p>

AW= S Identity

=C2=A0=

=C2=A0=

<= span style=3D"font-size:12pt;color:black">From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richar= d Backman, Annabelle"= ; <richanna=3D40amazon.com@dmar= c.ietf.org>
Cc: Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

=C2= =A0

= Hi Annabelle,

= =C2=A0

= can you elaborate what would be the violation / negative impact of usage of RFC8414?

= =C2=A0

= As it already makes use of `signed_metadata` and this language is present ...

= =C2=A0

= >=C2=A0Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.=C2=A0 If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

= =C2=A0

= ... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.

Best,
Filip

= =C2=A0

=C2=A0=

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=3D40amazon.com@dmar= c.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can=E2=80=99t adequ= ately address it =E2=80= =93 and I=E2=80=99ll readil= y grant that we probably don=E2=80= =99t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtls_endpo= ints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alter= nate_metadata=E2=80=9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/or= =E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com= >
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery<= /p>

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been = a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivile= ge.com> wrote:

IMHO that=E2=80= =99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com<= /a>) wrote:

It's been pointed out that the poten= tial issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,=C2=A0 a= t this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoin= ts' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.=C2=A0 = A straw-man example might look like this

{
=C2=A0 "issu= er":"htt= ps://server.example.com",
=C2=A0 "authorizati= on_endpoint":"https://server.example.com/authz",
=C2=A0 "token_endpo= int":"https://server.example.com/token",
=C2=A0 "token_endpo= int_auth_methods_supported":[ =C2=A0"client_secret_basic","tls_client_auth", "no= ne"],
=C2=A0 "userinfo_en= dpoint":"https://server.example.com/userinfo",
=C2=A0 "revocation_= endpoint":"https://server.example.com/revo",
=C2=A0 "jwks= _uri":"https://server.example.com/jwks.json",
=C2=A0 "m= tls_endpoints":{
=C2=A0 =C2=A0 "token_endpo= int":"https://mtls.example.com/token",
=C2=A0 =C2=A0 "userinfo_en= dpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_= endpoint":"https://mtls.example.com/revo"
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoi= nts" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoi= nts".


The idea being that "regula= r" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whether or not there'= s sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivile= ge.com> wrote:

We are currently implementing MTLS in IdentityServer.

=C2=A0

Our approach wil= l be that we=E2=80=99ll off= er a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_tok= en_endpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbel= l=3D40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bcampbell@pingi= dentity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com= @dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_au= th_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

"far" should have said "fair&q= uot; in the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/= confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn= 9;t needed or worth it in this document&quo= t; (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.= com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUI= RED unless only the implicit grant type is supported.=E2=80= =9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_au= th_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99= ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6= good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99= re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t thi= nk the metadata proposal as it=E2=80=99s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2= =80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthoriz= ation Server Metadata Extensions for mTLS Hybrids=E2= =80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com= @dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.= com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80= =99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_ur= i and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorizat= ion_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a pub= lic client, and don=E2=80=99t kno= w anything about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_ur= i.
  3. My AS metadata parser crashed because it didn=E2=80=99t ex= pect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t pr= ovide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t kno= w what that =E2=80= =9Cm=E2=80=9D means, but they told me to use HTTPS, so I should use the one with =E2=80=9Ctls= =E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99l= l have to clearly cover a lot of similar-but-sligh= tly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2= =A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.= com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40ao= l.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc= .ietf..org> wrote:

Wh= at if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoi= nts" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.c= o.uk> wrote:

I'= ;m in favour of the `mtls_endpoints` metadata parameter - although it should be optional.<= /p>


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.= 

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.i=
etf..org/mailman/listinfo/oauth

=C2=A0


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFIDE= NTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=

__= _____________________________________________
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/oa= uth

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
= 
____________=
___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf=
.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c336020581f3d730-- From nobody Fri Feb 15 11:42:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDF5130FF9 for ; Fri, 15 Feb 2019 11:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX8U9M4yXF1N for ; Fri, 15 Feb 2019 11:42:37 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA68130FEE for ; Fri, 15 Feb 2019 11:42:36 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1FJgSkb011222; Fri, 15 Feb 2019 19:42:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=0flecUZpZbPTtPOYFmASxOoETl/8YAgX8rvmbLYod7A=; b=WutRtIrZiPf8QGbioG1+3XWJrd0jhM8yD9QkphkzYvDm5Rjcz0AFsrpiKbCF6nd6N7x5 Iw58DpuoD0bGiMBGQjv2ESNgi2DgOtb7FRPQhf4jxEgoKwgooFpxQXwcyaGvf9ml/DAY 6L4TI/WtrEjJ24imSujou5SP4JK2dIEGkajMCVi2BfJwwupSWEFpWUzWYvhrEvixYHg7 RhWUuE3dO+/lgUFMZNCAPnemhfXTABRXWuDS5o5HYjp+zqyTujNPDyWf8FJcf0FdVc2o NiGObaTYPw3akADIG9+dGNybpZ3ofAakw2yPA4TW5QmBNV1ZUPX+WgSYEnaopmOWPzDp xg== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2qhrekyqxj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 19:42:33 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1FJgQoJ029189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Feb 2019 19:42:27 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1FJgQ1x014250; Fri, 15 Feb 2019 19:42:26 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Feb 2019 19:42:23 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-139F8A48-917A-41BC-BD80-8D8C03BA76BB Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Fri, 15 Feb 2019 11:42:21 -0800 Cc: George Fletcher , Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <4027f7d3-bf02-b95! 7-c169-b7842e5afe88@aol.com> To: Filip Skokan X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9168 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902150131 Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 19:42:42 -0000 --Apple-Mail-139F8A48-917A-41BC-BD80-8D8C03BA76BB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is what I would expect.=20 Phil > On Feb 15, 2019, at 11:32 AM, Filip Skokan wrote: >=20 > Hello George, >=20 > What do you think about what i wrote earlier? >=20 >> clients not having mtls capabilities won't care about the additional meth= od members being present. Clients that do implement mtls by the specificatio= n will know to look for mtls_endpoints and fall back to regular ones if the s= pecific endpoint or mtls_endpoints root property is not present. >=20 > S pozdravem, > Filip Skokan >=20 >=20 >> On Fri, 15 Feb 2019 at 20:29, George Fletcher wrote: >> I still don't see how we solve one of the use cases Annabelle brought up.= >>=20 >> If the 'mtls_endpoints' object just contains endpoints, then in the main m= eta-data section, should 'token_endpoint_auth_methods_supported' include an i= ndication of 'tls_client_auth' even though the endpoint specified by 'token_= endpoint' does NOT support MTLS? >>=20 >> Thanks, >> George >>=20 >>> On 2/14/19 6:08 PM, Brian Campbell wrote: >>> Maybe I'm wrong here (it's never out of the question) but based on this p= revious message and this one I believe that actually you are both in favor (= generally anyway) of the proposal with the optional "mtls_endpoints" paramet= er. While I believe that the comment about optionality and complexity was me= ant to be a more general remark. While I can certainly appreciate a desire t= o keep things simple, I do regret that this thread took a turn towards perso= nal. Whether it was the intent or not, there's an impact.=20 >>>=20 >>>=20 >>>=20 >>>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wrote= : >>>> I feel I have to disagree. I agree that optionality is often complexit= y and should be avoided. But, I think the optionality here is an agility fea= ture allowing mtls to work across a diversified market of different types of= tls terminators with varying capability. Lack of appropriate discovery/opti= ons could serve to make the spec unusable in many cases. =20 >>>>=20 >>>> A complicating factor with tls is that a tls layer failure prevents the= AS from issuing a correcting directive like an http error or h= ttp redirect.=20 >>>>=20 >>>> We have to be sure not to break existing clients so we may in some case= s need mtls only endpoints. I am not far enough along to know for sure. But I= tend to agree with Brian on this.=20 >>>>=20 >>>> This may be a sign we need more implementation data (including from tls= wg) to make the right call.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier = wrote: >>>>=20 >>>>> Sorry - this was not meant to be snide at all. >>>>>=20 >>>>> It was honest feedback that you also need to keep software complexity i= n mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR th= at, or send values in arbitrary order adds to complexity. Complexity is the n= atural enemy of security. >>>>>=20 >>>>> Cheers=20 >>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>> Dominick >>>>>=20 >>>>>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richann= a@amazon.com) wrote: >>>>>>=20 >>>>>> The issue is that the proposal violates the standard by changing the s= emantics of a parameter it defines. We should be very, very, VERY careful ab= out telling implementers to violate an existing standard... This change migh= t prove incompatible with existing or future implementations of 8414, it mig= ht not, but by violating the standard the proposal creates an opportunity fo= r incompatibility that didn=E2=80=99t exist before. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> As far as simplicity is concerned, I find a solution that reuses the e= xisting data model and naturally supports existing and future extensions to b= e far simpler than one that introduces ambiguous semantics to existing param= eters. Generally speaking, data models with properties that mean different t= hings in different contexts tend to be fragile and require more complex code= to work with. But that=E2=80=99s just my experience as, you know, an actual= developer. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80= =99 backgrounds off the list, please. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: Dominick Baier >>>>>> Date: Wednesday, February 13, 2019 at 4:18 AM >>>>>> To: "Richard Backman, Annabelle" , Filip Skokan <= panva.ip@gmail.com> >>>>>> Cc: Brian Campbell , "Richard Backman, An= nabelle" , oauth >>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & disc= overy >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I am for keeping it simple and not introducing another link to follow= . >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I sometimes wonder how many of the spec authors are actually develope= rs - these suggestions make software unnecessary complex ;) >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>=20 >>>>>> Dominick >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) w= rote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Additionally, a metadata document that omits token_endpoint in favor o= f mtls_endpoints since only mTLS is supported would violate 8414, as 8414 sa= ys token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type i= s supported.=E2=80=9D >>>>>>=20 >>>>>>=20 >>>>>> mtls only AS doesn't get anything out of using mtls_endpoints, its us= e should not be recommended for such AS and regular endpoints will be used, t= his satisfies the requirement >>>>>>=20 >>>>>> Here is one example, based on my understanding of the =E2=80=9Cstraw m= an=E2=80=9D format presented in this thread: RFC8414 defines the value of = token_endpoint_auth_methods_supported a= s a =E2=80=9CJSON array containing a list of client authentication methods s= upported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctl= s_client_auth=E2=80=9D and the endpo= int specified in token_endpoint does not support mTLS, then that metadata vi= olates 8414. You could address this by adding a token_endpoint_auth_methods_= supported parameter to the mtls_endpoints object, and likewise for the other= endpoints and auth methods. If you take that to its logical conclusion, you= end up with a complete metadata document hanging off of mtls_endpoints. It=E2= =80=99s that line of thought that led me to suggest just pointing to an alte= rnate document. >>>>>>=20 >>>>>>=20 >>>>>> Assuming we go with using the same root auth methods property, what's= the issue? Clients not having mtls capabilities won't care about the additi= onal method members being present. Clients that do implement mtls by the spe= cification will know to look for mtls_endpoints and fall back to regular one= s if the specific endpoint or mtls_endpoints root property is not present. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I gave `mtls_alternate_metadata` route a thought and don't see how it= helps, given the two above are non-issues (my $.02) another discovery docum= ent only brings more of them since every property can now be different, not j= ust the endpoints. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> S pozdravem, >>>>>> Filip Skokan >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> Here is one example, based on my understanding of the =E2=80=9Cstraw m= an=E2=80=9D format presented in this thread: RFC8414 defines the value of = token_endpoint_auth_methods_su= pported as a =E2=80=9CJSON array = containing a list of client authentication methods supported by this to= ken endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2=80= =9D and the endpoint specifi= ed in token_endpoint does not support mTLS, then that metadata violates 8414= . You could address this by adding a token_endpoint_auth_methods_supported p= arameter to the mtls_endpoints object, and likewise for the other endpoints a= nd auth methods. If you take that to its logical conclusion, you end up with= a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s th= at line of thought that led me to suggest just pointing to an alternate docu= ment. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Additionally, a metadata document that omits token_endpoint in favor o= f mtls_endpoints since only mTLS is supported would violate 8414, as 8414 sa= ys token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type i= s supported.=E2=80=9D >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> It is possible to define the mtls_endpoints parameter such that the a= bove use cases are invalid, but that does make the document more complicated= .. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip= past all of these issues, because it brings us back to just parsing the sam= e metadata that we do today. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth = on behalf of Filip Skokan >>>>>> Date: Tuesday, February 12, 2019 at 1:13 PM >>>>>> To: "Richard Backman, Annabelle" >>>>>> Cc: Brian Campbell , o= auth >>>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Hi Annabelle, >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> can you elaborate what would be the violation / negative impact of us= age of RFC8414? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> As it already makes use of `signed_metadata` and this language is pre= sent ... >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> > Consumers of the metadata = MAY ignore the signed metadata if they do not support this feat= ure. If the consumer of the metadata supports signed metadata, metadata val= ues conveyed in the signed metadata MUST take precedence over the correspond= ing values conveyed using plain JSON elements. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> ... would mtls_endpoints be any different? Clients are free to ignore= this if they don't support/use mtls, and if they do those values must take p= recedence over the root ones. the use of mtls_endpoints would not be recomme= nded for mtls-only AS but recommended for one with both mtls/regular authent= ication methods. token_endpoint remains required for all intents and purpose= s. And as for the usable client authentication methods - they should all be l= isted, or do you think we should separate the ones for each hostname/port lo= cation? To what end? Is there a risk having the mtls hostname/port accepting= regular requests? Other then secret/key _jwt auth methods assertion aud cla= im the endpoint location doesn't play a role in the authentication process. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>> Filip >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> I=E2=80=99m not opposed to introducing a metadata change, if the scen= ario is relevant and other approaches can=E2=80=99t adequately = address it =E2=80=93 and I=E2=80=99= ll readily grant that we probably don=E2=80=99t want to depend on consistenc= y of browser behavior at the intersection of client certificates and Access-= Control-Allow-Credentials. But care needs to be taken in designing that meta= data to avoid violating or otherwise negatively impacting usage of RFC8414. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80= =9D metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80= =9D parameter whose value is the URL of an alternate metadata = document intended for clients usin= g mTLS. An mTLS-optional AS could have two different metadata documents for m= TLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-on= ly scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/o= r=E2=80=9D semantics of mTLS-optional with some of the rigid parameter defin= itions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supporte= d). >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth on behalf of Brian Campbell >>>>>> Date: Tuesday, February 12, 2019 at 10:58 AM >>>>>> To: Dominick Baier >>>>>> Cc: oauth >>>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Thanks for the input, Dominick. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I'd said previously that I was having trouble adequately gauging whet= her or not there's sufficient consensus to go ahead with the update. I was e= ven thinking of asking the chairs about a consensus call during the office h= ours meeting yesterday. But it got canceled. And looking again back over the= discussion, I don't believe a consensus call is necessary. There's been a l= ot of general discussion over the last several weeks during which several fo= lks have stated support for the proposal while there's been only one voice o= f direct dissent. That seems like rough enough consensus and, as such, I pla= n to make the change in the next revision of the document (which should be d= one soon). Chairs, please let me know, if you believe the situation warrants= a different course of action. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier wrote: >>>>>>=20 >>>>>> IMHO that=E2=80=99s a reasonable and pragmatic option. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>=20 >>>>>> Dominick >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingident= ity.com) wrote: >>>>>>=20 >>>>>> It's been pointed out that the potential issue is not isolated to the= just token endpoint but that revocation, introspection, etc. could be impac= ted as well. So, at this point, the proposal on the table is to add a new o= ptional AS metadata parameter named 'mtls_endpoints' that's value = we be a JSON object which it= self contains endpoints that, when present, a client doing MTLS would use ra= ther than the regular endpoints. A straw-man example might look like this >>>>>>=20 >>>>>> { >>>>>> "issuer":"https://server.example.com", >>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>> "token_endpoint":"https://server.example.com/token", >>>>>> "token_endpoint_auth_methods_supported":[ "client_secret_basic","t= ls_client_auth", "none"], >>>>>> "userinfo_endpoint":"https://server.example.com/userinfo", >>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>> "mtls_endpoints":{ >>>>>> "token_endpoint":"https://mtls.example.com/token", >>>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>>>> "revocation_endpoint":"https://mtls.example.com/revo" >>>>>> } >>>>>> } >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> A client doing MTLS would look for and give precedence to an endpoint= under "mtls_endpoints" while falling back to use the normal endpoint from t= he top level of metadata when/if its not in "mtls_endpoints". >>>>>>=20 >>>>>>=20 >>>>>> The idea being that "regular" clients (those not doing MTLS) will use= the regular endpoints. And only the host/port of the endpoints listed in mt= ls_endpoints will be set up to request TLS client certificates during handsh= ake. Thus any potential impact of the CertificateRequest message being sent i= n the TLS handshake can be avoided for all the other regular clients that ar= e not going to do MTLS - including and most importantly in-browser = javascript clients where th= ere can be less than desirable UI presented to the end-user. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I'm struggling, however, to adequately gauge whether or not there's s= ufficient consensus to go ahead with = the update. There's been some support for it voiced. As w= ell as talk of other approaches that could be alternatives or additional mea= sures. And also some vocal opposition to it.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: >>>>>>=20 >>>>>> We are currently implementing MTLS in IdentityServer. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Our approach will be that we=E2=80=99ll offer a separate token endpoi= nt that supports client certs. Are you planning on adding an official endpoi= nt name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2= =80=9D. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>=20 >>>>>> Dominick >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingid= entity.com@dmarc.ietf.org) wrote: >>>>>>=20 >>>>>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a g= ood reminder that even a seemingly innocuous change that should be backwards= compatible can break things unexpectedly.. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve A= S metadata. We had clients in the wild that assumed that all the properties i= n the JSON object returned from our userinfo endpoint were scalar strings. T= his broke when we introduced a new property whose value was a JSON object. I= t was a good reminder that even a seemingly innocuous change that should be b= ackwards compatible can = force more work on clients than we expect. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: Brian Campbell >>>>>> Date: Wednesday, February 6, 2019 at 11:30 AM >>>>>> To: "Richard Backman, Annabelle" >>>>>> Cc: "Richard Backman, Annabelle" , oauth >>>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> And I'm honestly really struggling to see what could have gone wrong w= ith or how token_endpoint_auth_methods broke something with the user info en= dpoint. If you have the time and/or it'd be informative to this here little d= iscussion, please explain that one a bit more. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell wrote: >>>>>>=20 >>>>>> "far" should have said "fair" in the previous message >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: >>>>>>=20 >>>>>> It may well be due to my own intellectual shortcomings but these issu= es/questions/confusion-points are not resonating for me as being problematic= . >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The more general stance of "this isn't needed or worth it in this doc= ument" (I think th= at's far?) is being heard though. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> (TL;DR: punt AS metadata to a separate draft) >>>>>>=20 >>>>>> AS points #1-3 are all questions I would have as an implementer: >>>>>>=20 >>>>>> Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless o= nly the implicit grant type is supported.=E2=80=9D So what does the mTLS-onl= y AS put here? >>>>>> The claims for these other endpoints are OPTIONAL, potentially leadin= g to inconsistency= depending on how #1 gets decided. >>>>>> The example usage of the token_endpoint_auth_methods property given e= arlier is incompatible with RFC8414, since some of its contents are only val= id for the non-mTLS endpoints, and others are only valid for the mTLS endpoi= nts. Hence this question. >>>>>> This introduces a new metadata property that could impact how other s= pecs should extend AS metadata. That needs to be addressed. >>>>>> =20 >>>>>>=20 >>>>>> I could go on for client points but you already get the point. Though= I=E2=80=99ll share that #3 is real and once forced me to roll back an updat= e to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83= >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I don=E2=80=99t necessarily think an AS metadata property is wrong pe= r se, but understand that you=E2=80=99re bolting a layer of flexibility onto= a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think= the metadata proposal as it=E2=80=99s been discussed here sufficiently deal= s with the fallout from that. In my view this is a complex enough issue and i= t=E2=80=99s for a nuanced enough use case (as far as I can tell from discuss= ion? Please correct me if I=E2=80=99m wrong) that we should punt it to a sep= arate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTL= S Hybrids=E2=80=9D) and get mTLS out the door. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth on behalf of Brian Campbell >>>>>> Date: Monday, February 4, 2019 at 5:28 AM >>>>>> To: "Richard Backman, Annabelle" = >>>>>> Cc: oauth >>>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser c= lients using the token endpoint >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Those points of confusion strike me as somewhat hypothetical or hyper= bolic. But your general point is taken and your position of being anti addit= ional metadata on this issue is = noted. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> All of which leaves me a bit uncertain about how to proceed. There se= em to be a range of opinions on this point and gauging consensus is proving e= lusive for me. That's confounded by my own opinion on it being somewhat flui= d. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> And I'd really like to post an update to this draft about a month or t= wo ago. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> Confusion from the AS=E2=80=99s = perspective: >>>>>>=20 >>>>>> If I only support mTLS, do I need to include both token_endpoint_uri a= nd mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty s= tring? >>>>>> What if I only support mTLS for the token endpoint, but not revocatio= n or user info? >>>>>> How do I specify authentication methods for the mTLS token endpoint? D= oes token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoint= s? >>>>>> I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enab= led device_authorization_endpoint under mtls_endpoints? >>>>>> =20 >>>>>>=20 >>>>>> Confusion from the client=E2=80=99s perspective: >>>>>>=20 >>>>>> As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know= anything about mTLS, but the = IT admins installed client certs in their users=E2=80=99 browser= s and the AS expec= ts to use that to authenticate me. >>>>>> My AS metadata parser crashed because the mTLS-only AS omitted token_= endpoint_uri. >>>>>> My AS metadata parser crashed because it didn=E2=80=99t expect to enc= ounter a JSON object as a parameter value. >>>>>> The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, w= hat do I do? >>>>>> I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but = they told me to use HTTPS= , so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? >>>>>> =20 >>>>>>=20 >>>>>> Yes, you can write normative text that answers most of these. But you= =E2=80=99ll have to clearly cover a lot of similar-but-slightly-different sc= enarios and be very explicit. And implementers will still get it wrong. The m= etadata change introduces opportunities = for confusion and failure = that do not exist now, and forces them on ever= yone who supports mTLS. In contrast, the 307 redirect is only required when a= n AS wants to support both, and is unambiguous in its behavior and meaning. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: Brian Campbell >>>>>> Date: Friday, February 1, 2019 at 3:17 PM >>>>>> To: "Richard Backman, Annabelle" >>>>>> Cc: George Fletcher , oauth >>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clien= ts using the token endpoint >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> It doesn't seem like that confusing or large of a change to me - if t= he client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, then it uses that one. Otherwise it uses the regular endpoint. It gives a= n AS a lot of flexibility in deployment options. I personally think getting a= 307 approach deployed and working would be more complicated and error prone= .=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> It is a minority use case at the moment but there are forces in play,= like the push for increased security in general and to have javascript clie= nts use the code flow, that suggest it won't be terribly unusual to see an A= S that wants to support MTLS clients and javascript/spa clients at the same t= ime. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I've personally wavered back and forth in this thread on whether or n= ot to add the new metadata (or something like it). With my reasoning each wa= y kinda explained somewhere back in the 40 or so messages that make up this t= hread. But it seems like the rough consensus of the group here is in favor o= f it. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> This strikes me as a very prominent and confusing change to support w= hat seems to be a minority use case. I=E2=80=99m getting a headache just thi= nking about the text needed to clarify when the AS should provide `mtls_endp= oints` and when the client should use that versus using `token_endpoint.` Wh= y is the 307 status code insufficient to cover the = case where a single AS supports both mTLS a= nd non-mTLS? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth on behalf of Brian Campbell >>>>>> Date: Friday, February 1, 2019 at 1:31 PM >>>>>> To: George Fletcher >>>>>> Cc: oauth >>>>>> Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token e= ndpoint >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Yes, that would work.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: >>>>>>=20 >>>>>> What if the AS wants to ONLY support MTLS connections. Does it not sp= ecify the optional= "mtls_endpoints" and just use the normal metadata values? >>>>>>=20 >>>>>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>>>>>=20 >>>>>> It would definitely be optional, apologies if that wasn't made clear.= . It'd be something to the effect of optional for the AS to include and clie= nts doing MTLS would use it when present in AS metadata. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge wrote: >>>>>>=20 >>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although i= t should be optional. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.. If you hav= e received this co= mmunication in error, please notify the sender immediately by e-mail and del= ete the message and any file attachments from your computer. Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for = the sole use of the intended recipient(s). Any review, use, distribution or= disclosure by others is strictly prohibited.. = If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message an= d any file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is = strictly prohibited.. If you have received this = communication in err= or, please notify the sender immediately by = e-mail and delete the message and any file attachm= ents from your com= puter. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.. If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure = by others is strictly prohibited.. If you have received this co= mmunication in error, please notify the sender immediately by e-mail and del= ete the message and any file attachments from your computer. Thank you. ____= ___________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately b= y e-mail and delet= e the message and any file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.. If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________=20 >>>>>> OAuth mailing list=20 >>>>>> OAuth@ietf.org=20 >>>>>> 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 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you.=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 --Apple-Mail-139F8A48-917A-41BC-BD80-8D8C03BA76BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is what I would expect. 

<= div id=3D"AppleMailSignature" dir=3D"ltr">Phil

On = Feb 15, 2019, at 11:32 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Hello George,

What d= o you think about what i wrote earlier?

clients= not having mtls capabilities won't care about the additional method members= being present. Clients that do implement mtls by the specification will kno= w to look for mtls_endpoints and fall back to regular ones if the specific e= ndpoint or mtls_endpoints root property is not present.
<= div>
S pozdravem,
Filip Skokan
=

On Fri, 15 Feb 2019 at 20:29, George Fletcher <gfflet= ch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:= 08 PM, Brian Campbell wrote:
=20
Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.  

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect. 

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this. 

This may be a sign we need more implementation data (including from tls wg) to make the right call. 

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com= > wrote:

= Sorry - this was not meant to be snide at all.
=
= It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.
=
= Cheers 
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn=E2=80=99t exist before.

 

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that=E2=80=99s just my experien= ce as, you know, an actual developer.

 

Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80=99 backgrounds off the list, plea= se.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Dominick Baier <dbaier@leastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.c= om>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

 

I am for keeping it simple and not introducing another link to follow.=

 

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

 

=E2=80=94=E2=80=94=E2=80= =94

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9C= is REQUIRED unless only the implicit grant type is supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the =E2=80=9Cstraw m= an=E2=80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supporte= d as a =E2=80=9CJSON array containing a= list of client authentication methods supported by this token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2= =80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supporte= d parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that li= ne of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

 

I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.


S pozdravem,
Filip Skokan

 

 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the =E2=80=9Cstraw man=E2=80=9D f= ormat presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_= supported as a =E2=80=9CJSON array containing a list of client authentication methods supported by this token endpoint.=E2=80=9D= If that array contains =E2=80=9Ctls_client_auth=E2=80= =9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_= supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s= that line of thought that led me to suggest just pointing to an alternate document.

 <= /p>

Additio= nally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D

 <= /p>

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the =E2=80=9Cmtls_alternate_meta= data=E2=80=9D route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

 <= /p>

--&n= bsp;

Anna= belle Richard Backman

AWS Identity

 <= /p>

 <= /p>

From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ie= tf.org>
Cc: Brian Campbell <bcampbell=3D40pingidentity.= com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 = ;

H= i Annabelle,

&= nbsp;

c= an you elaborate what would be the violation / negative impact of usage of RFC8414?

&= nbsp;

A= s it already makes use of `signed_metadata` and this language is present ...

&= nbsp;

&= gt; Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.  If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

&= nbsp;

.= .. would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.

Best,
Filip

&nb= sp;

 <= /p>

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ie= tf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can=E2=80=99t adequa= tely address it =E2=80=93= and I=E2=80=99ll readily= grant that we probably don=E2=80=99= t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

 

Along those lines, instead of adding an =E2=80=9Cmtls_endpoi= nts=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_altern= ate_metadata=E2=80=9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/or=E2= =80=9D semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org>= on behalf of Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.c= om> wrote:

IMHO that=E2=80=99= s a reasonable and pragmatic option.

=

 

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at= this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A= straw-man example might look like this

=

{
  "issuer":"<= a href=3D"https://server.example.com" target=3D"_blank">https://server.examp= le.com",
  "authorization_end= point":"https= ://server.example.com/authz",
  "token_endpoint":"= https://serve= r.example.com/token",
  "token_endpoint_au= th_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint= ":"https:/= /server.example.com/userinfo",
  "revocation_endpoi= nt":"https://s= erver.example.com/revo",
  "jwks_uri":= "https://= server.example.com/jwks.json",
  "mtls_en= dpoints":{
    "token_endpoint":"= https://mtls.ex= ample.com/token",
    "userinfo_endpoint= ":"https://m= tls.example.com/userinfo",
    "revocation_endpoi= nt":"https= ://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".<= /p>


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.c= om> wrote:

We are currently implementing MTLS in IdentityServer.

 

Our approach will b= e that we=E2=80=99ll offe= r a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_toke= n_endpoint=E2=80=9D.

 

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D= 40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

=

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com= > wrote:

The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingide= ntity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dm= arc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_aut= h_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingide= ntity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/c= onfusion-points are not resonating for me as being problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com= @dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIR= ED unless only the implicit grant type is supported.=E2=80=9D= So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_aut= h_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Though I=E2=80=99l= l share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6g= ood times. =F0=9F=98=83

 

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99r= e bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t thin= k the metadata proposal as it=E2=80=99s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80= =99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthoriza= tion Server Metadata Extensions for mTLS Hybrids=E2=80= =9D) and get mTLS out the door.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org>= on behalf of Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dm= arc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com= @dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99= s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri= and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorizati= on_endpoint under mtls_endpoints?

 

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a publ= ic client, and don=E2=80=99t know= anything about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri= .
  3. My AS metadata parser crashed because it didn=E2=80=99t exp= ect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t pro= vide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know= what that =E2=80=9C= m=E2=80=9D means, but they told me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2= =80=9D in its name, right?

 

Yes, you can write normative text that answers most of these. But you=E2=80=99ll= have to clearly cover a lot of similar-but-slight= ly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread. = But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com= @dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org>= on behalf of Brian Campbell <bcampbell=3D40pingi= dentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.c= om@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ie= tf..org> wrote:

What= if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

=

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.= uk> wrote:

I'm in f= avour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>

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

 


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i> _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFIDEN= TIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>

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

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

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
<= /fieldset> 
_____________=
__________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-139F8A48-917A-41BC-BD80-8D8C03BA76BB-- From nobody Fri Feb 15 11:57:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907B7131000 for ; Fri, 15 Feb 2019 11:57:35 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AKEWvR5JRkd for ; Fri, 15 Feb 2019 11:57:28 -0800 (PST) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B70130FAB for ; Fri, 15 Feb 2019 11:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550260646; bh=IT7Z5pGZOHoKP/0lZgh6Zea1AnJixMTzP63y2Ue+5gs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=l99s+UpBJ4viVWUSaUl2124aGVk17zTUH5J3ce/y9SJii2Y+TKm2ZPanp5rmniwGrVNMmZ3UItK/7cNEU/dzXWgFIgzguWOAVgH3xAVvh2XsMz0SB162R/VNNV+nxAJ1RscdMdO/eQ5A6aqXyWQqBrA6sX/Gsfo7KuAkFwMlYDY/KTXF2yo+xd+mq5C3CRv30ZWqCa+xcqulHAtl1M9UnsHt9SmJQGARFkvLhkFQEO9qwoLh+8X1Wm3LNFqfhaEP3qOWjExHT/ywxuryZIDhIn3tHkPtLZ9PxwsOjdlswy+ujI+W3qouJR3TS+yYQr86c+Ghoj9pECqGqr+oRXDY+Q== X-YMail-OSG: tnXvVEoVM1lB9BzDheaAcUQ_F3wacnyK88DTVY.KI7.xEhChOMi5JhPGFfb79ZO ezK2uJu6Dr5ikxPbDDz_B.dPwnB7tNrCFkM4lJFCtptX1K2L0R4sFWHR135UTuL7enx1j.ESpxeH Xhv8CtMWBGxkkHZz7XTpqBqxmdGlZ1RY58KCpoRgGSsXCkdQEJJkNZ5IR5ydsX0GOyxsizyHePkF 9OHdZ5e6QwE2ePyNJ.aNuAPiHzxGB1zun3MFs4S9cPINESUSErbg5WYtcCUwGd9LW5YcaUKYwoR6 okTEOouvdVgzXwM0J5h_Q96o1nHSic6eVnZquR3yvJzDL2bKIh0DFBuvUm3Ngjmnp3zDp2q_hCy7 t9wIJ5D4bTYkV0FRii8VMfe5_wD55wKBv93Y1NYrbPmffTW4iqg1POlGsjvurvyGl2GDpV8qq2ed ivb_twPnxQGEmFLbHKI8PBt88qn9mu0w7i2fAh8edBdx6WCoprlenBGtAjm4RBTfyce7sIWTEjCH O_mNc30aiqxCnprQ894jwcsL2Z6fjT97TRDODwy4x3urHRcw0593P14hlY5.Ilw3o04W8LhXIDc2 XLehfq3FI__mQc.7.EWJ6tLKckljUtZ23FZ8XnUpgA.EoSWh8INsQGL1wCz1yWUZMkAtI2rbmybi 5XHNg4bI5Dju7UhvtGjTHNerVyQzETPVEgm2CnHv1NL.E95vQwjo_u58HBQnFqG9JEPX9WbanFsv OtZVK3Zbp7pYQ6SMi1WCpzhSUVfzovO0Azr9idTEgxHlp71yx8dAO7_PQvXW9EpM.MKP4LsP_Ved hh0JoplkZ8kFc2xavwU0AIY2U3Ui61AwK_7ZEpeIIh.zIao2xVsvIJy0IMFWHptsJSs8Fvl0BKFx BiOpW2NuJie6YOqYeQqUpEaKkxtP6px9XNIGtOG1vBeip.Z7G5fI9dWcvBHFm6fqC7xSTLQDH9MX m5hwkMyAZCtmg.aVk0_LTZWvoLNypBvtaOnuDzqSw2_wm1mcQBiSUr8bFGvSdpa6IbXiSTz_0LqC 9rEG508aw0dbkMJTxbGqeGTiGxWkBcUKBwszpx7Tichkcplrh_wD0pORzWFsH Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 19:57:26 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 64f581dbb2870d7a0374952355e7e8c2; Fri, 15 Feb 2019 19:57:24 +0000 (UTC) To: Phil Hunt , Filip Skokan Cc: Brian Campbell , oauth References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <4027f7d3-bf02-b95! 7-c169-b7842e5afe88@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 15 Feb 2019 14:57:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3FC1F4AB26A45C6DFE887A0A" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 19:57:36 -0000 This is a multi-part message in MIME format. --------------3FC1F4AB26A45C6DFE887A0A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Just to make sure I understand... If the AS ONLY supports MTLS endpoints, then it...    * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'    * does NOT specify the mlts_endpoints section If the AS does NOT support MTLS endpoints, then it...     * does NOT specify a value of 'tls_client_auth' in the 'token_endpoint_auth_methods_supported'     * does NOT specify the mlts_endpoints section If the AS supports BOTH "regular" and MTLS endpoints, then it...     * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic tls_client_auth" (as an example)     * specifies mtls_endpoints in addition to the endpoints normally defined for the AS For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS. Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it assume that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object? It will work, though it still feels "hacky" and overly complex. Thanks, George On 2/15/19 2:42 PM, Phil Hunt wrote: > This is what I would expect. > > Phil > > On Feb 15, 2019, at 11:32 AM, Filip Skokan > wrote: > >> Hello George, >> >> What do you think about what i wrote earlier? >> >> clients not having mtls capabilities won't care about the >> additional method members being present. Clients that do >> implement mtls by the specification will know to look for >> mtls_endpoints and fall back to regular ones if the specific >> endpoint or mtls_endpoints root property is not present. >> >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Fri, 15 Feb 2019 at 20:29, George Fletcher >> > >> wrote: >> >> I still don't see how we solve one of the use cases Annabelle >> brought up. >> >> If the 'mtls_endpoints' object just contains endpoints, then in >> the main meta-data section, should >> 'token_endpoint_auth_methods_supported' include an indication of >> 'tls_client_auth' even though the endpoint specified by >> 'token_endpoint' does NOT support MTLS? >> >> Thanks, >> George >> >> On 2/14/19 6:08 PM, Brian Campbell wrote: >>> Maybe I'm wrong here (it's never out of the question) but based >>> on this previous message >>> >>> and this one >>> >>> I believe that actually you are both in favor (generally anyway) >>> of the proposal with the optional "mtls_endpoints" parameter. >>> While I believe that the comment about optionality and >>> complexity was meant to be a more general remark. While I can >>> certainly appreciate a desire to keep things simple, I do regret >>> that this thread took a turn towards personal. Whether it was >>> the intent or not, there's an impact. >>> >>> >>> >>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt >> > wrote: >>> >>> I feel I have to disagree.  I agree that optionality is >>> often complexity and should be avoided. But, I think the >>> optionality here is an agility feature allowing mtls to work >>> across a diversified market of different types of tls >>> terminators with varying capability. Lack of appropriate >>> discovery/options could serve to make the spec unusable in >>> many cases. >>> >>> A complicating factor with tls is that a tls layer failure >>> prevents the AS from issuing a correcting directive like an >>> http error or http redirect. >>> >>> We have to be sure not to break existing clients so we may >>> in some cases need mtls only endpoints. I am not far enough >>> along to know for sure. But I tend to agree with Brian on this. >>> >>> This may be a sign we need more implementation data >>> (including from tls wg) to make the right call. >>> >>> Phil >>> >>> On Feb 14, 2019, at 8:56 AM, Dominick Baier >>> >> > wrote: >>> >>>> Sorry - this was not meant to be snide at all. >>>> >>>> It was honest feedback that you also need to keep software >>>> complexity in mind when creating a spec. Every MAY or >>>> OPTIONAL, or do it like this OR that, or send values in >>>> arbitrary order adds to complexity. Complexity is the >>>> natural enemy of security. >>>> >>>> Cheers >>>> ——— >>>> Dominick >>>> >>>> On 13. February 2019 at 20:39:16, Richard Backman, >>>> Annabelle (richanna@amazon.com >>>> ) wrote: >>>> >>>>> The issue is that the proposal violates the standard by >>>>> changing the semantics of a parameter it defines. We >>>>> should be very, very, VERY careful about telling >>>>> implementers to violate an existing standard... This >>>>> change might prove incompatible with existing or future >>>>> implementations of 8414, it might not, but by violating >>>>> the standard the proposal creates an opportunity for >>>>> incompatibility that didn’t exist before. >>>>> >>>>> As far as simplicity is concerned, I find a solution that >>>>> reuses the existing data model and naturally supports >>>>> existing and future extensions to be far simpler than one >>>>> that introduces ambiguous semantics to existing >>>>> parameters. Generally speaking, data models with >>>>> properties that mean different things in different >>>>> contexts tend to be fragile and require more complex code >>>>> to work with. But that’s just my experience as, you know, >>>>> an actual developer. >>>>> >>>>> Let’s keep the assumptions and snide remarks about others’ >>>>> backgrounds off the list, please. >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> *From: *Dominick Baier >>>> > >>>>> *Date: *Wednesday, February 13, 2019 at 4:18 AM >>>>> *To: *"Richard Backman, Annabelle" >>>> >, Filip Skokan >>>>> > >>>>> *Cc: *Brian Campbell >>>> >, "Richard Backman, >>>>> Annabelle" >>>> >, oauth >>>> > >>>>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token >>>>> endoint & discovery >>>>> >>>>> I am for keeping it simple and not introducing another >>>>> link to follow. >>>>> >>>>> I sometimes wonder how many of the spec authors are >>>>> actually developers - these suggestions make software >>>>> unnecessary complex ;) >>>>> >>>>> ——— >>>>> >>>>> Dominick >>>>> >>>>> On 13. February 2019 at 12:25:13, Filip Skokan >>>>> (panva.ip@gmail.com ) wrote: >>>>> >>>>> Hello, >>>>> >>>>> Additionally, a metadata document that omits >>>>> token_endpoint in favor of mtls_endpoints since >>>>> only mTLS is supported would violate 8414, as 8414 >>>>> says token_endpoint “is REQUIRED unless only the >>>>> implicit grant type is supported.” >>>>> >>>>> >>>>> mtls only AS doesn't get anything out of using >>>>> mtls_endpoints, its use should not be recommended for >>>>> such AS and regular endpoints will be used, this >>>>> satisfies the requirement >>>>> >>>>> Here is one example, based on my understanding of >>>>> the “straw man” format presented in this thread: >>>>> RFC8414 defines the value of >>>>> token_endpoint_auth_methods_supported as a “JSON >>>>> array containing a list of client authentication >>>>> methods supported by this token endpoint.” If that >>>>> array contains “tls_client_auth” and the endpoint >>>>> specified in token_endpoint does not support mTLS, >>>>> then that metadata violates 8414. You could >>>>> address this by adding a >>>>> token_endpoint_auth_methods_supported parameter to >>>>> the mtls_endpoints object, and likewise for the >>>>> other endpoints and auth methods. If you take that >>>>> to its logical conclusion, you end up with a >>>>> complete metadata document hanging off of >>>>> mtls_endpoints. It’s that line of thought that led >>>>> me to suggest just pointing to an alternate document. >>>>> >>>>> >>>>> Assuming we go with using the same root auth methods >>>>> property, what's the issue? Clients not having mtls >>>>> capabilities won't care about the additional method >>>>> members being present. Clients that do implement mtls >>>>> by the specification will know to look for >>>>> mtls_endpoints and fall back to regular ones if the >>>>> specific endpoint or mtls_endpoints root property is >>>>> not present. >>>>> >>>>> I gave `mtls_alternate_metadata` route a thought and >>>>> don't see how it helps, given the two above are >>>>> non-issues (my $.02) another discovery document only >>>>> brings more of them since every property can now be >>>>> different, not just the endpoints. >>>>> >>>>> >>>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, >>>>> Annabelle >>>> > wrote: >>>>> >>>>> Here is one example, based on my understanding of >>>>> the “straw man” format presented in this thread: >>>>> RFC8414 defines the value of >>>>> token_endpoint_auth_methods_supported as a “JSON >>>>> array containing a list of client authentication >>>>> methods supported by this token endpoint.” If that >>>>> array contains “tls_client_auth” and the endpoint >>>>> specified in token_endpoint does not support mTLS, >>>>> then that metadata violates 8414. You could >>>>> address this by adding a >>>>> token_endpoint_auth_methods_supported parameter to >>>>> the mtls_endpoints object, and likewise for the >>>>> other endpoints and auth methods. If you take that >>>>> to its logical conclusion, you end up with a >>>>> complete metadata document hanging off of >>>>> mtls_endpoints. It’s that line of thought that led >>>>> me to suggest just pointing to an alternate document. >>>>> >>>>> Additionally, a metadata document that omits >>>>> token_endpoint in favor of mtls_endpoints since >>>>> only mTLS is supported would violate 8414, as 8414 >>>>> says token_endpoint “is REQUIRED unless only the >>>>> implicit grant type is supported.” >>>>> >>>>> It is possible to define the mtls_endpoints >>>>> parameter such that the above use cases are >>>>> invalid, but that does make the document more >>>>> complicated.. If we go the >>>>> “mtls_alternate_metadata” route, we can skip past >>>>> all of these issues, because it brings us back to >>>>> just parsing the same metadata that we do today. >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> *From:* OAuth >>>> > on behalf of >>>>> Filip Skokan >>>> > >>>>> *Date:* Tuesday, February 12, 2019 at 1:13 PM >>>>> *To:* "Richard Backman, Annabelle" >>>>> >>>> > >>>>> *Cc:* Brian Campbell >>>>> >>>> >, oauth >>>>> > >>>>> *Subject:* Re: [OAUTH-WG] MTLS token endoint & >>>>> discovery >>>>> >>>>> Hi Annabelle, >>>>> >>>>> can you elaborate what would be the violation / >>>>> negative impact of usage of RFC8414? >>>>> >>>>> As it already makes use of `signed_metadata` and >>>>> this language is present ... >>>>> >>>>> > Consumers of the metadata MAY ignore the signed metadata if >>>>> they do not support this feature.  If the consumer >>>>> of the metadata supports signed metadata, metadata >>>>> values conveyed in the signed metadata MUST take >>>>> precedence over the corresponding values conveyed >>>>> using plain JSON elements. >>>>> >>>>> .... would mtls_endpoints be any different? >>>>> Clients are free to ignore this if they don't >>>>> support/use mtls, and if they do those values must >>>>> take precedence over the root ones. the use of >>>>> mtls_endpoints would not be recommended for >>>>> mtls-only AS but recommended for one with both >>>>> mtls/regular authentication methods. >>>>> token_endpoint remains required for all intents >>>>> and purposes. And as for the usable client >>>>> authentication methods - they should all be >>>>> listed, or do you think we should separate the >>>>> ones for each hostname/port location? To what end? >>>>> Is there a risk having the mtls hostname/port >>>>> accepting regular requests? Other then secret/key >>>>> _jwt auth methods assertion aud claim the endpoint >>>>> location doesn't play a role in the authentication >>>>> process. >>>>> >>>>> >>>>> Best, >>>>> *Filip* >>>>> >>>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, >>>>> Annabelle >>>> > wrote: >>>>> >>>>> I’m not opposed to introducing a metadata >>>>> change, if the scenario is relevant and other >>>>> approaches can’t adequately address it – and >>>>> I’ll readily grant that we probably don’t want >>>>> to depend on consistency of browser behavior >>>>> at the intersection of client certificates and >>>>> Access-Control-Allow-Credentials. But care >>>>> needs to be taken in designing that metadata >>>>> to avoid violating or otherwise negatively >>>>> impacting usage of RFC8414. >>>>> >>>>> Along those lines, instead of adding an >>>>> “mtls_endpoints” metadata parameter, we could >>>>> add an “mtls_alternate_metadata” parameter >>>>> whose value is the URL of an alternate >>>>> metadata document intended for clients using >>>>> mTLS. An mTLS-optional AS could have two >>>>> different metadata documents for mTLS and >>>>> non-mTLS clients, reducing the mTLS-optional >>>>> scenario to the mTLS-only scenario. This >>>>> sidesteps the challenges of aligning the >>>>> “either/or” semantics of mTLS-optional with >>>>> some of the rigid parameter definitions in >>>>> RFC8414 (see: token_endpoint, >>>>> token_endpoint_auth_methods_supported). >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> *From:* OAuth >>>> > on behalf of >>>>> Brian Campbell >>>>> >>>> > >>>>> *Date:* Tuesday, February 12, 2019 at 10:58 AM >>>>> *To:* Dominick Baier >>>>> >>>> > >>>>> *Cc:* oauth >>>> > >>>>> *Subject:* Re: [OAUTH-WG] MTLS token endoint & >>>>> discovery >>>>> >>>>> Thanks for the input, Dominick. >>>>> >>>>> I'd said previously that I was having trouble >>>>> adequately gauging whether or not there's >>>>> sufficient consensus to go ahead with the >>>>> update. I was even thinking of asking the >>>>> chairs about a consensus call during the >>>>> office hours meeting yesterday. But it got >>>>> canceled. And looking again back over the >>>>> discussion, I don't believe a consensus call >>>>> is necessary. There's been a lot of general >>>>> discussion over the last several weeks during >>>>> which several folks have stated support for >>>>> the proposal while there's been only one voice >>>>> of direct dissent. That seems like rough >>>>> enough consensus and, as such, I plan to make >>>>> the change in the next revision of the >>>>> document (which should be done soon). Chairs, >>>>> please let me know, if you believe the >>>>> situation warrants a different course of action. >>>>> >>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick >>>>> Baier >>>> > wrote: >>>>> >>>>> IMHO that’s a reasonable and pragmatic option. >>>>> >>>>> Thanks >>>>> >>>>> ——— >>>>> >>>>> Dominick >>>>> >>>>> On 11. February 2019 at 13:26:37, Brian >>>>> Campbell (bcampbell@pingidentity.com >>>>> ) wrote: >>>>> >>>>> It's been pointed out that the >>>>> potential issue is not isolated to the >>>>> just token endpoint but that >>>>> revocation, introspection, etc. could >>>>> be impacted as well. So,  at this >>>>> point, the proposal on the table is to >>>>> add a new optional AS metadata >>>>> parameter named 'mtls_endpoints' >>>>> that's value we be a JSON object which >>>>> itself contains endpoints that, when >>>>> present, a client doing MTLS would use >>>>> rather than the regular endpoints.  A >>>>> straw-man example might look like this >>>>> >>>>> { >>>>>   >>>>> "issuer":"https://server.example.com", >>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>> "token_endpoint":"https://server.example.com/token", >>>>> "token_endpoint_auth_methods_supported":[ >>>>>  "client_secret_basic","tls_client_auth", >>>>> "none"], >>>>> "userinfo_endpoint":"https://server.example.com/userinfo", >>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>   >>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>> *"mtls_endpoints":{ >>>>> "token_endpoint":"https://mtls.example.com/token", >>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>>> "revocation_endpoint":"https://mtls.example.com/revo >>>>> " >>>>>   }* >>>>> } >>>>> >>>>> A client doing MTLS would look for and >>>>> give precedence to an endpoint under >>>>> "mtls_endpoints" while falling back to >>>>> use the normal endpoint from the top >>>>> level of metadata when/if its not in >>>>> "mtls_endpoints". >>>>> >>>>> >>>>> The idea being that "regular" clients >>>>> (those not doing MTLS) will use the >>>>> regular endpoints. And only the >>>>> host/port of the endpoints listed in >>>>> mtls_endpoints will be set up to >>>>> request TLS client certificates during >>>>> handshake. Thus any potential impact >>>>> of the CertificateRequest message >>>>> being sent in the TLS handshake can be >>>>> avoided for all the other regular >>>>> clients that are not going to do MTLS >>>>> - including and most importantly >>>>> in-browser javascript clients where >>>>> there can be less than desirable UI >>>>> presented to the end-user. >>>>> >>>>> I'm struggling, however, to adequately >>>>> gauge whether or not there's >>>>> sufficient consensus to go ahead with >>>>> the update. There's been some support >>>>> for it voiced. As well as talk of >>>>> other approaches that could be >>>>> alternatives or additional measures. >>>>> And also some vocal opposition to it. >>>>> >>>>> On Sat, Feb 9, 2019 at 3:09 AM >>>>> Dominick Baier >>>>> >>>> > wrote: >>>>> >>>>> We are currently implementing MTLS >>>>> in IdentityServer. >>>>> >>>>> Our approach will be that we’ll >>>>> offer a separate token endpoint >>>>> that supports client certs. Are >>>>> you planning on adding an official >>>>> endpoint name for discovery? Right >>>>> now we are using >>>>> “mtls_token_endpoint”. >>>>> >>>>> Thanks >>>>> >>>>> ——— >>>>> >>>>> Dominick >>>>> >>>>> On 7. February 2019 at 22:36:55, >>>>> Brian Campbell >>>>> (bcampbell=40pingidentity.com@dmarc.ietf.org >>>>> ) >>>>> wrote: >>>>> >>>>> Ah yes, that makes sense. >>>>> Thanks for clarifying. And it >>>>> is indeed a good reminder that >>>>> even a seemingly innocuous >>>>> change that should be >>>>> backwards compatible can break >>>>> things unexpectedly.. >>>>> >>>>> On Thu, Feb 7, 2019 at 8:57 AM >>>>> Richard Backman, Annabelle >>>>> >>>> > >>>>> wrote: >>>>> >>>>> The case I’m referencing >>>>> didn’t specifically >>>>> involve AS metadata. We >>>>> had clients in the wild >>>>> that assumed that all the >>>>> properties in the JSON >>>>> object returned from our >>>>> userinfo endpoint were >>>>> scalar strings. This broke >>>>> when we introduced a new >>>>> property whose value was a >>>>> JSON object. It was a good >>>>> reminder that even a >>>>> seemingly innocuous change >>>>> that should be backwards >>>>> compatible can force more >>>>> work on clients than we >>>>> expect. >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> *From:* Brian Campbell >>>>> >>>> > >>>>> *Date:* Wednesday, >>>>> February 6, 2019 at 11:30 AM >>>>> *To:* "Richard Backman, >>>>> Annabelle" >>>>> >>>> > >>>>> *Cc:* "Richard Backman, >>>>> Annabelle" >>>>> >>>> >, >>>>> oauth >>>> > >>>>> *Subject:* Re: [OAUTH-WG] >>>>> [UNVERIFIED SENDER] Re: >>>>> MTLS and in-browser >>>>> clients using the token >>>>> endpoint >>>>> >>>>> And I'm honestly really >>>>> struggling to see what >>>>> could have gone wrong with >>>>> or how >>>>> token_endpoint_auth_methods >>>>> broke something with the >>>>> user info endpoint. If you >>>>> have the time and/or it'd >>>>> be informative to this >>>>> here little discussion, >>>>> please explain that one a >>>>> bit more. >>>>> >>>>> On Wed, Feb 6, 2019 at >>>>> 12:15 PM Brian Campbell >>>>> >>>> > >>>>> wrote: >>>>> >>>>> "far" should have said >>>>> "fair" in the previous >>>>> message >>>>> >>>>> On Tue, Feb 5, 2019 at >>>>> 4:35 PM Brian Campbell >>>>> >>>> > >>>>> wrote: >>>>> >>>>> It may well be due >>>>> to my own >>>>> intellectual >>>>> shortcomings but >>>>> these >>>>> issues/questions/confusion-points >>>>> are not resonating >>>>> for me as being >>>>> problematic. >>>>> >>>>> The more general >>>>> stance of "this >>>>> isn't needed or >>>>> worth it in this >>>>> document" (I think >>>>> that's far?) is >>>>> being heard though. >>>>> >>>>> On Tue, Feb 5, >>>>> 2019 at 1:42 PM >>>>> Richard Backman, >>>>> Annabelle >>>>> >>>> > >>>>> wrote: >>>>> >>>>> (TL;DR: punt >>>>> AS metadata to >>>>> a separate draft) >>>>> >>>>> AS points #1-3 >>>>> are all >>>>> questions I >>>>> would have as >>>>> an implementer: >>>>> >>>>> 1. Section 2 >>>>> of RFC8414 >>>>> >>>>> says >>>>> token_endpoint >>>>> “is >>>>> REQUIRED >>>>> unless >>>>> only the >>>>> implicit >>>>> grant type >>>>> is >>>>> supported.” >>>>> So what >>>>> does the >>>>> mTLS-only >>>>> AS put here? >>>>> 2. The claims >>>>> for these >>>>> other >>>>> endpoints >>>>> are >>>>> OPTIONAL, >>>>> potentially >>>>> leading to >>>>> inconsistency >>>>> depending >>>>> on how #1 >>>>> gets decided. >>>>> 3. The >>>>> example >>>>> usage of >>>>> the >>>>> token_endpoint_auth_methods >>>>> property >>>>> given >>>>> earlier is >>>>> incompatible >>>>> with >>>>> RFC8414, >>>>> since some >>>>> of its >>>>> contents >>>>> are only >>>>> valid for >>>>> the >>>>> non-mTLS >>>>> endpoints, >>>>> and others >>>>> are only >>>>> valid for >>>>> the mTLS >>>>> endpoints. >>>>> Hence this >>>>> question. >>>>> 4. This >>>>> introduces >>>>> a new >>>>> metadata >>>>> property >>>>> that could >>>>> impact how >>>>> other >>>>> specs >>>>> should >>>>> extend AS >>>>> metadata. >>>>> That needs >>>>> to be >>>>> addressed. >>>>> >>>>> I could go on >>>>> for client >>>>> points but you >>>>> already get >>>>> the point. >>>>> Though I’ll >>>>> share that #3 >>>>> is real and >>>>> once forced me >>>>> to roll back >>>>> an update to >>>>> the Login with >>>>> Amazon >>>>> userinfo >>>>> endpoint…good >>>>> times. 😃 >>>>> >>>>> I don’t >>>>> necessarily >>>>> think an AS >>>>> metadata >>>>> property is >>>>> wrong per se, >>>>> but understand >>>>> that you’re >>>>> bolting a >>>>> layer of >>>>> flexibility >>>>> onto a >>>>> standard that >>>>> wasn’t >>>>> designed for >>>>> that, and I >>>>> don’t think >>>>> the metadata >>>>> proposal as >>>>> it’s been >>>>> discussed here >>>>> sufficiently >>>>> deals with the >>>>> fallout from >>>>> that. In my >>>>> view this is a >>>>> complex enough >>>>> issue and it’s >>>>> for a nuanced >>>>> enough use >>>>> case (as far >>>>> as I can tell >>>>> from >>>>> discussion? >>>>> Please correct >>>>> me if I’m >>>>> wrong) that we >>>>> should punt it >>>>> to a separate >>>>> draft (e.g., >>>>> “Authorization >>>>> Server >>>>> Metadata >>>>> Extensions for >>>>> mTLS Hybrids”) >>>>> and get mTLS >>>>> out the door. >>>>> >>>>> -- >>>>> >>>>> Annabelle >>>>> Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> *From:* OAuth >>>>> >>>> > >>>>> on behalf of >>>>> Brian Campbell >>>>> >>>> > >>>>> *Date:* >>>>> Monday, >>>>> February 4, >>>>> 2019 at 5:28 AM >>>>> *To:* "Richard >>>>> Backman, >>>>> Annabelle" >>>>> >>>> > >>>>> *Cc:* oauth >>>>> >>>> > >>>>> *Subject:* Re: >>>>> [OAUTH-WG] >>>>> [UNVERIFIED >>>>> SENDER] Re: >>>>> MTLS and >>>>> in-browser >>>>> clients using >>>>> the token endpoint >>>>> >>>>> Those points >>>>> of confusion >>>>> strike me as >>>>> somewhat >>>>> hypothetical >>>>> or hyperbolic. >>>>> But your >>>>> general point >>>>> is taken and >>>>> your position >>>>> of being anti >>>>> additional >>>>> metadata on >>>>> this issue is >>>>> noted. >>>>> >>>>> All of which >>>>> leaves me a >>>>> bit uncertain >>>>> about how to >>>>> proceed. There >>>>> seem to be a >>>>> range of >>>>> opinions on >>>>> this point and >>>>> gauging >>>>> consensus is >>>>> proving >>>>> elusive for >>>>> me. That's >>>>> confounded by >>>>> my own opinion >>>>> on it being >>>>> somewhat fluid. >>>>> >>>>> And I'd really >>>>> like to post >>>>> an update to >>>>> this draft >>>>> about a month >>>>> or two ago. >>>>> >>>>> On Fri, Feb 1, >>>>> 2019 at 5:03 >>>>> PM Richard >>>>> Backman, >>>>> Annabelle >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Confusion >>>>> from the >>>>> AS’s >>>>> perspective: >>>>> >>>>> 1. If I >>>>> only >>>>> support >>>>> mTLS, >>>>> do I >>>>> need >>>>> to >>>>> include >>>>> both >>>>> token_endpoint_uri >>>>> and >>>>> mtls_endpoints? >>>>> Should >>>>> I omit >>>>> token_endpoint_uri? >>>>> Or set >>>>> it to >>>>> the >>>>> empty >>>>> string? >>>>> 2. What >>>>> if I >>>>> only >>>>> support >>>>> mTLS >>>>> for >>>>> the >>>>> token >>>>> endpoint, >>>>> but >>>>> not >>>>> revocation >>>>> or >>>>> user >>>>> info? >>>>> 3. How do >>>>> I >>>>> specify >>>>> authentication >>>>> methods >>>>> for >>>>> the >>>>> mTLS >>>>> token >>>>> endpoint? >>>>> Does >>>>> token_endpoint_auth_methods >>>>> apply >>>>> to >>>>> both >>>>> the >>>>> mTLS >>>>> and >>>>> non-mTLS >>>>> endpoints? >>>>> >>>>> 4. I’m >>>>> using >>>>> the >>>>> OAuth >>>>> 2.0 >>>>> Device >>>>> Flow. >>>>> Do I >>>>> include >>>>> a >>>>> mTLS-enabled >>>>> device_authorization_endpoint >>>>> under >>>>> mtls_endpoints? >>>>> >>>>> >>>>> Confusion >>>>> from the >>>>> client’s >>>>> perspective: >>>>> >>>>> 1. As far >>>>> as I >>>>> know, >>>>> I’m a >>>>> public >>>>> client, >>>>> and >>>>> don’t >>>>> know >>>>> anything >>>>> about >>>>> mTLS, >>>>> but >>>>> the IT >>>>> admins >>>>> installed >>>>> client >>>>> certs >>>>> in >>>>> their >>>>> users’ >>>>> browsers >>>>> and >>>>> the AS >>>>> expects >>>>> to use >>>>> that >>>>> to >>>>> authenticate >>>>> me. >>>>> 2. My AS >>>>> metadata >>>>> parser >>>>> crashed >>>>> because >>>>> the >>>>> mTLS-only >>>>> AS >>>>> omitted >>>>> token_endpoint_uri.. >>>>> >>>>> 3. My AS >>>>> metadata >>>>> parser >>>>> crashed >>>>> because >>>>> it >>>>> didn’t >>>>> expect >>>>> to >>>>> encounter >>>>> a JSON >>>>> object >>>>> as a >>>>> parameter >>>>> value. >>>>> 4. The >>>>> mTLS-only >>>>> AS >>>>> didn’t >>>>> provide >>>>> a >>>>> value >>>>> for >>>>> mtls_endpoints, >>>>> what >>>>> do I do? >>>>> 5. I >>>>> don’t >>>>> know >>>>> what >>>>> that >>>>> “m” >>>>> means, >>>>> but >>>>> they >>>>> told >>>>> me to >>>>> use >>>>> HTTPS, >>>>> so I >>>>> should >>>>> use >>>>> the >>>>> one >>>>> with >>>>> “tls” >>>>> in its >>>>> name, >>>>> right? >>>>> >>>>> Yes, you >>>>> can write >>>>> normative >>>>> text that >>>>> answers >>>>> most of >>>>> these. But >>>>> you’ll >>>>> have to >>>>> clearly >>>>> cover a >>>>> lot of >>>>> similar-but-slightly-different >>>>> scenarios >>>>> and be >>>>> very >>>>> explicit. >>>>> And >>>>> implementers >>>>> will still >>>>> get it >>>>> wrong. The >>>>> metadata >>>>> change >>>>> introduces >>>>> opportunities >>>>> for >>>>> confusion >>>>> and >>>>> failure >>>>> that do >>>>> not exist >>>>> now, and >>>>> forces >>>>> them on >>>>> everyone >>>>> who >>>>> supports >>>>> mTLS. In >>>>> contrast, >>>>> the 307 >>>>> redirect >>>>> is only >>>>> required >>>>> when an AS >>>>> wants to >>>>> support >>>>> both, and >>>>> is >>>>> unambiguous >>>>> in its >>>>> behavior >>>>> and meaning. >>>>> >>>>> -- >>>>> >>>>> Annabelle >>>>> Richard >>>>> Backman >>>>> >>>>> AWS Identity >>>>> >>>>> *From:* >>>>> Brian >>>>> Campbell >>>>> >>>> > >>>>> *Date:* >>>>> Friday, >>>>> February >>>>> 1, 2019 at >>>>> 3:17 PM >>>>> *To:* >>>>> "Richard >>>>> Backman, >>>>> Annabelle" >>>>> >>>> > >>>>> *Cc:* >>>>> George >>>>> Fletcher >>>>> >>>> >, >>>>> oauth >>>>> >>>> > >>>>> *Subject:* >>>>> [UNVERIFIED >>>>> SENDER] >>>>> Re: >>>>> [OAUTH-WG] >>>>> MTLS and >>>>> in-browser >>>>> clients >>>>> using the >>>>> token endpoint >>>>> >>>>> It doesn't >>>>> seem like >>>>> that >>>>> confusing >>>>> or large >>>>> of a >>>>> change to >>>>> me - if >>>>> the client >>>>> is doing >>>>> MTLS and >>>>> the given >>>>> endpoint >>>>> is present >>>>> in >>>>> `mtls_endpoints`, >>>>> then it >>>>> uses that >>>>> one. >>>>> Otherwise >>>>> it uses >>>>> the >>>>> regular >>>>> endpoint. >>>>> It gives >>>>> an AS a >>>>> lot of >>>>> flexibility >>>>> in >>>>> deployment >>>>> options. I >>>>> personally >>>>> think >>>>> getting a >>>>> 307 >>>>> approach >>>>> deployed >>>>> and >>>>> working >>>>> would be >>>>> more >>>>> complicated >>>>> and error >>>>> prone. >>>>> >>>>> It is a >>>>> minority >>>>> use case >>>>> at the >>>>> moment but >>>>> there are >>>>> forces in >>>>> play, like >>>>> the push >>>>> for >>>>> increased >>>>> security >>>>> in general >>>>> and to >>>>> have >>>>> javascript >>>>> clients >>>>> use the >>>>> code flow, >>>>> that >>>>> suggest it >>>>> won't be >>>>> terribly >>>>> unusual to >>>>> see an AS >>>>> that wants >>>>> to support >>>>> MTLS >>>>> clients >>>>> and >>>>> javascript/spa >>>>> clients at >>>>> the same time. >>>>> >>>>> I've >>>>> personally >>>>> wavered >>>>> back and >>>>> forth in >>>>> this >>>>> thread on >>>>> whether or >>>>> not to add >>>>> the new >>>>> metadata >>>>> (or >>>>> something >>>>> like it). >>>>> With my >>>>> reasoning >>>>> each way >>>>> kinda >>>>> explained >>>>> somewhere >>>>> back in >>>>> the 40 or >>>>> so >>>>> messages >>>>> that make >>>>> up this >>>>> thread. >>>>> But it >>>>> seems like >>>>> the rough >>>>> consensus >>>>> of the >>>>> group here >>>>> is in >>>>> favor of it. >>>>> >>>>> On Fri, >>>>> Feb 1, >>>>> 2019 at >>>>> 3:18 PM >>>>> Richard >>>>> Backman, >>>>> Annabelle >>>>> >>>> > >>>>> wrote: >>>>> >>>>> This >>>>> strikes >>>>> me as >>>>> a very >>>>> prominent >>>>> and >>>>> confusing >>>>> change >>>>> to >>>>> support >>>>> what >>>>> seems >>>>> to be >>>>> a >>>>> minority >>>>> use >>>>> case. >>>>> I’m >>>>> getting >>>>> a >>>>> headache >>>>> just >>>>> thinking >>>>> about >>>>> the >>>>> text >>>>> needed >>>>> to >>>>> clarify >>>>> when >>>>> the AS >>>>> should >>>>> provide >>>>> `mtls_endpoints` >>>>> and >>>>> when >>>>> the >>>>> client >>>>> should >>>>> use >>>>> that >>>>> versus >>>>> using >>>>> `token_endpoint.` >>>>> Why is >>>>> the >>>>> 307 >>>>> status >>>>> code >>>>> insufficient >>>>> to >>>>> cover >>>>> the >>>>> case >>>>> where >>>>> a >>>>> single >>>>> AS >>>>> supports >>>>> both >>>>> mTLS >>>>> and >>>>> non-mTLS? >>>>> >>>>> -- >>>>> >>>>> Annabelle >>>>> Richard >>>>> Backman >>>>> >>>>> AWS >>>>> Identity >>>>> >>>>> *From:* >>>>> OAuth >>>>> >>>> > >>>>> on >>>>> behalf >>>>> of >>>>> Brian >>>>> Campbell >>>>> >>>> > >>>>> *Date:* >>>>> Friday, >>>>> February >>>>> 1, >>>>> 2019 >>>>> at 1:31 PM >>>>> *To:* >>>>> George >>>>> Fletcher >>>>> >>>> > >>>>> *Cc:* >>>>> oauth >>>>> >>>> > >>>>> *Subject:* >>>>> Re: >>>>> [OAUTH-WG] >>>>> MTLS >>>>> and >>>>> in-browser >>>>> clients >>>>> using >>>>> the >>>>> token >>>>> endpoint >>>>> >>>>> Yes, >>>>> that >>>>> would >>>>> work. >>>>> >>>>> On >>>>> Fri, >>>>> Feb 1, >>>>> 2019 >>>>> at >>>>> 2:28 >>>>> PM >>>>> George >>>>> Fletcher >>>>> >>>> > >>>>> wrote: >>>>> >>>>> What >>>>> if >>>>> the >>>>> AS >>>>> wants >>>>> to >>>>> ONLY >>>>> support >>>>> MTLS >>>>> connections. >>>>> Does >>>>> it >>>>> not >>>>> specify >>>>> the >>>>> optional >>>>> "mtls_endpoints" >>>>> and >>>>> just >>>>> use >>>>> the >>>>> normal >>>>> metadata >>>>> values? >>>>> >>>>> On >>>>> 1/15/19 >>>>> 8:48 >>>>> AM, >>>>> Brian >>>>> Campbell >>>>> wrote: >>>>> >>>>> It >>>>> would >>>>> definitely >>>>> be >>>>> optional, >>>>> apologies >>>>> if >>>>> that >>>>> wasn't >>>>> made >>>>> clear.. >>>>> It'd >>>>> be >>>>> something >>>>> to >>>>> the >>>>> effect >>>>> of >>>>> optional >>>>> for >>>>> the >>>>> AS >>>>> to >>>>> include >>>>> and >>>>> clients >>>>> doing >>>>> MTLS >>>>> would >>>>> use >>>>> it >>>>> when >>>>> present >>>>> in >>>>> AS >>>>> metadata. >>>>> >>>>> On >>>>> Tue, >>>>> Jan >>>>> 15, >>>>> 2019 >>>>> at >>>>> 2:04 >>>>> AM >>>>> Dave >>>>> Tonge >>>>> >>>> > >>>>> wrote: >>>>> >>>>> I'm >>>>> in >>>>> favour >>>>> of >>>>> the >>>>> `mtls_endpoints` >>>>> metadata >>>>> parameter >>>>> - >>>>> although >>>>> it >>>>> should >>>>> be >>>>> optional. >>>>> >>>>> >>>>> /CONFIDENTIALITY >>>>> NOTICE: >>>>> This >>>>> email >>>>> may >>>>> contain >>>>> confidential >>>>> and >>>>> privileged >>>>> material >>>>> for >>>>> the >>>>> sole >>>>> use >>>>> of >>>>> the >>>>> intended >>>>> recipient(s). >>>>> Any >>>>> review, >>>>> use, >>>>> distribution >>>>> or >>>>> disclosure >>>>> by >>>>> others >>>>> is >>>>> strictly >>>>> prohibited.. >>>>> If >>>>> you >>>>> have >>>>> received >>>>> this >>>>> communication >>>>> in >>>>> error, >>>>> please >>>>> notify >>>>> the >>>>> sender >>>>> immediately >>>>> by >>>>> e-mail >>>>> and >>>>> delete >>>>> the >>>>> message >>>>> and >>>>> any >>>>> file >>>>> attachments >>>>> from >>>>> your >>>>> computer. >>>>> Thank >>>>> you./ >>>>> >>>>> _______________________________________________ >>>>> >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> >>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>> >>>>> >>>>> */CONFIDENTIALITY >>>>> NOTICE: >>>>> This >>>>> email >>>>> may >>>>> contain >>>>> confidential >>>>> and >>>>> privileged >>>>> material >>>>> for >>>>> the >>>>> sole >>>>> use of >>>>> the >>>>> intended >>>>> recipient(s). >>>>> Any >>>>> review, >>>>> use, >>>>> distribution >>>>> or >>>>> disclosure >>>>> by >>>>> others >>>>> is >>>>> strictly >>>>> prohibited.. >>>>> If you >>>>> have >>>>> received >>>>> this >>>>> communication >>>>> in >>>>> error, >>>>> please >>>>> notify >>>>> the >>>>> sender >>>>> immediately >>>>> by >>>>> e-mail >>>>> and >>>>> delete >>>>> the >>>>> message >>>>> and >>>>> any >>>>> file >>>>> attachments >>>>> from >>>>> your >>>>> computer. >>>>> Thank >>>>> you./* >>>>> >>>>> >>>>> */CONFIDENTIALITY >>>>> NOTICE: >>>>> This email >>>>> may >>>>> contain >>>>> confidential >>>>> and >>>>> privileged >>>>> material >>>>> for the >>>>> sole use >>>>> of the >>>>> intended >>>>> recipient(s). >>>>> Any >>>>> review, >>>>> use, >>>>> distribution >>>>> or >>>>> disclosure >>>>> by others >>>>> is >>>>> strictly >>>>> prohibited.. >>>>> If you >>>>> have >>>>> received >>>>> this >>>>> communication >>>>> in error, >>>>> please >>>>> notify the >>>>> sender >>>>> immediately >>>>> by e-mail >>>>> and delete >>>>> the >>>>> message >>>>> and any >>>>> file >>>>> attachments >>>>> from your >>>>> computer. >>>>> Thank you./* >>>>> >>>>> >>>>> */CONFIDENTIALITY >>>>> NOTICE: This >>>>> email may >>>>> contain >>>>> confidential >>>>> and privileged >>>>> material for >>>>> the sole use >>>>> of the >>>>> intended >>>>> recipient(s). >>>>> Any review, >>>>> use, >>>>> distribution >>>>> or disclosure >>>>> by others is >>>>> strictly >>>>> prohibited.. >>>>> If you have >>>>> received this >>>>> communication >>>>> in error, >>>>> please notify >>>>> the sender >>>>> immediately by >>>>> e-mail and >>>>> delete the >>>>> message and >>>>> any file >>>>> attachments >>>>> from your >>>>> computer. >>>>> Thank you./* >>>>> >>>>> >>>>> */CONFIDENTIALITY NOTICE: >>>>> This email may contain >>>>> confidential and >>>>> privileged material for >>>>> the sole use of the >>>>> intended recipient(s). Any >>>>> review, use, distribution >>>>> or disclosure by others is >>>>> strictly prohibited. If >>>>> you have received this >>>>> communication in error, >>>>> please notify the sender >>>>> immediately by e-mail and >>>>> delete the message and any >>>>> file attachments from your >>>>> computer. Thank you./* >>>>> >>>>> >>>>> */CONFIDENTIALITY NOTICE: This >>>>> email may contain confidential >>>>> and privileged material for >>>>> the sole use of the intended >>>>> recipient(s). Any review, use, >>>>> distribution or disclosure by >>>>> others is strictly >>>>> prohibited.. If you have >>>>> received this communication in >>>>> error, please notify the >>>>> sender immediately by e-mail >>>>> and delete the message and any >>>>> file attachments from your >>>>> computer. Thank you./* >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> */CONFIDENTIALITY NOTICE: This email >>>>> may contain confidential and >>>>> privileged material for the sole use >>>>> of the intended recipient(s). Any >>>>> review, use, distribution or >>>>> disclosure by others is strictly >>>>> prohibited. If you have received this >>>>> communication in error, please notify >>>>> the sender immediately by e-mail and >>>>> delete the message and any file >>>>> attachments from your computer. Thank >>>>> you./* >>>>> >>>>> >>>>> */CONFIDENTIALITY NOTICE: This email may >>>>> contain confidential and privileged material >>>>> for the sole use of the intended recipient(s). >>>>> Any review, use, distribution or disclosure by >>>>> others is strictly prohibited.. If you have >>>>> received this communication in error, please >>>>> notify the sender immediately by e-mail and >>>>> delete the message and any file attachments >>>>> from your computer. Thank you./* >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> /CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended >>> recipient(s). Any review, use, distribution or disclosure by >>> others is strictly prohibited.. If you have received this >>> communication in error, please notify the sender immediately by >>> e-mail and delete the message and any file attachments from your >>> computer. Thank you./ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --------------3FC1F4AB26A45C6DFE887A0A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Just to make sure I understand...

If the AS ONLY supports MTLS endpoints, then it...
   * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'
   * does NOT specify the mlts_endpoints section

If the AS does NOT support MTLS endpoints, then it...
    * does NOT specify a value of 'tls_client_auth' in the 'token_endpoint_auth_methods_supported'
    * does NOT specify the mlts_endpoints section

If the AS supports BOTH "regular" and MTLS endpoints, then it...
    * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic tls_client_auth" (as an example)
    * specifies mtls_endpoints in addition to the endpoints normally defined for the AS

For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS.

Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it assume that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object?

It will work, though it still feels "hacky" and overly complex.

Thanks,
George

On 2/15/19 2:42 PM, Phil Hunt wrote:
This is what I would expect. 

Phil

On Feb 15, 2019, at 11:32 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Hello George,

What do you think about what i wrote earlier?

clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:
I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.  

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect. 

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this. 

This may be a sign we need more implementation data (including from tls wg) to make the right call. 

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers 
———
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn’t exist before.

 

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that’s just my experience as, you know, an actual developer.

 

Let’s keep the assumptions and snide remarks about others’ backgrounds off the list, please.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Dominick Baier <dbaier@leastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

 

I am for keeping it simple and not introducing another link to follow.

 

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

 

———

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

 

I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.


S pozdravem,
Filip Skokan

 

 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”

 

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the “mtls_alternate_metadata” route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Hi Annabelle,

 

can you elaborate what would be the violation / negative impact of usage of RFC8414?

 

As it already makes use of `signed_metadata` and this language is present ...

 

> Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.  If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

 

.... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

 

 

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

I’m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can’t adequately address it – and I’ll readily grant that we probably don’t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

 

Along those lines, instead of adding an “mtls_endpoints” metadata parameter, we could add an “mtls_alternate_metadata” parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the “either/or” semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO that’s a reasonable and pragmatic option.

 

Thanks

———

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A straw-man example might look like this

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

 

Our approach will be that we’ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using “mtls_token_endpoint”.

 

Thanks

———

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I’m referencing didn’t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Though I’ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint…good times. 😃

 

I don’t necessarily think an AS metadata property is wrong per se, but understand that you’re bolting a layer of flexibility onto a standard that wasn’t designed for that, and I don’t think the metadata proposal as it’s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it’s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I’m wrong) that we should punt it to a separate draft (e.g., “Authorization Server Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS’s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

 

Confusion from the client’s perspective:

  1. As far as I know, I’m a public client, and don’t know anything about mTLS, but the IT admins installed client certs in their users’ browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri..
  3. My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
  5. I don’t know what that “m” means, but they told me to use HTTPS, so I should use the one with “tls” in its name, right?

 

Yes, you can write normative text that answers most of these. But you’ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I’m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=40aol.com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

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

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

--------------3FC1F4AB26A45C6DFE887A0A-- From nobody Fri Feb 15 12:01:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8DE1310E6 for ; Fri, 15 Feb 2019 12:01:22 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6-7dfB85Oje for ; Fri, 15 Feb 2019 12:01:13 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B53131264 for ; Fri, 15 Feb 2019 12:01:06 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id b3so18576008otp.4 for ; Fri, 15 Feb 2019 12:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6dL1AJTyMWwjcs0fGioDFC0sK1xuZKLjFxDtc/YdgiA=; b=lbq5xgK5lbSULtghsBovIMV5B1XmhssF62DAMAjy7wVcUFRNQWqGtnMpqkgYVhoa0v XE7iWh7jCKYgZdCOy/B1Rs1fln3s5rgkISTQADJUDPVoYU3ecqGKW4w177KqyDWgDM/C dX58DvAWoXjHmbDga72xQhzrPKh2/DbHNhg4l+d79eOmuKg4Mz+bdPKM5eWP8J6qffh2 CZguYP9eFIISDh5ccUXEQfrsbawlBEUswejz/td2tx61dW9WAh6JTW1+Qpg27QZxn9qU nOMp8t7mvfX5srgjm/yc5kgOYLNuae4QmsgxVo1AkY5wTSJ9veo2qrwXkgE14hFVP8JL udyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6dL1AJTyMWwjcs0fGioDFC0sK1xuZKLjFxDtc/YdgiA=; b=RvkkDzjE+VRHkbE6UCZqZOTL7AFVlfcUNI0HzTWhe3/tXdEIyYYIHDbz5/nOEY/LwO LxKpilpUTeoRmUkRh/kM8eEyMoWMOERlatRQPFKtHt3fwF5hCmorbgM65KGg+998JW+y gpUS9spvDavftEgDlsMjAUBanzHkkrvQ/vtFwAxWGcdTY1TiHRkj+X6ra9dwHHLk9AU0 mosdvMykeEKvTvngWReTZr+8VFVu627skOKJWRaPgRb1D6/xQeAF03K6bH8ynCig8Iyi UYywcUzxrpqaCTd9X6IFdrmUuFCV63ADQWrB4O82LchzvQSeFwo16MtRAyXfTpA4wJqZ bTsw== X-Gm-Message-State: AHQUAubcVGA4TlY/n1WfanVIwEK8WRw5Sv3UFhMb3fmql9wnvRcqlcOn BX0w2S0gJeTt7RSLR5/jSXwaupzxPXN3d5vurg== X-Google-Smtp-Source: AHgI3IZl1ACZZ1i/YOmQyfCWKqpq0KyqJrv+Mo0EWq1Zt60BCnyxlTcQQLJMDpgEZMUZWBxs5bz4bv0fP4OCRWij0/Y= X-Received: by 2002:a9d:6195:: with SMTP id g21mr6635062otk.76.1550260865241; Fri, 15 Feb 2019 12:01:05 -0800 (PST) MIME-Version: 1.0 References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> In-Reply-To: From: Filip Skokan Date: Fri, 15 Feb 2019 21:00:52 +0100 Message-ID: To: George Fletcher Cc: Phil Hunt , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000002e977d0581f43c6f" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 20:01:28 -0000 --0000000000002e977d0581f43c6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd say the evaluation should be on a per-endpoint basis, so presence of a different endpoint in mtls_endpoint does not affect the client's decision on using mtls on a regular endpoint given the auth methods for it also include mtls. S pozdravem, *Filip Skokan* On Fri, 15 Feb 2019 at 20:57, George Fletcher wrote: > Just to make sure I understand... > > If the AS ONLY supports MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth' > * does NOT specify the mlts_endpoints section > > If the AS does NOT support MTLS endpoints, then it... > * does NOT specify a value of 'tls_client_auth' in the > 'token_endpoint_auth_methods_supported' > * does NOT specify the mlts_endpoints section > > If the AS supports BOTH "regular" and MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to "client_secret_basi= c > tls_client_auth" (as an example) > * specifies mtls_endpoints in addition to the endpoints normally > defined for the AS > > For the client, if it supports mtls AND if it finds 'tls_client_auth' in > the 'token_endpoint_auth_methods_supported' then it first looks to see if > an mtls_endpoints object is provided and if so uses those endpoints, > otherwise it assumes the RFC 8414 defined endpoints support MLTS. > > Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but > not an 'introspection_endpoint' but the RFC 8414 meta-data does specify a= n > 'introspection_endpoint', is the client supposed to assume the > introspection endpoint also supports MTLS even though it wasn't listed in > the 'mtls_endpoints' object? or should it assume that endpoint does NOT > support MTLS because it's not part of the 'mtls_endpoints' object? > > It will work, though it still feels "hacky" and overly complex. > > Thanks, > George > > On 2/15/19 2:42 PM, Phil Hunt wrote: > > This is what I would expect. > > Phil > > On Feb 15, 2019, at 11:32 AM, Filip Skokan > wrote: > > Hello George, > > What do you think about what i wrote earlier? > > clients not having mtls capabilities won't care about the additional >> method members being present. Clients that do implement mtls by the >> specification will know to look for mtls_endpoints and fall back to regu= lar >> ones if the specific endpoint or mtls_endpoints root property is not >> present. > > > S pozdravem, > *Filip Skokan* > > > On Fri, 15 Feb 2019 at 20:29, George Fletcher 40aol.com@dmarc.ietf.org> wrote: > >> I still don't see how we solve one of the use cases Annabelle brought up= . >> >> If the 'mtls_endpoints' object just contains endpoints, then in the main >> meta-data section, should 'token_endpoint_auth_methods_supported' includ= e >> an indication of 'tls_client_auth' even though the endpoint specified by >> 'token_endpoint' does NOT support MTLS? >> >> Thanks, >> George >> >> On 2/14/19 6:08 PM, Brian Campbell wrote: >> >> Maybe I'm wrong here (it's never out of the question) but based on this >> previous message >> >> and this one >> >> I believe that actually you are both in favor (generally anyway) of the >> proposal with the optional "mtls_endpoints" parameter. While I believe t= hat >> the comment about optionality and complexity was meant to be a more gene= ral >> remark. While I can certainly appreciate a desire to keep things simple, >> I do regret that this thread took a turn towards personal. Whether it wa= s >> the intent or not, there's an impact. >> >> >> >> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wrote: >> >>> I feel I have to disagree. I agree that optionality is often complexit= y >>> and should be avoided. But, I think the optionality here is an agility >>> feature allowing mtls to work across a diversified market of different >>> types of tls terminators with varying capability. Lack of appropriate >>> discovery/options could serve to make the spec unusable in many cases. >>> >>> A complicating factor with tls is that a tls layer failure prevents the >>> AS from issuing a correcting directive like an http error or http redir= ect. >>> >>> We have to be sure not to break existing clients so we may in some case= s >>> need mtls only endpoints. I am not far enough along to know for sure. B= ut I >>> tend to agree with Brian on this. >>> >>> This may be a sign we need more implementation data (including from tls >>> wg) to make the right call. >>> >>> Phil >>> >>> On Feb 14, 2019, at 8:56 AM, Dominick Baier >>> wrote: >>> >>> Sorry - this was not meant to be snide at all. >>> >>> It was honest feedback that you also need to keep software complexity i= n >>> mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR >>> that, or send values in arbitrary order adds to complexity. Complexity = is >>> the natural enemy of security. >>> >>> Cheers >>> =E2=80=94=E2=80=94=E2=80=94 >>> Dominick >>> >>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle ( >>> richanna@amazon.com) wrote: >>> >>> The issue is that the proposal violates the standard by changing the >>> semantics of a parameter it defines. We should be very, very, VERY care= ful >>> about telling implementers to violate an existing standard... This chan= ge >>> might prove incompatible with existing or future implementations of 841= 4, >>> it might not, but by violating the standard the proposal creates an >>> opportunity for incompatibility that didn=E2=80=99t exist before. >>> >>> >>> >>> As far as simplicity is concerned, I find a solution that reuses the >>> existing data model and naturally supports existing and future extensio= ns >>> to be far simpler than one that introduces ambiguous semantics to exist= ing >>> parameters. Generally speaking, data models with properties that mean >>> different things in different contexts tend to be fragile and require m= ore >>> complex code to work with. But that=E2=80=99s just my experience as, yo= u know, an >>> actual developer. >>> >>> >>> >>> Let=E2=80=99s keep the assumptions and snide remarks about others=E2=80= =99 backgrounds >>> off the list, please. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *Dominick Baier >>> *Date: *Wednesday, February 13, 2019 at 4:18 AM >>> *To: *"Richard Backman, Annabelle" , Filip Skokan = < >>> panva.ip@gmail.com > >>> *Cc: *Brian Campbell , "Richard Backman, >>> Annabelle" , oauth >>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & >>> discovery >>> >>> >>> >>> I am for keeping it simple and not introducing another link to follow. >>> >>> >>> >>> I sometimes wonder how many of the spec authors are actually developers >>> - these suggestions make software unnecessary complex ;) >>> >>> >>> >>> =E2=80=94=E2=80=94=E2=80=94 >>> >>> Dominick >>> >>> >>> >>> On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) >>> wrote: >>> >>> Hello, >>> >>> >>> >>> Additionally, a metadata document that omits token_endpoint in favor of >>> mtls_endpoints since only mTLS is supported would violate 8414, as 8414 >>> says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant= type is >>> supported.=E2=80=9D >>> >>> >>> mtls only AS doesn't get anything out of using mtls_endpoints, its use >>> should not be recommended for such AS and regular endpoints will be use= d, >>> this satisfies the requirement >>> >>> Here is one example, based on my understanding of the =E2=80=9Cstraw ma= n=E2=80=9D format >>> presented in this thread: RFC8414 defines the value of >>> token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containi= ng a list of >>> client authentication methods supported by this token endpoint.=E2=80= =9D If that >>> array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint speci= fied in >>> token_endpoint does not support mTLS, then that metadata violates 8414.= You >>> could address this by adding a token_endpoint_auth_methods_supported >>> parameter to the mtls_endpoints object, and likewise for the other >>> endpoints and auth methods. If you take that to its logical conclusion,= you >>> end up with a complete metadata document hanging off of mtls_endpoints. >>> It=E2=80=99s that line of thought that led me to suggest just pointing = to an >>> alternate document. >>> >>> >>> Assuming we go with using the same root auth methods property, what's >>> the issue? Clients not having mtls capabilities won't care about the >>> additional method members being present. Clients that do implement mtls= by >>> the specification will know to look for mtls_endpoints and fall back to >>> regular ones if the specific endpoint or mtls_endpoints root property i= s >>> not present. >>> >>> >>> >>> I gave `mtls_alternate_metadata` route a thought and don't see how it >>> helps, given the two above are non-issues (my $.02) another discovery >>> document only brings more of them since every property can now be >>> different, not just the endpoints. >>> >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> >>> >>> >>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>> Here is one example, based on my understanding of the =E2=80=9Cstraw ma= n=E2=80=9D format >>> presented in this thread: RFC8414 defines the value of >>> token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containi= ng a list of >>> client authentication methods supported by this token endpoint.=E2=80= =9D If that >>> array contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint speci= fied in >>> token_endpoint does not support mTLS, then that metadata violates 8414.= You >>> could address this by adding a token_endpoint_auth_methods_supported >>> parameter to the mtls_endpoints object, and likewise for the other >>> endpoints and auth methods. If you take that to its logical conclusion,= you >>> end up with a complete metadata document hanging off of mtls_endpoints. >>> It=E2=80=99s that line of thought that led me to suggest just pointing = to an >>> alternate document. >>> >>> >>> >>> Additionally, a metadata document that omits token_endpoint in favor of >>> mtls_endpoints since only mTLS is supported would violate 8414, as 8414 >>> says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant= type is >>> supported.=E2=80=9D >>> >>> >>> >>> It is possible to define the mtls_endpoints parameter such that the >>> above use cases are invalid, but that does make the document more >>> complicated.. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D ro= ute, we can skip >>> past all of these issues, because it brings us back to just parsing the >>> same metadata that we do today. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* OAuth on behalf of Filip Skokan < >>> panva.ip@gmail.com> >>> *Date:* Tuesday, February 12, 2019 at 1:13 PM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* Brian Campbell , >>> oauth > >>> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery >>> >>> >>> >>> Hi Annabelle, >>> >>> >>> >>> can you elaborate what would be the violation / negative impact of usag= e >>> of RFC8414? >>> >>> >>> >>> As it already makes use of `signed_metadata` and this language is >>> present ... >>> >>> >>> >>> > Consumers of the metadata MAY ignore the signed metadata if they do >>> not support this feature. If the consumer of the metadata supports sig= ned >>> metadata, metadata values conveyed in the signed metadata MUST take >>> precedence over the corresponding values conveyed using plain JSON elem= ents. >>> >>> >>> >>> .... would mtls_endpoints be any different? Clients are free to ignore >>> this if they don't support/use mtls, and if they do those values must t= ake >>> precedence over the root ones. the use of mtls_endpoints would not be >>> recommended for mtls-only AS but recommended for one with both mtls/reg= ular >>> authentication methods. token_endpoint remains required for all intents= and >>> purposes. And as for the usable client authentication methods - they sh= ould >>> all be listed, or do you think we should separate the ones for each >>> hostname/port location? To what end? Is there a risk having the mtls >>> hostname/port accepting regular requests? Other then secret/key _jwt au= th >>> methods assertion aud claim the endpoint location doesn't play a role i= n >>> the authentication process. >>> >>> >>> Best, >>> *Filip* >>> >>> >>> >>> >>> >>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org> wrote: >>> >>> I=E2=80=99m not opposed to introducing a metadata change, if the scenar= io is >>> relevant and other approaches can=E2=80=99t adequately address it =E2= =80=93 and I=E2=80=99ll >>> readily grant that we probably don=E2=80=99t want to depend on consiste= ncy of >>> browser behavior at the intersection of client certificates and >>> Access-Control-Allow-Credentials. But care needs to be taken in designi= ng >>> that metadata to avoid violating or otherwise negatively impacting usag= e of >>> RFC8414. >>> >>> >>> >>> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80= =9D metadata >>> parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80=9D pa= rameter whose value >>> is the URL of an alternate metadata document intended for clients using >>> mTLS. An mTLS-optional AS could have two different metadata documents f= or >>> mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the >>> mTLS-only scenario. This sidesteps the challenges of aligning the >>> =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the= rigid parameter >>> definitions in RFC8414 (see: token_endpoint, >>> token_endpoint_auth_methods_supported). >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Tuesday, February 12, 2019 at 10:58 AM >>> *To:* Dominick Baier >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery >>> >>> >>> >>> Thanks for the input, Dominick. >>> >>> >>> >>> I'd said previously that I was having trouble adequately gauging whethe= r >>> or not there's sufficient consensus to go ahead with the update. I was = even >>> thinking of asking the chairs about a consensus call during the office >>> hours meeting yesterday. But it got canceled. And looking again back ov= er >>> the discussion, I don't believe a consensus call is necessary. There's = been >>> a lot of general discussion over the last several weeks during which >>> several folks have stated support for the proposal while there's been o= nly >>> one voice of direct dissent. That seems like rough enough consensus and= , as >>> such, I plan to make the change in the next revision of the document (w= hich >>> should be done soon). Chairs, please let me know, if you believe the >>> situation warrants a different course of action. >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>> IMHO that=E2=80=99s a reasonable and pragmatic option. >>> >>> >>> >>> Thanks >>> >>> =E2=80=94=E2=80=94=E2=80=94 >>> >>> Dominick >>> >>> >>> >>> On 11. February 2019 at 13:26:37, Brian Campbell ( >>> bcampbell@pingidentity.com) wrote: >>> >>> It's been pointed out that the potential issue is not isolated to the >>> just token endpoint but that revocation, introspection, etc. could be >>> impacted as well. So, at this point, the proposal on the table is to a= dd a >>> new optional AS metadata parameter named 'mtls_endpoints' that's value = we >>> be a JSON object which itself contains endpoints that, when present, a >>> client doing MTLS would use rather than the regular endpoints. A straw= -man >>> example might look like this >>> >>> { >>> "issuer":"https://server.example.com", >>> "authorization_endpoint":"https://server.example.com/authz", >>> "token_endpoint":"https://server.example.com/token", >>> "token_endpoint_auth_methods_supported":[ >>> "client_secret_basic","tls_client_auth", "none"], >>> "userinfo_endpoint":"https://server.example.com/userinfo", >>> "revocation_endpoint":"https://server.example.com/revo", >>> "jwks_uri":"https://server.example.com/jwks.json", >>> >>> >>> >>> >>> *"mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/toke= n >>> ", >>> "userinfo_endpoint":"https://mtls.example.com/userinfo >>> ", >>> "revocation_endpoint":"https://mtls.example.com/revo >>> " }* >>> } >>> >>> >>> >>> A client doing MTLS would look for and give precedence to an endpoint >>> under "mtls_endpoints" while falling back to use the normal endpoint fr= om >>> the top level of metadata when/if its not in "mtls_endpoints". >>> >>> >>> The idea being that "regular" clients (those not doing MTLS) will use >>> the regular endpoints. And only the host/port of the endpoints listed i= n >>> mtls_endpoints will be set up to request TLS client certificates during >>> handshake. Thus any potential impact of the CertificateRequest message >>> being sent in the TLS handshake can be avoided for all the other regula= r >>> clients that are not going to do MTLS - including and most importantly >>> in-browser javascript clients where there can be less than desirable UI >>> presented to the end-user. >>> >>> >>> >>> I'm struggling, however, to adequately gauge whether or not there's >>> sufficient consensus to go ahead with the update. There's been some sup= port >>> for it voiced. As well as talk of other approaches that could be >>> alternatives or additional measures. And also some vocal opposition to = it. >>> >>> >>> >>> >>> >>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier >>> wrote: >>> >>> We are currently implementing MTLS in IdentityServer. >>> >>> >>> >>> Our approach will be that we=E2=80=99ll offer a separate token endpoint= that >>> supports client certs. Are you planning on adding an official endpoint = name >>> for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2= =80=9D. >>> >>> >>> >>> Thanks >>> >>> =E2=80=94=E2=80=94=E2=80=94 >>> >>> Dominick >>> >>> >>> >>> On 7. February 2019 at 22:36:55, Brian Campbell ( >>> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: >>> >>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a goo= d >>> reminder that even a seemingly innocuous change that should be backward= s >>> compatible can break things unexpectedly.. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>> The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS= metadata. We had >>> clients in the wild that assumed that all the properties in the JSON ob= ject >>> returned from our userinfo endpoint were scalar strings. This broke whe= n we >>> introduced a new property whose value was a JSON object. It was a good >>> reminder that even a seemingly innocuous change that should be backward= s >>> compatible can force more work on clients than we expect. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* Brian Campbell >> > >>> *Date:* Wednesday, February 6, 2019 at 11:30 AM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* "Richard Backman, Annabelle" , oauth < >>> oauth@ietf.org> >>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> And I'm honestly really struggling to see what could have gone wrong >>> with or how token_endpoint_auth_methods broke something with the user i= nfo >>> endpoint. If you have the time and/or it'd be informative to this here >>> little discussion, please explain that one a bit more. >>> >>> >>> >>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> "far" should have said "fair" in the previous message >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> It may well be due to my own intellectual shortcomings but these >>> issues/questions/confusion-points are not resonating for me as being >>> problematic. >>> >>> >>> >>> The more general stance of "this isn't needed or worth it in this >>> document" (I think that's far?) is being heard though. >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: >>> >>> (TL;DR: punt AS metadata to a separate draft) >>> >>> AS points #1-3 are all questions I would have as an implementer: >>> >>> 1. Section 2 of RFC8414 >>> >>> says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gr= ant type is >>> supported.=E2=80=9D So what does the mTLS-only AS put here? >>> 2. The claims for these other endpoints are OPTIONAL, potentially >>> leading to inconsistency depending on how #1 gets decided. >>> 3. The example usage of the token_endpoint_auth_methods property >>> given earlier is incompatible with RFC8414, since some of its conten= ts are >>> only valid for the non-mTLS endpoints, and others are only valid for= the >>> mTLS endpoints. Hence this question. >>> 4. This introduces a new metadata property that could impact how >>> other specs should extend AS metadata. That needs to be addressed. >>> >>> >>> >>> I could go on for client points but you already get the point. Though >>> I=E2=80=99ll share that #3 is real and once forced me to roll back an u= pdate to the >>> Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>> >>> >>> >>> I don=E2=80=99t necessarily think an AS metadata property is wrong per = se, but >>> understand that you=E2=80=99re bolting a layer of flexibility onto a st= andard that >>> wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadat= a proposal as it=E2=80=99s >>> been discussed here sufficiently deals with the fallout from that. In m= y >>> view this is a complex enough issue and it=E2=80=99s for a nuanced enou= gh use case >>> (as far as I can tell from discussion? Please correct me if I=E2=80=99m= wrong) that >>> we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Ser= ver Metadata >>> Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Monday, February 4, 2019 at 5:28 AM >>> *To:* "Richard Backman, Annabelle" >> > >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> Those points of confusion strike me as somewhat hypothetical or >>> hyperbolic. But your general point is taken and your position of being = anti >>> additional metadata on this issue is noted. >>> >>> >>> >>> All of which leaves me a bit uncertain about how to proceed. There seem >>> to be a range of opinions on this point and gauging consensus is provin= g >>> elusive for me. That's confounded by my own opinion on it being somewha= t >>> fluid. >>> >>> >>> >>> And I'd really like to post an update to this draft about a month or tw= o >>> ago. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: >>> >>> Confusion from the AS=E2=80=99s perspective: >>> >>> 1. If I only support mTLS, do I need to include both >>> token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_= uri? Or >>> set it to the empty string? >>> 2. What if I only support mTLS for the token endpoint, but not >>> revocation or user info? >>> 3. How do I specify authentication methods for the mTLS token >>> endpoint? Does token_endpoint_auth_methods apply to both the mTLS an= d >>> non-mTLS endpoints? >>> 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-= enabled >>> device_authorization_endpoint under mtls_endpoints? >>> >>> >>> >>> Confusion from the client=E2=80=99s perspective: >>> >>> 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t = know anything >>> about mTLS, but the IT admins installed client certs in their users= =E2=80=99 >>> browsers and the AS expects to use that to authenticate me. >>> 2. My AS metadata parser crashed because the mTLS-only AS omitted >>> token_endpoint_uri.. >>> 3. My AS metadata parser crashed because it didn=E2=80=99t expect to >>> encounter a JSON object as a parameter value. >>> 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoint= s, what >>> do I do? >>> 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but the= y told me to use HTTPS, >>> so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, righ= t? >>> >>> >>> >>> Yes, you can write normative text that answers most of these. But you= =E2=80=99ll >>> have to clearly cover a lot of similar-but-slightly-different scenarios= and >>> be very explicit. And implementers will still get it wrong. The metadat= a >>> change introduces opportunities for confusion and failure that do not e= xist >>> now, and forces them on everyone who supports mTLS. In contrast, the 30= 7 >>> redirect is only required when an AS wants to support both, and is >>> unambiguous in its behavior and meaning. >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* Brian Campbell >>> *Date:* Friday, February 1, 2019 at 3:17 PM >>> *To:* "Richard Backman, Annabelle" >>> *Cc:* George Fletcher , oauth >>> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >>> clients using the token endpoint >>> >>> >>> >>> It doesn't seem like that confusing or large of a change to me - if the >>> client is doing MTLS and the given endpoint is present in `mtls_endpoin= ts`, >>> then it uses that one. Otherwise it uses the regular endpoint. It give= s an >>> AS a lot of flexibility in deployment options. I personally think getti= ng a >>> 307 approach deployed and working would be more complicated and error >>> prone. >>> >>> >>> >>> It is a minority use case at the moment but there are forces in play, >>> like the push for increased security in general and to have javascript >>> clients use the code flow, that suggest it won't be terribly unusual to= see >>> an AS that wants to support MTLS clients and javascript/spa clients at = the >>> same time. >>> >>> >>> >>> I've personally wavered back and forth in this thread on whether or not >>> to add the new metadata (or something like it). With my reasoning each = way >>> kinda explained somewhere back in the 40 or so messages that make up th= is >>> thread. But it seems like the rough consensus of the group here is in >>> favor of it. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle >> 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf....org>> wrote: >>> >>> This strikes me as a very prominent and confusing change to support wha= t >>> seems to be a minority use case. I=E2=80=99m getting a headache just th= inking about >>> the text needed to clarify when the AS should provide `mtls_endpoints` = and >>> when the client should use that versus using `token_endpoint.` Why is t= he >>> 307 status code insufficient to cover the case where a single AS suppor= ts >>> both mTLS and non-mTLS? >>> >>> >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From:* OAuth on behalf of Brian Campbell >>> >>> *Date:* Friday, February 1, 2019 at 1:31 PM >>> *To:* George Fletcher >> <40aol.com@dmarc............ietf.org>> >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >>> endpoint >>> >>> >>> >>> Yes, that would work. >>> >>> >>> >>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher >> 40aol.com@dmarc.ietf..org <40aol.com@dmarc.ietf.org>> wrote: >>> >>> What if the AS wants to ONLY support MTLS connections. Does it not >>> specify the optional "mtls_endpoints" and just use the normal metadata >>> values? >>> >>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>> >>> It would definitely be optional, apologies if that wasn't made clear.. >>> It'd be something to the effect of optional for the AS to include and >>> clients doing MTLS would use it when present in AS metadata. >>> >>> >>> >>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >>> wrote: >>> >>> I'm in favour of the `mtls_endpoints` metadata parameter - although it >>> should be optional. >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf..org/mailman/listinfo/oauth >>> >>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > --0000000000002e977d0581f43c6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd say the evaluation should be on a per-endpoin= t basis, so presence of a different endpoint in mtls_endpoint does not affe= ct the client's decision on using mtls on a regular endpoint given the = auth methods for it also include mtls.

S poz= dravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:57,= George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
Just to make sure I understand...

If the AS ONLY supports MTLS endpoints, then it...
=C2=A0=C2=A0 * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'
=C2=A0=C2=A0 * does NOT specify the mlts_endpoints section

If the AS does NOT support MTLS endpoints, then it...
=C2=A0=C2=A0=C2=A0 * does NOT specify a value of 'tls_client_auth&#= 39; in the 'token_endpoint_auth_methods_supported'
=C2=A0=C2=A0=C2=A0 * does NOT specify the mlts_endpoints section

If the AS supports BOTH "regular" and MTLS endpoints, then it= ...
=C2=A0=C2=A0=C2=A0 * sets 'token_endpoint_auth_methods_supported= 9; to "client_secret_basic tls_client_auth" (as an example)
=C2=A0=C2=A0=C2=A0 * specifies mtls_endpoints in addition to the endpoi= nts normally defined for the AS

For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_suppo= rted' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS.

Now if the 'mtls_endpoints' section defines a 'mtls_token_e= ndpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data = does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it = assume that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object?

It will work, though it still feels "hacky" and overly comple= x.

Thanks,
George

On 2/15/19 2:= 42 PM, Phil Hunt wrote:
=20 This is what I would expect.=C2=A0

Phil
Hello George,

What do you think about what i wrote earlier?

clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include a= n indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out= of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints= " parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact= .



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to disagree.=C2=A0 I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases. =C2=A0

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect.=C2=A0

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this.=C2=A0

This may be a sign we need more implementation data (including from tls wg) to make the right call.=C2=A0

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers=C2=A0
=E2=80=94=E2=80=94=E2=80= =94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn=E2=80= =99t exist before.

=C2=A0

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that=E2=80=99s just my experience= as, you know, an actual developer.

=C2=A0

Let=E2=80=99= s keep the assumptions and snide remarks about others=E2=80=99 backgrounds off the list, please.

=C2=A0

--= =C2=A0

Anna= belle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Dominick Baier <dbaier@leastprivilege.com&g= t;
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <= richanna@amazon.co= m>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annabelle" <richanna@amazon.com&g= t;, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

=C2=A0

I am for keeping it simple and not introducing another link to follow.

=C2=A0

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

=C2=A0

=E2=80=94= =E2=80=94=E2=80=94

Dominick=

=C2=A0

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

He= llo,

=C2= =A0

Ad= ditionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80= =9Cis REQUIRED unless only the implicit grant type is supported.=E2= =80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

He= re is one example, based on my understanding of the =E2=80=9Cstraw man=E2= =80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a= list of client authentication methods supported by this token endpoint.=E2=80=9D If t= hat array contains =E2=80=9Ctls_client_aut= h=E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_met= hods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2= =80=99s that line of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

= =C2=A0

I gave `mtls_alternate_metadat= a` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.

=

S pozdravem,
Filip Skokan

= =C2=A0

= =C2=A0

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com= > wrote:

Here is one example, based on my understanding of the =E2=80=9Cs= traw man=E2=80=9D form= at presented in this thread: RFC8414 defines the value of token_endpoint_au= th_methods_supported as a =E2=80=9CJSO= N array containing a list of client authentication methods supported by this token endpoint.=E2=80= =9D If that array contains =E2=80=9Ctls_clie= nt_auth=E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_au= th_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest ju= st pointing to an alternate document.

=C2=A0

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUI= RED unless only the implicit grant type is supported.=E2=80= =9D

=C2=A0

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the =E2=80=9Cmtls_alt= ernate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com= @dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery<= /p>

=C2=A0

Hi Annabelle,

=C2=A0

can you elaborate what would be the violation / negative impact of usage of RFC8414?

=C2=A0

As it already makes use of `signed_metadata` and this language is present ...

=C2=A0

>=C2=A0Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.=C2=A0 If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

=C2=A0

.... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play = a role in the authentication process.


Best,
Filip

=C2=A0

=C2=A0

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=3D40amazon.com= @dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll readily grant that we probably don=E2= =80=99t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

=C2=A0

Along those lines, instead of adding an =E2=80=9Cmtls_end= points=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alt= ernate_metadata=E2=80=9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/o= r=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com= >
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery<= /p>

=C2=A0

Thanks for the input, Dominick.

=C2=A0

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been = a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivile= ge.com> wrote:

IMHO that=E2=80= =99s a reasonable and pragmatic option.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com<= /a>) wrote:

It's been pointed out that the poten= tial issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,=C2=A0 a= t this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoin= ts' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.=C2=A0 = A straw-man example might look like this

{
=C2=A0 "issu= er":"htt= ps://server.example.com",
=C2=A0 "authorizati= on_endpoint":"https://server.example.com/authz",
=C2=A0 "token_endpo= int":"https://server.example.com/token",
=C2=A0 "token_endpo= int_auth_methods_supported":[ =C2=A0"client_secret_basic","tls_client_auth", "no= ne"],
=C2=A0 "userinfo_en= dpoint":"https://server.example.com/userinfo",
=C2=A0 "revocation_= endpoint":"https://server.example.com/revo",
=C2=A0 "jwks= _uri":"https://server.example.com/jwks.json",
=C2=A0 "m= tls_endpoints":{
=C2=A0 =C2=A0 "token_endpo= int":"https://mtls.example.com/token",
=C2=A0 =C2=A0 "userinfo_en= dpoint":"https://mtls.example.com/userinfo",
=C2=A0 =C2=A0 "revocation_= endpoint":"https://mtls.example.com/revo"
=C2=A0 }
}

=C2=A0

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoi= nts" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoi= nts".


The idea being that "regula= r" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

=C2=A0

I'm struggling, however, to adequately gauge whether or not there'= s sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it.=C2=A0

=C2=A0

=C2=A0

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivile= ge.com> wrote:

We are currently implementing MTLS in IdentityServer.

=C2=A0

Our approach wil= l be that we=E2=80=99ll off= er a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_tok= en_endpoint=E2=80=9D.

=C2=A0

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

=C2=A0

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbel= l=3D40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bcampbell@pingi= dentity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com= @dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_au= th_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

"far" should have said "fair&q= uot; in the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingi= dentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/= confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn= 9;t needed or worth it in this document&quo= t; (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.= com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Sect= ion 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUI= RED unless only the implicit grant type is supported.=E2=80= =9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_au= th_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99= ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6= good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99= re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t thi= nk the metadata proposal as it=E2=80=99s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2= =80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthoriz= ation Server Metadata Extensions for mTLS Hybrids=E2= =80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com= @dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.= com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80= =99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_ur= i and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorizat= ion_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a pub= lic client, and don=E2=80=99t kno= w anything about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_ur= i..
  3. My AS metadata parser crashed because it didn=E2=80=99t ex= pect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t pr= ovide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t kno= w what that =E2=80= =9Cm=E2=80=9D means, but they told me to use HTTPS, so I should use the one with =E2=80=9Ctls= =E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99l= l have to clearly cover a lot of similar-but-sligh= tly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2= =A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.= com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org&g= t; on behalf of Brian Campbell <bcampbell=3D<= a href=3D"mailto:40pingidentity.com@dmarc.ietf.org" target=3D"_blank">40pin= gidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40ao= l.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc= .ietf..org> wrote:

Wh= at if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoi= nts" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.c= o.uk> wrote:

I'= ;m in favour of the `mtls_endpoints` metadata parameter - although it should be optional.<= /p>


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.= 

____________=
___________________________________
OAuth mailin=
g list
OAuth@ietf.org
https://www.ietf..org/mailman/list=
info/oauth

=C2=A0


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=


CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2= =A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.=

_______________________________________________
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
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ie=
tf.org
https://ww=
w.ietf.org/mailman/listinfo/oauth

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

--0000000000002e977d0581f43c6f-- From nobody Fri Feb 15 12:16:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914A813103B for ; Fri, 15 Feb 2019 12:16:13 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oYZsTAf55VC for ; Fri, 15 Feb 2019 12:16:07 -0800 (PST) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E5C13102E for ; Fri, 15 Feb 2019 12:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550261764; bh=avGTU4mG5RKdXjcaDjDlE+8ESCmqCt5aY0HGJ3sW+a4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=tn1lN/CneGwIXvbakyxTBAkev9N12ws3/hLMzBkwNgtvLUprjUYZcJjryk5g8f1fZuxmLiE4l2HREcsJ0J2wDE1vbhj1R6okGTnJKE0fYoQZj73R8Iz2mcZ7UV32eehDQ7idM5J/NyJ1GxzZyvtOw4suLkvvJUct81IpjTElNMqZgHXd8NJycZVdv9DK+bBAugsOkwzDRfU9Bo2NngR1M/zRocSdgGNL5WusybE1w7JRIFCiFr2PdwsfYZnFWETnuFV2qvA0Q8yyWhiFmht2dAZScfTKPEPx4bXLae6JXbPH56Y82FNYhZS8hyQ7VRYZ8i4tkDRu+Yv8BrHd4bEdyg== X-YMail-OSG: F5pDqDEVM1m_K159ZnOdl8WhXF.AEkUM1fF2cILd43GwjK808KtlAcexDSwNv.6 O7Uql.JkcbeW2H1HRPcO.0Gja5JP8di9u5P43c_Ix2DJmNfPUpiKWfgBMqH6EIjoUkphbAfM2fIn vBiTu6wDZ9Rz0_7y13s1WIKS9Lz9AY_38TPK.dz0APXC7xlxswgTI2JZXz8cbzFgWZ2s7zUexnJj Z9zAexoAsol3uMybD.Am7LRh8a8SNeN9NqzCnRKAOBur0rrjISE3SP.ezsyjflP9NHX1wGLIXt41 fPeGRL5y50vhu3D9Qh1I_.Z1iFvK1SwnUhH2lHe4XNj8tmyPrCgPAlCrDZjRInEzuLozSubdD8Fh WyK8i_ye1FIvKrJ4o.HDG8maKALznoNosOtxO1xbc9kqb3dxKIwg2SzEUlwh2nyAHS7MakKCpjzL _7FPm21xrv3fGZ1Ib_K409cWgLnE4vBGxArPSb3aJqdbRWhv9PEntwPqPxxZ8W0ViY9mf1RLQpqP YQrcv2Ce6sJN5e4rU9gQPNzQpXk2l9c2yQPwuMQZB7VPD.IUO.6wcyAjNU6tQ8ENhAPN5E90GFg5 HzVew.Evb6qFh2hNydmy8IBIHOaIAQoVmrAK1fh8hTrrwPisZF5Smo4NIlRvWpe2LX5GALT5KUk4 7A1Mmjk30eTsAtNBWTYQjdLmwsq1DUzdSFHdhcu2Z9BJasZeCeLVYXeIvQB_zJ.oBivWFE4FJ91T DfdCTMXuu14t_1ZxWz0kY3K8DOq_mg0bp_uERS3muHmJ.bRtfdzHRDNv_S9ZsMlFNc6k5tW6YrFp 1Z4J9BApPV2Rg_Mm3wdKMDoDePWbUqGzAP384beUOemtV.51vP4KIaL3_q7dUX5OeDyxiIdER_tB RJP.3cNyYRgheLk40wm53yTW0Wtpio7qarWHYlAcs1eJ.FASfd3nVT68ypgt54feUXwosQr4B53o MkTOv2DDNSG7zVQlIoAs00xbrKlKsMVb6fAh6wl5ZVQ41ryoNThdtf7BG_cffrlHpu0DN6o0bx1S MmLdyk0LTBC1hsxJsvdqWNE4VknukFLvSRKdj.7wyFxQXViLw0w1E16tX Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 15 Feb 2019 20:16:04 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9cea7ff5de215e54e4916df6342b649e; Fri, 15 Feb 2019 20:16:03 +0000 (UTC) To: Filip Skokan Cc: Phil Hunt , Brian Campbell , oauth References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> From: George Fletcher Organization: AOL LLC Message-ID: <212ff561-bdf9-6531-9e87-650315989290@aol.com> Date: Fri, 15 Feb 2019 15:16:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A39F94B206E6977698EED011" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 20:16:14 -0000 This is a multi-part message in MIME format. --------------A39F94B206E6977698EED011 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If I understand correctly, then as the AS I could require MTLS on the revocation and introspection endpoints and so NOT put them in the mtls_endpoints section as long as the "...supported_methods" claim says those endpoints support MTLS. However for the token endpoint the AS wants to support both MTLS and non-MTLS so it ONLY adds the token endpoint into the 'mtls_endpoints' section. For me this just makes the solution even more complex. I still argue that having the MTLS definition of the AS and the non-MTLS definition of the AS is simpler for both the operator and the client to understand. On 2/15/19 3:00 PM, Filip Skokan wrote: > I'd say the evaluation should be on a per-endpoint basis, so presence > of a different endpoint in mtls_endpoint does not affect the client's > decision on using mtls on a regular endpoint given the auth methods > for it also include mtls. > > S pozdravem, > *Filip Skokan* > > > On Fri, 15 Feb 2019 at 20:57, George Fletcher > wrote: > > Just to make sure I understand... > > If the AS ONLY supports MTLS endpoints, then it... >    * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth' >    * does NOT specify the mlts_endpoints section > > If the AS does NOT support MTLS endpoints, then it... >     * does NOT specify a value of 'tls_client_auth' in the > 'token_endpoint_auth_methods_supported' >     * does NOT specify the mlts_endpoints section > > If the AS supports BOTH "regular" and MTLS endpoints, then it... >     * sets 'token_endpoint_auth_methods_supported' to > "client_secret_basic tls_client_auth" (as an example) >     * specifies mtls_endpoints in addition to the endpoints > normally defined for the AS > > For the client, if it supports mtls AND if it finds > 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' > then it first looks to see if an mtls_endpoints object is provided > and if so uses those endpoints, otherwise it assumes the RFC 8414 > defined endpoints support MLTS. > > Now if the 'mtls_endpoints' section defines a > 'mtls_token_endpoint' but not an 'introspection_endpoint' but the > RFC 8414 meta-data does specify an 'introspection_endpoint', is > the client supposed to assume the introspection endpoint also > supports MTLS even though it wasn't listed in the 'mtls_endpoints' > object? or should it assume that endpoint does NOT support MTLS > because it's not part of the 'mtls_endpoints' object? > > It will work, though it still feels "hacky" and overly complex. > > Thanks, > George > > On 2/15/19 2:42 PM, Phil Hunt wrote: >> This is what I would expect. >> >> Phil >> >> On Feb 15, 2019, at 11:32 AM, Filip Skokan > > wrote: >> >>> Hello George, >>> >>> What do you think about what i wrote earlier? >>> >>> clients not having mtls capabilities won't care about the >>> additional method members being present. Clients that do >>> implement mtls by the specification will know to look for >>> mtls_endpoints and fall back to regular ones if the specific >>> endpoint or mtls_endpoints root property is not present. >>> >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Fri, 15 Feb 2019 at 20:29, George Fletcher >>> >> > wrote: >>> >>> I still don't see how we solve one of the use cases >>> Annabelle brought up. >>> >>> If the 'mtls_endpoints' object just contains endpoints, then >>> in the main meta-data section, should >>> 'token_endpoint_auth_methods_supported' include an >>> indication of 'tls_client_auth' even though the endpoint >>> specified by 'token_endpoint' does NOT support MTLS? >>> >>> Thanks, >>> George >>> >>> On 2/14/19 6:08 PM, Brian Campbell wrote: >>>> Maybe I'm wrong here (it's never out of the question) but >>>> based on this previous message >>>> >>>> and this one >>>> >>>> I believe that actually you are both in favor (generally >>>> anyway) of the proposal with the optional "mtls_endpoints" >>>> parameter. While I believe that the comment about >>>> optionality and complexity was meant to be a more general >>>> remark. While I can certainly appreciate a desire to keep >>>> things simple, I do regret that this thread took a turn >>>> towards personal. Whether it was the intent or not, there's >>>> an impact. >>>> >>>> >>>> >>>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt >>>> > wrote: >>>> >>>> I feel I have to disagree.  I agree that optionality is >>>> often complexity and should be avoided. But, I think >>>> the optionality here is an agility feature allowing >>>> mtls to work across a diversified market of different >>>> types of tls terminators with varying capability. Lack >>>> of appropriate discovery/options could serve to make >>>> the spec unusable in many cases. >>>> >>>> A complicating factor with tls is that a tls layer >>>> failure prevents the AS from issuing a correcting >>>> directive like an http error or http redirect. >>>> >>>> We have to be sure not to break existing clients so we >>>> may in some cases need mtls only endpoints. I am not >>>> far enough along to know for sure. But I tend to agree >>>> with Brian on this. >>>> >>>> This may be a sign we need more implementation data >>>> (including from tls wg) to make the right call. >>>> >>>> Phil >>>> >>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier >>>> >>> > wrote: >>>> >>>>> Sorry - this was not meant to be snide at all. >>>>> >>>>> It was honest feedback that you also need to keep >>>>> software complexity in mind when creating a spec. >>>>> Every MAY or OPTIONAL, or do it like this OR that, or >>>>> send values in arbitrary order adds to complexity. >>>>> Complexity is the natural enemy of security. >>>>> >>>>> Cheers >>>>> ——— >>>>> Dominick >>>>> >>>>> On 13. February 2019 at 20:39:16, Richard Backman, >>>>> Annabelle (richanna@amazon.com >>>>> ) wrote: >>>>> >>>>>> The issue is that the proposal violates the standard >>>>>> by changing the semantics of a parameter it defines. >>>>>> We should be very, very, VERY careful about telling >>>>>> implementers to violate an existing standard... This >>>>>> change might prove incompatible with existing or >>>>>> future implementations of 8414, it might not, but by >>>>>> violating the standard the proposal creates an >>>>>> opportunity for incompatibility that didn’t exist before. >>>>>> >>>>>> As far as simplicity is concerned, I find a solution >>>>>> that reuses the existing data model and naturally >>>>>> supports existing and future extensions to be far >>>>>> simpler than one that introduces ambiguous semantics >>>>>> to existing parameters. Generally speaking, data >>>>>> models with properties that mean different things in >>>>>> different contexts tend to be fragile and require >>>>>> more complex code to work with. But that’s just my >>>>>> experience as, you know, an actual developer. >>>>>> >>>>>> Let’s keep the assumptions and snide remarks about >>>>>> others’ backgrounds off the list, please. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From: *Dominick Baier >>>>> > >>>>>> *Date: *Wednesday, February 13, 2019 at 4:18 AM >>>>>> *To: *"Richard Backman, Annabelle" >>>>>> >, >>>>>> Filip Skokan >>>>> > >>>>>> *Cc: *Brian Campbell >>>>> >, "Richard >>>>>> Backman, Annabelle" >>>>> >, oauth >>>>> > >>>>>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS >>>>>> token endoint & discovery >>>>>> >>>>>> I am for keeping it simple and not introducing >>>>>> another link to follow. >>>>>> >>>>>> I sometimes wonder how many of the spec authors are >>>>>> actually developers - these suggestions make software >>>>>> unnecessary complex ;) >>>>>> >>>>>> ——— >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 13. February 2019 at 12:25:13, Filip Skokan >>>>>> (panva.ip@gmail.com ) wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Additionally, a metadata document that omits >>>>>> token_endpoint in favor of mtls_endpoints >>>>>> since only mTLS is supported would violate >>>>>> 8414, as 8414 says token_endpoint “is >>>>>> REQUIRED unless only the implicit grant type >>>>>> is supported.” >>>>>> >>>>>> >>>>>> mtls only AS doesn't get anything out of using >>>>>> mtls_endpoints, its use should not be recommended >>>>>> for such AS and regular endpoints will be used, >>>>>> this satisfies the requirement >>>>>> >>>>>> Here is one example, based on my >>>>>> understanding of the “straw man” format >>>>>> presented in this thread: RFC8414 defines the >>>>>> value of >>>>>> token_endpoint_auth_methods_supported as a >>>>>> “JSON array containing a list of client >>>>>> authentication methods supported by this >>>>>> token endpoint.” If that array contains >>>>>> “tls_client_auth” and the endpoint specified >>>>>> in token_endpoint does not support mTLS, then >>>>>> that metadata violates 8414. You could >>>>>> address this by adding a >>>>>> token_endpoint_auth_methods_supported >>>>>> parameter to the mtls_endpoints object, and >>>>>> likewise for the other endpoints and auth >>>>>> methods. If you take that to its logical >>>>>> conclusion, you end up with a complete >>>>>> metadata document hanging off of >>>>>> mtls_endpoints. It’s that line of thought >>>>>> that led me to suggest just pointing to an >>>>>> alternate document. >>>>>> >>>>>> >>>>>> Assuming we go with using the same root auth >>>>>> methods property, what's the issue? Clients not >>>>>> having mtls capabilities won't care about the >>>>>> additional method members being present. Clients >>>>>> that do implement mtls by the specification will >>>>>> know to look for mtls_endpoints and fall back to >>>>>> regular ones if the specific endpoint or >>>>>> mtls_endpoints root property is not present. >>>>>> >>>>>> I gave `mtls_alternate_metadata` route a thought >>>>>> and don't see how it helps, given the two above >>>>>> are non-issues (my $.02) another discovery >>>>>> document only brings more of them since every >>>>>> property can now be different, not just the >>>>>> endpoints. >>>>>> >>>>>> >>>>>> S pozdravem, >>>>>> *Filip Skokan* >>>>>> >>>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, >>>>>> Annabelle >>>>> > wrote: >>>>>> >>>>>> Here is one example, based on my >>>>>> understanding of the “straw man” format >>>>>> presented in this thread: RFC8414 defines the >>>>>> value of >>>>>> token_endpoint_auth_methods_supported as a >>>>>> “JSON array containing a list of client >>>>>> authentication methods supported by this >>>>>> token endpoint.” If that array contains >>>>>> “tls_client_auth” and the endpoint specified >>>>>> in token_endpoint does not support mTLS, then >>>>>> that metadata violates 8414. You could >>>>>> address this by adding a >>>>>> token_endpoint_auth_methods_supported >>>>>> parameter to the mtls_endpoints object, and >>>>>> likewise for the other endpoints and auth >>>>>> methods. If you take that to its logical >>>>>> conclusion, you end up with a complete >>>>>> metadata document hanging off of >>>>>> mtls_endpoints. It’s that line of thought >>>>>> that led me to suggest just pointing to an >>>>>> alternate document. >>>>>> >>>>>> Additionally, a metadata document that omits >>>>>> token_endpoint in favor of mtls_endpoints >>>>>> since only mTLS is supported would violate >>>>>> 8414, as 8414 says token_endpoint “is >>>>>> REQUIRED unless only the implicit grant type >>>>>> is supported.” >>>>>> >>>>>> It is possible to define the mtls_endpoints >>>>>> parameter such that the above use cases are >>>>>> invalid, but that does make the document more >>>>>> complicated.. If we go the >>>>>> “mtls_alternate_metadata” route, we can skip >>>>>> past all of these issues, because it brings >>>>>> us back to just parsing the same metadata >>>>>> that we do today. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* OAuth >>>>> > on behalf of >>>>>> Filip Skokan >>>>> > >>>>>> *Date:* Tuesday, February 12, 2019 at 1:13 PM >>>>>> *To:* "Richard Backman, Annabelle" >>>>>> >>>>> > >>>>>> *Cc:* Brian Campbell >>>>>> >>>>> >, >>>>>> oauth > >>>>>> *Subject:* Re: [OAUTH-WG] MTLS token endoint >>>>>> & discovery >>>>>> >>>>>> Hi Annabelle, >>>>>> >>>>>> can you elaborate what would be the violation >>>>>> / negative impact of usage of RFC8414? >>>>>> >>>>>> As it already makes use of `signed_metadata` >>>>>> and this language is present ... >>>>>> >>>>>> > Consumers of the metadata MAY ignore the signed >>>>>> metadata if they do not support this >>>>>> feature.  If the consumer of the metadata >>>>>> supports signed metadata, metadata values >>>>>> conveyed in the signed metadata MUST take >>>>>> precedence over the corresponding values >>>>>> conveyed using plain JSON elements. >>>>>> >>>>>> .... would mtls_endpoints be any different? >>>>>> Clients are free to ignore this if they don't >>>>>> support/use mtls, and if they do those values >>>>>> must take precedence over the root ones. the >>>>>> use of mtls_endpoints would not be >>>>>> recommended for mtls-only AS but recommended >>>>>> for one with both mtls/regular authentication >>>>>> methods. token_endpoint remains required for >>>>>> all intents and purposes. And as for the >>>>>> usable client authentication methods - they >>>>>> should all be listed, or do you think we >>>>>> should separate the ones for each >>>>>> hostname/port location? To what end? Is there >>>>>> a risk having the mtls hostname/port >>>>>> accepting regular requests? Other then >>>>>> secret/key _jwt auth methods assertion aud >>>>>> claim the endpoint location doesn't play a >>>>>> role in the authentication process. >>>>>> >>>>>> >>>>>> Best, >>>>>> *Filip* >>>>>> >>>>>> On Tue, 12 Feb 2019 at 20:47, Richard >>>>>> Backman, Annabelle >>>>>> >>>>> > wrote: >>>>>> >>>>>> I’m not opposed to introducing a metadata >>>>>> change, if the scenario is relevant and >>>>>> other approaches can’t adequately address >>>>>> it – and I’ll readily grant that we >>>>>> probably don’t want to depend on >>>>>> consistency of browser behavior at the >>>>>> intersection of client certificates and >>>>>> Access-Control-Allow-Credentials. But >>>>>> care needs to be taken in designing that >>>>>> metadata to avoid violating or otherwise >>>>>> negatively impacting usage of RFC8414. >>>>>> >>>>>> Along those lines, instead of adding an >>>>>> “mtls_endpoints” metadata parameter, we >>>>>> could add an “mtls_alternate_metadata” >>>>>> parameter whose value is the URL of an >>>>>> alternate metadata document intended for >>>>>> clients using mTLS. An mTLS-optional AS >>>>>> could have two different metadata >>>>>> documents for mTLS and non-mTLS clients, >>>>>> reducing the mTLS-optional scenario to >>>>>> the mTLS-only scenario. This sidesteps >>>>>> the challenges of aligning the >>>>>> “either/or” semantics of mTLS-optional >>>>>> with some of the rigid parameter >>>>>> definitions in RFC8414 (see: >>>>>> token_endpoint, >>>>>> token_endpoint_auth_methods_supported). >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* OAuth >>>>> > on >>>>>> behalf of Brian Campbell >>>>>> >>>>> > >>>>>> *Date:* Tuesday, February 12, 2019 at >>>>>> 10:58 AM >>>>>> *To:* Dominick Baier >>>>>> >>>>> > >>>>>> *Cc:* oauth >>>>> > >>>>>> *Subject:* Re: [OAUTH-WG] MTLS token >>>>>> endoint & discovery >>>>>> >>>>>> Thanks for the input, Dominick. >>>>>> >>>>>> I'd said previously that I was having >>>>>> trouble adequately gauging whether or not >>>>>> there's sufficient consensus to go ahead >>>>>> with the update. I was even thinking of >>>>>> asking the chairs about a consensus call >>>>>> during the office hours meeting >>>>>> yesterday. But it got canceled. And >>>>>> looking again back over the discussion, I >>>>>> don't believe a consensus call is >>>>>> necessary. There's been a lot of general >>>>>> discussion over the last several weeks >>>>>> during which several folks have stated >>>>>> support for the proposal while there's >>>>>> been only one voice of direct dissent. >>>>>> That seems like rough enough consensus >>>>>> and, as such, I plan to make the change >>>>>> in the next revision of the document >>>>>> (which should be done soon). Chairs, >>>>>> please let me know, if you believe the >>>>>> situation warrants a different course of >>>>>> action. >>>>>> >>>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick >>>>>> Baier >>>>> > wrote: >>>>>> >>>>>> IMHO that’s a reasonable and >>>>>> pragmatic option. >>>>>> >>>>>> Thanks >>>>>> >>>>>> ——— >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 11. February 2019 at 13:26:37, >>>>>> Brian Campbell >>>>>> (bcampbell@pingidentity.com >>>>>> ) >>>>>> wrote: >>>>>> >>>>>> It's been pointed out that the >>>>>> potential issue is not isolated >>>>>> to the just token endpoint but >>>>>> that revocation, introspection, >>>>>> etc. could be impacted as well. >>>>>> So,  at this point, the proposal >>>>>> on the table is to add a new >>>>>> optional AS metadata parameter >>>>>> named 'mtls_endpoints' that's >>>>>> value we be a JSON object which >>>>>> itself contains endpoints that, >>>>>> when present, a client doing MTLS >>>>>> would use rather than the regular >>>>>> endpoints.  A straw-man example >>>>>> might look like this >>>>>> >>>>>> { >>>>>>   >>>>>> "issuer":"https://server.example.com", >>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>> "token_endpoint":"https://server.example.com/token", >>>>>> "token_endpoint_auth_methods_supported":[ >>>>>>  "client_secret_basic","tls_client_auth", >>>>>> "none"], >>>>>> "userinfo_endpoint":"https://server.example.com/userinfo", >>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>   >>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>> *"mtls_endpoints":{ >>>>>> "token_endpoint":"https://mtls.example.com/token", >>>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>>>> "revocation_endpoint":"https://mtls.example.com/revo >>>>>> " >>>>>>   }* >>>>>> } >>>>>> >>>>>> A client doing MTLS would look >>>>>> for and give precedence to an >>>>>> endpoint under "mtls_endpoints" >>>>>> while falling back to use the >>>>>> normal endpoint from the top >>>>>> level of metadata when/if its not >>>>>> in "mtls_endpoints". >>>>>> >>>>>> >>>>>> The idea being that "regular" >>>>>> clients (those not doing MTLS) >>>>>> will use the regular endpoints. >>>>>> And only the host/port of the >>>>>> endpoints listed in >>>>>> mtls_endpoints will be set up to >>>>>> request TLS client certificates >>>>>> during handshake. Thus any >>>>>> potential impact of the >>>>>> CertificateRequest message being >>>>>> sent in the TLS handshake can be >>>>>> avoided for all the other regular >>>>>> clients that are not going to do >>>>>> MTLS - including and most >>>>>> importantly in-browser javascript >>>>>> clients where there can be less >>>>>> than desirable UI presented to >>>>>> the end-user. >>>>>> >>>>>> I'm struggling, however, to >>>>>> adequately gauge whether or not >>>>>> there's sufficient consensus to >>>>>> go ahead with the update. There's >>>>>> been some support for it voiced. >>>>>> As well as talk of other >>>>>> approaches that could be >>>>>> alternatives or additional >>>>>> measures. And also some vocal >>>>>> opposition to it. >>>>>> >>>>>> On Sat, Feb 9, 2019 at 3:09 AM >>>>>> Dominick Baier >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> We are currently implementing >>>>>> MTLS in IdentityServer. >>>>>> >>>>>> Our approach will be that >>>>>> we’ll offer a separate token >>>>>> endpoint that supports client >>>>>> certs. Are you planning on >>>>>> adding an official endpoint >>>>>> name for discovery? Right now >>>>>> we are using >>>>>> “mtls_token_endpoint”. >>>>>> >>>>>> Thanks >>>>>> >>>>>> ——— >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 7. February 2019 at >>>>>> 22:36:55, Brian Campbell >>>>>> (bcampbell=40pingidentity.com@dmarc.ietf.org >>>>>> ) >>>>>> wrote: >>>>>> >>>>>> Ah yes, that makes sense. >>>>>> Thanks for clarifying. >>>>>> And it is indeed a good >>>>>> reminder that even a >>>>>> seemingly innocuous >>>>>> change that should be >>>>>> backwards compatible can >>>>>> break things unexpectedly.. >>>>>> >>>>>> On Thu, Feb 7, 2019 at >>>>>> 8:57 AM Richard Backman, >>>>>> Annabelle >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> The case I’m >>>>>> referencing didn’t >>>>>> specifically involve >>>>>> AS metadata. We had >>>>>> clients in the wild >>>>>> that assumed that all >>>>>> the properties in the >>>>>> JSON object returned >>>>>> from our userinfo >>>>>> endpoint were scalar >>>>>> strings. This broke >>>>>> when we introduced a >>>>>> new property whose >>>>>> value was a JSON >>>>>> object. It was a good >>>>>> reminder that even a >>>>>> seemingly innocuous >>>>>> change that should be >>>>>> backwards compatible >>>>>> can force more work >>>>>> on clients than we >>>>>> expect. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle Richard Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* Brian >>>>>> Campbell >>>>>> >>>>> > >>>>>> *Date:* Wednesday, >>>>>> February 6, 2019 at >>>>>> 11:30 AM >>>>>> *To:* "Richard >>>>>> Backman, Annabelle" >>>>>> >>>>> > >>>>>> *Cc:* "Richard >>>>>> Backman, Annabelle" >>>>>> >>>>> >, >>>>>> oauth >>>>> > >>>>>> *Subject:* Re: >>>>>> [OAUTH-WG] >>>>>> [UNVERIFIED SENDER] >>>>>> Re: MTLS and >>>>>> in-browser clients >>>>>> using the token endpoint >>>>>> >>>>>> And I'm honestly >>>>>> really struggling to >>>>>> see what could have >>>>>> gone wrong with or >>>>>> how >>>>>> token_endpoint_auth_methods >>>>>> broke something with >>>>>> the user info >>>>>> endpoint. If you have >>>>>> the time and/or it'd >>>>>> be informative to >>>>>> this here little >>>>>> discussion, please >>>>>> explain that one a >>>>>> bit more. >>>>>> >>>>>> On Wed, Feb 6, 2019 >>>>>> at 12:15 PM Brian >>>>>> Campbell >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> "far" should have >>>>>> said "fair" in >>>>>> the previous message >>>>>> >>>>>> On Tue, Feb 5, >>>>>> 2019 at 4:35 PM >>>>>> Brian Campbell >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> It may well >>>>>> be due to my >>>>>> own >>>>>> intellectual >>>>>> shortcomings >>>>>> but these >>>>>> issues/questions/confusion-points >>>>>> are not >>>>>> resonating >>>>>> for me as >>>>>> being >>>>>> problematic. >>>>>> >>>>>> The more >>>>>> general >>>>>> stance of >>>>>> "this isn't >>>>>> needed or >>>>>> worth it in >>>>>> this >>>>>> document" (I >>>>>> think that's >>>>>> far?) is >>>>>> being heard >>>>>> though. >>>>>> >>>>>> On Tue, Feb >>>>>> 5, 2019 at >>>>>> 1:42 PM >>>>>> Richard >>>>>> Backman, >>>>>> Annabelle >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> (TL;DR: >>>>>> punt AS >>>>>> metadata >>>>>> to a >>>>>> separate >>>>>> draft) >>>>>> >>>>>> AS points >>>>>> #1-3 are >>>>>> all >>>>>> questions >>>>>> I would >>>>>> have as >>>>>> an >>>>>> implementer: >>>>>> >>>>>> 1. Section >>>>>> 2 of >>>>>> RFC8414 >>>>>> >>>>>> says >>>>>> token_endpoint >>>>>> “is >>>>>> REQUIRED >>>>>> unless >>>>>> only >>>>>> the >>>>>> implicit >>>>>> grant >>>>>> type >>>>>> is >>>>>> supported.” >>>>>> So >>>>>> what >>>>>> does >>>>>> the >>>>>> mTLS-only >>>>>> AS >>>>>> put >>>>>> here? >>>>>> 2. The >>>>>> claims >>>>>> for >>>>>> these >>>>>> other >>>>>> endpoints >>>>>> are >>>>>> OPTIONAL, >>>>>> potentially >>>>>> leading >>>>>> to >>>>>> inconsistency >>>>>> depending >>>>>> on >>>>>> how >>>>>> #1 >>>>>> gets >>>>>> decided. >>>>>> 3. The >>>>>> example >>>>>> usage >>>>>> of >>>>>> the >>>>>> token_endpoint_auth_methods >>>>>> property >>>>>> given >>>>>> earlier >>>>>> is >>>>>> incompatible >>>>>> with >>>>>> RFC8414, >>>>>> since >>>>>> some >>>>>> of >>>>>> its >>>>>> contents >>>>>> are >>>>>> only >>>>>> valid >>>>>> for >>>>>> the >>>>>> non-mTLS >>>>>> endpoints, >>>>>> and >>>>>> others >>>>>> are >>>>>> only >>>>>> valid >>>>>> for >>>>>> the >>>>>> mTLS >>>>>> endpoints. >>>>>> Hence >>>>>> this >>>>>> question. >>>>>> >>>>>> 4. This >>>>>> introduces >>>>>> a new >>>>>> metadata >>>>>> property >>>>>> that >>>>>> could >>>>>> impact >>>>>> how >>>>>> other >>>>>> specs >>>>>> should >>>>>> extend >>>>>> AS >>>>>> metadata. >>>>>> That >>>>>> needs >>>>>> to be >>>>>> addressed. >>>>>> >>>>>> >>>>>> I could >>>>>> go on for >>>>>> client >>>>>> points >>>>>> but you >>>>>> already >>>>>> get the >>>>>> point. >>>>>> Though >>>>>> I’ll >>>>>> share >>>>>> that #3 >>>>>> is real >>>>>> and once >>>>>> forced me >>>>>> to roll >>>>>> back an >>>>>> update to >>>>>> the Login >>>>>> with >>>>>> Amazon >>>>>> userinfo >>>>>> endpoint…good >>>>>> times. 😃 >>>>>> >>>>>> I don’t >>>>>> necessarily >>>>>> think an >>>>>> AS >>>>>> metadata >>>>>> property >>>>>> is wrong >>>>>> per se, >>>>>> but >>>>>> understand >>>>>> that >>>>>> you’re >>>>>> bolting a >>>>>> layer of >>>>>> flexibility >>>>>> onto a >>>>>> standard >>>>>> that >>>>>> wasn’t >>>>>> designed >>>>>> for that, >>>>>> and I >>>>>> don’t >>>>>> think the >>>>>> metadata >>>>>> proposal >>>>>> as it’s >>>>>> been >>>>>> discussed >>>>>> here >>>>>> sufficiently >>>>>> deals >>>>>> with the >>>>>> fallout >>>>>> from >>>>>> that. In >>>>>> my view >>>>>> this is a >>>>>> complex >>>>>> enough >>>>>> issue and >>>>>> it’s for >>>>>> a nuanced >>>>>> enough >>>>>> use case >>>>>> (as far >>>>>> as I can >>>>>> tell from >>>>>> discussion? >>>>>> Please >>>>>> correct >>>>>> me if I’m >>>>>> wrong) >>>>>> that we >>>>>> should >>>>>> punt it >>>>>> to a >>>>>> separate >>>>>> draft >>>>>> (e.g., >>>>>> “Authorization >>>>>> Server >>>>>> Metadata >>>>>> Extensions >>>>>> for mTLS >>>>>> Hybrids”) >>>>>> and get >>>>>> mTLS out >>>>>> the door. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle >>>>>> Richard >>>>>> Backman >>>>>> >>>>>> AWS Identity >>>>>> >>>>>> *From:* >>>>>> OAuth >>>>>> >>>>> > >>>>>> on behalf >>>>>> of Brian >>>>>> Campbell >>>>>> >>>>> > >>>>>> *Date:* >>>>>> Monday, >>>>>> February >>>>>> 4, 2019 >>>>>> at 5:28 AM >>>>>> *To:* >>>>>> "Richard >>>>>> Backman, >>>>>> Annabelle" >>>>>> >>>>> > >>>>>> *Cc:* >>>>>> oauth >>>>>> >>>>> > >>>>>> *Subject:* >>>>>> Re: >>>>>> [OAUTH-WG] >>>>>> [UNVERIFIED >>>>>> SENDER] >>>>>> Re: MTLS >>>>>> and >>>>>> in-browser >>>>>> clients >>>>>> using the >>>>>> token >>>>>> endpoint >>>>>> >>>>>> Those >>>>>> points of >>>>>> confusion >>>>>> strike me >>>>>> as >>>>>> somewhat >>>>>> hypothetical >>>>>> or >>>>>> hyperbolic. >>>>>> But your >>>>>> general >>>>>> point is >>>>>> taken and >>>>>> your >>>>>> position >>>>>> of being >>>>>> anti >>>>>> additional >>>>>> metadata >>>>>> on this >>>>>> issue is >>>>>> noted. >>>>>> >>>>>> All of >>>>>> which >>>>>> leaves me >>>>>> a bit >>>>>> uncertain >>>>>> about how >>>>>> to >>>>>> proceed. >>>>>> There >>>>>> seem to >>>>>> be a >>>>>> range of >>>>>> opinions >>>>>> on this >>>>>> point and >>>>>> gauging >>>>>> consensus >>>>>> is >>>>>> proving >>>>>> elusive >>>>>> for me. >>>>>> That's >>>>>> confounded >>>>>> by my own >>>>>> opinion >>>>>> on it >>>>>> being >>>>>> somewhat >>>>>> fluid. >>>>>> >>>>>> And I'd >>>>>> really >>>>>> like to >>>>>> post an >>>>>> update to >>>>>> this >>>>>> draft >>>>>> about a >>>>>> month or >>>>>> two ago. >>>>>> >>>>>> On Fri, >>>>>> Feb 1, >>>>>> 2019 at >>>>>> 5:03 PM >>>>>> Richard >>>>>> Backman, >>>>>> Annabelle >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Confusion >>>>>> from >>>>>> the >>>>>> AS’s >>>>>> perspective: >>>>>> >>>>>> 1. If >>>>>> I >>>>>> only >>>>>> support >>>>>> mTLS, >>>>>> do >>>>>> I >>>>>> need >>>>>> to >>>>>> include >>>>>> both >>>>>> token_endpoint_uri >>>>>> and >>>>>> mtls_endpoints? >>>>>> Should >>>>>> I >>>>>> omit >>>>>> token_endpoint_uri? >>>>>> Or >>>>>> set >>>>>> it >>>>>> to >>>>>> the >>>>>> empty >>>>>> string? >>>>>> >>>>>> 2. What >>>>>> if >>>>>> I >>>>>> only >>>>>> support >>>>>> mTLS >>>>>> for >>>>>> the >>>>>> token >>>>>> endpoint, >>>>>> but >>>>>> not >>>>>> revocation >>>>>> or >>>>>> user >>>>>> info? >>>>>> >>>>>> 3. How >>>>>> do >>>>>> I >>>>>> specify >>>>>> authentication >>>>>> methods >>>>>> for >>>>>> the >>>>>> mTLS >>>>>> token >>>>>> endpoint? >>>>>> Does >>>>>> token_endpoint_auth_methods >>>>>> apply >>>>>> to >>>>>> both >>>>>> the >>>>>> mTLS >>>>>> and >>>>>> non-mTLS >>>>>> endpoints? >>>>>> >>>>>> 4. I’m >>>>>> using >>>>>> the >>>>>> OAuth >>>>>> 2.0 >>>>>> Device >>>>>> Flow. >>>>>> Do >>>>>> I >>>>>> include >>>>>> a >>>>>> mTLS-enabled >>>>>> device_authorization_endpoint >>>>>> under >>>>>> mtls_endpoints? >>>>>> >>>>>> >>>>>> Confusion >>>>>> from >>>>>> the >>>>>> client’s >>>>>> perspective: >>>>>> >>>>>> 1. As >>>>>> far >>>>>> as >>>>>> I >>>>>> know, >>>>>> I’m >>>>>> a >>>>>> public >>>>>> client, >>>>>> and >>>>>> don’t >>>>>> know >>>>>> anything >>>>>> about >>>>>> mTLS, >>>>>> but >>>>>> the >>>>>> IT >>>>>> admins >>>>>> installed >>>>>> client >>>>>> certs >>>>>> in >>>>>> their >>>>>> users’ >>>>>> browsers >>>>>> and >>>>>> the >>>>>> AS >>>>>> expects >>>>>> to >>>>>> use >>>>>> that >>>>>> to >>>>>> authenticate >>>>>> me. >>>>>> 2. My >>>>>> AS >>>>>> metadata >>>>>> parser >>>>>> crashed >>>>>> because >>>>>> the >>>>>> mTLS-only >>>>>> AS >>>>>> omitted >>>>>> token_endpoint_uri.. >>>>>> >>>>>> 3. My >>>>>> AS >>>>>> metadata >>>>>> parser >>>>>> crashed >>>>>> because >>>>>> it >>>>>> didn’t >>>>>> expect >>>>>> to >>>>>> encounter >>>>>> a >>>>>> JSON >>>>>> object >>>>>> as >>>>>> a >>>>>> parameter >>>>>> value. >>>>>> >>>>>> 4. The >>>>>> mTLS-only >>>>>> AS >>>>>> didn’t >>>>>> provide >>>>>> a >>>>>> value >>>>>> for >>>>>> mtls_endpoints, >>>>>> what >>>>>> do >>>>>> I >>>>>> do? >>>>>> 5. I >>>>>> don’t >>>>>> know >>>>>> what >>>>>> that >>>>>> “m” >>>>>> means, >>>>>> but >>>>>> they >>>>>> told >>>>>> me >>>>>> to >>>>>> use >>>>>> HTTPS, >>>>>> so >>>>>> I >>>>>> should >>>>>> use >>>>>> the >>>>>> one >>>>>> with >>>>>> “tls” >>>>>> in >>>>>> its >>>>>> name, >>>>>> right? >>>>>> >>>>>> >>>>>> Yes, >>>>>> you >>>>>> can >>>>>> write >>>>>> normative >>>>>> text >>>>>> that >>>>>> answers >>>>>> most >>>>>> of >>>>>> these. >>>>>> But >>>>>> you’ll >>>>>> have >>>>>> to >>>>>> clearly >>>>>> cover >>>>>> a lot >>>>>> of >>>>>> similar-but-slightly-different >>>>>> scenarios >>>>>> and >>>>>> be >>>>>> very >>>>>> explicit. >>>>>> And >>>>>> implementers >>>>>> will >>>>>> still >>>>>> get >>>>>> it >>>>>> wrong. >>>>>> The >>>>>> metadata >>>>>> change >>>>>> introduces >>>>>> opportunities >>>>>> for >>>>>> confusion >>>>>> and >>>>>> failure >>>>>> that >>>>>> do >>>>>> not >>>>>> exist >>>>>> now, >>>>>> and >>>>>> forces >>>>>> them >>>>>> on >>>>>> everyone >>>>>> who >>>>>> supports >>>>>> mTLS. >>>>>> In >>>>>> contrast, >>>>>> the >>>>>> 307 >>>>>> redirect >>>>>> is >>>>>> only >>>>>> required >>>>>> when >>>>>> an AS >>>>>> wants >>>>>> to >>>>>> support >>>>>> both, >>>>>> and >>>>>> is >>>>>> unambiguous >>>>>> in >>>>>> its >>>>>> behavior >>>>>> and >>>>>> meaning. >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle >>>>>> Richard >>>>>> Backman >>>>>> >>>>>> AWS >>>>>> Identity >>>>>> >>>>>> *From:* >>>>>> Brian >>>>>> Campbell >>>>>> >>>>> > >>>>>> *Date:* >>>>>> Friday, >>>>>> February >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 3:17 PM >>>>>> *To:* >>>>>> "Richard >>>>>> Backman, >>>>>> Annabelle" >>>>>> >>>>> > >>>>>> *Cc:* >>>>>> George >>>>>> Fletcher >>>>>> >>>>> >, >>>>>> oauth >>>>>> >>>>> > >>>>>> *Subject:* >>>>>> [UNVERIFIED >>>>>> SENDER] >>>>>> Re: >>>>>> [OAUTH-WG] >>>>>> MTLS >>>>>> and >>>>>> in-browser >>>>>> clients >>>>>> using >>>>>> the >>>>>> token >>>>>> endpoint >>>>>> >>>>>> It >>>>>> doesn't >>>>>> seem >>>>>> like >>>>>> that >>>>>> confusing >>>>>> or >>>>>> large >>>>>> of a >>>>>> change >>>>>> to me >>>>>> - if >>>>>> the >>>>>> client >>>>>> is >>>>>> doing >>>>>> MTLS >>>>>> and >>>>>> the >>>>>> given >>>>>> endpoint >>>>>> is >>>>>> present >>>>>> in >>>>>> `mtls_endpoints`, >>>>>> then >>>>>> it >>>>>> uses >>>>>> that >>>>>> one. >>>>>> Otherwise >>>>>> it >>>>>> uses >>>>>> the >>>>>> regular >>>>>> endpoint. >>>>>> It >>>>>> gives >>>>>> an AS >>>>>> a lot >>>>>> of >>>>>> flexibility >>>>>> in >>>>>> deployment >>>>>> options. >>>>>> I >>>>>> personally >>>>>> think >>>>>> getting >>>>>> a 307 >>>>>> approach >>>>>> deployed >>>>>> and >>>>>> working >>>>>> would >>>>>> be >>>>>> more >>>>>> complicated >>>>>> and >>>>>> error >>>>>> prone. >>>>>> >>>>>> It is >>>>>> a >>>>>> minority >>>>>> use >>>>>> case >>>>>> at >>>>>> the >>>>>> moment >>>>>> but >>>>>> there >>>>>> are >>>>>> forces >>>>>> in >>>>>> play, >>>>>> like >>>>>> the >>>>>> push >>>>>> for >>>>>> increased >>>>>> security >>>>>> in >>>>>> general >>>>>> and >>>>>> to >>>>>> have >>>>>> javascript >>>>>> clients >>>>>> use >>>>>> the >>>>>> code >>>>>> flow, >>>>>> that >>>>>> suggest >>>>>> it >>>>>> won't >>>>>> be >>>>>> terribly >>>>>> unusual >>>>>> to >>>>>> see >>>>>> an AS >>>>>> that >>>>>> wants >>>>>> to >>>>>> support >>>>>> MTLS >>>>>> clients >>>>>> and >>>>>> javascript/spa >>>>>> clients >>>>>> at >>>>>> the >>>>>> same >>>>>> time. >>>>>> >>>>>> I've >>>>>> personally >>>>>> wavered >>>>>> back >>>>>> and >>>>>> forth >>>>>> in >>>>>> this >>>>>> thread >>>>>> on >>>>>> whether >>>>>> or >>>>>> not >>>>>> to >>>>>> add >>>>>> the >>>>>> new >>>>>> metadata >>>>>> (or >>>>>> something >>>>>> like >>>>>> it). >>>>>> With >>>>>> my >>>>>> reasoning >>>>>> each >>>>>> way >>>>>> kinda >>>>>> explained >>>>>> somewhere >>>>>> back >>>>>> in >>>>>> the >>>>>> 40 or >>>>>> so >>>>>> messages >>>>>> that >>>>>> make >>>>>> up >>>>>> this >>>>>> thread. >>>>>> But >>>>>> it >>>>>> seems >>>>>> like >>>>>> the >>>>>> rough >>>>>> consensus >>>>>> of >>>>>> the >>>>>> group >>>>>> here >>>>>> is in >>>>>> favor >>>>>> of it. >>>>>> >>>>>> On >>>>>> Fri, >>>>>> Feb >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 3:18 >>>>>> PM >>>>>> Richard >>>>>> Backman, >>>>>> Annabelle >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> This >>>>>> strikes >>>>>> me >>>>>> as >>>>>> a >>>>>> very >>>>>> prominent >>>>>> and >>>>>> confusing >>>>>> change >>>>>> to >>>>>> support >>>>>> what >>>>>> seems >>>>>> to >>>>>> be >>>>>> a >>>>>> minority >>>>>> use >>>>>> case. >>>>>> I’m >>>>>> getting >>>>>> a >>>>>> headache >>>>>> just >>>>>> thinking >>>>>> about >>>>>> the >>>>>> text >>>>>> needed >>>>>> to >>>>>> clarify >>>>>> when >>>>>> the >>>>>> AS >>>>>> should >>>>>> provide >>>>>> `mtls_endpoints` >>>>>> and >>>>>> when >>>>>> the >>>>>> client >>>>>> should >>>>>> use >>>>>> that >>>>>> versus >>>>>> using >>>>>> `token_endpoint.` >>>>>> Why >>>>>> is >>>>>> the >>>>>> 307 >>>>>> status >>>>>> code >>>>>> insufficient >>>>>> to >>>>>> cover >>>>>> the >>>>>> case >>>>>> where >>>>>> a >>>>>> single >>>>>> AS >>>>>> supports >>>>>> both >>>>>> mTLS >>>>>> and >>>>>> non-mTLS? >>>>>> >>>>>> -- >>>>>> >>>>>> Annabelle >>>>>> Richard >>>>>> Backman >>>>>> >>>>>> AWS >>>>>> Identity >>>>>> >>>>>> *From:* >>>>>> OAuth >>>>>> >>>>> > >>>>>> on >>>>>> behalf >>>>>> of >>>>>> Brian >>>>>> Campbell >>>>>> >>>>> > >>>>>> *Date:* >>>>>> Friday, >>>>>> February >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 1:31 >>>>>> PM >>>>>> *To:* >>>>>> George >>>>>> Fletcher >>>>>> >>>>> > >>>>>> *Cc:* >>>>>> oauth >>>>>> >>>>> > >>>>>> *Subject:* >>>>>> Re: >>>>>> [OAUTH-WG] >>>>>> MTLS >>>>>> and >>>>>> in-browser >>>>>> clients >>>>>> using >>>>>> the >>>>>> token >>>>>> endpoint >>>>>> >>>>>> Yes, >>>>>> that >>>>>> would >>>>>> work. >>>>>> >>>>>> >>>>>> On >>>>>> Fri, >>>>>> Feb >>>>>> 1, >>>>>> 2019 >>>>>> at >>>>>> 2:28 >>>>>> PM >>>>>> George >>>>>> Fletcher >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> What >>>>>> if >>>>>> the >>>>>> AS >>>>>> wants >>>>>> to >>>>>> ONLY >>>>>> support >>>>>> MTLS >>>>>> connections. >>>>>> Does >>>>>> it >>>>>> not >>>>>> specify >>>>>> the >>>>>> optional >>>>>> "mtls_endpoints" >>>>>> and >>>>>> just >>>>>> use >>>>>> the >>>>>> normal >>>>>> metadata >>>>>> values? >>>>>> >>>>>> On >>>>>> 1/15/19 >>>>>> 8:48 >>>>>> AM, >>>>>> Brian >>>>>> Campbell >>>>>> wrote: >>>>>> >>>>>> It >>>>>> would >>>>>> definitely >>>>>> be >>>>>> optional, >>>>>> apologies >>>>>> if >>>>>> that >>>>>> wasn't >>>>>> made >>>>>> clear.. >>>>>> It'd >>>>>> be >>>>>> something >>>>>> to >>>>>> the >>>>>> effect >>>>>> of >>>>>> optional >>>>>> for >>>>>> the >>>>>> AS >>>>>> to >>>>>> include >>>>>> and >>>>>> clients >>>>>> doing >>>>>> MTLS >>>>>> would >>>>>> use >>>>>> it >>>>>> when >>>>>> present >>>>>> in >>>>>> AS >>>>>> metadata. >>>>>> >>>>>> On >>>>>> Tue, >>>>>> Jan >>>>>> 15, >>>>>> 2019 >>>>>> at >>>>>> 2:04 >>>>>> AM >>>>>> Dave >>>>>> Tonge >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> I'm >>>>>> in >>>>>> favour >>>>>> of >>>>>> the >>>>>> `mtls_endpoints` >>>>>> metadata >>>>>> parameter >>>>>> - >>>>>> although >>>>>> it >>>>>> should >>>>>> be >>>>>> optional. >>>>>> >>>>>> >>>>>> /CONFIDENTIALITY >>>>>> NOTICE: >>>>>> This >>>>>> email >>>>>> may >>>>>> contain >>>>>> confidential >>>>>> and >>>>>> privileged >>>>>> material >>>>>> for >>>>>> the >>>>>> sole >>>>>> use >>>>>> of >>>>>> the >>>>>> intended >>>>>> recipient(s). >>>>>> Any >>>>>> review, >>>>>> use, >>>>>> distribution >>>>>> or >>>>>> disclosure >>>>>> by >>>>>> others >>>>>> is >>>>>> strictly >>>>>> prohibited.. >>>>>> If >>>>>> you >>>>>> have >>>>>> received >>>>>> this >>>>>> communication >>>>>> in >>>>>> error, >>>>>> please >>>>>> notify >>>>>> the >>>>>> sender >>>>>> immediately >>>>>> by >>>>>> e-mail >>>>>> and >>>>>> delete >>>>>> the >>>>>> message >>>>>> and >>>>>> any >>>>>> file >>>>>> attachments >>>>>> from >>>>>> your >>>>>> computer. >>>>>> Thank >>>>>> you./ >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> OAuth mailing list >>>>>> >>>>>> OAuth@ietf.org >>>>>> >>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY >>>>>> NOTICE: >>>>>> This >>>>>> email >>>>>> may >>>>>> contain >>>>>> confidential >>>>>> and >>>>>> privileged >>>>>> material >>>>>> for >>>>>> the >>>>>> sole >>>>>> use >>>>>> of >>>>>> the >>>>>> intended >>>>>> recipient(s). >>>>>> Any >>>>>> review, >>>>>> use, >>>>>> distribution >>>>>> or >>>>>> disclosure >>>>>> by >>>>>> others >>>>>> is >>>>>> strictly >>>>>> prohibited.. >>>>>> If >>>>>> you >>>>>> have >>>>>> received >>>>>> this >>>>>> communication >>>>>> in >>>>>> error, >>>>>> please >>>>>> notify >>>>>> the >>>>>> sender >>>>>> immediately >>>>>> by >>>>>> e-mail >>>>>> and >>>>>> delete >>>>>> the >>>>>> message >>>>>> and >>>>>> any >>>>>> file >>>>>> attachments >>>>>> from >>>>>> your >>>>>> computer. >>>>>> Thank >>>>>> you./* >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY >>>>>> NOTICE: >>>>>> This >>>>>> email >>>>>> may >>>>>> contain >>>>>> confidential >>>>>> and >>>>>> privileged >>>>>> material >>>>>> for >>>>>> the >>>>>> sole >>>>>> use >>>>>> of >>>>>> the >>>>>> intended >>>>>> recipient(s). >>>>>> Any >>>>>> review, >>>>>> use, >>>>>> distribution >>>>>> or >>>>>> disclosure >>>>>> by >>>>>> others >>>>>> is >>>>>> strictly >>>>>> prohibited.. >>>>>> If >>>>>> you >>>>>> have >>>>>> received >>>>>> this >>>>>> communication >>>>>> in >>>>>> error, >>>>>> please >>>>>> notify >>>>>> the >>>>>> sender >>>>>> immediately >>>>>> by >>>>>> e-mail >>>>>> and >>>>>> delete >>>>>> the >>>>>> message >>>>>> and >>>>>> any >>>>>> file >>>>>> attachments >>>>>> from >>>>>> your >>>>>> computer. >>>>>> Thank >>>>>> you./* >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY >>>>>> NOTICE: >>>>>> This >>>>>> email may >>>>>> contain >>>>>> confidential >>>>>> and >>>>>> privileged >>>>>> material >>>>>> for the >>>>>> sole use >>>>>> of the >>>>>> intended >>>>>> recipient(s). >>>>>> Any >>>>>> review, >>>>>> use, >>>>>> distribution >>>>>> or >>>>>> disclosure >>>>>> by others >>>>>> is >>>>>> strictly >>>>>> prohibited.. >>>>>> If you >>>>>> have >>>>>> received >>>>>> this >>>>>> communication >>>>>> in error, >>>>>> please >>>>>> notify >>>>>> the >>>>>> sender >>>>>> immediately >>>>>> by e-mail >>>>>> and >>>>>> delete >>>>>> the >>>>>> message >>>>>> and any >>>>>> file >>>>>> attachments >>>>>> from your >>>>>> computer. >>>>>> Thank you./* >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY >>>>>> NOTICE: This email >>>>>> may contain >>>>>> confidential and >>>>>> privileged material >>>>>> for the sole use of >>>>>> the intended >>>>>> recipient(s). Any >>>>>> review, use, >>>>>> distribution or >>>>>> disclosure by others >>>>>> is strictly >>>>>> prohibited. If you >>>>>> have received this >>>>>> communication in >>>>>> error, please notify >>>>>> the sender >>>>>> immediately by e-mail >>>>>> and delete the >>>>>> message and any file >>>>>> attachments from your >>>>>> computer. Thank you./* >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY NOTICE: >>>>>> This email may contain >>>>>> confidential and >>>>>> privileged material for >>>>>> the sole use of the >>>>>> intended recipient(s). >>>>>> Any review, use, >>>>>> distribution or >>>>>> disclosure by others is >>>>>> strictly prohibited.. If >>>>>> you have received this >>>>>> communication in error, >>>>>> please notify the sender >>>>>> immediately by e-mail and >>>>>> delete the message and >>>>>> any file attachments from >>>>>> your computer. Thank >>>>>> you./* >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY NOTICE: This >>>>>> email may contain confidential >>>>>> and privileged material for the >>>>>> sole use of the intended >>>>>> recipient(s). Any review, use, >>>>>> distribution or disclosure by >>>>>> others is strictly prohibited. If >>>>>> you have received this >>>>>> communication in error, please >>>>>> notify the sender immediately by >>>>>> e-mail and delete the message and >>>>>> any file attachments from your >>>>>> computer. Thank you./* >>>>>> >>>>>> >>>>>> */CONFIDENTIALITY NOTICE: This email may >>>>>> contain confidential and privileged >>>>>> material for the sole use of the intended >>>>>> recipient(s). Any review, use, >>>>>> distribution or disclosure by others is >>>>>> strictly prohibited.. If you have >>>>>> received this communication in error, >>>>>> please notify the sender immediately by >>>>>> e-mail and delete the message and any >>>>>> file attachments from your computer. >>>>>> Thank you./* >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> /CONFIDENTIALITY NOTICE: This email may contain >>>> confidential and privileged material for the sole use of >>>> the intended recipient(s). Any review, use, distribution or >>>> disclosure by others is strictly prohibited..  If you have >>>> received this communication in error, please notify the >>>> sender immediately by e-mail and delete the message and any >>>> file attachments from your computer. Thank you./ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> > --------------A39F94B206E6977698EED011 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit If I understand correctly, then as the AS I could require MTLS on the revocation and introspection endpoints and so NOT put them in the mtls_endpoints section as long as the "...supported_methods" claim says those endpoints support MTLS. However for the token endpoint the AS wants to support both MTLS and non-MTLS so it ONLY adds the token endpoint into the 'mtls_endpoints' section.

For me this just makes the solution even more complex. I still argue that having the MTLS definition of the AS and the non-MTLS definition of the AS is simpler for both the operator and the client to understand.

On 2/15/19 3:00 PM, Filip Skokan wrote:
I'd say the evaluation should be on a per-endpoint basis, so presence of a different endpoint in mtls_endpoint does not affect the client's decision on using mtls on a regular endpoint given the auth methods for it also include mtls.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:57, George Fletcher <gffletch@aol.com> wrote:
Just to make sure I understand...

If the AS ONLY supports MTLS endpoints, then it...
   * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'
   * does NOT specify the mlts_endpoints section

If the AS does NOT support MTLS endpoints, then it...
    * does NOT specify a value of 'tls_client_auth' in the 'token_endpoint_auth_methods_supported'
    * does NOT specify the mlts_endpoints section

If the AS supports BOTH "regular" and MTLS endpoints, then it...
    * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic tls_client_auth" (as an example)
    * specifies mtls_endpoints in addition to the endpoints normally defined for the AS

For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS.

Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it assume that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object?

It will work, though it still feels "hacky" and overly complex.

Thanks,
George

On 2/15/19 2:42 PM, Phil Hunt wrote:
This is what I would expect. 

Phil

On Feb 15, 2019, at 11:32 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Hello George,

What do you think about what i wrote earlier?

clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:
I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.  

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect. 

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this. 

This may be a sign we need more implementation data (including from tls wg) to make the right call. 

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers 
———
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn’t exist before.

 

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that’s just my experience as, you know, an actual developer.

 

Let’s keep the assumptions and snide remarks about others’ backgrounds off the list, please.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Dominick Baier <dbaier@leastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

 

I am for keeping it simple and not introducing another link to follow.

 

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

 

———

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

 

I gave `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.


S pozdravem,
Filip Skokan

 

 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the “straw man” format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a “JSON array containing a list of client authentication methods supported by this token endpoint.” If that array contains “tls_client_auth” and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It’s that line of thought that led me to suggest just pointing to an alternate document.

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.”

 

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the “mtls_alternate_metadata” route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Hi Annabelle,

 

can you elaborate what would be the violation / negative impact of usage of RFC8414?

 

As it already makes use of `signed_metadata` and this language is present ...

 

> Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.  If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

 

.... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

 

 

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

I’m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can’t adequately address it – and I’ll readily grant that we probably don’t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

 

Along those lines, instead of adding an “mtls_endpoints” metadata parameter, we could add an “mtls_alternate_metadata” parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the “either/or” semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO that’s a reasonable and pragmatic option.

 

Thanks

———

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A straw-man example might look like this

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    "token_endpoint":"https://mtls.example.com/token",
    "userinfo_endpoint":"https://mtls.example.com/userinfo",
    "revocation_endpoint":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

 

Our approach will be that we’ll offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using “mtls_token_endpoint”.

 

Thanks

———

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I’m referencing didn’t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the implicit grant type is supported.” So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Though I’ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint…good times. 😃

 

I don’t necessarily think an AS metadata property is wrong per se, but understand that you’re bolting a layer of flexibility onto a standard that wasn’t designed for that, and I don’t think the metadata proposal as it’s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it’s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I’m wrong) that we should punt it to a separate draft (e.g., “Authorization Server Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS’s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

 

Confusion from the client’s perspective:

  1. As far as I know, I’m a public client, and don’t know anything about mTLS, but the IT admins installed client certs in their users’ browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri..
  3. My AS metadata parser crashed because it didn’t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
  5. I don’t know what that “m” means, but they told me to use HTTPS, so I should use the one with “tls” in its name, right?

 

Yes, you can write normative text that answers most of these. But you’ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.  But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I’m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

AWS Identity

 

 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=40aol.com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

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

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

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


--------------A39F94B206E6977698EED011-- From nobody Fri Feb 15 12:32:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314A213106E for ; Fri, 15 Feb 2019 12:32:14 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk8ssT1dBe4p for ; Fri, 15 Feb 2019 12:32:05 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCC8131055 for ; Fri, 15 Feb 2019 12:32:04 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id h22so7480248wmb.0 for ; Fri, 15 Feb 2019 12:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4/Me9Jfrpsd6YiYA8Wj0tM/LfHj570Cbq/dhGHnKlOw=; b=EtnbUD9Q4vJbSAQQXliHVIh0Txt5/JGoVLbAKAoo9Tym9VNK5mE11CSTWAzD3nfEdF 2+rtkU6NX521Tul1VmktmVCVIXoplyL0qBUVfDzDasUfaMCsywEwtGzOmZjzak6zTbfn DS/YD4kNk5F8lEoWewRYoruLaGJAJ2YnP5wFk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4/Me9Jfrpsd6YiYA8Wj0tM/LfHj570Cbq/dhGHnKlOw=; b=bufCdPdf+5q6zmjMj4KaOLYEYC6dVJ5E4pMLhtJWhopNdIYNrJe135HJ80d7pSg40q FQMeklqFwChJsOBKRCRn8swe+B9D48YdkaylCSxPKVoobOhzEtBydLghguLEsFA7Q8NE 5MayckT6tMSRaqW1+nMDZeTwEbDvAkmvRSIPsJhHYk5km9RoG9V8Z+3Duzn1CUNPLwNa TFbfQnIE1yFeMZr7y3+5zSSh+EEmmaKaL19r9yAtQHbQRfTGaj4HHzkOaKtYPcfcK7Mc PkWu9wE8zB/irwuv4iw5oVzNvRYb5nEUzX/0538syhyLQoDdHcUkz0amt1Mg8tXHWTcX WarQ== X-Gm-Message-State: AHQUAuZHbZjdfIFyoWvffkc8KNPW4JpdSb6g4M5XzX5T6KLzA7JLDxJ8 HhoE5NWqPY9TfPylo9e8fj6o1Q== X-Google-Smtp-Source: AHgI3Ibt+13blNnZ7QicBfnK2LdnP1uesDrh7PehyMlfTRDMYfz5K0gkIq1G1qGBex8LGILf4hwvgw== X-Received: by 2002:a1c:5fc5:: with SMTP id t188mr3937221wmb.86.1550262722500; Fri, 15 Feb 2019 12:32:02 -0800 (PST) Received: from ?IPv6:2a01:4c8:9:4d58:5d1c:7c78:7ce0:542e? ([2a01:4c8:9:4d58:5d1c:7c78:7ce0:542e]) by smtp.gmail.com with ESMTPSA id a1sm4862659wrq.96.2019.02.15.12.32.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 12:32:00 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-35774E83-9C0B-4EB5-9D9B-AE2A40415E68 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Fri, 15 Feb 2019 20:31:59 +0000 Cc: Phil Hunt , Filip Skokan , oauth Content-Transfer-Encoding: 7bit Message-Id: <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com> References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <4027f7d3-bf02-b95! 7-c169-b7842e5afe88@aol.com> To: George Fletcher Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 20:32:14 -0000 --Apple-Mail-35774E83-9C0B-4EB5-9D9B-AE2A40415E68 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As another case - if the client wants certificate-bound access tokens but st= ill authenticates with client_secret_basic or is a public client (as per [1]= ), presumably it can use the mtls-specific endpoints and assume they support= all the other authentication methods as the normal endpoints? But so long as we can define some half-sensible behaviour for these cases, I= =E2=80=99m happy with this proposal.=20 [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-12#section-4.3 > On 15 Feb 2019, at 19:57, George Fletcher wrote: >=20 > Just to make sure I understand... >=20 > If the AS ONLY supports MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth' > * does NOT specify the mlts_endpoints section >=20 > If the AS does NOT support MTLS endpoints, then it... > * does NOT specify a value of 'tls_client_auth' in the 'token_endpoint= _auth_methods_supported' > * does NOT specify the mlts_endpoints section >=20 > If the AS supports BOTH "regular" and MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic= tls_client_auth" (as an example) > * specifies mtls_endpoints in addition to the endpoints normally defin= ed for the AS >=20 > For the client, if it supports mtls AND if it finds 'tls_client_auth' in t= he 'token_endpoint_auth_methods_supported' then it first looks to see if an m= tls_endpoints object is provided and if so uses those endpoints, otherwise i= t assumes the RFC 8414 defined endpoints support MLTS. >=20 > Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but no= t an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'in= trospection_endpoint', is the client supposed to assume the introspection en= dpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoint= s' object? or should it assume that endpoint does NOT support MTLS becau= se it's not part of the 'mtls_endpoints' object? >=20 > It will work, though it still feels "hacky" and overly complex. >=20 > Thanks, > George >=20 >> On 2/15/19 2:42 PM, Phil Hunt wrote: >> This is what I would expect.=20 >>=20 >> Phil >>=20 >> On Feb 15, 2019, at 11:32 AM, Filip Skokan wrote: >>=20 >>> Hello George, >>>=20 >>> What do you think about what i wrote earlier? >>>=20 >>>> clients not having mtls capabilities won't care about the additional me= thod members being present. Clients that do implement mtls by the specificat= ion will know to look for mtls_endpoints and fall back to regular ones if th= e specific endpoint or mtls_endpoints root property is not present. >>>=20 >>> S pozdravem, >>> Filip Skokan >>>=20 >>>=20 >>>> On Fri, 15 Feb 2019 at 20:29, George Fletcher wrote: >>>> I still don't see how we solve one of the use cases Annabelle brought u= p. >>>>=20 >>>> If the 'mtls_endpoints' object just contains endpoints, then in the mai= n meta-data section, should 'token_endpoint_auth_methods_supported' include a= n indication of 'tls_client_auth' even though the endpoint specified by 'tok= en_endpoint' does NOT support MTLS? >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>>> On 2/14/19 6:08 PM, Brian Campbell wrote: >>>>> Maybe I'm wrong here (it's never out of the question) but based on thi= s previous message and this one I believe that actually you are both in favo= r (generally anyway) of the proposal with the optional "mtls_endpoints" para= meter. While I believe that the comment about optionality and complexity was= meant to be a more general remark. While I can certainly appreciate a desir= e to keep things simple, I do regret that this thread took a turn towards pe= rsonal. Whether it was the intent or not, there's an impact.=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt wro= te: >>>>>> I feel I have to disagree. I agree that optionality is often complex= ity and should be avoided. But, I think the optionality here is an agility f= eature allowing mtls to work across a diversified market of different types o= f tls terminators with varying capability. Lack of appropriate discovery/opt= ions could serve to make the spec unusable in many cases. =20 >>>>>>=20 >>>>>> A complicating factor with tls is that a tls layer failure prevents t= he AS from issuing a correcting directive like an http error or http redirec= t.=20 >>>>>>=20 >>>>>> We have to be sure not to break existing clients so we may in some ca= ses need mtls only endpoints. I am not far enough along to know for sure. Bu= t I tend to agree with Brian on this.=20 >>>>>>=20 >>>>>> This may be a sign we need more implementation data (including from t= ls wg) to make the right call.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier wrote: >>>>>>=20 >>>>>>> Sorry - this was not meant to be snide at all. >>>>>>>=20 >>>>>>> It was honest feedback that you also need to keep software complexit= y in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR= that, or send values in arbitrary order adds to complexity. Complexity is t= he natural enemy of security. >>>>>>>=20 >>>>>>> Cheers=20 >>>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>> Dominick >>>>>>>=20 >>>>>>>> On 13. February 2019 at 20:39:16, Richard = Backman, Annabelle (richanna@amazon.com) wrote: >>>>>>>>=20 >>>>>>>> The issue is that the proposal violates the standard by changing th= e semantics of a parameter it defines. We should be very, very, VERY careful= about telling implementers to violate an existing standard... This change m= ight prove incompatible with existing or future implementations of 8414, it m= ight not, but by violating the standard the proposal creates an opportunity f= or incompatibility that didn=E2=80=99t exist before. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> As far as simplicity is concerned, I find a solution that reuses th= e existing data model and naturally supports existing and future extensions t= o be far simpler than one that introduces ambiguous semantics to existing pa= rameters. Generally speaking, data models with properties that mean differen= t things in different contexts tend to be fragile and require more complex c= ode to work with. But that=E2=80=99s just my experience as, you know, an act= ual developer. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Let=E2=80=99s keep the assumptions and snide remarks about others=E2= =80=99 backgrounds off the list, please. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: Dominick Baier >>>>>>>> Date: Wednesday, February 13, 2019 at 4:18 AM >>>>>>>> To: "Richard Backman, Annabelle" , Filip Skoka= n >>>>>>>> Cc: Brian Campbell , "Richard Backman, A= nnabelle" , oauth >>>>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & di= scovery >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I am for keeping it simple and not introducing another link to foll= ow. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I sometimes wonder how many of the spec authors are actually develo= pers - these suggestions make software unnecessary complex ;) >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>>>=20 >>>>>>>> Dominick >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com)= wrote: >>>>>>>>=20 >>>>>>>> Hello, >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Additionally, a metadata document that omits token_endpoint in favo= r of mtls_endpoints since only mTLS is supported would violate 8414, as 8414= says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant typ= e is supported.=E2=80=9D >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> mtls only AS doesn't get anything out of using mtls_endpoints, its u= se should not be recommended for such AS and regular = endpoints will be used, this satisfies the requir= ement >>>>>>>>=20 >>>>>>>> Here is one example, based on my understanding of the =E2=80=9Cstra= w man=E2=80=9D format pr= esented in this thread: RFC8414 defines the value of token_endpoint_auth_met= hods_supported as a =E2=80=9CJSON array containing a list of client authenti= cation methods supported by this token endpoint.=E2=80=9D If that array cont= ains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified in token_e= ndpoint does not support mTLS, then that metadata violates 8414. You could a= ddress this by adding a token_endpoint_auth_methods_supported parameter to t= he mtls_endpoints object, and likewise for the other endpoints and auth meth= ods. If you take that to its logical conclusion, you end up with a complete m= etadata document hanging off of mtls_endpoints. It=E2=80=99s that line of th= ought that led me to suggest just pointing to an alternate document. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Assuming we go with using the same root = auth methods property, what's the issue? Clients not h= aving mtls capabilities won't care about the additional method members being= present. Clients that do implement mtls by the specification will know to l= ook for mtls_endpoints and fall back to regular ones if the specific endpoin= t or mtls_endpoints root property is not present. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I gave `mtls_alternate_metadata` route a thought and don't see how i= t helps, given the two above are non-issues (my $.02) another discovery docu= ment only brings more of them since every property can now be different, not= just the endpoints. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> S pozdravem, >>>>>>>> Filip Skokan >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle wrote: >>>>>>>>=20 >>>>>>>> Here is one example, based on my understanding of the =E2=80=9Cstra= w man=E2=80=9D format = presented in this thread: RFC8414 defines the value of token_endpoint_au= th_methods_supported as a =E2=80=9CJSON array containing a list of client au= thentication methods supported by this token endpoint.=E2=80=9D If that arra= y contains =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified in t= oken_endpoint does not support mTLS, then that metadata violates 8414. You c= ould address this by adding a token_endpoint_auth_methods_supported paramete= r to the mtls_endpoints object, and likewise for the other endpoints and aut= h methods. If you take that to its logical conclusion, you end up with a com= plete metadata document hanging off of mtls_endpoints. It=E2=80=99s that lin= e of thought that led me to suggest just pointing to an alternate document. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Additionally, a metadata document that omits token_endpoint in favo= r of mtls_endpoints since only mTLS is supported would violate 8414, as 8414= says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant typ= e is supported.=E2=80=9D >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> It is possible to define the mtls_endpoints parameter such that the= above use cases are invalid, but that does make the document more complicat= ed.. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can sk= ip past all of these issues, because it brings us back to just parsing the s= ame metadata that we do today. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth on behalf of Filip Skokan >>>>>>>> Date: Tuesday, February 12, 2019 at 1:13 PM >>>>>>>> To: "Richard Backman, Annabelle" >>>>>>>> Cc: Brian Campbell ,= oauth >>>>>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Hi Annabelle, >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> can you elaborate what would be the violation / negative impact of u= sage of RFC8414? >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> As it already makes use of `signed_metadata` and this language is p= resent ... >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> > Consumers of the metadata MAY ignore the signed metadata if they d= o not support this= feature. If the consumer of the metadata supports signed metadata, = metadata values conveyed i= n the signed metadata MUST take precedence over the corresponding values con= veyed using plain JSON elements. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> .... would mtls_endpoints be any different? Clients are free to ign= ore this if they don't support/use mtls, and if they do those values must ta= ke precedence over the root ones. the use of mtls_endpoints would not be rec= ommended for mtls-only AS but recommended for one with both mtls/regular aut= hentication methods. token_endpoint remains required for all intents and pur= poses. And as for the usable client authentication methods - they should all= be listed, or do you think we should separate the ones for each hostname/po= rt location? To what end? Is there a risk having the mtls hostname/port acce= pting regular requests? Other then secret/key _jwt auth methods assertion au= d claim the endpoint location doesn't play a role in the authentication proc= ess. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best, >>>>>>>> Filip >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle wrote: >>>>>>>>=20 >>>>>>>> I=E2=80=99m not opposed to introducing a metadata change, if the sc= enario is relevant and other approaches can=E2=80=99t adequately address it =E2= =80=93 and I=E2=80=99ll readily grant that we probably don=E2=80=99t want to= depend on consistency of browser behavior at the intersection of client cer= tificates and Access-Control-Allow-Credentials. But care needs to be taken i= n designing that metadata to avoid violating or otherwise negatively impacti= ng usage of RFC8414. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80= =9D metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2=80= =9D parameter whose value is the URL of an alternate metadata document inten= ded for clients using mTLS. An mTLS-optional AS could have two different met= adata documents for mTLS and non-mTLS clients, reducing the mTLS-optional sc= enario to the mTLS-only scenario. This sidesteps the challenges of aligning t= he =E2=80=9Ceither/or=E2=80=9D = semantics of mTLS-optional with some of the rigid parameter def= initions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_suppor= ted). >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth on behalf of Brian Campbell >>>>>>>> Date: Tuesday, February 12, 2019 at 10:58 = AM >>>>>>>> To: Dominick Baier >>>>>>>> Cc: oauth >>>>>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Thanks for the input, Dominick. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I'd said previously that I was having trouble adequately gauging wh= ether or not there's sufficient consensus to go ahead with the update. I was= even thinking of asking the chairs about a consensus call during the office= hours meeting yesterday. But it got canceled. And looking again back over t= he discussion, I don't believe a consensus call is necessary. There's been a= lot of general discussion over the last several weeks during which several f= olks have stated support for the proposal while there's been only one voice o= f direct dissent. That seems like rough enough consensus and, as such, I pla= n to make the change in the next revision of the document (which should be d= one soon). Chairs,= please let me know, if you believe the situation warrants a different = course of action. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier wrote: >>>>>>>>=20 >>>>>>>> IMHO that=E2=80=99s a reasonable and pragmatic option. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>>=20 >>>>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>>>=20 >>>>>>>> Dominick >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingide= ntity.com) wrote: >>>>>>>>=20 >>>>>>>> It's been pointed out that the potential issue is not isolated to t= he just token endpoint but that revocation, introspection, etc. could be imp= acted as well. So, at this point, the proposal on the table is to add a new= optional AS metadata parameter named 'mtls_endpoints' that's value we be a J= SON object which itself contains endpoints that, when present, a client doin= g MTLS would use rather than the regular endpoints. A straw-man example mig= ht look like this >>>>>>>>=20 >>>>>>>> { >>>>>>>> "issuer":"https://server.example.com", >>>>>>>> "authorization_endpoint":"https://server.example.com/authz", >>>>>>>> "token_endpoint":"https://server.example.com/token", >>>>>>>> "token_endpoint_auth_methods_supported":[ "client_secret_basic",= "tls_client_auth", "none"], >>>>>>>> "userinfo_endpoint":"https://server.example.com/userinfo", >>>>>>>> "revocation_endpoint":"https://server.example.com/revo", >>>>>>>> "jwks_uri":"https://server.example.com/jwks.json", >>>>>>>> "mtls_endpoints":{ >>>>>>>> "token_endpoint":"https://mtls.example.com/token", >>>>>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo", >>>>>>>> "revocation_endpoint":"https://mtls.example.com/revo" >>>>>>>> } >>>>>>>> } >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> A client doing MTLS would look for and = give precedence to an endpoint under "mtls_end= points" while falling back to use the normal endpoint from the top level of m= etadata when/if its not in "mtls_endpoints". >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The idea being that "regular" clients (those not doing MTLS) will u= se the regular endpoints. And only the host/port of the endpoints listed in m= tls_endpoints will be set up to request TLS client certificates during hands= hake. Thus any potential impact of the CertificateRequest message being sent= in the TLS handshake can be avoided for all the other regular clients that a= re not going to do MTLS - including and most importantly in-browser javascri= pt clients where there can be less than desirable UI presented to the end-us= er. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I'm struggling, however, to adequately gauge whether or not there's= sufficient consen= sus to go ahead with the update. There's been some support for it voiced. As= well as talk of other approaches that could be alternatives or additional m= easures. And also some vocal opposition to it.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: >>>>>>>>=20 >>>>>>>> We are currently implementing MTLS in IdentityServer. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Our approach will be that we=E2=80=99ll offer a separate token endp= oint that supports client certs. Are you planning on adding an official endp= oint name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint= =E2=80=9D. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>>=20 >>>>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>>>=20 >>>>>>>> Dominick >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40ping= identity.com@dmarc.ietf.org) wrote: >>>>>>>>=20 >>>>>>>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a= good reminder that even a seemingly innocuous change that should be backwar= ds compatible can break things unexpectedly.. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle wrote: >>>>>>>>=20 >>>>>>>> The case I=E2=80=99m referencing didn=E2=80=99t specifically involv= e AS metadata. We had clients in the wild that assumed that all the properti= es in the JSON object returned from our userinfo endpoint were scalar string= s. This broke when we introduced a new property whose value was a JSON objec= t. It was a good reminder that even a seemingly innocuous change that should= be backwards compatible can force more work on clients than we expect. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: Brian Campbell >>>>>>>> Date: Wednesday, February 6, 2019 at 11:30 AM >>>>>>>> To: "Richard Backman, Annabelle" >>>>>>>> Cc: "Richard Backman, Annabelle" , oauth >>>>>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser= clients using the token endpoint >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> And I'm honestly really struggling to see what could have gone wron= g with or how token_endpoint_auth_methods broke something with the user info= endpoint. If you have the time and/or it'd be informative to this here litt= le discussion, please explain that one a bit more. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell wrote: >>>>>>>>=20 >>>>>>>> "far" should have said "fair" in the previous message >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell wrote: >>>>>>>>=20 >>>>>>>> It may well be due to my own intellectual shortcomings but these = issues/questions/con= fusion-points are not resonating for me as being problematic. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> The more general stance of "this isn't needed or worth it in this d= ocument" (I think that's far?) is being heard though. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle wrote: >>>>>>>>=20 >>>>>>>> (TL;DR: punt AS metadata to a separate draft) >>>>>>>>=20 >>>>>>>> AS points #1-3 are all questions I would have as an implementer: >>>>>>>>=20 >>>>>>>> Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unles= s only the implicit grant type is supported.=E2=80=9D So what does the mTLS-= only AS put here? >>>>>>>> The claims for these other endpoints are OPTIONAL, potentially lead= ing to inconsistency depending on how #1 gets decided. >>>>>>>> The example usage of the token_endpoint_auth_methods property given= earlier is incompatible with RFC8414, since some of its contents are only v= alid for the non-mTLS endpoints, and others are only valid for the mTLS endp= oints. Hence this question. >>>>>>>> This introduces a new metadata property that could impact how other= specs should extend AS metadata. That needs to be addressed. >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I could go on for client points but you already get the point. Thou= gh I=E2=80=99ll share that #3 is real and once forced me to roll back an upd= ate to the Login w= ith Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I don=E2=80=99t necessarily think an AS metadata property is wrong p= er se, but understand that you=E2=80=99re bolting a layer of flexibility ont= o a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t thin= k the metadata proposal as it=E2=80=99s been discussed here sufficiently dea= ls with the fallout from that. In my view this is a complex enough issue and= it=E2=80=99s for a nuanced enough use case (as far as I can tell from discu= ssion? Please correct me if I=E2=80=99m wrong) that we should punt it to a s= eparate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for m= TLS Hybrids=E2=80=9D) and get mTLS out the door. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth on behalf of Brian Campbell >>>>>>>> Date: Monday, February 4, 2019 at 5:28 AM >>>>>>>> To: "Richard Backman, Annabelle" >>>>>>>> Cc: oauth >>>>>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser= clients using the token endpoint >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Those points of confusion strike me as somewhat hypothetical or hyp= erbolic. But your general point is taken and your position of being anti add= itional metadata on this issue is noted. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> All of which leaves me a bit uncertain about how to proceed. There s= eem to be a range of opinions on this point and gauging consensus is proving= elusive for me. That's confounded by my own opinion on it being somewhat fl= uid. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> And I'd really like to post an update to this draft about a month o= r two ago. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle wrote: >>>>>>>>=20 >>>>>>>> Confusion from the AS=E2=80=99s perspective: >>>>>>>>=20 >>>>>>>> If I only support mTLS, do I need to include both token_endpoint_ur= i and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the emp= ty string? >>>>>>>> What if I only support mTLS for the token endpoint, but not revocat= ion or user info? >>>>>>>> How do I specify authentication methods for the mTLS token endpoint= ? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpo= ints? >>>>>>>> I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled device_authorization_endpoint under mtls_endpoints? >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Confusion from the client=E2=80=99s perspective: >>>>>>>>=20 >>>>>>>> As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything about mTLS, but the IT admins installed client certs in their us= ers=E2=80=99 browsers and the AS expects to use that to authenticate me. >>>>>>>> My AS metadata parser crashed because the mTLS-only AS omitted toke= n_endpoint_uri.. >>>>>>>> My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter a JSON object as a parameter value. >>>>>>>> The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do I do? >>>>>>>> I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they t= old me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in i= ts name, right? >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Yes, you can write normative text that answers most of these. But y= ou=E2=80=99ll have to clearly cover a lot of = similar-but-slightly-different scenarios and be v= ery explicit. And implementers will still get it wrong. The metadata change i= ntroduces opportunities for confusion and failure that do not exist now, and= forces them on everyone who supports mTLS. In contrast, the 307 redirect is= only required when an AS wants to support both, and is unambiguous in its b= ehavior and meaning. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: Brian Campbell >>>>>>>> Date: Friday, February 1, 2019 at 3:17 PM >>>>>>>> To: "Richard Backman, Annabelle" >>>>>>>> Cc: George Fletcher , oauth >>>>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser cli= ents using the token endpoint >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> It doesn't seem like that confusing or large of a change to me - if= the client is doing MTLS and the given endpoint is present in `mtls_endpoin= ts`, then it uses that one. Otherwise it uses the regular endpoint. It give= s an AS a lot of flexibility in deployment options. I personally think getti= ng a 307 approach deployed and working would be more complicated and error p= rone.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> It is a minority use case at the moment but there are forces in pla= y, like the push for increased security in general and to have javascript cl= ients use the code flow, that suggest it won't be terribly unusual to see an= AS that wants to support MTLS clients and javascript/spa clients at the sam= e time. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I've personally wavered back and forth in this thread on whether or= not to add the new metadata (or something like it). With my reasoning each w= ay kinda explained somewhere back in the 40 or so messages that make up this= thread. But it seems like the rough consensus of the group here is in favo= r of it. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle wrote: >>>>>>>>=20 >>>>>>>> This strikes me as a very prominent and confusing change to support= what seems to be a minority use case. I=E2=80=99m getting a headache just t= hinking about the text needed to clarify when the AS should provide `mtls_en= dpoints` and when the client should use that versus using `token_endpoint.` W= hy is the 307 status code insufficient to cover the case where a single AS s= upports both mTLS and non-mTLS? >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> AWS Identity >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth on behalf of Brian Campbell >>>>>>>> Date: Friday, February 1, 2019 at 1:31 PM >>>>>>>> To: George Fletcher >>>>>>>> Cc: oauth >>>>>>>> Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token= endpoint >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Yes, that would work.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote: >>>>>>>>=20 >>>>>>>> What if the AS wants to ONLY support MTLS connections. Does it not s= pecify the optional "mtls_endpoints" and just use the normal metadata values= ? >>>>>>>>=20 >>>>>>>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>>>>>>>=20 >>>>>>>> It would definitely be optional, apologies if that wasn't made clea= r.. It'd be something to the effect of optional for the AS to include and cl= ients doing MTLS would use it when present in AS = metadata. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge wrote: >>>>>>>>=20 >>>>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although= it should be optional. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended = recipient(s). Any review, use, distribution o= r disclosure by others is strictly prohibited.. If you have received this c= ommunication in error, please notify the sender immediately by = e-mail and delete the message a= nd any file attachments from your computer. Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf..org/mailman/listinfo/oauth >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you ha= ve received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file = attachments from your computer. Thank you. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution o= r disclosure by others is strictly prohibited.. If you have received this c= ommunication in error, please notify the sender immediately by e-mail and de= lete the message and any file attachments from your computer. Thank you. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you ha= ve received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your comput= er. Thank you. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited. If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you ha= ve received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your comput= er. Thank you. _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, = use, distribution o= r disclosure by others is strictly prohibited. If you have received this co= mmunication in error, please notify the sender immediately by e-mail and del= ete the message and any file attachments from your computer. Thank you. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited.. If you ha= ve received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your comput= er. Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________=20 >>>>>>>> OAuth mailing list=20 >>>>>>>> OAuth@ietf.org=20 >>>>>>>> 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 >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited.. If you have= received this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer.= Thank you.=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-35774E83-9C0B-4EB5-9D9B-AE2A40415E68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As a= nother case - if the client wants certificate-bound access tokens but still a= uthenticates with client_secret_basic or is a public client (as per [1]), pr= esumably it can use the mtls-specific endpoints and assume they support all t= he other authentication methods as the normal endpoints?

But so long as we can define some half-sensibl= e behaviour for these cases, I=E2=80=99m happy with this proposal. 


O= n 15 Feb 2019, at 19:57, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20 Just to make sure I understand...

If the AS ONLY supports MTLS endpoints, then it...
   * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'
   * does NOT specify the mlts_endpoints section

If the AS does NOT support MTLS endpoints, then it...
    * does NOT specify a value of 'tls_client_auth' in th= e 'token_endpoint_auth_methods_supported'
    * does NOT specify the mlts_endpoints section

If the AS supports BOTH "regular" and MTLS endpoints, then it...
    * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic tls_client_auth" (as an example)
    * specifies mtls_endpoints in addition to the endpoin= ts normally defined for the AS

For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS.

Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it assume that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object?

It will work, though it still feels "hacky" and overly complex.

Thanks,
George

On 2/15/19 2:42 PM, Phil Hunt wrote:
This is what I would expect. 

Phil

On Feb 15, 2019, at 11:32 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Hello George,

What do you think about what i wrote earlier?

clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>= ; wrote:
I still don't see how we solve one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

O= n 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general = remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle= .com> wrote:
I feel I have to disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.  

A complicating factor with tls is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect. 

We have to be sure not to break existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this. 

This may be a sign we need more implementation data (including from tls wg) to make the right call. 

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com>= ; wrote:

Sorry - this was not meant to be snide at all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers 
=E2=80=94=E2=80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.co= m) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn=E2=80=99= t exist before.

 

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that=E2=80=99s just my experience a= s, you know, an actual developer.

=

 

Let=E2=80=99s= keep the assumptions and snide remarks about others=E2=80=99 backgrounds off the list, please.

 

--&nb= sp;

Annab= elle Richard Backman

AWS Identity

 

 

From: Dominick Baier <dbaier@l= eastprivilege.com>
Date: Wednesday, February 13, 2019 at 4:18 AM
To: "Richard Backman, Annabelle" <= richanna@amazon.com>, Filip Skokan <panva.i= p@gmail.com>
Cc: Brian Campbell <bcampbell@pin= gidentity.com>, "Richard Backman, Annabelle" <richanna@= amazon.com>, oauth <oauth@ietf.org&= gt;
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

 

I am for keeping it simple and not introducing another link to follow.=

 

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

 

=E2=80=94=E2= =80=94=E2=80=94

Dominick<= /p>

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.= com) wrote:

Hel= lo,

 = ;

Add= itionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9C= is REQUIRED unless only the implicit grant type is supported.=E2=80= =9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Her= e is one example, based on my understanding of the =E2=80=9Cstraw man=E2=80= =9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array containing a l= ist of client authentication methods supported by this token endpoint.=E2=80=9D If th= at array contains =E2=80=9Ctls_client_auth= =E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_auth_meth= ods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80= =99s that line of thought that led me to suggest just pointing to an alternate document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

&nb= sp;

I gave `mtls_alternate_metadata= ` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.

<= br clear=3D"all">

S pozdravem,
Filip Skokan

&= nbsp;

&nb= sp;

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <= richanna@amazon.com> wrote:

Here is one example, based on my understanding of the =E2=80=9Cst= raw man=E2=80=9D forma= t presented in this thread: RFC8414 defines the value of token_endpoint_aut= h_methods_supported as a =E2=80=9CJSON= array containing a list of client authentication methods supported by this token endpoint.=E2=80=9D= If that array contains =E2=80=9Ctls_clien= t_auth=E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a token_endpoint_aut= h_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest jus= t pointing to an alternate document.

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis REQUIR= ED unless only the implicit grant type is supported.=E2=80=9D=

 

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the =E2=80=9Cmtls_alte= rnate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth= -bounces@ietf.org> on behalf of Filip Skokan <panva.ip@= gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>, oauth <oauth@iet= f..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Hi Annabelle,

 

can you elaborate what would be the violation / negative impact of usage of RFC8414?

 

As it already makes use of `signed_metadata` and this language is present ...

 

> Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.  If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

 

.... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.


Best,
Filip

 

 

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

I=E2=80=99m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can=E2=80=99t adequately address it =E2=80=93= and I=E2=80=99ll readily grant that we probably don=E2=80= =99t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of RFC8414.

 

Along those lines, instead of adding an =E2=80=9Cmtls_endp= oints=E2=80=9D metadata parameter, we could add an =E2=80=9Cmtls_alte= rnate_metadata=E2=80=9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the =E2=80=9Ceither/or= =E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth= -bounces@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <db= aier@leastprivilege.com>
Cc: oauth <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery

 

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 

 

 

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO that=E2=80=99= s a reasonable and pragmatic option.

=

 

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcam= pbell@pingidentity.com) wrote:

It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,  at= this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.  A= straw-man example might look like this

=

{
  "issuer":"<= a href=3D"https://server.example.com" target=3D"_blank" moz-do-not-send=3D"t= rue">https://server.example.com",
  "authorization_end= point":"https://server.example.com/authz",
  "token_endpoint":"= https://server.example.com/token",
  "token_endpoint_au= th_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint= ":"https://server.example.com/userinfo",
  "revocation_endpoi= nt":"https://server.example.com/revo",
  "jwks_uri":= "https://server.example.com/jwks.json",
  "mtls_en= dpoints":{
    "token_endpoint":"= https://mtls.example.com/token",
    "userinfo_endpoint= ":"https://mtls.example.com/userinfo",
    "revocation_endpoi= nt":"https://mtls.example.com/revo"
  }
}

 

A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints".<= /p>


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 

 

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

We are currently implementing MTLS in IdentityServer.

 

Our approach will b= e that we=E2=80=99ll offe= r a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_toke= n_endpoint=E2=80=9D.

 

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..

=

 

 

 

 

 

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: Brian Campbell <bcampbell@pingidentity..com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna= @amazon.com>, oauth <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_aut= h_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

"far" should have said "fair" in the previous message

 

 

 

 

 

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/c= onfusion-points are not resonating for me as being problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 

 

 

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8= 414 says token_endpoint =E2=80=9Cis REQUIR= ED unless only the implicit grant type is supported.=E2=80=9D= So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_aut= h_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

 

I could go on for client points but you already get the point. Though I=E2=80=99l= l share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6g= ood times. =F0=9F=98=83

 

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99r= e bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t thin= k the metadata proposal as it=E2=80=99s been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80= =99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthoriza= tion Server Metadata Extensions for mTLS Hybrids=E2=80= =9D) and get mTLS out the door.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth= -bounces@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

 

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two ago.

 

 

 

 

 

 

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99= s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri= and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorizati= on_endpoint under mtls_endpoints?

 

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a publ= ic client, and don=E2=80=99t know= anything about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri= ..
  3. My AS metadata parser crashed because it didn=E2=80=99t exp= ect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t pro= vide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know= what that =E2=80=9C= m=E2=80=9D means, but they told me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2= =80=9D in its name, right?

 

Yes, you can write normative text that answers most of these. But you=E2=80=99ll= have to clearly cover a lot of similar-but-slight= ly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna= @amazon.com>
Cc: George Fletcher <gf= fletch@aol.com>, oauth <oauth@iet= f.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread. = But it seems like the rough consensus of the group here is in favor of it.

 

 

 

 

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard Backman

=

AWS Identity

 

 

From: OAuth <oauth= -bounces@ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

 

Yes, that would work. 

 

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf..org> wrote:

What= if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" and just use the normal metadata values?

=

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <= dave.tonge@momentumft.co.uk> wrote:

I'm in f= avour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>

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

 


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i> _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>


CONFID= ENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. = If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /i>

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

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

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_=
______________________________________________
OAuth mailing list
OAuth@ietf.o=
rg
https://www.ietf.o=
rg/mailman/listinfo/oauth

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

=20
= --Apple-Mail-35774E83-9C0B-4EB5-9D9B-AE2A40415E68-- From nobody Fri Feb 15 22:30:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F970129C6A for ; Fri, 15 Feb 2019 22:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_-rGHbTtK9e for ; Fri, 15 Feb 2019 22:30:27 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id A07D11295D8 for ; Fri, 15 Feb 2019 22:30:26 -0800 (PST) Received: from [IPv6:2601:282:202:b210:f414:599b:2fff:a013] (unknown [IPv6:2601:282:202:b210:f414:599b:2fff:a013]) by alkaline-solutions.com (Postfix) with ESMTPSA id 2EC2831546; Sat, 16 Feb 2019 06:30:23 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_36995972-38BC-4541-864C-AE8469A6E3D9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Fri, 15 Feb 2019 23:30:22 -0700 In-Reply-To: Cc: Phil Hunt , Filip Skokan , oauth To: George Fletcher References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <4027f7d3-bf02-b95! 7-c169-b7842e5afe88@aol.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 06:30:34 -0000 --Apple-Mail=_36995972-38BC-4541-864C-AE8469A6E3D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As a potential simplification (and alternative to consider): What do people think of the idea that MTLS clients perform discovery of = a different suffix (as allowed by RFC 8414). A MTLS-enabled client would = first look up metadata at say = "/.well-known/mtls-oauth-authorization-server=E2=80=9D, falling back to = the =E2=80=9Coauth-authorization-server=E2=80=9D suffix if the = specialized suffix was not found. It would be expected this to be a full, legal discovery document, so = there is no merging nor cross-pollination of supported features of the = two. Should it not be found, such clients would then fall back to = /.well-known/oauth-authorization-server - with the same evaluation = rules. This also means that an AS that either uses MTLS only, is willing = to use optional client certificates/upgrading, uses HTTP redirects or = does not support MTLS would still publish a single discovery endpoint. The drawback to this approach is that there are multiple discovery = documents of the AS - but there are already multiple documents involved = - both additional metadata referenced such as a JWKS endpoint, and the = potential that implementations/specifications that extend OAuth (such as = OpenID Connect) have separate suffixes and discovery data. -DW > On Feb 15, 2019, at 12:57 PM, George Fletcher = wrote: >=20 > Just to make sure I understand... >=20 > If the AS ONLY supports MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth' > * does NOT specify the mlts_endpoints section >=20 > If the AS does NOT support MTLS endpoints, then it... > * does NOT specify a value of 'tls_client_auth' in the = 'token_endpoint_auth_methods_supported' > * does NOT specify the mlts_endpoints section >=20 > If the AS supports BOTH "regular" and MTLS endpoints, then it... > * sets 'token_endpoint_auth_methods_supported' to = "client_secret_basic tls_client_auth" (as an example) > * specifies mtls_endpoints in addition to the endpoints normally = defined for the AS >=20 > For the client, if it supports mtls AND if it finds 'tls_client_auth' = in the 'token_endpoint_auth_methods_supported' then it first looks to = see if an mtls_endpoints object is provided and if so uses those = endpoints, otherwise it assumes the RFC 8414 defined endpoints support = MLTS. >=20 > Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' = but not an 'introspection_endpoint' but the RFC 8414 meta-data does = specify an 'introspection_endpoint', is the client supposed to assume = the introspection endpoint also supports MTLS even though it wasn't = listed in the 'mtls_endpoints' object? or should it assume that endpoint = does NOT support MTLS because it's not part of the 'mtls_endpoints' = object? >=20 > It will work, though it still feels "hacky" and overly complex. >=20 > Thanks, > George >=20 > On 2/15/19 2:42 PM, Phil Hunt wrote: >> This is what I would expect.=20 >>=20 >> Phil >>=20 >> On Feb 15, 2019, at 11:32 AM, Filip Skokan > wrote: >>=20 >>> Hello George, >>>=20 >>> What do you think about what i wrote earlier? >>>=20 >>> clients not having mtls capabilities won't care about the additional = method members being present. Clients that do implement mtls by the = specification will know to look for mtls_endpoints and fall back to = regular ones if the specific endpoint or mtls_endpoints root property is = not present. >>>=20 >>> S pozdravem, >>> Filip Skokan >>>=20 >>>=20 >>> On Fri, 15 Feb 2019 at 20:29, George Fletcher = > = wrote: >>> I still don't see how we solve one of the use cases Annabelle = brought up. >>>=20 >>> If the 'mtls_endpoints' object just contains endpoints, then in the = main meta-data section, should 'token_endpoint_auth_methods_supported' = include an indication of 'tls_client_auth' even though the endpoint = specified by 'token_endpoint' does NOT support MTLS? >>>=20 >>> Thanks, >>> George >>>=20 >>> On 2/14/19 6:08 PM, Brian Campbell wrote: >>>> Maybe I'm wrong here (it's never out of the question) but based on = this previous message = and this one = I believe that actually you are = both in favor (generally anyway) of the proposal with the optional = "mtls_endpoints" parameter. While I believe that the comment about = optionality and complexity was meant to be a more general remark. While = I can certainly appreciate a desire to keep things simple, I do regret = that this thread took a turn towards personal. Whether it was the intent = or not, there's an impact.=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt > wrote: >>>> I feel I have to disagree. I agree that optionality is often = complexity and should be avoided. But, I think the optionality here is = an agility feature allowing mtls to work across a diversified market of = different types of tls terminators with varying capability. Lack of = appropriate discovery/options could serve to make the spec unusable in = many cases. =20 >>>>=20 >>>> A complicating factor with tls is that a tls layer failure prevents = the AS from issuing a correcting directive like an http error or http = redirect.=20 >>>>=20 >>>> We have to be sure not to break existing clients so we may in some = cases need mtls only endpoints. I am not far enough along to know for = sure. But I tend to agree with Brian on this.=20 >>>>=20 >>>> This may be a sign we need more implementation data (including from = tls wg) to make the right call.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier = > wrote: >>>>=20 >>>>> Sorry - this was not meant to be snide at all. >>>>>=20 >>>>> It was honest feedback that you also need to keep software = complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it = like this OR that, or send values in arbitrary order adds to complexity. = Complexity is the natural enemy of security. >>>>>=20 >>>>> Cheers=20 >>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>> Dominick >>>>>=20 >>>>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle = (richanna@amazon.com ) wrote: >>>>>=20 >>>>>> The issue is that the proposal violates the standard by changing = the semantics of a parameter it defines. We should be very, very, VERY = careful about telling implementers to violate an existing standard... = This change might prove incompatible with existing or future = implementations of 8414, it might not, but by violating the standard the = proposal creates an opportunity for incompatibility that didn=E2=80=99t = exist before. >>>>>>=20 >>>>>> =20 >>>>>> As far as simplicity is concerned, I find a solution that reuses = the existing data model and naturally supports existing and future = extensions to be far simpler than one that introduces ambiguous = semantics to existing parameters. Generally speaking, data models with = properties that mean different things in different contexts tend to be = fragile and require more complex code to work with. But that=E2=80=99s = just my experience as, you know, an actual developer. >>>>>>=20 >>>>>> =20 >>>>>> Let=E2=80=99s keep the assumptions and snide remarks about = others=E2=80=99 backgrounds off the list, please. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: Dominick Baier > >>>>>> Date: Wednesday, February 13, 2019 at 4:18 AM >>>>>> To: "Richard Backman, Annabelle" >, Filip Skokan > >>>>>> Cc: Brian Campbell >, "Richard Backman, Annabelle" = >, oauth = > >>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & = discovery >>>>>>=20 >>>>>> =20 >>>>>> I am for keeping it simple and not introducing another link to = follow. >>>>>>=20 >>>>>> =20 >>>>>> I sometimes wonder how many of the spec authors are actually = developers - these suggestions make software unnecessary complex ;) >>>>>>=20 >>>>>> =20 >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>=20 >>>>>> Dominick >>>>>>=20 >>>>>> =20 >>>>>> On 13. February 2019 at 12:25:13, Filip Skokan = (panva.ip@gmail.com ) wrote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> =20 >>>>>> Additionally, a metadata document that omits token_endpoint in = favor of mtls_endpoints since only mTLS is supported would violate 8414, = as 8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the = implicit grant type is supported.=E2=80=9D >>>>>>=20 >>>>>>=20 >>>>>> mtls only AS doesn't get anything out of using mtls_endpoints, = its use should not be recommended for such AS and regular endpoints will = be used, this satisfies the requirement >>>>>>=20 >>>>>> Here is one example, based on my understanding of the =E2=80=9Cstra= w man=E2=80=9D format presented in this thread: RFC8414 defines the = value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array = containing a list of client authentication methods supported by this = token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2= =80=9D and the endpoint specified in token_endpoint does not support = mTLS, then that metadata violates 8414. You could address this by adding = a token_endpoint_auth_methods_supported parameter to the mtls_endpoints = object, and likewise for the other endpoints and auth methods. If you = take that to its logical conclusion, you end up with a complete metadata = document hanging off of mtls_endpoints. It=E2=80=99s that line of = thought that led me to suggest just pointing to an alternate document. >>>>>>=20 >>>>>>=20 >>>>>> Assuming we go with using the same root auth methods property, = what's the issue? Clients not having mtls capabilities won't care about = the additional method members being present. Clients that do implement = mtls by the specification will know to look for mtls_endpoints and fall = back to regular ones if the specific endpoint or mtls_endpoints root = property is not present. >>>>>>=20 >>>>>> =20 >>>>>> I gave `mtls_alternate_metadata` route a thought and don't see = how it helps, given the two above are non-issues (my $.02) another = discovery document only brings more of them since every property can now = be different, not just the endpoints. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> S pozdravem, >>>>>> Filip Skokan >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> Here is one example, based on my understanding of the =E2=80=9Cstra= w man=E2=80=9D format presented in this thread: RFC8414 defines the = value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array = containing a list of client authentication methods supported by this = token endpoint.=E2=80=9D If that array contains =E2=80=9Ctls_client_auth=E2= =80=9D and the endpoint specified in token_endpoint does not support = mTLS, then that metadata violates 8414. You could address this by adding = a token_endpoint_auth_methods_supported parameter to the mtls_endpoints = object, and likewise for the other endpoints and auth methods. If you = take that to its logical conclusion, you end up with a complete metadata = document hanging off of mtls_endpoints. It=E2=80=99s that line of = thought that led me to suggest just pointing to an alternate document. >>>>>>=20 >>>>>> =20 >>>>>> Additionally, a metadata document that omits token_endpoint in = favor of mtls_endpoints since only mTLS is supported would violate 8414, = as 8414 says = token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type = is supported.=E2=80=9D >>>>>>=20 >>>>>> =20 >>>>>> It is possible to define the mtls_endpoints parameter such that = the above use cases are invalid, but that does make the document more = complicated.. If we go the =E2=80=9Cmtls_alternate_metadata=E2=80=9D = route, we can skip past all of these issues, because it brings us back = to just parsing the same metadata that we do today. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: OAuth > on behalf of Filip Skokan = > >>>>>> Date: Tuesday, February 12, 2019 at 1:13 PM >>>>>> To: "Richard Backman, Annabelle" = > >>>>>> Cc: Brian Campbell >, oauth > >>>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>>>=20 >>>>>> =20 >>>>>> Hi Annabelle, >>>>>>=20 >>>>>> =20 >>>>>> can you elaborate what would be the violation / negative impact = of usage of RFC8414? >>>>>>=20 >>>>>> =20 >>>>>> As it already makes use of `signed_metadata` and this language is = present ... >>>>>>=20 >>>>>> =20 >>>>>> > Consumers of the metadata MAY ignore the signed metadata if = they do not support this feature. If the consumer of the metadata = supports signed metadata, metadata values conveyed in the signed = metadata MUST take precedence over the corresponding values conveyed = using plain JSON elements. >>>>>>=20 >>>>>> =20 >>>>>> .... would mtls_endpoints be any different? Clients are free to = ignore this if they don't support/use mtls, and if they do those values = must take precedence over the root ones. the use of mtls_endpoints would = not be recommended for mtls-only AS but recommended for one with both = mtls/regular authentication methods. token_endpoint remains required for = all intents and purposes. And as for the usable client authentication = methods - they should all be listed, or do you think we should separate = the ones for each hostname/port location? To what end? Is there a risk = having the mtls hostname/port accepting regular requests? Other then = secret/key _jwt auth methods assertion aud claim the endpoint location = doesn't play a role in the authentication process. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>> Filip >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> I=E2=80=99m not opposed to introducing a metadata change, if the = scenario is relevant and other approaches can=E2=80=99t adequately = address it =E2=80=93 and I=E2=80=99ll readily grant that we probably = don=E2=80=99t want to depend on consistency of browser behavior at the = intersection of client certificates and = Access-Control-Allow-Credentials. But care needs to be taken in = designing that metadata to avoid violating or otherwise negatively = impacting usage of RFC8414. >>>>>>=20 >>>>>> =20 >>>>>> Along those lines, instead of adding an =E2=80=9Cmtls_endpoints=E2=80= =9D metadata parameter, we could add an =E2=80=9Cmtls_alternate_metadata=E2= =80=9D parameter whose value is the URL of an alternate metadata = document intended for clients using mTLS. An mTLS-optional AS could have = two different metadata documents for mTLS and non-mTLS clients, reducing = the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the = challenges of aligning the =E2=80=9Ceither/or=E2=80=9D semantics of = mTLS-optional with some of the rigid parameter definitions in RFC8414 = (see: token_endpoint, token_endpoint_auth_methods_supported). >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: OAuth > on behalf of Brian Campbell = > >>>>>> Date: Tuesday, February 12, 2019 at 10:58 AM >>>>>> To: Dominick Baier > >>>>>> Cc: oauth > >>>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery >>>>>>=20 >>>>>> =20 >>>>>> Thanks for the input, Dominick. >>>>>>=20 >>>>>> =20 >>>>>> I'd said previously that I was having trouble adequately gauging = whether or not there's sufficient consensus to go ahead with the update. = I was even thinking of asking the chairs about a consensus call during = the office hours meeting yesterday. But it got canceled. And looking = again back over the discussion, I don't believe a consensus call is = necessary. There's been a lot of general discussion over the last = several weeks during which several folks have stated support for the = proposal while there's been only one voice of direct dissent. That seems = like rough enough consensus and, as such, I plan to make the change in = the next revision of the document (which should be done soon). Chairs, = please let me know, if you believe the situation warrants a different = course of action. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier = > wrote: >>>>>>=20 >>>>>> IMHO that=E2=80=99s a reasonable and pragmatic option. >>>>>>=20 >>>>>> =20 >>>>>> Thanks >>>>>>=20 >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>=20 >>>>>> Dominick >>>>>>=20 >>>>>> =20 >>>>>> On 11. February 2019 at 13:26:37, Brian Campbell = (bcampbell@pingidentity.com ) wrote: >>>>>>=20 >>>>>> It's been pointed out that the potential issue is not isolated to = the just token endpoint but that revocation, introspection, etc. could = be impacted as well. So, at this point, the proposal on the table is to = add a new optional AS metadata parameter named 'mtls_endpoints' that's = value we be a JSON object which itself contains endpoints that, when = present, a client doing MTLS would use rather than the regular = endpoints. A straw-man example might look like this >>>>>>=20 >>>>>> { >>>>>> "issuer":"https://server.example.com = ", >>>>>> "authorization_endpoint":"https://server.example.com/authz = ", >>>>>> "token_endpoint":"https://server.example.com/token = ", >>>>>> "token_endpoint_auth_methods_supported":[ = "client_secret_basic","tls_client_auth", "none"], >>>>>> "userinfo_endpoint":"https://server.example.com/userinfo = ", >>>>>> "revocation_endpoint":"https://server.example.com/revo = ", >>>>>> "jwks_uri":"https://server.example.com/jwks.json = ", >>>>>> "mtls_endpoints":{ >>>>>> "token_endpoint":"https://mtls.example.com/token = ", >>>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo = ", >>>>>> "revocation_endpoint":"https://mtls.example.com/revo = " >>>>>> } >>>>>> } >>>>>>=20 >>>>>> =20 >>>>>> A client doing MTLS would look for and give precedence to an = endpoint under "mtls_endpoints" while falling back to use the normal = endpoint from the top level of metadata when/if its not in = "mtls_endpoints". >>>>>>=20 >>>>>>=20 >>>>>> The idea being that "regular" clients (those not doing MTLS) will = use the regular endpoints. And only the host/port of the endpoints = listed in mtls_endpoints will be set up to request TLS client = certificates during handshake. Thus any potential impact of the = CertificateRequest message being sent in the TLS handshake can be = avoided for all the other regular clients that are not going to do MTLS = - including and most importantly in-browser javascript clients where = there can be less than desirable UI = presented to the end-user. >>>>>>=20 >>>>>> =20 >>>>>> I'm struggling, however, to adequately gauge whether or not = there's sufficient consensus to go ahead with the update. There's been = some support for it voiced. As well as talk of other approaches that = could be alternatives or additional measures. And also some vocal = opposition to it.=20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier = > wrote: >>>>>>=20 >>>>>> We are currently implementing MTLS in IdentityServer. >>>>>>=20 >>>>>> =20 >>>>>> Our approach will be that we=E2=80=99ll offer a separate token = endpoint that supports client certs. Are you planning on adding an = official endpoint name for discovery? Right now we are using = =E2=80=9Cmtls_token_endpoint=E2=80=9D. >>>>>>=20 >>>>>> =20 >>>>>> Thanks >>>>>>=20 >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>>=20 >>>>>> Dominick >>>>>>=20 >>>>>> =20 >>>>>> On 7. February 2019 at 22:36:55, Brian Campbell = (bcampbell=3D40pingidentity.com@dmarc.ietf.org = ) wrote: >>>>>>=20 >>>>>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed = a good reminder that even a seemingly innocuous change that should be = backwards = compatible can break things unexpectedly.. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> The case I=E2=80=99m referencing didn=E2=80=99t specifically = involve AS metadata. We had clients in the wild that assumed that all = the properties in the JSON object returned from our userinfo endpoint = were scalar strings. This broke when we introduced a new property whose = value was a JSON = object. It was a good reminder that even a seemingly innocuous change = that should be backwards compatible can force more work on clients than = we expect. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: Brian Campbell > >>>>>> Date: Wednesday, February 6, 2019 at 11:30 AM >>>>>> To: "Richard Backman, Annabelle" = > >>>>>> Cc: "Richard Backman, Annabelle" >, oauth > >>>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and = in-browser clients using the token endpoint >>>>>>=20 >>>>>> =20 >>>>>> And I'm honestly really struggling to see what could have gone = wrong with or how token_endpoint_auth_methods broke something with the = user info endpoint. If you have the time and/or it'd be = informative to this here little = discussion, please explain that one a bit more. >>>>>>=20 >>>>>> =20 >>>>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell = > wrote: >>>>>>=20 >>>>>> "far" should have said "fair" in the previous message >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell = > wrote: >>>>>>=20 >>>>>> It may well be due to my own intellectual shortcomings but these = issues/questions/confusion-points are not resonating for me as being = problematic. >>>>>>=20 >>>>>> =20 >>>>>> The more general stance of "this isn't needed or worth it in this = document" (I think that's far?) is being heard though. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> (TL;DR: punt AS metadata to a separate draft) >>>>>>=20 >>>>>> AS points #1-3 are all questions I would have as an implementer: >>>>>>=20 >>>>>> Section 2 of RFC8414 = says token_endpoint =E2=80=9Cis REQUIRED unless only the = implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS = put here? >>>>>> The claims for these other endpoints are OPTIONAL, potentially = leading to inconsistency depending on how #1 gets decided. >>>>>> The example usage of the token_endpoint_auth_methods property = given earlier is incompatible with RFC8414, since some of its contents = are only valid for the non-mTLS endpoints, and others are only valid for = the mTLS endpoints. Hence this question. >>>>>> This introduces a new metadata property that could impact how = other specs should extend AS metadata. That = needs to be addressed. >>>>>> =20 >>>>>> I could go on for client points but you already get the point. = Though I=E2=80=99ll share that #3 is real and once forced me to roll = back an update to the Login with Amazon userinfo endpoint=E2=80=A6good = times. =F0=9F=98=83 >>>>>>=20 >>>>>> =20 >>>>>> I don=E2=80=99t necessarily think an AS metadata property is = wrong per se, but understand that you=E2=80=99re bolting a layer of = flexibility onto a standard that wasn=E2=80=99t designed for that, and I = don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed = here sufficiently deals with the fallout from that. In my view this is a = complex enough issue and it=E2=80=99s for a nuanced enough use case (as = far as I can tell from discussion? Please correct me if I=E2=80=99m = wrong) that we should punt it to a separate draft (e.g., = =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D= ) and get mTLS out the door. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: OAuth > on behalf of Brian Campbell = > >>>>>> Date: Monday, February 4, 2019 at 5:28 AM >>>>>> To: "Richard Backman, Annabelle" = > >>>>>> Cc: oauth > >>>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and = in-browser clients using the token endpoint >>>>>>=20 >>>>>> =20 >>>>>> Those points of confusion strike me as somewhat hypothetical or = hyperbolic. But your general point is taken and your position of being = anti additional metadata on this issue is noted. >>>>>>=20 >>>>>> =20 >>>>>> All of which leaves me a bit uncertain about how to proceed. = There seem to be a range of opinions on this point and gauging consensus = is proving elusive for me. That's confounded by my own opinion on it = being somewhat fluid. >>>>>>=20 >>>>>> =20 >>>>>> And I'd really like to post an update to this draft about a month = or two ago. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> Confusion from the AS=E2=80=99s perspective: >>>>>>=20 >>>>>> If I only support mTLS, do I need to include both = token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? = Or set it to the empty string? >>>>>> What if I only support mTLS for the token endpoint, but not = revocation or user info? >>>>>> How do I specify authentication methods for the mTLS token = endpoint? Does token_endpoint_auth_methods apply to both the mTLS and = non-mTLS endpoints? >>>>>> I=E2=80=99m using the OAuth 2.0 Device Flow. = Do I include a mTLS-enabled = device_authorization_endpoint under = mtls_endpoints? >>>>>> =20 >>>>>> Confusion from the client=E2=80=99s perspective: >>>>>>=20 >>>>>> As far as I know, I=E2=80=99m a public client, and don=E2=80=99t = know anything about mTLS, but the IT admins installed client certs in = their users=E2=80=99 browsers and the AS expects to use that to = authenticate me. >>>>>> My AS metadata parser crashed because the mTLS-only AS omitted = token_endpoint_uri.. >>>>>> My AS metadata parser crashed because it didn=E2=80=99t expect to = encounter a JSON object as a parameter value.=20 >>>>>> The mTLS-only AS didn=E2=80=99t provide a value for = mtls_endpoints, what do I do? >>>>>> I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but = they told me to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80= =9D in its name, right? >>>>>> =20 >>>>>> Yes, you can write normative text that answers most of these. But = you=E2=80=99ll have to clearly cover a lot of = similar-but-slightly-different scenarios and be very explicit. And = implementers will still get it wrong. The metadata change introduces = opportunities for confusion and failure that do not exist now, and = forces them on everyone who supports mTLS. In contrast, the 307 redirect = is only required when an AS wants to support both, and is unambiguous in = its behavior and meaning. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: Brian Campbell > >>>>>> Date: Friday, February 1, 2019 at 3:17 PM >>>>>> To: "Richard Backman, Annabelle" > >>>>>> Cc: George Fletcher >, = oauth > >>>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser = clients using the token endpoint >>>>>>=20 >>>>>> =20 >>>>>> It doesn't seem like that confusing or large of a change to me - = if the client is doing MTLS and the given endpoint is present in = `mtls_endpoints`, then it uses that one. Otherwise it uses the regular = endpoint. It gives an AS a lot of flexibility in deployment options. I = personally think getting a 307 approach deployed and working would be = more complicated and error prone.=20 >>>>>>=20 >>>>>> =20 >>>>>> It is a minority use case at the moment but there are forces in = play, like the push for increased security in general and to have = javascript clients use the code flow, that suggest it won't be terribly = unusual to see an AS that wants to support MTLS clients and = javascript/spa clients at the same time. >>>>>>=20 >>>>>> =20 >>>>>> I've personally wavered back and forth in this thread on whether = or not to add the new metadata (or something like it). With my reasoning = each way kinda explained somewhere back in the 40 or so messages that = make up this thread. But it seems like the rough consensus of the group = here is in favor of it. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> This strikes me as a very prominent and confusing change to = support what seems to be a minority use case. I=E2=80=99m getting a = headache just thinking about the text needed to clarify when the AS = should provide `mtls_endpoints` and when the client should use that = versus using `token_endpoint.` Why is the 307 status code insufficient = to cover the case where a single AS supports both mTLS and non-mTLS? >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: OAuth > on behalf of = Brian Campbell = > >>>>>> Date: Friday, February 1, 2019 at 1:31 PM >>>>>> To: George Fletcher > >>>>>> Cc: oauth > >>>>>> Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the = token endpoint >>>>>>=20 >>>>>> =20 >>>>>> Yes, that would work.=20 >>>>>>=20 >>>>>> =20 >>>>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher = > = wrote: >>>>>>=20 >>>>>> What if the AS wants to ONLY support MTLS connections. Does it = not specify the optional "mtls_endpoints" and just use the normal = metadata values? >>>>>>=20 >>>>>> On 1/15/19 8:48 AM, Brian Campbell wrote: >>>>>>=20 >>>>>> It would definitely be optional, apologies if that wasn't made = clear.. It'd = be something to the effect of optional for the AS to include and clients = doing MTLS would use it when present in AS metadata. >>>>>>=20 >>>>>> =20 >>>>>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge = > wrote: >>>>>>=20 >>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for = the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited.. If you = have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments = from your computer. Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf..org/mailman/listinfo/oauth = >>>>>> =20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. = _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>> _______________________________________________=20 >>>>>> OAuth mailing list=20 >>>>>> OAuth@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/oauth = _______________________________________________ >>>>> OAuth mailing 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 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you.=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_36995972-38BC-4541-864C-AE8469A6E3D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = a potential simplification (and alternative to consider):

What do people think of = the idea that MTLS clients perform discovery of a different suffix (as = allowed by RFC 8414). A MTLS-enabled client would first look up metadata = at say "/.well-known/mtls-oauth-authorization-server=E2=80=9D, falling = back to the =E2=80=9Coauth-authorization-server=E2=80=9D suffix if the = specialized suffix was not found.

It would be expected this to be a full, legal discovery = document, so there is no merging nor cross-pollination of supported = features of the two. Should it not be found, such clients would then = fall back to /.well-known/oauth-authorization-server - with the same = evaluation rules. This also means that an AS that either uses MTLS only, = is willing to use optional client certificates/upgrading, uses HTTP = redirects or does not support MTLS would still publish a single = discovery endpoint.

The drawback to this approach is that there are multiple = discovery documents of the AS - but there are already multiple documents = involved - both additional metadata referenced such as a JWKS endpoint, = and the potential that implementations/specifications that extend OAuth = (such as OpenID Connect) have separate suffixes and discovery = data.

-DW

On Feb 15, 2019, at 12:57 PM, George Fletcher = <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20
Just to make sure I understand...

If the AS ONLY supports MTLS endpoints, then it...
   * sets 'token_endpoint_auth_methods_supported' to 'tls_client_auth'
   * does NOT specify the mlts_endpoints section

If the AS does NOT support MTLS endpoints, then it...
    * does NOT specify a value of 'tls_client_auth' = in the 'token_endpoint_auth_methods_supported'
    * does NOT specify the mlts_endpoints section

If the AS supports BOTH "regular" and MTLS endpoints, then it...
    * sets 'token_endpoint_auth_methods_supported' to "client_secret_basic tls_client_auth" (as an example)
    * specifies mtls_endpoints in addition to the = endpoints normally defined for the AS

For the client, if it supports mtls AND if it finds 'tls_client_auth' in the 'token_endpoint_auth_methods_supported' then it first looks to see if an mtls_endpoints object is provided and if so uses those endpoints, otherwise it assumes the RFC 8414 defined endpoints support MLTS.

Now if the 'mtls_endpoints' section defines a 'mtls_token_endpoint' but not an 'introspection_endpoint' but the RFC 8414 meta-data does specify an 'introspection_endpoint', is the client supposed to assume the introspection endpoint also supports MTLS even though it wasn't listed in the 'mtls_endpoints' object? or should it assume that endpoint does NOT support MTLS because it's not part of the 'mtls_endpoints' object?

It will work, though it still feels "hacky" and overly complex.

Thanks,
George

On 2/15/19 2:42 PM, Phil Hunt = wrote:
This is what I would expect. 

Phil

On Feb 15, 2019, at 11:32 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Hello George,

What do you think about what i wrote = earlier?

clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

S pozdravem,
Filip Skokan


On Fri, 15 Feb 2019 at 20:29, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
I still don't see how we solve = one of the use cases Annabelle brought up.

If the 'mtls_endpoints' object just contains endpoints, then in the main meta-data section, should 'token_endpoint_auth_methods_supported' include an indication of 'tls_client_auth' even though the endpoint specified by 'token_endpoint' does NOT support MTLS?

Thanks,
George

On 2/14/19 6:08 PM, Brian Campbell wrote:
Maybe I'm wrong here (it's = never out of the question) but based on this previous message and this one I believe that actually you are both in favor (generally anyway) of the proposal with the optional "mtls_endpoints" parameter. While I believe that the comment about optionality and complexity was meant to be a more general remark. While I can certainly appreciate a desire to keep things simple, I do regret that this thread took a turn towards personal. Whether it was the intent or not, there's an impact.



On Thu, Feb = 14, 2019 at 10:20 AM Phil Hunt <phil.hunt@oracle.com> wrote:
I feel I have to = disagree.  I agree that optionality is often complexity and should be avoided. But, I think the optionality here is an agility feature allowing mtls to work across a diversified market of different types of tls terminators with varying capability. Lack of appropriate discovery/options could serve to make the spec unusable in many cases.  

A complicating factor with tls = is that a tls layer failure prevents the AS from issuing a correcting directive like an http error or http redirect. 

We have to be sure not to break = existing clients so we may in some cases need mtls only endpoints. I am not far enough along to know for sure. But I tend to agree with Brian on this. 

This may be a sign we need more implementation data (including from tls wg) to make the right call. 

Phil

On Feb 14, 2019, at 8:56 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:

Sorry - this was not meant to be snide at = all.

It was honest feedback that you also need to keep software complexity in mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or send values in arbitrary order adds to complexity. Complexity is the natural enemy of security.

Cheers 
=E2=80=94=E2= =80=94=E2=80=94
Dominick

On 13. February 2019 at 20:39:16, Richard Backman, Annabelle (richanna@amazon.com) wrote:

The issue is that the proposal violates the standard by changing the semantics of a parameter it defines. We should be very, very, VERY careful about telling implementers to violate an existing standard... This change might prove incompatible with existing or future implementations of 8414, it might not, but by violating the standard the proposal creates an opportunity for incompatibility that didn=E2=80=99= t exist before.

 

As far as simplicity is concerned, I find a solution that reuses the existing data model and naturally supports existing and future extensions to be far simpler than one that introduces ambiguous semantics to existing parameters. Generally speaking, data models with properties that mean different things in different contexts tend to be fragile and require more complex code to work with. But that=E2=80=99s just my = experience as, you know, an actual = developer.

 

Let=E2=80=99= s keep the assumptions and snide remarks about others=E2=80=99 backgrounds off the list, please.

 

-- 

Annabelle Richard = Backman

AWS Identity

 
 

From: Dominick Baier <dbaier@leastprivilege.com>
Date: = Wednesday, February 13, 2019 at 4:18 AM
To: = "Richard Backman, Annabelle" <richanna@amazon.com>, Filip Skokan <panva.ip@gmail.com>
Cc: = Brian Campbell <bcampbell@pingidentity.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: = [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery

 

I am for keeping it simple and not introducing another link to = follow.

 

I sometimes wonder how many of the spec authors are actually developers - these suggestions make software unnecessary complex ;)

 

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 13. February 2019 at 12:25:13, Filip Skokan (panva.ip@gmail.com) wrote:

Hello,

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9C= is REQUIRED unless only the implicit grant type is = supported.=E2=80=9D


mtls only AS doesn't get anything out of using mtls_endpoints, its use should not be recommended for such AS and regular endpoints will be used, this satisfies the requirement

Here is one example, based on my understanding of the =E2=80=9Cstraw = man=E2=80=9D format presented in this thread: RFC8414 defines the value of token_endpoint_auth_methods_supported as a =E2=80=9CJSON array = containing a list of client authentication methods supported by this token endpoint.=E2=80=9D = If that array contains = =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a = token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. = It=E2=80=99s that line of thought that led me to suggest just pointing to an alternate = document.


Assuming we go with using the same root auth methods property, what's the issue? Clients not having mtls capabilities won't care about the additional method members being present. Clients that do implement mtls by the specification will know to look for mtls_endpoints and fall back to regular ones if the specific endpoint or mtls_endpoints root property is not present.

 

I gave = `mtls_alternate_metadata` route a thought and don't see how it helps, given the two above are non-issues (my $.02) another discovery document only brings more of them since every property can now be different, not just the endpoints.


S pozdravem,
Filip Skokan

 
 

On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Here is one example, based on my understanding of the = =E2=80=9Cstraw man=E2=80=9D = format presented in this thread: RFC8414 defines the value of = token_endpoint_auth_methods_supported as a =E2=80=9CJS= ON array containing a list of client authentication methods supported by this token endpoint.=E2=80=9D= If that array contains = =E2=80=9Ctls_client_auth=E2=80=9D and the endpoint specified in token_endpoint does not support mTLS, then that metadata violates 8414. You could address this by adding a = token_endpoint_auth_methods_supported parameter to the mtls_endpoints object, and likewise for the other endpoints and auth methods. If you take that to its logical conclusion, you end up with a complete metadata document hanging off of mtls_endpoints. It=E2=80=99s that line of thought that led me to suggest = just pointing to an alternate = document.

 

Additionally, a metadata document that omits token_endpoint in favor of mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says token_endpoint =E2=80=9Cis = REQUIRED unless only the implicit grant type is = supported.=E2=80=9D

 

It is possible to define the mtls_endpoints parameter such that the above use cases are invalid, but that does make the document more complicated.. If we go the = =E2=80=9Cmtls_alternate_metadata=E2=80=9D route, we can skip past all of these issues, because it brings us back to just parsing the same metadata that we do today.

 

-- 

Annabelle Richard = Backman

AWS = Identity

 
 

From: OAuth <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com>
Date: Tuesday, February 12, 2019 at 1:13 PM
To: "Richard Backman, Annabelle" = <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf..org>
Subject: Re: [OAUTH-WG] MTLS token endoint & = discovery

 
=
=

Hi Annabelle,

 

can you elaborate what would be the violation / negative impact of usage of RFC8414?

 

As it already makes use of = `signed_metadata` and this language is present = ...

 

> Consumers of the metadata MAY ignore the signed metadata if they do not support this feature.  = If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

 

.... would mtls_endpoints be any different? Clients are free to ignore this if they don't support/use mtls, and if they do those values must take precedence over the root ones. the use of mtls_endpoints would not be recommended for mtls-only AS but recommended for one with both mtls/regular authentication methods. token_endpoint remains required for all intents and purposes. And as for the usable client authentication methods - they should all be listed, or do you think we should separate the ones for each hostname/port location? To what end? Is there a risk having the mtls hostname/port accepting regular requests? Other then secret/key _jwt auth methods assertion aud claim the endpoint location doesn't play a role in the authentication process.


=

Best,
Filip

 
 
=

On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

=

I=E2=80=99m not opposed to introducing a metadata change, if the scenario is relevant and other approaches can=E2=80=99t adequately address it =E2=80= =93 and I=E2=80=99ll= readily grant that we probably = don=E2=80=99t want to depend on consistency of browser behavior at the intersection of client certificates and Access-Control-Allow-Credentials. But care needs to be taken in designing that metadata to avoid violating or otherwise negatively impacting usage of = RFC8414.

 

Along those lines, instead of adding an = =E2=80=9Cmtls_endpoints=E2=80=9D metadata parameter, we could add an = =E2=80=9Cmtls_alternate_metadata=E2=80=9D parameter whose value is the URL of an alternate metadata document intended for clients using mTLS. An mTLS-optional AS could have two different metadata documents for mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only scenario. This sidesteps the challenges of aligning the = =E2=80=9Ceither/or=E2=80=9D semantics of mTLS-optional with some of the rigid parameter definitions in RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).

 

-- 

Annabelle Richard = Backman

AWS = Identity

 
 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & = discovery

 
=
=
=
=

Thanks for the input, Dominick.

 

I'd said previously that I was having trouble adequately gauging whether or not there's sufficient consensus to go ahead with the update. I was even thinking of asking the chairs about a consensus call during the office hours meeting yesterday. But it got canceled. And looking again back over the discussion, I don't believe a consensus call is necessary. There's been a lot of general discussion over the last several weeks during which several folks have stated support for the proposal while there's been only one voice of direct dissent. That seems like rough enough consensus and, as such, I plan to make the change in the next revision of the document (which should be done soon). Chairs, please let me know, if you believe the situation warrants a different course of action.

 
 
 
=

On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dbaier@leastprivilege.com> wrote:

=

IMHO that=E2=80=99= s a reasonable and pragmatic = option.

 

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.com) wrote:

=
=
=
=
=
=
=
=

It's been = pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. = So,  at this point, the proposal on the table is to add a new optional AS metadata parameter named = 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular = endpoints.  A straw-man example might look like = this

{
  = "issuer":"https://server.example.com",
  = "authorization_endpoint":"https://server.example.com/authz",
  = "token_endpoint":"https://server.example.com/token",
  = "token_endpoint_auth_methods_supported":[  "client_secret_basic","tls_client_auth", "none"],
  = "userinfo_endpoint":"https://server.example.com/userinfo",
  = "revocation_endpoint":"https://server.example.com/revo",
  = "jwks_uri":"https://server.example.com/jwks.json",
  "mtls_endpoints":{
    = "token_endpoint":"https://mtls.example.com/token",
    = "userinfo_endpoint":"https://mtls.example.com/userinfo",
    = "revocation_endpoint":"https://mtls.example.com/revo"
  = }
}

 

A client doing MTLS would look for and give precedence to an endpoint under = "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in = "mtls_endpoints".


The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the = end-user.

 

I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. 

 
 
=

On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com> wrote:

=

We are = currently implementing MTLS in = IdentityServer.

 

Our approach = will be that we=E2=80=99ll = offer a separate token endpoint that supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using = =E2=80=9Cmtls_token_endpoint=E2=80=9D.

 

Thanks

=E2=80=94=E2=80=94=E2=80=94

Dominick

 

On 7. February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote:

=
=
=
=

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things = unexpectedly..

 
 
 
 
 
=

On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle = <richanna@amazon.com> wrote:

=

The case I=E2=80=99m= referencing didn=E2=80=99t specifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we = expect.

 

-- 

Annabelle Richard = Backman

AWS = Identity

 
 

From: Brian Campbell = <bcampbell@pingidentity..com> Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" = <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token = endpoint

 
=

And I'm honestly really struggling to see what could have gone wrong with or how = token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

 
=

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell = <bcampbell@pingidentity.com> wrote:

=
=

"far" should have said "fair" in the previous message

 
 
 
 
 
=

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell = <bcampbell@pingidentity.com> wrote:

=
=

It may well be due to my own intellectual shortcomings but these = issues/questions/confusion-points are not resonating for me as being = problematic.

 

The more general stance of "this isn't needed or worth it in this document" (I think that's far?) is being heard though.

 
 
 
=

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

=

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an = implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis = REQUIRED unless only the implicit grant type is supported.=E2=80= =9D So what does the mTLS-only AS put here? =
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the = token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question. =
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed. =
 

I could go on for client points but you already get the point. Though I=E2=80=99= ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo = endpoint=E2=80=A6good times. =F0=9F=98=83

 

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99= re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t = think the metadata proposal as it=E2=80=99s = been discussed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and = it=E2=80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99= m wrong) that we should punt it to a separate draft (e.g., = =E2=80=9CAuthorization Server Metadata Extensions for mTLS = Hybrids=E2=80=9D) and get mTLS out the = door.

 

-- 

Annabelle Richard = Backman

AWS = Identity

 
 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" = <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token = endpoint

 
=
=
=
=

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

 

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

 

And I'd really like to post an update to this draft about a month or two = ago.

 
 
 
 
 
 
=

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

=

Confusion from the = AS=E2=80=99s = perspective:

  1. If I only support mTLS, do I need to include both = token_endpoint_uri and = mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints? =
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled = device_authorization_endpoint under = mtls_endpoints?
 

Confusion from the client=E2=80=99s= = perspective:

  1. As far as I know, I=E2=80=99m a = public client, and don=E2=80=99t = know anything about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted = token_endpoint_uri..
  3. My AS metadata parser crashed because it didn=E2=80=99t = expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t = provide a value for = mtls_endpoints, what do I do?
  5. I don=E2=80=99t = know what that = =E2=80=9Cm=E2=80=9D means, but they told me to use HTTPS, so I should use the one with =E2=80=9Ctl= s=E2=80=9D in its name, right?
 

Yes, you can write normative text that answers most of these. But you=E2=80=99= ll have to clearly cover a lot of = similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and = meaning.

 

-- 

Annabelle Richard = Backman

AWS = Identity

 
 

From: Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher = <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

 
=
=

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in = `mtls_endpoints`, then it uses that = one.  Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error = prone. 

 

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

 

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this = thread.  But it seems like the rough consensus of the group here is in favor of it.

 
 
 
 
=

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

=

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99= m getting a headache just thinking about the text needed to clarify when the AS should provide = `mtls_endpoints` and when the client should use that versus using = `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

 

-- 

Annabelle Richard = Backman

AWS = Identity

 
 

From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher = <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

 

Yes, that would = work. 

 
=

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher = <gffletch=3D40aol.com@dmarc.ietf..org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional = "mtls_endpoints" and just use the normal metadata = values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

=
=

It would definitely be optional, apologies if that wasn't made clear.. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

 
=

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

=
=
=

I'm = in favour of the = `mtls_endpoints` metadata parameter - although it should be = optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you.

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

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

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank = you. 
______________________=
_________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing 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=_36995972-38BC-4541-864C-AE8469A6E3D9-- From nobody Sun Feb 17 02:44:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF66128B01 for ; Sun, 17 Feb 2019 02:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoow3-bhW9SI for ; Sun, 17 Feb 2019 02:44:23 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E69127AC2 for ; Sun, 17 Feb 2019 02:44:22 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id b20so11369087edw.11 for ; Sun, 17 Feb 2019 02:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=QmxpcS92Qw1WnY4T+lYELFgKy2tfo4htf1jP4Lujx10=; b=D/DM862OYKOB7oHfJpLjKA+xJWTBZvEU95OQsbMXB+W0ZiHs0RpGgcpBMfyRWNHIpk SphKpcD7trxQm4A7x5C41Q49sy9GUQaeIOSe8anXhaibcniX8BmoJxirbZLGmwEAs6vy NNIOV9t3ihISKBjFlby5J7r5O+Iu1xDwC0nNjJX7kOG5Il75yaGMQiT0UJKjodKti4Ji ev04Z1qUWWtvn8cfdacElSxfHPaCps67GNJXDyDk7H2ll9luJzHZKKCktAGHU+gNLsNp /lUufwL74OGl9kad5DozTlLEzWUJc0f2I2/NWsa5B4gV6FLdFxUj2We4tJIDIcehhRlH XoCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=QmxpcS92Qw1WnY4T+lYELFgKy2tfo4htf1jP4Lujx10=; b=B7iz0EYARAGl8qpI3J9Uw03ynHLVB5kvtN3mgkG3Ng5+TEZmatfc53megED8VSZoKk 221BT+ykGCbJ/ZZ3klLTN8ZMVATn7WtyjWmTztw/hVqNqFNtW+5Ghgcurkd0K0/ZNqx4 TmEr0ubO6vTSoqvh6yMv4Ni0BZpJV+c/wDxAV3t5h0i1qZrrC31AX4TNjp03U5zMjj8N uChbuqjyn/zFgqYCMsdyj4NS202cSf0qH/HRfPqaKsXxaX2EYfvtO57CiUTOOeLpYu4m Z06hc1Lp8v3i2ILcFuxGCzNxjgoFEyTY/MQTaewqG9zmxnB/eGvnjnAvtMkXRXmYgu0p Rn9w== X-Gm-Message-State: AHQUAuaUxpcZ2UIc6pJ/HZfP19siwpTZsE82fCXmk4QS4yUvLf9a3LO3 f9ZrnG6LAXmvuymGVhwlUKDneHeMCRJksQ== X-Google-Smtp-Source: AHgI3Ia85j0/fxZn3kV89fmw+P+iULfdd2G+GgMVKz+o8ajgf//M68luz+3tAsZOXU1KE/tpWK4s3Q== X-Received: by 2002:a50:a622:: with SMTP id d31mr15360708edc.228.1550400260552; Sun, 17 Feb 2019 02:44:20 -0800 (PST) Received: from [192.168.1.228] (d51A484BC.access.telenet.be. [81.164.132.188]) by smtp.gmail.com with ESMTPSA id j6sm3134116edd.43.2019.02.17.02.44.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 02:44:19 -0800 (PST) From: Jim Manico Content-Type: multipart/alternative; boundary=Apple-Mail-7DC02457-1411-4678-A483-7BF9AA428D91 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sun, 17 Feb 2019 11:44:18 +0100 Message-Id: <0DA81B0D-B8CA-4B91-89D2-E4B000D1D125@manicode.com> To: oauth@ietf.org X-Mailer: iPhone Mail (16D57) Archived-At: Subject: [OAUTH-WG] On XSS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 10:44:25 -0000 --Apple-Mail-7DC02457-1411-4678-A483-7BF9AA428D91 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable OAuth community, XSS is a problematic risk in all web applications. It=E2=80=99s easy to intr= oduce into apps, hard to find, and one variant is dramatically growing - DOM= XSS. If you care about this risk; please give this a read from one of the worlds b= est on this topic and a potential solution (at least for DOM XSS) that will a= rrive in the near future. https://developers.google.com/web/updates/2019/02/trusted-types -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805= --Apple-Mail-7DC02457-1411-4678-A483-7BF9AA428D91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable OAuth community,

XSS is a= problematic risk in all web applications. It=E2=80=99s easy to introduce in= to apps, hard to find, and one variant is dramatically growing - DOM XSS.

If you care about this risk; please give this a read f= rom one of the worlds best on this topic and a potential solution (at least f= or DOM XSS) that will arrive in the near future.

ht= tps://developers.google.com/web/updates/2019/02/trusted-types

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
= --Apple-Mail-7DC02457-1411-4678-A483-7BF9AA428D91-- From nobody Sun Feb 17 10:30:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC25B12D4E8 for ; Sun, 17 Feb 2019 10:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdUIymT5RyxU for ; Sun, 17 Feb 2019 10:30:04 -0800 (PST) Received: from sonic305-20.consmr.mail.ir2.yahoo.com (sonic305-20.consmr.mail.ir2.yahoo.com [77.238.177.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20C512426E for ; Sun, 17 Feb 2019 10:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1550428201; bh=4m9KXLvjvRtsjfzyLgqDakxFnsNm1MjufJA7zZhHPQI=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=F77xCEA8jQYgpSrlofoApsjxTHVBFYArGwyJzlRXHYWY+FcP965DA3HAgMtWJBbGcu3h4wQvcMJQgKL+GAMlUZhcLvKjhPTHpEz4IuRyCUKlgL/k6OIA59ggdtYUq8D7pgywNWm1FmsLTrH0xtAqx23zCOLCm43dUW4xw85R5hpSrqwWrJplRyIHQxCVJ20S0PzEha2MuMNaW//g6BHObPAz56AU+XXTGeW4rbe4sFvWyLZyRTAEWcQ7roEXG9edowWvWpM/ooeuysQnShlu1Imi9xRNO/vy26sQAgyOzTg8FAP2VPSabVDk85OBBuK0zDr38U518SP2PNrnme0F3A== X-YMail-OSG: 8YzRJHkVM1ng0eiv2Lt1asn81sOncqbA5YG3ZOxx4uOnOD3nL7FuxvzAJO_IB4k enXx48AxIt5OnXROhrETXMS21O09829BDqCRbeBZErQBe8WDfnntDlN__rtxwLJQ8rTQVzSzPms2 TatfdCcgnR9dzWyJVGtcHbenn6B9MjJtF_1WU2H.u7TfUh47ImHmoddH5HwiMlWFEUI4a10MlikF lGhf5yW545lhhp_dYY5aI_WLPHUa7tnUu2W2SyUwmJf9Wy9J64sUkWzWyn0kHXj2ZtQlnvMNlOep HVvR8SgHquXiomM4YHtaq6e59PjiYOg1ln8oJfUla95SHJycKEYKW5aNJC4K_gQGGavDfdepKUjk 6DU1g1eP7R1AcoYClpoIir0tmM9Lzy2LHfu2uExg5FfFA78DzkIhmv4SLV1IeEaR9XyimR2jw83f SwRMS8yXWNNYsCLKnKOMQBQbbUcy1fLCgvGZ0jEMNWwYmrjxZUQkjcVYLhHN.CL0cmqi58BBoIyw bU9Dm0JUhAyAKBiiGi6ITRvEYq2Yw5x3Vrgs3kFxppf6pZsLuEYZr3F5RIQhaTos3r2gEQWqyvzQ HK_H98QAnshAX0eK6pBg9EW30lEr05AtmQC7gWHA9Sfvtgh9_uDWQgolU7yL3OV6RC4RXTQjEUyy BbSgR0KGePcFmF3fYnnNK7sj64zxHL.49QA0K2tAN3771pTNql3suNOJt8bHJKYFPfy16AeiMbOd 6ElacaDNM_LYL6bEE0aOQE7_s6.qlJJnE1wPCmVYezk0yFLZ_DQwzjIxIDK27OqDTGKOISsEgshF tEEWZBAq3eF4HCijar9ioU3IDSSZhEYdUA5fimoelTmI9VZOcIR5B50a_mjARqmPog7bfIn0zKbQ OS4DT7Y_3GXyL5lUHvRpNeT61i69.xLMiedFkdYUuQDP8puL6d0zMTakzwXEnYaKd2DnTl8WY0jC 2Sspr29FTv1VxbIHb_fyLX5i5gi4DvsDF5AY8p4hktiau_4jhdmeZdAk3L3Zyq9_8BMtCNva0Ypk I1HWThs3Nz44ikOPEfb8AE6IS72d5ILoRXqc9Ij0_4RY8mIXq34_olS.WA3AZaleMhI2hn5Xn6uF 7aCK7wPPHDJ42AhIcEwgDyW4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Sun, 17 Feb 2019 18:30:01 +0000 Received: from sonic309-25.consmr.mail.ir2.yahoo.com (EHLO sonic309-25.consmr.mail.ir2.yahoo.com) ([77.238.179.83]) by smtp425.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2684afd52278276c9b71999401bbb72a for ; Sun, 17 Feb 2019 18:30:00 +0000 (UTC) X-YMail-OSG: umSQmiAVM1kOQyLj7BjH_J4mzFRfXgmyiTOs7dAaCCJxbKJVzBX.Oy0czT257ep PKLbUf3ArwrnnSTEfKnGHWKnDN6MnTyuwhP4EINOkERanCwszGO_kObegeiPCvAdUx_fhygETPtl RJXn9jf9tSgSWNP6MSQu6YoU87SNsg8ijqYQgiamt91Ws28Uq8_engvE5oSkzl27OfLv1uVXK7Sh AQEP7RCevvKZUk1AWAbwLtX.xjXZPFFCPSoZNfZrU9alI22SvWYF1UFxsdulrAdFZQUFYeRmohRM COUAJvsKAbAttf2fI2fSLRcxTp98wxIRWUwuaIFO.sOsLiKRpP_1Mqva9s5QOfqlM9rvbYmbRt_r e65yK5zv_9zqOzl0JU.YzzvxVbGPPyxe.3XNGo4gTjBCWITIvx1LZJ5RMrCxU3j44Yy4isY69VhV MuNYd.MD6gsi5zsCfu9pBCkNpkFB035lQ81o_mV3WHTydwPO4i5nTvQVM3b9m5IjWNNjc2IdD6lK l.NOO_UE5XzrLaU9n7BQRbLu3ylvCPXswUGecPRKgGS8jogowNL2eV7QItpwY8PfJjBhwhFFxk_A smdPP0RWUBCc0KvLJQmqVe..oKU2yiXdv12k7cjinqVWPz_g.lWhvxnoHrmohCi11ZR_OpoD36J_ diImRqfpPX_upQphvMm6Vm0AteOM14NMETMAKaL.2Qlw77Tc86Rso3FourjKEdTXQaOoaw9htDz1 MLJx_W_Wxsg5kqoeMY6yVN7ZxUhZDtV3NoLUAlQ1WpS_ice6LOFuMpyWxCsYLMk87w8Q48fDWbpQ SRdyvYMTxnMrnr6udBIqbkaxeCYhg._NPbPQAumiP7XXHnwj2v3gjTnBA3v4SMeACjmaLn3LB_49 LcX5y.RNzfx8SRJ1mtSz6VrfbNRSC0SLlwb8nvEzvZgoz0KYKS_UJRNJVaXGh80NTbArA2AC4xV4 4rWe0DdkeTZU9jvEpvazc.qHwtamI0t9bjfPyhDBjuVQs3_UY4SPagk8DPSQE1jA_VZwBezTF6K0 6.kgzsv3DdW5fUVjSF8waMCOi4vzhjCfsOhj2rmhnBVs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ir2.yahoo.com with HTTP; Sun, 17 Feb 2019 18:29:59 +0000 Date: Sun, 17 Feb 2019 18:29:55 +0000 (UTC) From: Rafal Reply-To: Rafal To: oauth@ietf.org Message-ID: <1426369836.919465.1550428195530@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_919464_1411346147.1550428195519" X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (Windows NT 6.1; rv:65.0) Gecko/20100101 Firefox/65.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 124, Issue 33 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 18:30:08 -0000 ------=_Part_919464_1411346147.1550428195519 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable heartbkit@yahoo.com,alfabeta69@yahoo.com,rafal.rogala@aol.com,rogalarafal6= 9@gmail.com,aidis_addict@outlook.beHeartGrtz W wtorek, 12 lutego 2019, 07:01:41 CET, napisa= =C5=82(-a): =20 =20 Send OAuth mailing list submissions to =C2=A0=C2=A0=C2=A0 oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0 oauth-request@ietf.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0 oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: =C2=A0 1. Re: MTLS token endoint & discovery (Dominick Baier) ---------------------------------------------------------------------- Message: 1 Date: Mon, 11 Feb 2019 22:01:04 -0800 From: Dominick Baier To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] MTLS token endoint & discovery Message-ID: =C2=A0=C2=A0=C2=A0 Content-Type: text/plain; charset=3D"utf-8" IMHO that?s a reasonable and pragmatic option. Thanks ??? Dominick On 11. February 2019 at 13:26:37, Brian Campbell (bcampbell@pingidentity.co= m) wrote: It's been pointed out that the potential issue is not isolated to the just token endpoint but that revocation, introspection, etc. could be impacted as well. So,=C2=A0 at this point, the proposal on the table is to add a new optional AS metadata parameter named 'mtls_endpoints' that's value we be a JSON object which itself contains endpoints that, when present, a client doing MTLS would use rather than the regular endpoints.=C2=A0 A straw-man example might look like this { =C2=A0 "issuer":"https://server.example.com", =C2=A0 "authorization_endpoint":"https://server.example.com/authz", =C2=A0 "token_endpoint":"https://server.example.com/token", =C2=A0 "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_client_auth", "none"], =C2=A0 "userinfo_endpoint":"https://server.example.com/userinfo", =C2=A0 "revocation_endpoint":"https://server.example.com/revo", =C2=A0 "jwks_uri":"https://server.example.com/jwks.json", *"mtls_endpoints":{=C2=A0 =C2=A0 "token_endpoint":"https://mtls.example.com= /token ", "userinfo_endpoint":"https://mtls.example.com/userinfo ", "revocation_endpoint":"https://mtls.example.com/revo "=C2=A0 }* } A client doing MTLS would look for and give precedence to an endpoint under "mtls_endpoints" while falling back to use the normal endpoint from the top level of metadata when/if its not in "mtls_endpoints". The idea being that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user. I'm struggling, however, to adequately gauge whether or not there's sufficient consensus to go ahead with the update. There's been some support for it voiced. As well as talk of other approaches that could be alternatives or additional measures. And also some vocal opposition to it. On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier wrote: > We are currently implementing MTLS in IdentityServer. > > Our approach will be that we?ll offer a separate token endpoint that > supports client certs. Are you planning on adding an official endpoint na= me > for discovery? Right now we are using ?mtls_token_endpoint?. > > Thanks > ??? > Dominick > > On 7. February 2019 at 22:36:55, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good > reminder that even a seemingly innocuous change that should be backwards > compatible can break things unexpectedly.. > > > > > > On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> The case I?m referencing didn?t specifically involve AS metadata. We had >> clients in the wild that assumed that all the properties in the JSON obj= ect >> returned from our userinfo endpoint were scalar strings. This broke when= we >> introduced a new property whose value was a JSON object. It was a good >> reminder that even a seemingly innocuous change that should be backwards >> compatible can force more work on clients than we expect. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Wednesday, February 6, 2019 at 11:30 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* "Richard Backman, Annabelle" , oauth < >> oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> And I'm honestly really struggling to see what could have gone wrong wit= h >> or how token_endpoint_auth_methods broke something with the user info >> endpoint. If you have the time and/or it'd be informative to this here >> little discussion, please explain that one a bit more. >> >> >> >> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> "far" should have said "fair" in the previous message >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell >> wrote: >> >> It may well be due to my own intellectual shortcomings but these >> issues/questions/confusion-points are not resonating for me as being >> problematic. >> >> >> >> The more general stance of "this isn't needed or worth it in this >> document" (I think that's far?) is being heard though. >> >> >> >> >> >> >> >> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> (TL;DR: punt AS metadata to a separate draft) >> >> AS points #1-3 are all questions I would have as an implementer: >> >>=C2=A0 =C2=A0 1. Section 2 of RFC8414 >>=C2=A0 =C2=A0 says token_= endpoint >>=C2=A0 =C2=A0 ?is REQUIRED unless only the implicit grant type is support= ed.? So what >>=C2=A0 =C2=A0 does the mTLS-only AS put here? >>=C2=A0 =C2=A0 2. The claims for these other endpoints are OPTIONAL, poten= tially >>=C2=A0 =C2=A0 leading to inconsistency depending on how #1 gets decided. >>=C2=A0 =C2=A0 3. The example usage of the token_endpoint_auth_methods pro= perty >>=C2=A0 =C2=A0 given earlier is incompatible with RFC8414, since some of i= ts contents are >>=C2=A0 =C2=A0 only valid for the non-mTLS endpoints, and others are only = valid for the >>=C2=A0 =C2=A0 mTLS endpoints. Hence this question. >>=C2=A0 =C2=A0 4. This introduces a new metadata property that could impac= t how >>=C2=A0 =C2=A0 other specs should extend AS metadata. That needs to be add= ressed. >> >> >> >> I could go on for client points but you already get the point. Though >> I?ll share that #3 is real and once forced me to roll back an update to = the >> Login with Amazon userinfo endpoint?good times. ? >> >> >> >> I don?t necessarily think an AS metadata property is wrong per se, but >> understand that you?re bolting a layer of flexibility onto a standard th= at >> wasn?t designed for that, and I don?t think the metadata proposal as it?= s >> been discussed here sufficiently deals with the fallout from that. In my >> view this is a complex enough issue and it?s for a nuanced enough use ca= se >> (as far as I can tell from discussion? Please correct me if I?m wrong) t= hat >> we should punt it to a separate draft (e.g., ?Authorization Server Metad= ata >> Extensions for mTLS Hybrids?) and get mTLS out the door. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Monday, February 4, 2019 at 5:28 AM >> *To:* "Richard Backman, Annabelle" >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser >> clients using the token endpoint >> >> >> >> Those points of confusion strike me as somewhat hypothetical or >> hyperbolic. But your general point is taken and your position of being a= nti >> additional metadata on this issue is noted. >> >> >> >> All of which leaves me a bit uncertain about how to proceed. There seem >> to be a range of opinions on this point and gauging consensus is proving >> elusive for me. That's confounded by my own opinion on it being somewhat >> fluid. >> >> >> >> And I'd really like to post an update to this draft about a month or two >> ago. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> Confusion from the AS?s perspective: >> >>=C2=A0 =C2=A0 1. If I only support mTLS, do I need to include both >>=C2=A0 =C2=A0 token_endpoint_uri and mtls_endpoints? Should I omit token_= endpoint_uri? Or >>=C2=A0 =C2=A0 set it to the empty string? >>=C2=A0 =C2=A0 2. What if I only support mTLS for the token endpoint, but = not >>=C2=A0 =C2=A0 revocation or user info? >>=C2=A0 =C2=A0 3. How do I specify authentication methods for the mTLS tok= en >>=C2=A0 =C2=A0 endpoint? Does token_endpoint_auth_methods apply to both th= e mTLS and >>=C2=A0 =C2=A0 non-mTLS endpoints? >>=C2=A0 =C2=A0 4. I?m using the OAuth 2.0 Device Flow. Do I include a mTLS= -enabled >>=C2=A0 =C2=A0 device_authorization_endpoint under mtls_endpoints? >> >> >> >> Confusion from the client?s perspective: >> >>=C2=A0 =C2=A0 1. As far as I know, I?m a public client, and don?t know an= ything >>=C2=A0 =C2=A0 about mTLS, but the IT admins installed client certs in the= ir users? >>=C2=A0 =C2=A0 browsers and the AS expects to use that to authenticate me. >>=C2=A0 =C2=A0 2. My AS metadata parser crashed because the mTLS-only AS o= mitted >>=C2=A0 =C2=A0 token_endpoint_uri. >>=C2=A0 =C2=A0 3. My AS metadata parser crashed because it didn?t expect t= o >>=C2=A0 =C2=A0 encounter a JSON object as a parameter value. >>=C2=A0 =C2=A0 4. The mTLS-only AS didn?t provide a value for mtls_endpoin= ts, what >>=C2=A0 =C2=A0 do I do? >>=C2=A0 =C2=A0 5. I don?t know what that ?m? means, but they told me to us= e HTTPS, >>=C2=A0 =C2=A0 so I should use the one with ?tls? in its name, right? >> >> >> >> Yes, you can write normative text that answers most of these. But you?ll >> have to clearly cover a lot of similar-but-slightly-different scenarios = and >> be very explicit. And implementers will still get it wrong. The metadata >> change introduces opportunities for confusion and failure that do not ex= ist >> now, and forces them on everyone who supports mTLS. In contrast, the 307 >> redirect is only required when an AS wants to support both, and is >> unambiguous in its behavior and meaning. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* Brian Campbell >> *Date:* Friday, February 1, 2019 at 3:17 PM >> *To:* "Richard Backman, Annabelle" >> *Cc:* George Fletcher , oauth >> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser >> clients using the token endpoint >> >> >> >> It doesn't seem like that confusing or large of a change to me - if the >> client is doing MTLS and the given endpoint is present in `mtls_endpoint= s`, >> then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It = gives an >> AS a lot of flexibility in deployment options. I personally think gettin= g a >> 307 approach deployed and working would be more complicated and error >> prone. >> >> >> >> It is a minority use case at the moment but there are forces in play, >> like the push for increased security in general and to have javascript >> clients use the code flow, that suggest it won't be terribly unusual to = see >> an AS that wants to support MTLS clients and javascript/spa clients at t= he >> same time. >> >> >> >> I've personally wavered back and forth in this thread on whether or not >> to add the new metadata (or something like it). With my reasoning each w= ay >> kinda explained somewhere back in the 40 or so messages that make up thi= s >> thread.=C2=A0 But it seems like the rough consensus of the group here is= in >> favor of it. >> >> >> >> >> >> >> >> >> >> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org <40amazon.com@dmarc.ietf..org>> wrote: >> >> This strikes me as a very prominent and confusing change to support what >> seems to be a minority use case. I?m getting a headache just thinking ab= out >> the text needed to clarify when the AS should provide `mtls_endpoints` a= nd >> when the client should use that versus using `token_endpoint.` Why is th= e >> 307 status code insufficient to cover the case where a single AS support= s >> both mTLS and non-mTLS? >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From:* OAuth on behalf of Brian Campbell >> >> *Date:* Friday, February 1, 2019 at 1:31 PM >> *To:* George Fletcher > <40aol.com@dmarc.....ietf.org>> >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token >> endpoint >> >> >> >> Yes, that would work. >> >> >> >> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >> What if the AS wants to ONLY support MTLS connections. Does it not >> specify the optional "mtls_endpoints" and just use the normal metadata >> values? >> >> On 1/15/19 8:48 AM, Brian Campbell wrote: >> >> It would definitely be optional, apologies if that wasn't made clear. >> It'd be something to the effect of optional for the AS to include and >> clients doing MTLS would use it when present in AS metadata. >> >> >> >> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge >> wrote: >> >> I'm in favour of the `mtls_endpoints` metadata parameter - although it >> should be optional. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf..org/mailman/listinfo/oauth >> >> >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> * CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* ______________________________________________= _ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > * CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 124, Issue 33 ************************************** =20 ------=_Part_919464_1411346147.1550428195519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
heartbkit@yahoo.com,alfabeta69@yahoo.com,rafal.rogala@aol.com,= rogalarafal69@gmail.com,aidis_addict@outlook.be
HeartGrtz

=20
=20
W wtorek, 12 lutego 2019, 07:01:41 CET, <oauth-requ= est@ietf.org> napisa=C5=82(-a):


Send OAuth mailing list submissions t= o

To subscribe or unsubscribe via the Wo= rld Wide Web, visit
or, via emai= l, send a message with subject or body 'help' to

You can reach the person managing the list= at



Today's Topics:

  1. Re: MTLS token endoint &a= mp; discovery (Dominick Baier)


---------------------------------------= -------------------------------

Message: 1
Date: Mon, 11 Feb 2019 22:01= :04 -0800
To: Brian Camp= bell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
Subject= : Re: [OAUTH-WG] MTLS token endoint & discovery
Message-ID:
    <CAO7Ng+tGnf= 1fvWjsewexUidiJo06ZdQZbFthTrJZRqSYVB+t0g@mail.gmail.com>
<= div dir=3D"ltr">Content-Type: text/plain; charset=3D"utf-8"

IMHO that?s a reasonable and pragmati= c option.

Thanks
???
Dominick

On 11. February 2019 at 13:26:37, Bri= an Campbell (bcampbell@pingidentity.com)
wrote:

It= 's been pointed out that the potential issue is not isolated to the just
token endpoint but that revocation, introspection, = etc. could be impacted
as well. So,  at this= point, the proposal on the table is to add a new
optional AS metadata parameter named 'mtls_endpoints' that's value we be a=
JSON object which itself contains endpoints that= , when present, a client
doing MTLS would use rat= her than the regular endpoints.  A straw-man
example might look like this

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint_auth_methods_suppo= rted":[
"client_secret_basic","tls_client_auth",= "none"],
  "userinfo_endpoint":"https://server.examp= le.com/userinfo",
  "revocation_endpoint= ":"https://se= rver.example.com/revo",
  "jwks_uri":"https://se= rver.example.com/jwks.json",




=
*"mtls_endpoints":{    "token_endpoint":"https://mtls.example= .com/token
"userinfo_endpoint":"https://mtls.example.com/userinfo
<= /div>
"revocation_endpoint":"https://mtls.example.com/revo
}


A= client doing MTLS would look for and give precedence to an endpoint under<= br>
"mtls_endpoints" while falling back to use the no= rmal endpoint from the top
level of metadata when= /if its not in "mtls_endpoints".

The idea being that "regular" clients (those not doing MTLS) wil= l use the
regular endpoints. And only the host/po= rt of the endpoints listed in
mtls_endpoints will= be set up to request TLS client certificates during
handshake. Thus any potential impact of the CertificateRequest message<= br>
being sent in the TLS handshake can be avoided fo= r all the other regular
clients that are not goin= g to do MTLS - including and most importantly
in-= browser javascript clients where there can be less than desirable UI
presented to the end-user.
I'm struggling, however, to adequately gauge wheth= er or not there's
sufficient consensus to go ahea= d with the update. There's been some support
for = it voiced. As well as talk of other approaches that could be
alternatives or additional measures. And also some vocal opposi= tion to it.


=
On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dbaier@leastprivilege.com>
wrote:

> We are currently i= mplementing MTLS in IdentityServer.
>
> Our approach will be that we?ll offer a separate tok= en endpoint that
> supports client certs. Are = you planning on adding an official endpoint name
= > for discovery? Right now we are using ?mtls_token_endpoint?.
=
>
> Thanks
> ???
> Dominick
>
> On 7. February 2019 at 22:36= :55, Brian Campbell (
> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote:
>
> Ah yes, that makes se= nse. Thanks for clarifying. And it is indeed a good
> reminder that even a seemingly innocuous change that should be back= wards
> compatible can break things unexpected= ly..
>
>
>
>
>
> On Thu, Feb 7, 2019 at 8:57 AM Ric= hard Backman, Annabelle <
>
>> The case I?m referencing didn?t specifically involve AS metad= ata. We had
>> clients in the wild that ass= umed that all the properties in the JSON object
&= gt;> returned from our userinfo endpoint were scalar strings. This broke= when we
>> introduced a new property whose= value was a JSON object. It was a good
>> = reminder that even a seemingly innocuous change that should be backwards
>> compatible can force more work on clients = than we expect.
>>
>>
>>
>= ;> --
>>
>&= gt; Annabelle Richard Backman
>>
<= div dir=3D"ltr">>> AWS Identity
>>
>>
>>
>>
>>
>> *From:* Brian Campbell <bcampbel= l@pingidentity.com>
>> *Date:* Wedne= sday, February 6, 2019 at 11:30 AM
>> *To:*= "Richard Backman, Annabelle" <richanna=3D40amazon.co= m@dmarc.ietf.org>
>> *Cc:* "Richard = Backman, Annabelle" <richanna@amazon.com>, oauth <
>&g= t; *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>> clients using the token endpoint
=
>>
>>
>>
>> And I'm honestly re= ally struggling to see what could have gone wrong with
>> or how token_endpoint_auth_methods broke something with the = user info
>> endpoint. If you have the time= and/or it'd be informative to this here
>>= little discussion, please explain that one a bit more.
>>
>>
>>
>> On Wed, Feb 6, 2019 at 12:1= 5 PM Brian Campbell <
>&= gt;
>> "far" should have said "fair" in the= previous message
>>
>>
>>
&= gt;>
>>
>&g= t;
>>
>>
>>
>>
>>
>> On Tue, Feb = 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pingidenti= ty.com>
>> wrote:
>>
>> It may well be due to = my own intellectual shortcomings but these
>&g= t; issues/questions/confusion-points are not resonating for me as being
=
>> problematic.
>= >
>>
>><= br>
>> The more general stance of "this isn't n= eeded or worth it in this
>> document" (I t= hink that's far?) is being heard though.
>>=
>>
>>
<= /div>
>>
>>
=
>>
>>
>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabe= lle <richanna=3D
>>
>> (TL;DR: punt AS metadata to a separate draft)
>>
>> AS points = #1-3 are all questions I would have as an implementer:
>>
>>    1. Section 2= of RFC8414
>>    ?is REQUIRED unless only the implicit = grant type is supported.? So what
>>  =   does the mTLS-only AS put here?
>>&n= bsp;   2. The claims for these other endpoints are OPTIONAL, potential= ly
>>    leading to inconsistency= depending on how #1 gets decided.
>> =   3. The example usage of the token_endpoint_auth_methods property
>>    given earlier is incompatible= with RFC8414, since some of its contents are
>= ;>    only valid for the non-mTLS endpoints, and others are on= ly valid for the
>>    mTLS endpo= ints. Hence this question.
>>    = 4. This introduces a new metadata property that could impact how
<= div dir=3D"ltr">>>    other specs should extend AS metadata= . That needs to be addressed.
>>
<= div dir=3D"ltr">>>
>>
>> I could go on for client points but you already get the= point. Though
>> I?ll share that #3 is rea= l and once forced me to roll back an update to the
>> Login with Amazon userinfo endpoint?good times. ?
>>
>>
>>
>> I don?t necessarily th= ink an AS metadata property is wrong per se, but
= >> understand that you?re bolting a layer of flexibility onto a stand= ard that
>> wasn?t designed for that, and I= don?t think the metadata proposal as it?s
>&g= t; been discussed here sufficiently deals with the fallout from that. In my=
>> view this is a complex enough issue and= it?s for a nuanced enough use case
>> (as = far as I can tell from discussion? Please correct me if I?m wrong) that
=
>> we should punt it to a separate draft (e.g.= , ?Authorization Server Metadata
>> Extensi= ons for mTLS Hybrids?) and get mTLS out the door.
>>
>>
>= >
>> --
>&g= t;
>> Annabelle Richard Backman
>>
>> AWS Identity
=
>>
>>
>>
>>
>>
>> *From:* OAuth <= oauth-bounces@ietf.org> on behalf of Brian Campbell
>>= ; *Date:* Monday, February 4, 2019 at 5:28 AM
>= ;> *To:* "Richard Backman, Annabelle" <richanna=3D= 40amazon.com@dmarc.ietf.org>
>> *Cc:= * oauth <oauth@ietf.org>
>> *Subject:* R= e: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>> clients using the token endpoint
>>
>>
>= ;>
>> Those points of confusion strike m= e as somewhat hypothetical or
>> hyperbolic= . But your general point is taken and your position of being anti
=
>> additional metadata on this issue is noted.
>>
>>
<= div dir=3D"ltr">>>
>> All of which le= aves me a bit uncertain about how to proceed. There seem
>> to be a range of opinions on this point and gauging conse= nsus is proving
>> elusive for me. That's c= onfounded by my own opinion on it being somewhat
= >> fluid.
>>
>>
>>
>= ;> And I'd really like to post an update to this draft about a month or = two
>> ago.
>&= gt;
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
= >> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <rich= anna=3D
=
>>
>>
>> Confusion from the client?s perspective:
>>
>>    encounter a JSON object as a parameter value.
<= /div>
>>    4. The mTLS-only AS didn?t prov= ide a value for mtls_endpoints, what
>>&nbs= p;   do I do?
>>    5. I don= ?t know what that ?m? means, but they told me to use HTTPS,
>>    so I should use the one with ?tls? in its = name, right?
>>
&= gt;>
>>
>&g= t; Yes, you can write normative text that answers most of these. But you?ll=
>> have to clearly cover a lot of similar-= but-slightly-different scenarios and
>> be = very explicit. And implementers will still get it wrong. The metadata
>> change introduces opportunities for confusion= and failure that do not exist
>> now, and = forces them on everyone who supports mTLS. In contrast, the 307
>> redirect is only required when an AS wants to suppo= rt both, and is
>> unambiguous in its behav= ior and meaning.
>>
>>
>>
&g= t;> --
>>
>= > Annabelle Richard Backman
>>
=
>> AWS Identity
>>
>>
>> *Date:* Friday, February 1, 2019 at 3:17 PM
>> *To:* "Richard Backman, Annabelle" <richan= na@amazon.com>
>> *Cc:* George Fletc= her <gffletch@aol.com>, oauth <oauth@ietf.org>
>> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in= -browser
>> clients using the token endpoin= t
>>
>>
=
>>
>> It doesn= 't seem like that confusing or large of a change to me - if the
>> client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`,
>> then it uses th= at one.  Otherwise it uses the regular endpoint. It gives an
=
>> AS a lot of flexibility in deployment options. I = personally think getting a
>> 307 approach = deployed and working would be more complicated and error
>> prone.
>>
>>
>>
>> It is a minority use case at the moment but there are forces= in play,
>> like the push for increased se= curity in general and to have javascript
>>= clients use the code flow, that suggest it won't be terribly unusual to se= e
>> an AS that wants to support MTLS clien= ts and javascript/spa clients at the
>> sam= e time.
>>
>&g= t;
>>
>> I'= ve personally wavered back and forth in this thread on whether or not
>> to add the new metadata (or something like it= ). With my reasoning each way
>> kinda expl= ained somewhere back in the 40 or so messages that make up this
>> thread.  But it seems like the rough consensus= of the group here is in
>> favor of it.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 1, 2019 at 3:18= PM Richard Backman, Annabelle <richanna=3D
>>
>> This strikes me as a v= ery prominent and confusing change to support what
>> seems to be a minority use case. I?m getting a headache just thi= nking about
>> the text needed to clarify w= hen the AS should provide `mtls_endpoints` and
&g= t;> when the client should use that versus using `token_endpoint.` Why i= s the
>> 307 status code insufficient to co= ver the case where a single AS supports
>> = both mTLS and non-mTLS?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>= ;>
>>
>>=
>>
>>
<= /div>
>> *From:* OAuth <oauth-bounces@iet= f.org> on behalf of Brian Campbell
>> *Date:* Friday, February= 1, 2019 at 1:31 PM
>> *To:* George Fletche= r <gffletch=3D40aol.com@dmarc.ietf.org
>> *Subject:* Re: [OAUTH-WG] MTLS and in-= browser clients using the token
>> endpoint=
>>
>>
<= /div>
>>
>> Yes, that= would work.
>>
&= gt;>
>>
>&g= t; On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D
=
>>
>> W= hat if the AS wants to ONLY support MTLS connections. Does it not
=
>> specify the optional "mtls_endpoints" and just us= e the normal metadata
>> values?
<= div dir=3D"ltr">>>
>> On 1/15/19 8:48= AM, Brian Campbell wrote:
>>
>> It would definitely be optional, apologies if that wa= sn't made clear.
>> It'd be something to th= e effect of optional for the AS to include and
&g= t;> clients doing MTLS would use it when present in AS metadata.
>>
>>
>>
>> On Tue, Jan 15, 2= 019 at 2:04 AM Dave Tonge <dave.tonge@momentumft.co.u= k>
>> wrote:
>>
>> I'm in favour of the `mtls_e= ndpoints` metadata parameter - although it
>&g= t; should be optional.
>>
>>
>> *CONFIDENTIALITY NOTIC= E: This email may contain confidential and
>&g= t; privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure b= y others is strictly prohibited..
>> If you= have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message a= nd any file attachments from
>> your comput= er. Thank you.*
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>>
>>
<= div dir=3D"ltr">>>
>>
>>
>> * CONFIDENTIALITY NO= TICE: This email may contain confidential and
>= ;> privileged material for the sole use of the intended recipient(s). An= y
>> review, use, distribution or disclosur= e by others is strictly prohibited..
>> If = you have received this communication in error, please notify the sender
=
>> immediately by e-mail and delete the messag= e and any file attachments from
>> your com= puter. Thank you.*
>>
>>
>> * CONFIDENTIALITY NOTICE: = This email may contain confidential and
>> = privileged material for the sole use of the intended recipient(s). Any
<= /div>
>> review, use, distribution or disclosure by o= thers is strictly prohibited..
>> If you ha= ve received this communication in error, please notify the sender
=
>> immediately by e-mail and delete the message and = any file attachments from
>> your computer.= Thank you.*
>>
&= gt;>
>> * CONFIDENTIALITY NOTICE: This e= mail may contain confidential and
>> privil= eged material for the sole use of the intended recipient(s). Any
<= div dir=3D"ltr">>> review, use, distribution or disclosure by others = is strictly prohibited..
>> If you have rec= eived this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any fi= le attachments from
>> your computer. Thank= you.*
>>
>>= ;
>> * CONFIDENTIALITY NOTICE: This email m= ay contain confidential and
>> privileged m= aterial for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is str= ictly prohibited.
>> If you have received t= his communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file atta= chments from
>> your computer. Thank you.*<= br>
>>
>
=
> * CONFIDENTIALITY NOTICE: This email may contain conf= idential and
> privileged material for the sol= e use of the intended recipient(s). Any
> revi= ew, use, distribution or disclosure by others is strictly prohibited..
<= /div>
> If you have received this communication in error= , please notify the sender
> immediately by e-= mail and delete the message and any file attachments from
> your computer. Thank you.* __________________________________= _____________
> OAuth mailing list
> OAuth@ietf.org
>
=
>
* CONFIDENTIALITY NOTICE: T= his email may contain confidential and
privileged= material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly p= rohibited.
If you have received this communicatio= n in error, please notify the sender
immediately = by e-mail and delete the message and any file attachments from
your computer. Thank you.*
--------= ------ next part --------------
An HTML attachmen= t was scrubbed...

------------------------------

Subject: Digest Footer

___________________________________= ____________
OAuth mailing list

------------------------------

End of OAuth Digest, Vol 124, Issue 33
=
**************************************
------=_Part_919464_1411346147.1550428195519-- From nobody Mon Feb 18 12:55:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7A131001 for ; Mon, 18 Feb 2019 12:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.8 X-Spam-Level: X-Spam-Status: No, score=-11.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZkZT5xbtSwf for ; Mon, 18 Feb 2019 12:55:15 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE97130FE8 for ; Mon, 18 Feb 2019 12:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1550523314; x=1582059314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+qlm2t2WqKBe3furJPIqOAzthH+FNOUm1MPXXflW+sw=; b=tr0kqNmpVM7L8BarugKOtDNdSznahQpumjtZKGQNeaZYDqLJUN5QOdsU ncoNgatJVvf9RX0iesp/m+Vs71089z962bbJ6tTaZZ2ZFB8T7TeUGdlAt O79/ArWvRDS6aEh4vq2zAdLgbrGz/GXH52RQ7LT93ENHTneHmpfUuRPwQ U=; X-IronPort-AV: E=Sophos;i="5.58,385,1544486400"; d="scan'208,217";a="783593599" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-1e-c7c08562.us-east-1.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2019 20:55:11 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-c7c08562.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id x1IKt7M9082350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Feb 2019 20:55:10 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Feb 2019 20:55:10 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Feb 2019 20:55:09 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 18 Feb 2019 20:55:09 +0000 From: "Richard Backman, Annabelle" To: David Waite , George Fletcher CC: oauth Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery Thread-Index: AQHUxImcYGYvMmjDYECA9hOXj77UKKXf6zgAgAFU2QCAAAFSAIAAAquAgAAEM4CAALDbAIADkCuA Date: Mon, 18 Feb 2019 20:55:09 +0000 Message-ID: References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.189] Content-Type: multipart/alternative; boundary="_000_B1A6967E17D742FC9C67613084CA2F65amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 20:55:21 -0000 --_000_B1A6967E17D742FC9C67613084CA2F65amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gd2l0aCB1c2luZyBhIGRpZmZlcmVudCBzdWZmaXggZm9yIG1UTFMgaXMgdGhh dCBtVExTIGFzIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBmb3IgT0F1dGggMi4wLCBpdCBt YXkgYmUgdXNlZCBieSBhbnkgbnVtYmVyIG9mIGFwcGxpY2F0aW9ucyBvZiBPQXV0aCAyLjAgKGUu Zy4sIE9wZW5JRCBDb25uZWN0KS4gQW55IGFwcGxpY2F0aW9uIHRoYXQgZGVmaW5lcyBpdHMgb3du IHN1ZmZpeCB3b3VsZCBuZWVkIHRvIGFsc28gZGVmaW5lIGFuIG1UTFMtc3BlY2lmaWMgc3VmZml4 IChlLmcuLCDigJxvYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlci1tdGxz4oCdLCDigJxvcGVuaWQt Y29uZmlndXJhdGlvbi1tdGxz4oCdLCDigKYpLiBJZiB0aGUgbVRMUyBwb2ludGVyIGlzIHBhcnQg b2YgdGhlIG1ldGFkYXRhIGRvY3VtZW50IGl0c2VsZiwgdGhlbiBhbGwgYXBwbGljYXRpb25zIGdh aW4gc3VwcG9ydCBmb3IgaXQg4oCcZm9yIGZyZWUu4oCdDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIERhdmlkIFdhaXRlIDxkYXZpZEBhbGthbGluZS1zb2x1dGlv bnMuY29tPg0KRGF0ZTogRnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxOSBhdCAxMDozMSBQTQ0KVG86 IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6 IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtVTlZFUklG SUVEIFNFTkRFUl0gUmU6IE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2NvdmVyeQ0KDQpBcyBhIHBv dGVudGlhbCBzaW1wbGlmaWNhdGlvbiAoYW5kIGFsdGVybmF0aXZlIHRvIGNvbnNpZGVyKToNCg0K V2hhdCBkbyBwZW9wbGUgdGhpbmsgb2YgdGhlIGlkZWEgdGhhdCBNVExTIGNsaWVudHMgcGVyZm9y bSBkaXNjb3Zlcnkgb2YgYSBkaWZmZXJlbnQgc3VmZml4IChhcyBhbGxvd2VkIGJ5IFJGQyA4NDE0 KS4gQSBNVExTLWVuYWJsZWQgY2xpZW50IHdvdWxkIGZpcnN0IGxvb2sgdXAgbWV0YWRhdGEgYXQg c2F5ICIvLndlbGwta25vd24vbXRscy1vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAnSwgZmFs bGluZyBiYWNrIHRvIHRoZSDigJxvYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAnSBzdWZmaXgg aWYgdGhlIHNwZWNpYWxpemVkIHN1ZmZpeCB3YXMgbm90IGZvdW5kLg0KDQpJdCB3b3VsZCBiZSBl eHBlY3RlZCB0aGlzIHRvIGJlIGEgZnVsbCwgbGVnYWwgZGlzY292ZXJ5IGRvY3VtZW50LCBzbyB0 aGVyZSBpcyBubyBtZXJnaW5nIG5vciBjcm9zcy1wb2xsaW5hdGlvbiBvZiBzdXBwb3J0ZWQgZmVh dHVyZXMgb2YgdGhlIHR3by4gU2hvdWxkIGl0IG5vdCBiZSBmb3VuZCwgc3VjaCBjbGllbnRzIHdv dWxkIHRoZW4gZmFsbCBiYWNrIHRvIC8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNl cnZlciAtIHdpdGggdGhlIHNhbWUgZXZhbHVhdGlvbiBydWxlcy4gVGhpcyBhbHNvIG1lYW5zIHRo YXQgYW4gQVMgdGhhdCBlaXRoZXIgdXNlcyBNVExTIG9ubHksIGlzIHdpbGxpbmcgdG8gdXNlIG9w dGlvbmFsIGNsaWVudCBjZXJ0aWZpY2F0ZXMvdXBncmFkaW5nLCB1c2VzIEhUVFAgcmVkaXJlY3Rz IG9yIGRvZXMgbm90IHN1cHBvcnQgTVRMUyB3b3VsZCBzdGlsbCBwdWJsaXNoIGEgc2luZ2xlIGRp c2NvdmVyeSBlbmRwb2ludC4NCg0KVGhlIGRyYXdiYWNrIHRvIHRoaXMgYXBwcm9hY2ggaXMgdGhh dCB0aGVyZSBhcmUgbXVsdGlwbGUgZGlzY292ZXJ5IGRvY3VtZW50cyBvZiB0aGUgQVMgLSBidXQg dGhlcmUgYXJlIGFscmVhZHkgbXVsdGlwbGUgZG9jdW1lbnRzIGludm9sdmVkIC0gYm90aCBhZGRp dGlvbmFsIG1ldGFkYXRhIHJlZmVyZW5jZWQgc3VjaCBhcyBhIEpXS1MgZW5kcG9pbnQsIGFuZCB0 aGUgcG90ZW50aWFsIHRoYXQgaW1wbGVtZW50YXRpb25zL3NwZWNpZmljYXRpb25zIHRoYXQgZXh0 ZW5kIE9BdXRoIChzdWNoIGFzIE9wZW5JRCBDb25uZWN0KSBoYXZlIHNlcGFyYXRlIHN1ZmZpeGVz IGFuZCBkaXNjb3ZlcnkgZGF0YS4NCg0KLURXDQoNCk9uIEZlYiAxNSwgMjAxOSwgYXQgMTI6NTcg UE0sIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzpnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KSnVzdCB0 byBtYWtlIHN1cmUgSSB1bmRlcnN0YW5kLi4uDQoNCklmIHRoZSBBUyBPTkxZIHN1cHBvcnRzIE1U TFMgZW5kcG9pbnRzLCB0aGVuIGl0Li4uDQogICAqIHNldHMgJ3Rva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kc19zdXBwb3J0ZWQnIHRvICd0bHNfY2xpZW50X2F1dGgnDQogICAqIGRvZXMgTk9UIHNw ZWNpZnkgdGhlIG1sdHNfZW5kcG9pbnRzIHNlY3Rpb24NCg0KSWYgdGhlIEFTIGRvZXMgTk9UIHN1 cHBvcnQgTVRMUyBlbmRwb2ludHMsIHRoZW4gaXQuLi4NCiAgICAqIGRvZXMgTk9UIHNwZWNpZnkg YSB2YWx1ZSBvZiAndGxzX2NsaWVudF9hdXRoJyBpbiB0aGUgJ3Rva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kc19zdXBwb3J0ZWQnDQogICAgKiBkb2VzIE5PVCBzcGVjaWZ5IHRoZSBtbHRzX2VuZHBv aW50cyBzZWN0aW9uDQoNCklmIHRoZSBBUyBzdXBwb3J0cyBCT1RIICJyZWd1bGFyIiBhbmQgTVRM UyBlbmRwb2ludHMsIHRoZW4gaXQuLi4NCiAgICAqIHNldHMgJ3Rva2VuX2VuZHBvaW50X2F1dGhf bWV0aG9kc19zdXBwb3J0ZWQnIHRvICJjbGllbnRfc2VjcmV0X2Jhc2ljIHRsc19jbGllbnRfYXV0 aCIgKGFzIGFuIGV4YW1wbGUpDQogICAgKiBzcGVjaWZpZXMgbXRsc19lbmRwb2ludHMgaW4gYWRk aXRpb24gdG8gdGhlIGVuZHBvaW50cyBub3JtYWxseSBkZWZpbmVkIGZvciB0aGUgQVMNCg0KRm9y IHRoZSBjbGllbnQsIGlmIGl0IHN1cHBvcnRzIG10bHMgQU5EIGlmIGl0IGZpbmRzICd0bHNfY2xp ZW50X2F1dGgnIGluIHRoZSAndG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCcg dGhlbiBpdCBmaXJzdCBsb29rcyB0byBzZWUgaWYgYW4gbXRsc19lbmRwb2ludHMgb2JqZWN0IGlz IHByb3ZpZGVkIGFuZCBpZiBzbyB1c2VzIHRob3NlIGVuZHBvaW50cywgb3RoZXJ3aXNlIGl0IGFz c3VtZXMgdGhlIFJGQyA4NDE0IGRlZmluZWQgZW5kcG9pbnRzIHN1cHBvcnQgTUxUUy4NCg0KTm93 IGlmIHRoZSAnbXRsc19lbmRwb2ludHMnIHNlY3Rpb24gZGVmaW5lcyBhICdtdGxzX3Rva2VuX2Vu ZHBvaW50JyBidXQgbm90IGFuICdpbnRyb3NwZWN0aW9uX2VuZHBvaW50JyBidXQgdGhlIFJGQyA4 NDE0IG1ldGEtZGF0YSBkb2VzIHNwZWNpZnkgYW4gJ2ludHJvc3BlY3Rpb25fZW5kcG9pbnQnLCBp cyB0aGUgY2xpZW50IHN1cHBvc2VkIHRvIGFzc3VtZSB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2lu dCBhbHNvIHN1cHBvcnRzIE1UTFMgZXZlbiB0aG91Z2ggaXQgd2Fzbid0IGxpc3RlZCBpbiB0aGUg J210bHNfZW5kcG9pbnRzJyBvYmplY3Q/IG9yIHNob3VsZCBpdCBhc3N1bWUgdGhhdCBlbmRwb2lu dCBkb2VzIE5PVCBzdXBwb3J0IE1UTFMgYmVjYXVzZSBpdCdzIG5vdCBwYXJ0IG9mIHRoZSAnbXRs c19lbmRwb2ludHMnIG9iamVjdD8NCg0KSXQgd2lsbCB3b3JrLCB0aG91Z2ggaXQgc3RpbGwgZmVl bHMgImhhY2t5IiBhbmQgb3Zlcmx5IGNvbXBsZXguDQoNClRoYW5rcywNCkdlb3JnZQ0KT24gMi8x NS8xOSAyOjQyIFBNLCBQaGlsIEh1bnQgd3JvdGU6DQpUaGlzIGlzIHdoYXQgSSB3b3VsZCBleHBl Y3QuDQpQaGlsDQoNCk9uIEZlYiAxNSwgMjAxOSwgYXQgMTE6MzIgQU0sIEZpbGlwIFNrb2thbiA8 cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52YS5pcEBnbWFpbC4uY29tPj4gd3JvdGU6DQpI ZWxsbyBHZW9yZ2UsDQoNCldoYXQgZG8geW91IHRoaW5rIGFib3V0IHdoYXQgaSB3cm90ZSBlYXJs aWVyPw0KDQpjbGllbnRzIG5vdCBoYXZpbmcgbXRscyBjYXBhYmlsaXRpZXMgd29uJ3QgY2FyZSBh Ym91dCB0aGUgYWRkaXRpb25hbCBtZXRob2QgbWVtYmVycyBiZWluZyBwcmVzZW50LiBDbGllbnRz IHRoYXQgZG8gaW1wbGVtZW50IG10bHMgYnkgdGhlIHNwZWNpZmljYXRpb24gd2lsbCBrbm93IHRv IGxvb2sgZm9yIG10bHNfZW5kcG9pbnRzIGFuZCBmYWxsIGJhY2sgdG8gcmVndWxhciBvbmVzIGlm IHRoZSBzcGVjaWZpYyBlbmRwb2ludCBvciBtdGxzX2VuZHBvaW50cyByb290IHByb3BlcnR5IGlz IG5vdCBwcmVzZW50Lg0KDQpTIHBvemRyYXZlbSwNCkZpbGlwIFNrb2thbg0KDQoNCk9uIEZyaSwg MTUgRmViIDIwMTkgYXQgMjA6MjksIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29t QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToN Ckkgc3RpbGwgZG9uJ3Qgc2VlIGhvdyB3ZSBzb2x2ZSBvbmUgb2YgdGhlIHVzZSBjYXNlcyBBbm5h YmVsbGUgYnJvdWdodCB1cC4NCg0KSWYgdGhlICdtdGxzX2VuZHBvaW50cycgb2JqZWN0IGp1c3Qg Y29udGFpbnMgZW5kcG9pbnRzLCB0aGVuIGluIHRoZSBtYWluIG1ldGEtZGF0YSBzZWN0aW9uLCBz aG91bGQgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQnIGluY2x1ZGUgYW4g aW5kaWNhdGlvbiBvZiAndGxzX2NsaWVudF9hdXRoJyBldmVuIHRob3VnaCB0aGUgZW5kcG9pbnQg c3BlY2lmaWVkIGJ5ICd0b2tlbl9lbmRwb2ludCcgZG9lcyBOT1Qgc3VwcG9ydCBNVExTPw0KDQpU aGFua3MsDQpHZW9yZ2UNCk9uIDIvMTQvMTkgNjowOCBQTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6 DQpNYXliZSBJJ20gd3JvbmcgaGVyZSAoaXQncyBuZXZlciBvdXQgb2YgdGhlIHF1ZXN0aW9uKSBi dXQgYmFzZWQgb24gdGhpcyBwcmV2aW91cyBtZXNzYWdlPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuLmlldGYub3JnX2FyY2hf bXNnX29hdXRoX2VxT1RxNzRoYkh6OU12LTVGVXpoa3ZpM3pnRVFNJmQ9RHdNRmFRJmM9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0 RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJeGhJMS1Z dmJPa2lnczdxTHdQSnhjJnM9c1dHRVRPelhiSTdMWnotb1FiR3FPMmtFRFFrSEVybXJtQWFrYUVl R0lJdyZlPT4gYW5kIHRoaXMgb25lPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuLmlldGYub3JnX2FyY2hfbXNnX29hdXRoX05K cVc5a0l2eExSay0yRDRwaUM5LTJESHNSN3dsck0mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FM d1BKeGMmcz1WdFVYY0xsSVBwbi10V2hYbjFuMDZzTFFzbU9aNnZqcENKVUgySHZvZUFNJmU9PiBJ IGJlbGlldmUgdGhhdCBhY3R1YWxseSB5b3UgYXJlIGJvdGggaW4gZmF2b3IgKGdlbmVyYWxseSBh bnl3YXkpIG9mIHRoZSBwcm9wb3NhbCB3aXRoIHRoZSBvcHRpb25hbCAibXRsc19lbmRwb2ludHMi IHBhcmFtZXRlci4gV2hpbGUgSSBiZWxpZXZlIHRoYXQgdGhlIGNvbW1lbnQgYWJvdXQgb3B0aW9u YWxpdHkgYW5kIGNvbXBsZXhpdHkgd2FzIG1lYW50IHRvIGJlIGEgbW9yZSBnZW5lcmFsIHJlbWFy ay4gV2hpbGUgSSBjYW4gY2VydGFpbmx5IGFwcHJlY2lhdGUgYSBkZXNpcmUgdG8ga2VlcCB0aGlu Z3Mgc2ltcGxlLCBJIGRvIHJlZ3JldCB0aGF0IHRoaXMgdGhyZWFkIHRvb2sgYSB0dXJuIHRvd2Fy ZHMgcGVyc29uYWwuIFdoZXRoZXIgaXQgd2FzIHRoZSBpbnRlbnQgb3Igbm90LCB0aGVyZSdzIGFu IGltcGFjdC4NCg0KDQoNCk9uIFRodSwgRmViIDE0LCAyMDE5IGF0IDEwOjIwIEFNIFBoaWwgSHVu dCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3Jv dGU6DQpJIGZlZWwgSSBoYXZlIHRvIGRpc2FncmVlLiAgSSBhZ3JlZSB0aGF0IG9wdGlvbmFsaXR5 IGlzIG9mdGVuIGNvbXBsZXhpdHkgYW5kIHNob3VsZCBiZSBhdm9pZGVkLiBCdXQsIEkgdGhpbmsg dGhlIG9wdGlvbmFsaXR5IGhlcmUgaXMgYW4gYWdpbGl0eSBmZWF0dXJlIGFsbG93aW5nIG10bHMg dG8gd29yayBhY3Jvc3MgYSBkaXZlcnNpZmllZCBtYXJrZXQgb2YgZGlmZmVyZW50IHR5cGVzIG9m IHRscyB0ZXJtaW5hdG9ycyB3aXRoIHZhcnlpbmcgY2FwYWJpbGl0eS4gTGFjayBvZiBhcHByb3By aWF0ZSBkaXNjb3Zlcnkvb3B0aW9ucyBjb3VsZCBzZXJ2ZSB0byBtYWtlIHRoZSBzcGVjIHVudXNh YmxlIGluIG1hbnkgY2FzZXMuDQoNCkEgY29tcGxpY2F0aW5nIGZhY3RvciB3aXRoIHRscyBpcyB0 aGF0IGEgdGxzIGxheWVyIGZhaWx1cmUgcHJldmVudHMgdGhlIEFTIGZyb20gaXNzdWluZyBhIGNv cnJlY3RpbmcgZGlyZWN0aXZlIGxpa2UgYW4gaHR0cCBlcnJvciBvciBodHRwIHJlZGlyZWN0Lg0K DQpXZSBoYXZlIHRvIGJlIHN1cmUgbm90IHRvIGJyZWFrIGV4aXN0aW5nIGNsaWVudHMgc28gd2Ug bWF5IGluIHNvbWUgY2FzZXMgbmVlZCBtdGxzIG9ubHkgZW5kcG9pbnRzLiBJIGFtIG5vdCBmYXIg ZW5vdWdoIGFsb25nIHRvIGtub3cgZm9yIHN1cmUuIEJ1dCBJIHRlbmQgdG8gYWdyZWUgd2l0aCBC cmlhbiBvbiB0aGlzLg0KDQpUaGlzIG1heSBiZSBhIHNpZ24gd2UgbmVlZCBtb3JlIGltcGxlbWVu dGF0aW9uIGRhdGEgKGluY2x1ZGluZyBmcm9tIHRscyB3ZykgdG8gbWFrZSB0aGUgcmlnaHQgY2Fs bC4NCg0KUGhpbA0KDQpPbiBGZWIgMTQsIDIwMTksIGF0IDg6NTYgQU0sIERvbWluaWNrIEJhaWVy IDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2Uu Y29tPj4gd3JvdGU6DQpTb3JyeSAtIHRoaXMgd2FzIG5vdCBtZWFudCB0byBiZSBzbmlkZSBhdCBh bGwuDQoNCkl0IHdhcyBob25lc3QgZmVlZGJhY2sgdGhhdCB5b3UgYWxzbyBuZWVkIHRvIGtlZXAg c29mdHdhcmUgY29tcGxleGl0eSBpbiBtaW5kIHdoZW4gY3JlYXRpbmcgYSBzcGVjLiBFdmVyeSBN QVkgb3IgT1BUSU9OQUwsIG9yIGRvIGl0IGxpa2UgdGhpcyBPUiB0aGF0LCBvciBzZW5kIHZhbHVl cyBpbiBhcmJpdHJhcnkgb3JkZXIgYWRkcyB0byBjb21wbGV4aXR5LiBDb21wbGV4aXR5IGlzIHRo ZSBuYXR1cmFsIGVuZW15IG9mIHNlY3VyaXR5Lg0KDQpDaGVlcnMNCuKAlOKAlOKAlA0KRG9taW5p Y2sNCg0KDQpPbiAxMy4gRmVicnVhcnkgMjAxOSBhdCAyMDozOToxNiwgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgKHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5j b20+KSB3cm90ZToNClRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBwcm9wb3NhbCB2aW9sYXRlcyB0aGUg c3RhbmRhcmQgYnkgY2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiBhIHBhcmFtZXRlciBpdCBkZWZp bmVzLiBXZSBzaG91bGQgYmUgdmVyeSwgdmVyeSwgVkVSWSBjYXJlZnVsIGFib3V0IHRlbGxpbmcg aW1wbGVtZW50ZXJzIHRvIHZpb2xhdGUgYW4gZXhpc3Rpbmcgc3RhbmRhcmQuLi4gVGhpcyBjaGFu Z2UgbWlnaHQgcHJvdmUgaW5jb21wYXRpYmxlIHdpdGggZXhpc3Rpbmcgb3IgZnV0dXJlIGltcGxl bWVudGF0aW9ucyBvZiA4NDE0LCBpdCBtaWdodCBub3QsIGJ1dCBieSB2aW9sYXRpbmcgdGhlIHN0 YW5kYXJkIHRoZSBwcm9wb3NhbCBjcmVhdGVzIGFuIG9wcG9ydHVuaXR5IGZvciBpbmNvbXBhdGli aWxpdHkgdGhhdCBkaWRu4oCZdCBleGlzdCBiZWZvcmUuDQoNCkFzIGZhciBhcyBzaW1wbGljaXR5 IGlzIGNvbmNlcm5lZCwgSSBmaW5kIGEgc29sdXRpb24gdGhhdCByZXVzZXMgdGhlIGV4aXN0aW5n IGRhdGEgbW9kZWwgYW5kIG5hdHVyYWxseSBzdXBwb3J0cyBleGlzdGluZyBhbmQgZnV0dXJlIGV4 dGVuc2lvbnMgdG8gYmUgZmFyIHNpbXBsZXIgdGhhbiBvbmUgdGhhdCBpbnRyb2R1Y2VzIGFtYmln dW91cyBzZW1hbnRpY3MgdG8gZXhpc3RpbmcgcGFyYW1ldGVycy4gR2VuZXJhbGx5IHNwZWFraW5n LCBkYXRhIG1vZGVscyB3aXRoIHByb3BlcnRpZXMgdGhhdCBtZWFuIGRpZmZlcmVudCB0aGluZ3Mg aW4gZGlmZmVyZW50IGNvbnRleHRzIHRlbmQgdG8gYmUgZnJhZ2lsZSBhbmQgcmVxdWlyZSBtb3Jl IGNvbXBsZXggY29kZSB0byB3b3JrIHdpdGguIEJ1dCB0aGF04oCZcyBqdXN0IG15IGV4cGVyaWVu Y2UgYXMsIHlvdSBrbm93LCBhbiBhY3R1YWwgZGV2ZWxvcGVyLg0KDQpMZXTigJlzIGtlZXAgdGhl IGFzc3VtcHRpb25zIGFuZCBzbmlkZSByZW1hcmtzIGFib3V0IG90aGVyc+KAmSBiYWNrZ3JvdW5k cyBvZmYgdGhlIGxpc3QsIHBsZWFzZS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4N CkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2 aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4NCkRhdGU6IFdlZG5l c2RheSwgRmVicnVhcnkgMTMsIDIwMTkgYXQgNDoxOCBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5j b20+PiwgRmlsaXAgU2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb208bWFpbHRvOnBhbnZhLi5pcEBn bWFpbC5jb20+Pg0KQ2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiwgIlJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1Ympl Y3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gTVRMUyB0b2tlbiBlbmRvaW50 ICYgZGlzY292ZXJ5DQoNCkkgYW0gZm9yIGtlZXBpbmcgaXQgc2ltcGxlIGFuZCBub3QgaW50cm9k dWNpbmcgYW5vdGhlciBsaW5rIHRvIGZvbGxvdy4NCg0KSSBzb21ldGltZXMgd29uZGVyIGhvdyBt YW55IG9mIHRoZSBzcGVjIGF1dGhvcnMgYXJlIGFjdHVhbGx5IGRldmVsb3BlcnMgLSB0aGVzZSBz dWdnZXN0aW9ucyBtYWtlIHNvZnR3YXJlIHVubmVjZXNzYXJ5IGNvbXBsZXggOykNCg0K4oCU4oCU 4oCUDQpEb21pbmljaw0KDQoNCk9uIDEzLiBGZWJydWFyeSAyMDE5IGF0IDEyOjI1OjEzLCBGaWxp cCBTa29rYW4gKHBhbnZhLmlwQGdtYWlsLmNvbTxtYWlsdG86cGFudmEuaXBAZ21haWwuY29tPikg d3JvdGU6DQpIZWxsbywNCg0KQWRkaXRpb25hbGx5LCBhIG1ldGFkYXRhIGRvY3VtZW50IHRoYXQg b21pdHMgdG9rZW5fZW5kcG9pbnQgaW4gZmF2b3Igb2YgbXRsc19lbmRwb2ludHMgc2luY2Ugb25s eSBtVExTIGlzIHN1cHBvcnRlZCB3b3VsZCB2aW9sYXRlIDg0MTQsIGFzIDg0MTQgc2F5cyB0b2tl bl9lbmRwb2ludCDigJxpcyBSRVFVSVJFRCB1bmxlc3Mgb25seSB0aGUgaW1wbGljaXQgZ3JhbnQg dHlwZSBpcyBzdXBwb3J0ZWQu4oCdDQoNCm10bHMgb25seSBBUyBkb2Vzbid0IGdldCBhbnl0aGlu ZyBvdXQgb2YgdXNpbmcgbXRsc19lbmRwb2ludHMsIGl0cyB1c2Ugc2hvdWxkIG5vdCBiZSByZWNv bW1lbmRlZCBmb3Igc3VjaCBBUyBhbmQgcmVndWxhciBlbmRwb2ludHMgd2lsbCBiZSB1c2VkLCB0 aGlzIHNhdGlzZmllcyB0aGUgcmVxdWlyZW1lbnQNCkhlcmUgaXMgb25lIGV4YW1wbGUsIGJhc2Vk IG9uIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIOKAnHN0cmF3IG1hbuKAnSBmb3JtYXQgcHJlc2Vu dGVkIGluIHRoaXMgdGhyZWFkOiBSRkM4NDE0IGRlZmluZXMgdGhlIHZhbHVlIG9mIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgYXMgYSDigJxKU09OIGFycmF5IGNvbnRhaW5p bmcgYSBsaXN0IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIHN1cHBvcnRlZCBieSB0 aGlzIHRva2VuIGVuZHBvaW50LuKAnSBJZiB0aGF0IGFycmF5IGNvbnRhaW5zIOKAnHRsc19jbGll bnRfYXV0aOKAnSBhbmQgdGhlIGVuZHBvaW50IHNwZWNpZmllZCBpbiB0b2tlbl9lbmRwb2ludCBk b2VzIG5vdCBzdXBwb3J0IG1UTFMsIHRoZW4gdGhhdCBtZXRhZGF0YSB2aW9sYXRlcyA4NDE0LiBZ b3UgY291bGQgYWRkcmVzcyB0aGlzIGJ5IGFkZGluZyBhIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0 aG9kc19zdXBwb3J0ZWQgcGFyYW1ldGVyIHRvIHRoZSBtdGxzX2VuZHBvaW50cyBvYmplY3QsIGFu ZCBsaWtld2lzZSBmb3IgdGhlIG90aGVyIGVuZHBvaW50cyBhbmQgYXV0aCBtZXRob2RzLiBJZiB5 b3UgdGFrZSB0aGF0IHRvIGl0cyBsb2dpY2FsIGNvbmNsdXNpb24sIHlvdSBlbmQgdXAgd2l0aCBh IGNvbXBsZXRlIG1ldGFkYXRhIGRvY3VtZW50IGhhbmdpbmcgb2ZmIG9mIG10bHNfZW5kcG9pbnRz LiBJdOKAmXMgdGhhdCBsaW5lIG9mIHRob3VnaHQgdGhhdCBsZWQgbWUgdG8gc3VnZ2VzdCBqdXN0 IHBvaW50aW5nIHRvIGFuIGFsdGVybmF0ZSBkb2N1bWVudC4NCg0KQXNzdW1pbmcgd2UgZ28gd2l0 aCB1c2luZyB0aGUgc2FtZSByb290IGF1dGggbWV0aG9kcyBwcm9wZXJ0eSwgd2hhdCdzIHRoZSBp c3N1ZT8gQ2xpZW50cyBub3QgaGF2aW5nIG10bHMgY2FwYWJpbGl0aWVzIHdvbid0IGNhcmUgYWJv dXQgdGhlIGFkZGl0aW9uYWwgbWV0aG9kIG1lbWJlcnMgYmVpbmcgcHJlc2VudC4gQ2xpZW50cyB0 aGF0IGRvIGltcGxlbWVudCBtdGxzIGJ5IHRoZSBzcGVjaWZpY2F0aW9uIHdpbGwga25vdyB0byBs b29rIGZvciBtdGxzX2VuZHBvaW50cyBhbmQgZmFsbCBiYWNrIHRvIHJlZ3VsYXIgb25lcyBpZiB0 aGUgc3BlY2lmaWMgZW5kcG9pbnQgb3IgbXRsc19lbmRwb2ludHMgcm9vdCBwcm9wZXJ0eSBpcyBu b3QgcHJlc2VudC4NCg0KSSBnYXZlIGBtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YWAgcm91dGUgYSB0 aG91Z2h0IGFuZCBkb24ndCBzZWUgaG93IGl0IGhlbHBzLCBnaXZlbiB0aGUgdHdvIGFib3ZlIGFy ZSBub24taXNzdWVzIChteSAkLjAyKSBhbm90aGVyIGRpc2NvdmVyeSBkb2N1bWVudCBvbmx5IGJy aW5ncyBtb3JlIG9mIHRoZW0gc2luY2UgZXZlcnkgcHJvcGVydHkgY2FuIG5vdyBiZSBkaWZmZXJl bnQsIG5vdCBqdXN0IHRoZSBlbmRwb2ludHMuDQoNClMgcG96ZHJhdmVtLA0KRmlsaXAgU2tva2Fu DQoNCg0KT24gV2VkLCAxMyBGZWIgMjAxOSBhdCAwMDowMCwgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3 cm90ZToNCkhlcmUgaXMgb25lIGV4YW1wbGUsIGJhc2VkIG9uIG15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIOKAnHN0cmF3IG1hbuKAnSBmb3JtYXQgcHJlc2VudGVkIGluIHRoaXMgdGhyZWFkOiBSRkM4 NDE0IGRlZmluZXMgdGhlIHZhbHVlIG9mIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBw b3J0ZWQgYXMgYSDigJxKU09OIGFycmF5IGNvbnRhaW5pbmcgYSBsaXN0IG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBtZXRob2RzIHN1cHBvcnRlZCBieSB0aGlzIHRva2VuIGVuZHBvaW50LuKAnSBJ ZiB0aGF0IGFycmF5IGNvbnRhaW5zIOKAnHRsc19jbGllbnRfYXV0aOKAnSBhbmQgdGhlIGVuZHBv aW50IHNwZWNpZmllZCBpbiB0b2tlbl9lbmRwb2ludCBkb2VzIG5vdCBzdXBwb3J0IG1UTFMsIHRo ZW4gdGhhdCBtZXRhZGF0YSB2aW9sYXRlcyA4NDE0LiBZb3UgY291bGQgYWRkcmVzcyB0aGlzIGJ5 IGFkZGluZyBhIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgcGFyYW1ldGVy IHRvIHRoZSBtdGxzX2VuZHBvaW50cyBvYmplY3QsIGFuZCBsaWtld2lzZSBmb3IgdGhlIG90aGVy IGVuZHBvaW50cyBhbmQgYXV0aCBtZXRob2RzLiBJZiB5b3UgdGFrZSB0aGF0IHRvIGl0cyBsb2dp Y2FsIGNvbmNsdXNpb24sIHlvdSBlbmQgdXAgd2l0aCBhIGNvbXBsZXRlIG1ldGFkYXRhIGRvY3Vt ZW50IGhhbmdpbmcgb2ZmIG9mIG10bHNfZW5kcG9pbnRzLiBJdOKAmXMgdGhhdCBsaW5lIG9mIHRo b3VnaHQgdGhhdCBsZWQgbWUgdG8gc3VnZ2VzdCBqdXN0IHBvaW50aW5nIHRvIGFuIGFsdGVybmF0 ZSBkb2N1bWVudC4NCg0KQWRkaXRpb25hbGx5LCBhIG1ldGFkYXRhIGRvY3VtZW50IHRoYXQgb21p dHMgdG9rZW5fZW5kcG9pbnQgaW4gZmF2b3Igb2YgbXRsc19lbmRwb2ludHMgc2luY2Ugb25seSBt VExTIGlzIHN1cHBvcnRlZCB3b3VsZCB2aW9sYXRlIDg0MTQsIGFzIDg0MTQgc2F5cyB0b2tlbl9l bmRwb2ludCDigJxpcyBSRVFVSVJFRCB1bmxlc3Mgb25seSB0aGUgaW1wbGljaXQgZ3JhbnQgdHlw ZSBpcyBzdXBwb3J0ZWQu4oCdDQoNCkl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgbXRsc19l bmRwb2ludHMgcGFyYW1ldGVyIHN1Y2ggdGhhdCB0aGUgYWJvdmUgdXNlIGNhc2VzIGFyZSBpbnZh bGlkLCBidXQgdGhhdCBkb2VzIG1ha2UgdGhlIGRvY3VtZW50IG1vcmUgY29tcGxpY2F0ZWQuLiBJ ZiB3ZSBnbyB0aGUg4oCcbXRsc19hbHRlcm5hdGVfbWV0YWRhdGHigJ0gcm91dGUsIHdlIGNhbiBz a2lwIHBhc3QgYWxsIG9mIHRoZXNlIGlzc3VlcywgYmVjYXVzZSBpdCBicmluZ3MgdXMgYmFjayB0 byBqdXN0IHBhcnNpbmcgdGhlIHNhbWUgbWV0YWRhdGEgdGhhdCB3ZSBkbyB0b2RheS4NCg0KLS0N CkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRo IDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52 YS5pcEBnbWFpbC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQgMTox MyBQTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4N CkNjOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4sIG9hdXRo IDxvYXV0aEBpZXRmLi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2NvdmVyeQ0KDQpIaSBBbm5hYmVsbGUs DQoNCmNhbiB5b3UgZWxhYm9yYXRlIHdoYXQgd291bGQgYmUgdGhlIHZpb2xhdGlvbiAvIG5lZ2F0 aXZlIGltcGFjdCBvZiB1c2FnZSBvZiBSRkM4NDE0Pw0KDQpBcyBpdCBhbHJlYWR5IG1ha2VzIHVz ZSBvZiBgc2lnbmVkX21ldGFkYXRhYCBhbmQgdGhpcyBsYW5ndWFnZSBpcyBwcmVzZW50IC4uLi4N Cg0KPiBDb25zdW1lcnMgb2YgdGhlIG1ldGFkYXRhIE1BWSBpZ25vcmUgdGhlIHNpZ25lZCBtZXRh ZGF0YSBpZiB0aGV5IGRvIG5vdCBzdXBwb3J0IHRoaXMgZmVhdHVyZS4gIElmIHRoZSBjb25zdW1l ciBvZiB0aGUgbWV0YWRhdGEgc3VwcG9ydHMgc2lnbmVkIG1ldGFkYXRhLCBtZXRhZGF0YSB2YWx1 ZXMgY29udmV5ZWQgaW4gdGhlIHNpZ25lZCBtZXRhZGF0YSBNVVNUIHRha2UgcHJlY2VkZW5jZSBv dmVyIHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlcyBjb252ZXllZCB1c2luZyBwbGFpbiBKU09OIGVs ZW1lbnRzLg0KDQouLi4uIHdvdWxkIG10bHNfZW5kcG9pbnRzIGJlIGFueSBkaWZmZXJlbnQ/IENs aWVudHMgYXJlIGZyZWUgdG8gaWdub3JlIHRoaXMgaWYgdGhleSBkb24ndCBzdXBwb3J0L3VzZSBt dGxzLCBhbmQgaWYgdGhleSBkbyB0aG9zZSB2YWx1ZXMgbXVzdCB0YWtlIHByZWNlZGVuY2Ugb3Zl ciB0aGUgcm9vdCBvbmVzLiB0aGUgdXNlIG9mIG10bHNfZW5kcG9pbnRzIHdvdWxkIG5vdCBiZSBy ZWNvbW1lbmRlZCBmb3IgbXRscy1vbmx5IEFTIGJ1dCByZWNvbW1lbmRlZCBmb3Igb25lIHdpdGgg Ym90aCBtdGxzL3JlZ3VsYXIgYXV0aGVudGljYXRpb24gbWV0aG9kcy4gdG9rZW5fZW5kcG9pbnQg cmVtYWlucyByZXF1aXJlZCBmb3IgYWxsIGludGVudHMgYW5kIHB1cnBvc2VzLiBBbmQgYXMgZm9y IHRoZSB1c2FibGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgLSB0aGV5IHNob3VsZCBh bGwgYmUgbGlzdGVkLCBvciBkbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHNlcGFyYXRlIHRoZSBvbmVz IGZvciBlYWNoIGhvc3RuYW1lL3BvcnQgbG9jYXRpb24/IFRvIHdoYXQgZW5kPyBJcyB0aGVyZSBh IHJpc2sgaGF2aW5nIHRoZSBtdGxzIGhvc3RuYW1lL3BvcnQgYWNjZXB0aW5nIHJlZ3VsYXIgcmVx dWVzdHM/IE90aGVyIHRoZW4gc2VjcmV0L2tleSBfand0IGF1dGggbWV0aG9kcyBhc3NlcnRpb24g YXVkIGNsYWltIHRoZSBlbmRwb2ludCBsb2NhdGlvbiBkb2Vzbid0IHBsYXkgYSByb2xlIGluIHRo ZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLg0KDQpCZXN0LA0KRmlsaXANCg0KDQpPbiBUdWUsIDEy IEZlYiAyMDE5IGF0IDIwOjQ3LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9 NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmc+PiB3cm90ZToNCknigJltIG5vdCBvcHBvc2VkIHRvIGludHJvZHVjaW5nIGEgbWV0YWRh dGEgY2hhbmdlLCBpZiB0aGUgc2NlbmFyaW8gaXMgcmVsZXZhbnQgYW5kIG90aGVyIGFwcHJvYWNo ZXMgY2Fu4oCZdCBhZGVxdWF0ZWx5IGFkZHJlc3MgaXQg4oCTIGFuZCBJ4oCZbGwgcmVhZGlseSBn cmFudCB0aGF0IHdlIHByb2JhYmx5IGRvbuKAmXQgd2FudCB0byBkZXBlbmQgb24gY29uc2lzdGVu Y3kgb2YgYnJvd3NlciBiZWhhdmlvciBhdCB0aGUgaW50ZXJzZWN0aW9uIG9mIGNsaWVudCBjZXJ0 aWZpY2F0ZXMgYW5kIEFjY2Vzcy1Db250cm9sLUFsbG93LUNyZWRlbnRpYWxzLiBCdXQgY2FyZSBu ZWVkcyB0byBiZSB0YWtlbiBpbiBkZXNpZ25pbmcgdGhhdCBtZXRhZGF0YSB0byBhdm9pZCB2aW9s YXRpbmcgb3Igb3RoZXJ3aXNlIG5lZ2F0aXZlbHkgaW1wYWN0aW5nIHVzYWdlIG9mIFJGQzg0MTQu DQoNCkFsb25nIHRob3NlIGxpbmVzLCBpbnN0ZWFkIG9mIGFkZGluZyBhbiDigJxtdGxzX2VuZHBv aW50c+KAnSBtZXRhZGF0YSBwYXJhbWV0ZXIsIHdlIGNvdWxkIGFkZCBhbiDigJxtdGxzX2FsdGVy bmF0ZV9tZXRhZGF0YeKAnSBwYXJhbWV0ZXIgd2hvc2UgdmFsdWUgaXMgdGhlIFVSTCBvZiBhbiBh bHRlcm5hdGUgbWV0YWRhdGEgZG9jdW1lbnQgaW50ZW5kZWQgZm9yIGNsaWVudHMgdXNpbmcgbVRM Uy4gQW4gbVRMUy1vcHRpb25hbCBBUyBjb3VsZCBoYXZlIHR3byBkaWZmZXJlbnQgbWV0YWRhdGEg ZG9jdW1lbnRzIGZvciBtVExTIGFuZCBub24tbVRMUyBjbGllbnRzLCByZWR1Y2luZyB0aGUgbVRM Uy1vcHRpb25hbCBzY2VuYXJpbyB0byB0aGUgbVRMUy1vbmx5IHNjZW5hcmlvLiBUaGlzIHNpZGVz dGVwcyB0aGUgY2hhbGxlbmdlcyBvZiBhbGlnbmluZyB0aGUg4oCcZWl0aGVyL29y4oCdIHNlbWFu dGljcyBvZiBtVExTLW9wdGlvbmFsIHdpdGggc29tZSBvZiB0aGUgcmlnaWQgcGFyYW1ldGVyIGRl ZmluaXRpb25zIGluIFJGQzg0MTQgKHNlZTogdG9rZW5fZW5kcG9pbnQsIHRva2VuX2VuZHBvaW50 X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQpLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21h bg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw cGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFy eSAxMiwgMjAxOSBhdCAxMDo1OCBBTQ0KVG86IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rw cml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4NCkNjOiBvYXV0 aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2NvdmVyeQ0KDQpUaGFua3MgZm9yIHRo ZSBpbnB1dCwgRG9taW5pY2suDQoNCkknZCBzYWlkIHByZXZpb3VzbHkgdGhhdCBJIHdhcyBoYXZp bmcgdHJvdWJsZSBhZGVxdWF0ZWx5IGdhdWdpbmcgd2hldGhlciBvciBub3QgdGhlcmUncyBzdWZm aWNpZW50IGNvbnNlbnN1cyB0byBnbyBhaGVhZCB3aXRoIHRoZSB1cGRhdGUuIEkgd2FzIGV2ZW4g dGhpbmtpbmcgb2YgYXNraW5nIHRoZSBjaGFpcnMgYWJvdXQgYSBjb25zZW5zdXMgY2FsbCBkdXJp bmcgdGhlIG9mZmljZSBob3VycyBtZWV0aW5nIHllc3RlcmRheS4gQnV0IGl0IGdvdCBjYW5jZWxl ZC4gQW5kIGxvb2tpbmcgYWdhaW4gYmFjayBvdmVyIHRoZSBkaXNjdXNzaW9uLCBJIGRvbid0IGJl bGlldmUgYSBjb25zZW5zdXMgY2FsbCBpcyBuZWNlc3NhcnkuIFRoZXJlJ3MgYmVlbiBhIGxvdCBv ZiBnZW5lcmFsIGRpc2N1c3Npb24gb3ZlciB0aGUgbGFzdCBzZXZlcmFsIHdlZWtzIGR1cmluZyB3 aGljaCBzZXZlcmFsIGZvbGtzIGhhdmUgc3RhdGVkIHN1cHBvcnQgZm9yIHRoZSBwcm9wb3NhbCB3 aGlsZSB0aGVyZSdzIGJlZW4gb25seSBvbmUgdm9pY2Ugb2YgZGlyZWN0IGRpc3NlbnQuIFRoYXQg c2VlbXMgbGlrZSByb3VnaCBlbm91Z2ggY29uc2Vuc3VzIGFuZCwgYXMgc3VjaCwgSSBwbGFuIHRv IG1ha2UgdGhlIGNoYW5nZSBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnQgKHdo aWNoIHNob3VsZCBiZSBkb25lIHNvb24pLiBDaGFpcnMsIHBsZWFzZSBsZXQgbWUga25vdywgaWYg eW91IGJlbGlldmUgdGhlIHNpdHVhdGlvbiB3YXJyYW50cyBhIGRpZmZlcmVudCBjb3Vyc2Ugb2Yg YWN0aW9uLg0KDQoNCg0KT24gTW9uLCBGZWIgMTEsIDIwMTkgYXQgMTE6MDEgUE0gRG9taW5pY2sg QmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZp bGVnZS5jb20+PiB3cm90ZToNCklNSE8gdGhhdOKAmXMgYSByZWFzb25hYmxlIGFuZCBwcmFnbWF0 aWMgb3B0aW9uLg0KDQpUaGFua3MNCuKAlOKAlOKAlA0KRG9taW5pY2sNCg0KDQpPbiAxMS4gRmVi cnVhcnkgMjAxOSBhdCAxMzoyNjozNywgQnJpYW4gQ2FtcGJlbGwgKGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4pIHdyb3RlOg0KSXQn cyBiZWVuIHBvaW50ZWQgb3V0IHRoYXQgdGhlIHBvdGVudGlhbCBpc3N1ZSBpcyBub3QgaXNvbGF0 ZWQgdG8gdGhlIGp1c3QgdG9rZW4gZW5kcG9pbnQgYnV0IHRoYXQgcmV2b2NhdGlvbiwgaW50cm9z cGVjdGlvbiwgZXRjLiBjb3VsZCBiZSBpbXBhY3RlZCBhcyB3ZWxsLiBTbywgIGF0IHRoaXMgcG9p bnQsIHRoZSBwcm9wb3NhbCBvbiB0aGUgdGFibGUgaXMgdG8gYWRkIGEgbmV3IG9wdGlvbmFsIEFT IG1ldGFkYXRhIHBhcmFtZXRlciBuYW1lZCAnbXRsc19lbmRwb2ludHMnIHRoYXQncyB2YWx1ZSB3 ZSBiZSBhIEpTT04gb2JqZWN0IHdoaWNoIGl0c2VsZiBjb250YWlucyBlbmRwb2ludHMgdGhhdCwg d2hlbiBwcmVzZW50LCBhIGNsaWVudCBkb2luZyBNVExTIHdvdWxkIHVzZSByYXRoZXIgdGhhbiB0 aGUgcmVndWxhciBlbmRwb2ludHMuICBBIHN0cmF3LW1hbiBleGFtcGxlIG1pZ2h0IGxvb2sgbGlr ZSB0aGlzDQp7DQogICJpc3N1ZXIiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbTxodHRwczov L3NlcnZlci5leGFtcGxlLmNvbS8+IiwNCiAgImF1dGhvcml6YXRpb25fZW5kcG9pbnQiOiJodHRw czovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRoeiIsDQogICJ0b2tlbl9lbmRwb2ludCI6Imh0dHBz Oi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgInRva2VuX2VuZHBvaW50X2F1dGhfbWV0 aG9kc19zdXBwb3J0ZWQiOlsgICJjbGllbnRfc2VjcmV0X2Jhc2ljIiwidGxzX2NsaWVudF9hdXRo IiwgIm5vbmUiXSwNCiAgInVzZXJpbmZvX2VuZHBvaW50IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb20vdXNlcmluZm8iLA0KICAicmV2b2NhdGlvbl9lbmRwb2ludCI6Imh0dHBzOi8vc2VydmVy LmV4YW1wbGUuY29tL3Jldm8iLA0KICAiandrc191cmkiOiJodHRwczovL3NlcnZlci5leGFtcGxl LmNvbS9qd2tzLmpzb24iLA0KICAibXRsc19lbmRwb2ludHMiOnsNCiAgICAidG9rZW5fZW5kcG9p bnQiOiJodHRwczovL210bHMuZXhhbXBsZS5jb20vdG9rZW4iLA0KICAgICJ1c2VyaW5mb19lbmRw b2ludCI6Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS91c2VyaW5mbyIsDQogICAgInJldm9jYXRp b25fZW5kcG9pbnQiOiJodHRwczovL210bHMuZXhhbXBsZS5jb20vcmV2bzxodHRwczovL210bHMu Li4uLi4uZXhhbXBsZS5jb20vcmV2bz4iDQogIH0NCn0NCg0KQSBjbGllbnQgZG9pbmcgTVRMUyB3 b3VsZCBsb29rIGZvciBhbmQgZ2l2ZSBwcmVjZWRlbmNlIHRvIGFuIGVuZHBvaW50IHVuZGVyICJt dGxzX2VuZHBvaW50cyIgd2hpbGUgZmFsbGluZyBiYWNrIHRvIHVzZSB0aGUgbm9ybWFsIGVuZHBv aW50IGZyb20gdGhlIHRvcCBsZXZlbCBvZiBtZXRhZGF0YSB3aGVuL2lmIGl0cyBub3QgaW4gIm10 bHNfZW5kcG9pbnRzIi4NCg0KVGhlIGlkZWEgYmVpbmcgdGhhdCAicmVndWxhciIgY2xpZW50cyAo dGhvc2Ugbm90IGRvaW5nIE1UTFMpIHdpbGwgdXNlIHRoZSByZWd1bGFyIGVuZHBvaW50cy4gQW5k IG9ubHkgdGhlIGhvc3QvcG9ydCBvZiB0aGUgZW5kcG9pbnRzIGxpc3RlZCBpbiBtdGxzX2VuZHBv aW50cyB3aWxsIGJlIHNldCB1cCB0byByZXF1ZXN0IFRMUyBjbGllbnQgY2VydGlmaWNhdGVzIGR1 cmluZyBoYW5kc2hha2UuIFRodXMgYW55IHBvdGVudGlhbCBpbXBhY3Qgb2YgdGhlIENlcnRpZmlj YXRlUmVxdWVzdCBtZXNzYWdlIGJlaW5nIHNlbnQgaW4gdGhlIFRMUyBoYW5kc2hha2UgY2FuIGJl IGF2b2lkZWQgZm9yIGFsbCB0aGUgb3RoZXIgcmVndWxhciBjbGllbnRzIHRoYXQgYXJlIG5vdCBn b2luZyB0byBkbyBNVExTIC0gaW5jbHVkaW5nIGFuZCBtb3N0IGltcG9ydGFudGx5IGluLWJyb3dz ZXIgamF2YXNjcmlwdCBjbGllbnRzIHdoZXJlIHRoZXJlIGNhbiBiZSBsZXNzIHRoYW4gZGVzaXJh YmxlIFVJIHByZXNlbnRlZCB0byB0aGUgZW5kLXVzZXIuDQoNCkknbSBzdHJ1Z2dsaW5nLCBob3dl dmVyLCB0byBhZGVxdWF0ZWx5IGdhdWdlIHdoZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVu dCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBUaGVyZSdzIGJlZW4gc29t ZSBzdXBwb3J0IGZvciBpdCB2b2ljZWQuIEFzIHdlbGwgYXMgdGFsayBvZiBvdGhlciBhcHByb2Fj aGVzIHRoYXQgY291bGQgYmUgYWx0ZXJuYXRpdmVzIG9yIGFkZGl0aW9uYWwgbWVhc3VyZXMuIEFu ZCBhbHNvIHNvbWUgdm9jYWwgb3Bwb3NpdGlvbiB0byBpdC4NCg0KDQpPbiBTYXQsIEZlYiA5LCAy MDE5IGF0IDM6MDkgQU0gRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208 bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNCldlIGFyZSBjdXJyZW50 bHkgaW1wbGVtZW50aW5nIE1UTFMgaW4gSWRlbnRpdHlTZXJ2ZXIuDQoNCk91ciBhcHByb2FjaCB3 aWxsIGJlIHRoYXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBvaW50IHRoYXQg c3VwcG9ydHMgY2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGluZyBhbiBvZmZp Y2lhbCBlbmRwb2ludCBuYW1lIGZvciBkaXNjb3Zlcnk/IFJpZ2h0IG5vdyB3ZSBhcmUgdXNpbmcg 4oCcbXRsc190b2tlbl9lbmRwb2ludOKAnS4NCg0KVGhhbmtzDQrigJTigJTigJQNCkRvbWluaWNr DQoNCg0KT24gNy4gRmVicnVhcnkgMjAxOSBhdCAyMjozNjo1NSwgQnJpYW4gQ2FtcGJlbGwgKGJj YW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmJjYW1wYmVs bD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNCkFoIHllcywgdGhh dCBtYWtlcyBzZW5zZS4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nLiBBbmQgaXQgaXMgaW5kZWVkIGEg Z29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5ub2N1b3VzIGNoYW5nZSB0aGF0 IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gYnJlYWsgdGhpbmdzIHVuZXhwZWN0 ZWRseS4uDQoNCg0KDQoNCg0KT24gVGh1LCBGZWIgNywgMjAxOSBhdCA4OjU3IEFNIFJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tPj4gd3JvdGU6DQpUaGUgY2FzZSBJ4oCZbSByZWZlcmVuY2luZyBkaWRu4oCZdCBz cGVjaWZpY2FsbHkgaW52b2x2ZSBBUyBtZXRhZGF0YS4gV2UgaGFkIGNsaWVudHMgaW4gdGhlIHdp bGQgdGhhdCBhc3N1bWVkIHRoYXQgYWxsIHRoZSBwcm9wZXJ0aWVzIGluIHRoZSBKU09OIG9iamVj dCByZXR1cm5lZCBmcm9tIG91ciB1c2VyaW5mbyBlbmRwb2ludCB3ZXJlIHNjYWxhciBzdHJpbmdz LiBUaGlzIGJyb2tlIHdoZW4gd2UgaW50cm9kdWNlZCBhIG5ldyBwcm9wZXJ0eSB3aG9zZSB2YWx1 ZSB3YXMgYSBKU09OIG9iamVjdC4gSXQgd2FzIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBz ZWVtaW5nbHkgaW5ub2N1b3VzIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0 aWJsZSBjYW4gZm9yY2UgbW9yZSB3b3JrIG9uIGNsaWVudHMgdGhhbiB3ZSBleHBlY3QuDQoNCi0t DQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS4uY29tPG1haWx0bzpiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDYsIDIwMTkgYXQg MTE6MzAgQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYT00MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9y Zz4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNv bTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVE IFNFTkRFUl0gUmU6IE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4g ZW5kcG9pbnQNCg0KQW5kIEknbSBob25lc3RseSByZWFsbHkgc3RydWdnbGluZyB0byBzZWUgd2hh dCBjb3VsZCBoYXZlIGdvbmUgd3Jvbmcgd2l0aCBvciBob3cgdG9rZW5fZW5kcG9pbnRfYXV0aF9t ZXRob2RzIGJyb2tlIHNvbWV0aGluZyB3aXRoIHRoZSB1c2VyIGluZm8gZW5kcG9pbnQuIElmIHlv dSBoYXZlIHRoZSB0aW1lIGFuZC9vciBpdCdkIGJlIGluZm9ybWF0aXZlIHRvIHRoaXMgaGVyZSBs aXR0bGUgZGlzY3Vzc2lvbiwgcGxlYXNlIGV4cGxhaW4gdGhhdCBvbmUgYSBiaXQgbW9yZS4NCg0K T24gV2VkLCBGZWIgNiwgMjAxOSBhdCAxMjoxNSBQTSBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3Jv dGU6DQoiZmFyIiBzaG91bGQgaGF2ZSBzYWlkICJmYWlyIiBpbiB0aGUgcHJldmlvdXMgbWVzc2Fn ZQ0KDQoNCg0KDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgNDozNSBQTSBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPj4gd3JvdGU6DQpJdCBtYXkgd2VsbCBiZSBkdWUgdG8gbXkgb3duIGludGVsbGVjdHVh bCBzaG9ydGNvbWluZ3MgYnV0IHRoZXNlIGlzc3Vlcy9xdWVzdGlvbnMvY29uZnVzaW9uLXBvaW50 cyBhcmUgbm90IHJlc29uYXRpbmcgZm9yIG1lIGFzIGJlaW5nIHByb2JsZW1hdGljLg0KDQpUaGUg bW9yZSBnZW5lcmFsIHN0YW5jZSBvZiAidGhpcyBpc24ndCBuZWVkZWQgb3Igd29ydGggaXQgaW4g dGhpcyBkb2N1bWVudCIgKEkgdGhpbmsgdGhhdCdzIGZhcj8pIGlzIGJlaW5nIGhlYXJkIHRob3Vn aC4NCg0KDQoNCk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgMTo0MiBQTSBSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLi5vcmc+PiB3cm90ZToNCihUTDtEUjogcHVudCBBUyBt ZXRhZGF0YSB0byBhIHNlcGFyYXRlIGRyYWZ0KQ0KDQpBUyBwb2ludHMgIzEtMyBhcmUgYWxsIHF1 ZXN0aW9ucyBJIHdvdWxkIGhhdmUgYXMgYW4gaW1wbGVtZW50ZXI6DQoNCiAgMS4gIFNlY3Rpb24g MiBvZiBSRkM4NDE0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM4NDE0LTIzc2VjdGlvbi0yRDImZD1Ed01G YVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hy cUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1nZkw3ZVBBUG9KTmxZWEF1VzF4ZmNyWkwwTWtn aWJ1bnlWZ0lVcmhHT0dnJmU9PiBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVu bGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0gU28gd2hh dCBkb2VzIHRoZSBtVExTLW9ubHkgQVMgcHV0IGhlcmU/DQogIDIuICBUaGUgY2xhaW1zIGZvciB0 aGVzZSBvdGhlciBlbmRwb2ludHMgYXJlIE9QVElPTkFMLCBwb3RlbnRpYWxseSBsZWFkaW5nIHRv IGluY29uc2lzdGVuY3kgZGVwZW5kaW5nIG9uIGhvdyAjMSBnZXRzIGRlY2lkZWQuDQogIDMuICBU aGUgZXhhbXBsZSB1c2FnZSBvZiB0aGUgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIHByb3Bl cnR5IGdpdmVuIGVhcmxpZXIgaXMgaW5jb21wYXRpYmxlIHdpdGggUkZDODQxNCwgc2luY2Ugc29t ZSBvZiBpdHMgY29udGVudHMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBub24tbVRMUyBlbmRwb2lu dHMsIGFuZCBvdGhlcnMgYXJlIG9ubHkgdmFsaWQgZm9yIHRoZSBtVExTIGVuZHBvaW50cy4gSGVu Y2UgdGhpcyBxdWVzdGlvbi4NCiAgNC4gIFRoaXMgaW50cm9kdWNlcyBhIG5ldyBtZXRhZGF0YSBw cm9wZXJ0eSB0aGF0IGNvdWxkIGltcGFjdCBob3cgb3RoZXIgc3BlY3Mgc2hvdWxkIGV4dGVuZCBB UyBtZXRhZGF0YS4gVGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQuDQoNCkkgY291bGQgZ28gb24g Zm9yIGNsaWVudCBwb2ludHMgYnV0IHlvdSBhbHJlYWR5IGdldCB0aGUgcG9pbnQuIFRob3VnaCBJ 4oCZbGwgc2hhcmUgdGhhdCAjMyBpcyByZWFsIGFuZCBvbmNlIGZvcmNlZCBtZSB0byByb2xsIGJh Y2sgYW4gdXBkYXRlIHRvIHRoZSBMb2dpbiB3aXRoIEFtYXpvbiB1c2VyaW5mbyBlbmRwb2ludOKA pmdvb2QgdGltZXMuIPCfmIMNCg0KSSBkb27igJl0IG5lY2Vzc2FyaWx5IHRoaW5rIGFuIEFTIG1l dGFkYXRhIHByb3BlcnR5IGlzIHdyb25nIHBlciBzZSwgYnV0IHVuZGVyc3RhbmQgdGhhdCB5b3Xi gJlyZSBib2x0aW5nIGEgbGF5ZXIgb2YgZmxleGliaWxpdHkgb250byBhIHN0YW5kYXJkIHRoYXQg d2FzbuKAmXQgZGVzaWduZWQgZm9yIHRoYXQsIGFuZCBJIGRvbuKAmXQgdGhpbmsgdGhlIG1ldGFk YXRhIHByb3Bvc2FsIGFzIGl04oCZcyBiZWVuIGRpc2N1c3NlZCBoZXJlIHN1ZmZpY2llbnRseSBk ZWFscyB3aXRoIHRoZSBmYWxsb3V0IGZyb20gdGhhdC4gSW4gbXkgdmlldyB0aGlzIGlzIGEgY29t cGxleCBlbm91Z2ggaXNzdWUgYW5kIGl04oCZcyBmb3IgYSBudWFuY2VkIGVub3VnaCB1c2UgY2Fz ZSAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgZnJvbSBkaXNjdXNzaW9uPyBQbGVhc2UgY29ycmVjdCBt ZSBpZiBJ4oCZbSB3cm9uZykgdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFyYXRlIGRy YWZ0IChlLmcuLCDigJxBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSBFeHRlbnNpb25zIGZv ciBtVExTIEh5YnJpZHPigJ0pIGFuZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuDQoNCi0tDQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJl aGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4NCkRh dGU6IE1vbmRheSwgRmVicnVhcnkgNCwgMjAxOSBhdCA1OjI4IEFNDQpUbzogIlJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRm Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1VO VkVSSUZJRUQgU0VOREVSXSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRo ZSB0b2tlbiBlbmRwb2ludA0KDQpUaG9zZSBwb2ludHMgb2YgY29uZnVzaW9uIHN0cmlrZSBtZSBh cyBzb21ld2hhdCBoeXBvdGhldGljYWwgb3IgaHlwZXJib2xpYy4gQnV0IHlvdXIgZ2VuZXJhbCBw b2ludCBpcyB0YWtlbiBhbmQgeW91ciBwb3NpdGlvbiBvZiBiZWluZyBhbnRpIGFkZGl0aW9uYWwg bWV0YWRhdGEgb24gdGhpcyBpc3N1ZSBpcyBub3RlZC4NCg0KQWxsIG9mIHdoaWNoIGxlYXZlcyBt ZSBhIGJpdCB1bmNlcnRhaW4gYWJvdXQgaG93IHRvIHByb2NlZWQuIFRoZXJlIHNlZW0gdG8gYmUg YSByYW5nZSBvZiBvcGluaW9ucyBvbiB0aGlzIHBvaW50IGFuZCBnYXVnaW5nIGNvbnNlbnN1cyBp cyBwcm92aW5nIGVsdXNpdmUgZm9yIG1lLiBUaGF0J3MgY29uZm91bmRlZCBieSBteSBvd24gb3Bp bmlvbiBvbiBpdCBiZWluZyBzb21ld2hhdCBmbHVpZC4NCg0KQW5kIEknZCByZWFsbHkgbGlrZSB0 byBwb3N0IGFuIHVwZGF0ZSB0byB0aGlzIGRyYWZ0IGFib3V0IGEgbW9udGggb3IgdHdvIGFnby4N Cg0KDQoNCg0KDQoNCk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgNTowMyBQTSBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi4uLi5vcmc+PiB3cm90ZToNCkNvbmZ1c2lvbiBmcm9t IHRoZSBBU+KAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIElmIEkgb25seSBzdXBwb3J0IG1UTFMs IGRvIEkgbmVlZCB0byBpbmNsdWRlIGJvdGggdG9rZW5fZW5kcG9pbnRfdXJpIGFuZCBtdGxzX2Vu ZHBvaW50cz8gU2hvdWxkIEkgb21pdCB0b2tlbl9lbmRwb2ludF91cmk/IE9yIHNldCBpdCB0byB0 aGUgZW1wdHkgc3RyaW5nPw0KICAyLiAgV2hhdCBpZiBJIG9ubHkgc3VwcG9ydCBtVExTIGZvciB0 aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCBub3QgcmV2b2NhdGlvbiBvciB1c2VyIGluZm8/DQogIDMu ICBIb3cgZG8gSSBzcGVjaWZ5IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgZm9yIHRoZSBtVExTIHRv a2VuIGVuZHBvaW50PyBEb2VzIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBhcHBseSB0byBi b3RoIHRoZSBtVExTIGFuZCBub24tbVRMUyBlbmRwb2ludHM/DQogIDQuICBJ4oCZbSB1c2luZyB0 aGUgT0F1dGggMi4wIERldmljZSBGbG93LiBEbyBJIGluY2x1ZGUgYSBtVExTLWVuYWJsZWQgZGV2 aWNlX2F1dGhvcml6YXRpb25fZW5kcG9pbnQgdW5kZXIgbXRsc19lbmRwb2ludHM/DQoNCkNvbmZ1 c2lvbiBmcm9tIHRoZSBjbGllbnTigJlzIHBlcnNwZWN0aXZlOg0KDQogIDEuICBBcyBmYXIgYXMg SSBrbm93LCBJ4oCZbSBhIHB1YmxpYyBjbGllbnQsIGFuZCBkb27igJl0IGtub3cgYW55dGhpbmcg YWJvdXQgbVRMUywgYnV0IHRoZSBJVCBhZG1pbnMgaW5zdGFsbGVkIGNsaWVudCBjZXJ0cyBpbiB0 aGVpciB1c2Vyc+KAmSBicm93c2VycyBhbmQgdGhlIEFTIGV4cGVjdHMgdG8gdXNlIHRoYXQgdG8g YXV0aGVudGljYXRlIG1lLg0KICAyLiAgTXkgQVMgbWV0YWRhdGEgcGFyc2VyIGNyYXNoZWQgYmVj YXVzZSB0aGUgbVRMUy1vbmx5IEFTIG9taXR0ZWQgdG9rZW5fZW5kcG9pbnRfdXJpLi4NCiAgMy4g IE15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0 IHRvIGVuY291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLg0KICA0LiAg VGhlIG1UTFMtb25seSBBUyBkaWRu4oCZdCBwcm92aWRlIGEgdmFsdWUgZm9yIG10bHNfZW5kcG9p bnRzLCB3aGF0IGRvIEkgZG8/DQogIDUuICBJIGRvbuKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKA nSBtZWFucywgYnV0IHRoZXkgdG9sZCBtZSB0byB1c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0 aGUgb25lIHdpdGgg4oCcdGxz4oCdIGluIGl0cyBuYW1lLCByaWdodD8NCg0KWWVzLCB5b3UgY2Fu IHdyaXRlIG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5zd2VycyBtb3N0IG9mIHRoZXNlLiBCdXQgeW91 4oCZbGwgaGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEgbG90IG9mIHNpbWlsYXItYnV0LXNsaWdodGx5 LWRpZmZlcmVudCBzY2VuYXJpb3MgYW5kIGJlIHZlcnkgZXhwbGljaXQuIEFuZCBpbXBsZW1lbnRl cnMgd2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9kdWNl cyBvcHBvcnR1bml0aWVzIGZvciBjb25mdXNpb24gYW5kIGZhaWx1cmUgdGhhdCBkbyBub3QgZXhp c3Qgbm93LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZlcnlvbmUgd2hvIHN1cHBvcnRzIG1UTFMuIElu IGNvbnRyYXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlzIG9ubHkgcmVxdWlyZWQgd2hlbiBhbiBBUyB3 YW50cyB0byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1bmFtYmlndW91cyBpbiBpdHMgYmVoYXZpb3Ig YW5kIG1lYW5pbmcuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRp dHkNCg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn Pj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAzOjE3IFBNDQpUbzogIlJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbT4+DQpDYzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1h aWx0bzpnZmZsZXRjaEBhb2wuY29tPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdH XSBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoN Ckl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxhcmdlIG9mIGEgY2hhbmdl IHRvIG1lIC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0aGUgZ2l2ZW4gZW5kcG9p bnQgaXMgcHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0IHVzZXMgdGhhdCBvbmUu ICBPdGhlcndpc2UgaXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4gQVMg YSBsb3Qgb2YgZmxleGliaWxpdHkgaW4gZGVwbG95bWVudCBvcHRpb25zLiBJIHBlcnNvbmFsbHkg dGhpbmsgZ2V0dGluZyBhIDMwNyBhcHByb2FjaCBkZXBsb3llZCBhbmQgd29ya2luZyB3b3VsZCBi ZSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBwcm9uZS4NCg0KSXQgaXMgYSBtaW5vcml0eSB1 c2UgY2FzZSBhdCB0aGUgbW9tZW50IGJ1dCB0aGVyZSBhcmUgZm9yY2VzIGluIHBsYXksIGxpa2Ug dGhlIHB1c2ggZm9yIGluY3JlYXNlZCBzZWN1cml0eSBpbiBnZW5lcmFsIGFuZCB0byBoYXZlIGph dmFzY3JpcHQgY2xpZW50cyB1c2UgdGhlIGNvZGUgZmxvdywgdGhhdCBzdWdnZXN0IGl0IHdvbid0 IGJlIHRlcnJpYmx5IHVudXN1YWwgdG8gc2VlIGFuIEFTIHRoYXQgd2FudHMgdG8gc3VwcG9ydCBN VExTIGNsaWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNhbWUgdGltZS4N Cg0KSSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQgZm9ydGggaW4gdGhpcyB0aHJlYWQg b24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0YWRhdGEgKG9yIHNvbWV0aGluZyBs aWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkga2luZGEgZXhwbGFpbmVkIHNvbWV3 aGVyZSBiYWNrIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0aHJl YWQuICBCdXQgaXQgc2VlbXMgbGlrZSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSBncm91cCBo ZXJlIGlzIGluIGZhdm9yIG9mIGl0Lg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6 MTggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBk bWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi4ub3JnPj4gd3Jv dGU6DQpUaGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVzaW5nIGNo YW5nZSB0byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2FzZS4gSeKA mW0gZ2V0dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQgbmVlZGVk IHRvIGNsYXJpZnkgd2hlbiB0aGUgQVMgc2hvdWxkIHByb3ZpZGUgYG10bHNfZW5kcG9pbnRzYCBh bmQgd2hlbiB0aGUgY2xpZW50IHNob3VsZCB1c2UgdGhhdCB2ZXJzdXMgdXNpbmcgYHRva2VuX2Vu ZHBvaW50LmAgV2h5IGlzIHRoZSAzMDcgc3RhdHVzIGNvZGUgaW5zdWZmaWNpZW50IHRvIGNvdmVy IHRoZSBjYXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIGJvdGggbVRMUyBhbmQgbm9uLW1U TFM/DQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpG cm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJj LmlldGYub3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBNDQpU bzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOjQwYW9sLmNvbUBkbWFyYy4uLi4uLi4uLi4uLmlldGYub3JnPj4NCkNjOiBvYXV0aCA8b2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIE1UTFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQN Cg0KWWVzLCB0aGF0IHdvdWxkIHdvcmsuDQoNCk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQ TSBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLi5vcmc8bWFp bHRvOjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2hhdCBpZiB0aGUgQVMgd2Fu dHMgdG8gT05MWSBzdXBwb3J0IE1UTFMgY29ubmVjdGlvbnMuIERvZXMgaXQgbm90IHNwZWNpZnkg dGhlIG9wdGlvbmFsICJtdGxzX2VuZHBvaW50cyIgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0 YWRhdGEgdmFsdWVzPw0KT24gMS8xNS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToN Ckl0IHdvdWxkIGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0IHdhc24n dCBtYWRlIGNsZWFyLi4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25h bCBmb3IgdGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2Ug aXQgd2hlbiBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0KDQpPbiBUdWUsIEphbiAxNSwgMjAxOSBh dCAyOjA0IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51azxtYWlsdG86 ZGF2ZS50b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3JvdGU6DQpJJ20gaW4gZmF2b3VyIG9mIHRo ZSBgbXRsc19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhvdWdoIGl0IHNob3Vs ZCBiZSBvcHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4g IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBt ZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5r IHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlx UGtBSTFhTGNMTjRLWk5BJm09eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3 UEp4YyZzPWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmZT0+DQoN Cg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNj bG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklE RU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5k IHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRh Y2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZ IE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVn ZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMp LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5 IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBm cm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTog VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJp YWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj b21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4g VGhhbmsgeW91LiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMm cz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmU9Pg0KDQpDT05G SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUg Ynkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0 YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFu cVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4 aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxw cGs5ZFR1WHFBJmU9Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC4uY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlx UGtBSTFhTGNMTjRLWk5BJm09eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3 UEp4YyZzPWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmZT0+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZt PXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1nQ2M5dEpMVnV1 SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmU9Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmQ9RHdN RmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT14ZUhmWU1DYXdXOWwxaE9I cnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJnM9Z0NjOXRKTFZ1dUs3Q1hVZ3pBXzE5ZkVUX1c2 OVN5VnZMcHBrOWRUdVhxQSZlPT4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0 eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9r aWdzN3FMd1BKeGMmcz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFB JmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1n Q2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmU9Pg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_B1A6967E17D742FC9C67613084CA2F65amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW0tMjkxOTk1ODMyMzkx NzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4 Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwYWlybWFpbG9uLCBsaS5nbWFpbC1tLTI5MTk5 NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3 NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MGFpcm1haWxvbiwgZGl2LmdtYWls LW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05 MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwYWlybWFpbG9uDQoJ e21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tXzg0NjM1 NzIxMTQyMTQ2MTQwNTBnbWFpbC1tXy05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbV8tNDA3NTY3 NjAzNzE0NTc2Mzg4MGFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0 NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYz ODgwYWlybWFpbG9uMCwgbGkuZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1 NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYw MzcxNDU3NjM4ODBhaXJtYWlsb24wLCBkaXYuZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21h aWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1t LTQwNzU2NzYwMzcxNDU3NjM4ODBhaXJtYWlsb24wDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1f LTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tXzg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tXy05 MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbV8tNDA3NTY3NjAzNzE0NTc2Mzg4MGFpcm1haWxvbjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS0yOTE5OTU4 MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQw MjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMyZ21h aWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02 MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1 MzI1NDMxLCBsaS5nbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIx NDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2 Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0y MDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1 NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzEsIGRpdi5nbWFpbC1tLTI5MTk5NTgzMjM5 MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0 ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1t NjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQz MTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0 MzENCgl7bXNvLXN0eWxlLW5hbWU6ImdtYWlsLW1fLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1t Xzg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tXy05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbV8t NDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTcz OTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3 MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzEiOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExMzUyOTA5NTU7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xOTM0NDg2NTUyO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE2OTIzNjg1 NTA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjMxNTIzMzQ4NDt9DQpAbGlzdCBsMg0KCXttc28t bGlzdC1pZDoxNzY3NTgxODU0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozNTgwMDgyMjt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBwcm9ibGVtIHdpdGggdXNpbmcgYSBkaWZmZXJlbnQgc3VmZml4IGZvciBtVExTIGlzIHRo YXQgbVRMUyBhcyBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZm9yIE9BdXRoIDIuMCwgaXQg bWF5IGJlIHVzZWQgYnkgYW55IG51bWJlciBvZiBhcHBsaWNhdGlvbnMgb2YgT0F1dGggMi4wIChl LmcuLCBPcGVuSUQgQ29ubmVjdCkuIEFueSBhcHBsaWNhdGlvbiB0aGF0IGRlZmluZXMgaXRzIG93 biBzdWZmaXgNCiB3b3VsZCBuZWVkIHRvIGFsc28gZGVmaW5lIGFuIG1UTFMtc3BlY2lmaWMgc3Vm Zml4IChlLmcuLCDigJxvYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlci1tdGxz4oCdLCDigJxvcGVu aWQtY29uZmlndXJhdGlvbi1tdGxz4oCdLCDigKYpLiBJZiB0aGUgbVRMUyBwb2ludGVyIGlzIHBh cnQgb2YgdGhlIG1ldGFkYXRhIGRvY3VtZW50IGl0c2VsZiwgdGhlbiBhbGwgYXBwbGljYXRpb25z IGdhaW4gc3VwcG9ydCBmb3IgaXQg4oCcZm9yIGZyZWUu4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBEYXZpZCBXYWl0ZSAmbHQ7ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25z LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxOSBhdCAx MDozMSBQTTxicj4NCjxiPlRvOiA8L2I+R2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD00MGFv bC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5vYXV0aCAmbHQ7b2F1dGhA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFtVTlZFUklG SUVEIFNFTkRFUl0gUmU6IE1UTFMgdG9rZW4gZW5kb2ludCAmYW1wOyBkaXNjb3Zlcnk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYSBwb3Rl bnRpYWwgc2ltcGxpZmljYXRpb24gKGFuZCBhbHRlcm5hdGl2ZSB0byBjb25zaWRlcik6DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8gcGVvcGxl IHRoaW5rIG9mIHRoZSBpZGVhIHRoYXQgTVRMUyBjbGllbnRzIHBlcmZvcm0gZGlzY292ZXJ5IG9m IGEgZGlmZmVyZW50IHN1ZmZpeCAoYXMgYWxsb3dlZCBieSBSRkMgODQxNCkuIEEgTVRMUy1lbmFi bGVkIGNsaWVudCB3b3VsZCBmaXJzdCBsb29rIHVwIG1ldGFkYXRhIGF0IHNheSAmcXVvdDsvLndl bGwta25vd24vbXRscy1vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAnSwgZmFsbGluZyBiYWNr DQogdG8gdGhlIOKAnG9hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIHN1ZmZpeCBpZiB0aGUg c3BlY2lhbGl6ZWQgc3VmZml4IHdhcyBub3QgZm91bmQuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIGV4cGVjdGVkIHRoaXMgdG8gYmUg YSBmdWxsLCBsZWdhbCBkaXNjb3ZlcnkgZG9jdW1lbnQsIHNvIHRoZXJlIGlzIG5vIG1lcmdpbmcg bm9yIGNyb3NzLXBvbGxpbmF0aW9uIG9mIHN1cHBvcnRlZCBmZWF0dXJlcyBvZiB0aGUgdHdvLiBT aG91bGQgaXQgbm90IGJlIGZvdW5kLCBzdWNoIGNsaWVudHMgd291bGQgdGhlbiBmYWxsIGJhY2sg dG8gLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVyDQogLSB3aXRoIHRoZSBz YW1lIGV2YWx1YXRpb24gcnVsZXMuIFRoaXMgYWxzbyBtZWFucyB0aGF0IGFuIEFTIHRoYXQgZWl0 aGVyIHVzZXMgTVRMUyBvbmx5LCBpcyB3aWxsaW5nIHRvIHVzZSBvcHRpb25hbCBjbGllbnQgY2Vy dGlmaWNhdGVzL3VwZ3JhZGluZywgdXNlcyBIVFRQIHJlZGlyZWN0cyBvciBkb2VzIG5vdCBzdXBw b3J0IE1UTFMgd291bGQgc3RpbGwgcHVibGlzaCBhIHNpbmdsZSBkaXNjb3ZlcnkgZW5kcG9pbnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBkcmF3YmFjayB0byB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlIGRp c2NvdmVyeSBkb2N1bWVudHMgb2YgdGhlIEFTIC0gYnV0IHRoZXJlIGFyZSBhbHJlYWR5IG11bHRp cGxlIGRvY3VtZW50cyBpbnZvbHZlZCAtIGJvdGggYWRkaXRpb25hbCBtZXRhZGF0YSByZWZlcmVu Y2VkIHN1Y2ggYXMgYSBKV0tTIGVuZHBvaW50LCBhbmQgdGhlIHBvdGVudGlhbCB0aGF0IGltcGxl bWVudGF0aW9ucy9zcGVjaWZpY2F0aW9ucw0KIHRoYXQgZXh0ZW5kIE9BdXRoIChzdWNoIGFzIE9w ZW5JRCBDb25uZWN0KSBoYXZlIHNlcGFyYXRlIHN1ZmZpeGVzIGFuZCBkaXNjb3ZlcnkgZGF0YS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LURX PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAxNSwgMjAxOSwgYXQgMTI6NTcgUE0s IEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoPTQwYW9sLmNvbUBk bWFyYy5pZXRmLm9yZyI+Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkp1c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZC4u Ljxicj4NCjxicj4NCklmIHRoZSBBUyBPTkxZIHN1cHBvcnRzIE1UTFMgZW5kcG9pbnRzLCB0aGVu IGl0Li4uPGJyPg0KJm5ic3A7Jm5ic3A7ICogc2V0cyAndG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRo b2RzX3N1cHBvcnRlZCcgdG8gJ3Rsc19jbGllbnRfYXV0aCc8YnI+DQombmJzcDsmbmJzcDsgKiBk b2VzIE5PVCBzcGVjaWZ5IHRoZSBtbHRzX2VuZHBvaW50cyBzZWN0aW9uPGJyPg0KPGJyPg0KSWYg dGhlIEFTIGRvZXMgTk9UIHN1cHBvcnQgTVRMUyBlbmRwb2ludHMsIHRoZW4gaXQuLi48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgKiBkb2VzIE5PVCBzcGVjaWZ5IGEgdmFsdWUgb2YgJ3Rsc19jbGll bnRfYXV0aCcgaW4gdGhlICd0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkJzxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAqIGRvZXMgTk9UIHNwZWNpZnkgdGhlIG1sdHNfZW5kcG9p bnRzIHNlY3Rpb248YnI+DQo8YnI+DQpJZiB0aGUgQVMgc3VwcG9ydHMgQk9USCAmcXVvdDtyZWd1 bGFyJnF1b3Q7IGFuZCBNVExTIGVuZHBvaW50cywgdGhlbiBpdC4uLjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyAqIHNldHMgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQnIHRv ICZxdW90O2NsaWVudF9zZWNyZXRfYmFzaWMgdGxzX2NsaWVudF9hdXRoJnF1b3Q7IChhcyBhbiBl eGFtcGxlKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAqIHNwZWNpZmllcyBtdGxzX2VuZHBvaW50 cyBpbiBhZGRpdGlvbiB0byB0aGUgZW5kcG9pbnRzIG5vcm1hbGx5IGRlZmluZWQgZm9yIHRoZSBB Uzxicj4NCjxicj4NCkZvciB0aGUgY2xpZW50LCBpZiBpdCBzdXBwb3J0cyBtdGxzIEFORCBpZiBp dCBmaW5kcyAndGxzX2NsaWVudF9hdXRoJyBpbiB0aGUgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0 aG9kc19zdXBwb3J0ZWQnIHRoZW4gaXQgZmlyc3QgbG9va3MgdG8gc2VlIGlmIGFuIG10bHNfZW5k cG9pbnRzIG9iamVjdCBpcyBwcm92aWRlZCBhbmQgaWYgc28gdXNlcyB0aG9zZSBlbmRwb2ludHMs IG90aGVyd2lzZSBpdCBhc3N1bWVzIHRoZSBSRkMgODQxNCBkZWZpbmVkDQogZW5kcG9pbnRzIHN1 cHBvcnQgTUxUUy48YnI+DQo8YnI+DQpOb3cgaWYgdGhlICdtdGxzX2VuZHBvaW50cycgc2VjdGlv biBkZWZpbmVzIGEgJ210bHNfdG9rZW5fZW5kcG9pbnQnIGJ1dCBub3QgYW4gJ2ludHJvc3BlY3Rp b25fZW5kcG9pbnQnIGJ1dCB0aGUgUkZDIDg0MTQgbWV0YS1kYXRhIGRvZXMgc3BlY2lmeSBhbiAn aW50cm9zcGVjdGlvbl9lbmRwb2ludCcsIGlzIHRoZSBjbGllbnQgc3VwcG9zZWQgdG8gYXNzdW1l IHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGFsc28gc3VwcG9ydHMgTVRMUyBldmVuDQogdGhv dWdoIGl0IHdhc24ndCBsaXN0ZWQgaW4gdGhlICdtdGxzX2VuZHBvaW50cycgb2JqZWN0PyBvciBz aG91bGQgaXQgYXNzdW1lIHRoYXQgZW5kcG9pbnQgZG9lcyBOT1Qgc3VwcG9ydCBNVExTIGJlY2F1 c2UgaXQncyBub3QgcGFydCBvZiB0aGUgJ210bHNfZW5kcG9pbnRzJyBvYmplY3Q/PGJyPg0KPGJy Pg0KSXQgd2lsbCB3b3JrLCB0aG91Z2ggaXQgc3RpbGwgZmVlbHMgJnF1b3Q7aGFja3kmcXVvdDsg YW5kIG92ZXJseSBjb21wbGV4Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpHZW9yZ2U8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzE1LzE5IDI6NDIgUE0s IFBoaWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMgaXMgd2hhdCBJIHdvdWxk IGV4cGVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAxNSwgMjAxOSwgYXQg MTE6MzIgQU0sIEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlwQGdtYWls Li5jb20iPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gR2Vvcmdl LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8g eW91IHRoaW5rIGFib3V0IHdoYXQgaSB3cm90ZSBlYXJsaWVyPzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNsaWVudHMgbm90IGhhdmlu ZyBtdGxzIGNhcGFiaWxpdGllcyB3b24ndCBjYXJlIGFib3V0IHRoZSBhZGRpdGlvbmFsIG1ldGhv ZCBtZW1iZXJzIGJlaW5nIHByZXNlbnQuIENsaWVudHMgdGhhdCBkbyBpbXBsZW1lbnQgbXRscyBi eSB0aGUgc3BlY2lmaWNhdGlvbiB3aWxsIGtub3cgdG8gbG9vayBmb3IgbXRsc19lbmRwb2ludHMg YW5kIGZhbGwgYmFjayB0byByZWd1bGFyIG9uZXMgaWYgdGhlIHNwZWNpZmljIGVuZHBvaW50DQog b3IgbXRsc19lbmRwb2ludHMgcm9vdCBwcm9wZXJ0eSBpcyBub3QgcHJlc2VudC48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xl YXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UyBwb3pkcmF2ZW0sPGJyPg0KPGI+RmlsaXAgU2tva2FuPC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRnJpLCAxNSBGZWIgMjAxOSBhdCAyMDoyOSwgR2VvcmdlIEZsZXRjaGVyICZsdDtnZmZs ZXRjaD08YSBocmVmPSJtYWlsdG86NDBhb2wuY29tQGRtYXJjLmlldGYub3JnIj40MGFvbC5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPkkgc3RpbGwgZG9u J3Qgc2VlIGhvdyB3ZSBzb2x2ZSBvbmUgb2YgdGhlIHVzZSBjYXNlcyBBbm5hYmVsbGUgYnJvdWdo dCB1cC48YnI+DQo8YnI+DQpJZiB0aGUgJ210bHNfZW5kcG9pbnRzJyBvYmplY3QganVzdCBjb250 YWlucyBlbmRwb2ludHMsIHRoZW4gaW4gdGhlIG1haW4gbWV0YS1kYXRhIHNlY3Rpb24sIHNob3Vs ZCAndG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCcgaW5jbHVkZSBhbiBpbmRp Y2F0aW9uIG9mICd0bHNfY2xpZW50X2F1dGgnIGV2ZW4gdGhvdWdoIHRoZSBlbmRwb2ludCBzcGVj aWZpZWQgYnkgJ3Rva2VuX2VuZHBvaW50JyBkb2VzIE5PVCBzdXBwb3J0IE1UTFM/PGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NCkdlb3JnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiAyLzE0LzE5IDY6MDggUE0sIEJyaWFuIENhbXBiZWxsIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgSSdtIHdyb25nIGhlcmUgKGl0J3MgbmV2 ZXIgb3V0IG9mIHRoZSBxdWVzdGlvbikgYnV0IGJhc2VkIG9uDQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLi5p ZXRmLm9yZ19hcmNoX21zZ19vYXV0aF9lcU9UcTc0aGJIejlNdi01RlV6aGt2aTN6Z0VRTSZhbXA7 ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu RSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDtt PXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmYW1wO3M9c1dHRVRP elhiSTdMWnotb1FiR3FPMmtFRFFrSEVybXJtQWFrYUVlR0lJdyZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj4NCnRoaXMgcHJldmlvdXMgbWVzc2FnZTwvYT4gYW5kIDxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuLmll dGYub3JnX2FyY2hfbXNnX29hdXRoX05KcVc5a0l2eExSay0yRDRwaUM5LTJESHNSN3dsck0mYW1w O2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7 bT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJmFtcDtzPVZ0VVhj TGxJUHBuLXRXaFhuMW4wNnNMUXNtT1o2dmpwQ0pVSDJIdm9lQU0mYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+DQp0aGlzIG9uZTwvYT4gSSBiZWxpZXZlIHRoYXQgYWN0dWFsbHkgeW91IGFyZSBib3Ro IGluIGZhdm9yIChnZW5lcmFsbHkgYW55d2F5KSBvZiB0aGUgcHJvcG9zYWwgd2l0aCB0aGUgb3B0 aW9uYWwgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgcGFyYW1ldGVyLiBXaGlsZSBJIGJlbGll dmUgdGhhdCB0aGUgY29tbWVudCBhYm91dCBvcHRpb25hbGl0eSBhbmQgY29tcGxleGl0eSB3YXMg bWVhbnQgdG8gYmUgYSBtb3JlIGdlbmVyYWwNCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjti YWNrZ3JvdW5kOndoaXRlIj4NCnJlbWFyazwvc3Bhbj4uIFdoaWxlIEkgY2FuIGNlcnRhaW5seSBh cHByZWNpYXRlIGEgZGVzaXJlIHRvIGtlZXAgdGhpbmdzIHNpbXBsZSwgSSBkbyByZWdyZXQgdGhh dCB0aGlzIHRocmVhZCB0b29rIGEgdHVybiB0b3dhcmRzIHBlcnNvbmFsLiBXaGV0aGVyIGl0IHdh cyB0aGUgaW50ZW50IG9yIG5vdCwgdGhlcmUncyBhbiBpbXBhY3QuDQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgRmViIDE0LCAyMDE5IGF0IDEwOjIwIEFNIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZlZWwgSSBoYXZlIHRvIGRpc2FncmVlLiZuYnNw OyBJIGFncmVlIHRoYXQgb3B0aW9uYWxpdHkgaXMgb2Z0ZW4gY29tcGxleGl0eSBhbmQgc2hvdWxk IGJlIGF2b2lkZWQuIEJ1dCwgSSB0aGluayB0aGUgb3B0aW9uYWxpdHkgaGVyZSBpcyBhbiBhZ2ls aXR5IGZlYXR1cmUgYWxsb3dpbmcgbXRscyB0byB3b3JrIGFjcm9zcyBhIGRpdmVyc2lmaWVkIG1h cmtldCBvZiBkaWZmZXJlbnQgdHlwZXMgb2YgdGxzIHRlcm1pbmF0b3JzDQogd2l0aCB2YXJ5aW5n IGNhcGFiaWxpdHkuIExhY2sgb2YgYXBwcm9wcmlhdGUgZGlzY292ZXJ5L29wdGlvbnMgY291bGQg c2VydmUgdG8gbWFrZSB0aGUgc3BlYyB1bnVzYWJsZSBpbiBtYW55IGNhc2VzLiAmbmJzcDsNCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjb21wbGljYXRp bmcgZmFjdG9yIHdpdGggdGxzIGlzIHRoYXQgYSB0bHMgbGF5ZXIgZmFpbHVyZSBwcmV2ZW50cyB0 aGUgQVMgZnJvbSBpc3N1aW5nIGEgY29ycmVjdGluZyBkaXJlY3RpdmUgbGlrZSBhbiBodHRwIGVy cm9yIG9yIGh0dHAgcmVkaXJlY3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUgdG8gYmUgc3VyZSBub3QgdG8gYnJlYWsg ZXhpc3RpbmcgY2xpZW50cyBzbyB3ZSBtYXkgaW4gc29tZSBjYXNlcyBuZWVkIG10bHMgb25seSBl bmRwb2ludHMuIEkgYW0gbm90IGZhciBlbm91Z2ggYWxvbmcgdG8ga25vdyBmb3Igc3VyZS4gQnV0 IEkgdGVuZCB0byBhZ3JlZSB3aXRoIEJyaWFuIG9uIHRoaXMuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWF5IGJlIGEgc2ln biB3ZSBuZWVkIG1vcmUgaW1wbGVtZW50YXRpb24gZGF0YSAoaW5jbHVkaW5nIGZyb20gdGxzIHdn KSB0byBtYWtlIHRoZSByaWdodCBjYWxsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlk PSJnbWFpbC1tXy0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbV84NDYzNTcyMTE0MjE0NjE0MDUw Z21haWwtbV8tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW1fLTQwNzU2NzYwMzcxNDU3NjM4ODBB cHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMTQsIDIwMTksIGF0IDg6NTYgQU0sIERvbWluaWNr IEJhaWVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+U29y cnkgLSB0aGlzIHdhcyBub3QgbWVhbnQgdG8gYmUgc25pZGUgYXQgYWxsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JdCB3YXMgaG9u ZXN0IGZlZWRiYWNrIHRoYXQgeW91IGFsc28gbmVlZCB0byBrZWVwIHNvZnR3YXJlIGNvbXBsZXhp dHkgaW4gbWluZCB3aGVuIGNyZWF0aW5nIGEgc3BlYy4gRXZlcnkgTUFZIG9yIE9QVElPTkFMLCBv ciBkbyBpdCBsaWtlIHRoaXMgT1IgdGhhdCwgb3Igc2VuZCB2YWx1ZXMgaW4gYXJiaXRyYXJ5IG9y ZGVyDQogYWRkcyB0byBjb21wbGV4aXR5LiBDb21wbGV4aXR5IGlzIHRoZSBuYXR1cmFsIGVuZW15 IG9mIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhIj5DaGVlcnMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJTigJTigJQgPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9taW5pY2s8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIx NDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2 Mzg4MGFpcm1haWxvbiI+DQpPbiAxMy4gRmVicnVhcnkgMjAxOSBhdCAyMDozOToxNiwgUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgKDxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo ZSBpc3N1ZSBpcyB0aGF0IHRoZSBwcm9wb3NhbCB2aW9sYXRlcyB0aGUgc3RhbmRhcmQgYnkgY2hh bmdpbmcgdGhlIHNlbWFudGljcyBvZiBhIHBhcmFtZXRlciBpdCBkZWZpbmVzLiBXZSBzaG91bGQg YmUgdmVyeSwgdmVyeSwgVkVSWSBjYXJlZnVsIGFib3V0IHRlbGxpbmcgaW1wbGVtZW50ZXJzIHRv IHZpb2xhdGUNCiBhbiBleGlzdGluZyBzdGFuZGFyZC4uLiBUaGlzIGNoYW5nZSBtaWdodCBwcm92 ZSBpbmNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBvciBmdXR1cmUgaW1wbGVtZW50YXRpb25zIG9m IDg0MTQsIGl0IG1pZ2h0IG5vdCwgYnV0IGJ5IHZpb2xhdGluZyB0aGUgc3RhbmRhcmQgdGhlIHBy b3Bvc2FsIGNyZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIGluY29tcGF0aWJpbGl0eSB0aGF0IGRp ZG7igJl0IGV4aXN0IGJlZm9yZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BcyBmYXIgYXMgc2ltcGxpY2l0eSBpcyBjb25jZXJuZWQsIEkgZmluZCBhIHNvbHV0aW9u IHRoYXQgcmV1c2VzIHRoZSBleGlzdGluZyBkYXRhIG1vZGVsIGFuZCBuYXR1cmFsbHkgc3VwcG9y dHMgZXhpc3RpbmcgYW5kIGZ1dHVyZSBleHRlbnNpb25zIHRvIGJlIGZhciBzaW1wbGVyIHRoYW4g b25lIHRoYXQgaW50cm9kdWNlcw0KIGFtYmlndW91cyBzZW1hbnRpY3MgdG8gZXhpc3RpbmcgcGFy YW1ldGVycy4gR2VuZXJhbGx5IHNwZWFraW5nLCBkYXRhIG1vZGVscyB3aXRoIHByb3BlcnRpZXMg dGhhdCBtZWFuIGRpZmZlcmVudCB0aGluZ3MgaW4gZGlmZmVyZW50IGNvbnRleHRzIHRlbmQgdG8g YmUgZnJhZ2lsZSBhbmQgcmVxdWlyZSBtb3JlIGNvbXBsZXggY29kZSB0byB3b3JrIHdpdGguIEJ1 dCB0aGF04oCZcyBqdXN0IG15IGV4cGVyaWVuY2UgYXMsIHlvdSBrbm93LCBhbiBhY3R1YWwNCiBk ZXZlbG9wZXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV04oCZ cyBrZWVwIHRoZSBhc3N1bXB0aW9ucyBhbmQgc25pZGUgcmVtYXJrcyBhYm91dCBvdGhlcnPigJkg YmFja2dyb3VuZHMgb2ZmIHRoZSBsaXN0LCBwbGVhc2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QVdTIElkZW50aXR5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNv bG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xv ciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RG9t aW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPldlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTkgYXQgNDoxOCBBTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFu bmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpw YW52YS4uaXBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGFudmEuaXBAZ21haWwuY29tPC9h PiZndDs8YnI+DQo8Yj5DYzogPC9iPkJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbTwvYT4mZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDssIG9hdXRoICZsdDs8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10g TVRMUyB0b2tlbiBlbmRvaW50ICZhbXA7IGRpc2NvdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkkgYW0g Zm9yIGtlZXBpbmcgaXQgc2ltcGxlIGFuZCBub3QgaW50cm9kdWNpbmcgYW5vdGhlciBsaW5rIHRv IGZvbGxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JIHNvbWV0aW1lcyB3b25kZXIgaG93IG1hbnkg b2YgdGhlIHNwZWMgYXV0aG9ycyBhcmUgYWN0dWFsbHkgZGV2ZWxvcGVycyAtIHRoZXNlIHN1Z2dl c3Rpb25zIG1ha2Ugc29mdHdhcmUgdW5uZWNlc3NhcnkgY29tcGxleA0KIDspPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAlOKA lOKAlA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb21p bmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW0t MjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5 NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwYWlybWFpbG9uMCI+DQpP biAxMy4gRmVicnVhcnkgMjAxOSBhdCAxMjoyNToxMywgRmlsaXAgU2tva2FuICg8YSBocmVmPSJt YWlsdG86cGFudmEuaXBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGFudmEuaXBAZ21haWwu Y29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9y ZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCkiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5BZGRpdGlvbmFsbHksIGEgbWV0YWRhdGEgZG9jdW1lbnQgdGhhdCBvbWl0 cyB0b2tlbl9lbmRwb2ludCBpbiBmYXZvciBvZiBtdGxzX2VuZHBvaW50cyBzaW5jZSBvbmx5IG1U TFMgaXMgc3VwcG9ydGVkIHdvdWxkIHZpb2xhdGUgODQxNCwgYXMgODQxNCBzYXlzIHRva2VuX2Vu ZHBvaW50IOKAnGlzIFJFUVVJUkVEDQogdW5sZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50IHR5 cGUgaXMgc3VwcG9ydGVkLuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQptdGxzIG9ubHkgQVMgZG9lc24ndCBnZXQgYW55dGhpbmcgb3V0IG9m IHVzaW5nIG10bHNfZW5kcG9pbnRzLCBpdHMgdXNlIHNob3VsZCBub3QgYmUgcmVjb21tZW5kZWQg Zm9yIHN1Y2ggQVMgYW5kIHJlZ3VsYXIgZW5kcG9pbnRzIHdpbGwgYmUgdXNlZCwgdGhpcyBzYXRp c2ZpZXMgdGhlIHJlcXVpcmVtZW50PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50 Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj dXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVyZSBpcyBv bmUgZXhhbXBsZSwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg4oCcc3RyYXcgbWFu 4oCdIGZvcm1hdCBwcmVzZW50ZWQgaW4gdGhpcyB0aHJlYWQ6IFJGQzg0MTQgZGVmaW5lcyB0aGUg dmFsdWUgb2YgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBhcyBhIOKAnEpT T04NCiBhcnJheSBjb250YWluaW5nIGEgbGlzdCBvZiBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0 aG9kcyBzdXBwb3J0ZWQgYnkgdGhpcyB0b2tlbiBlbmRwb2ludC7igJ0gSWYgdGhhdCBhcnJheSBj b250YWlucyDigJx0bHNfY2xpZW50X2F1dGjigJ0gYW5kIHRoZSBlbmRwb2ludCBzcGVjaWZpZWQg aW4gdG9rZW5fZW5kcG9pbnQgZG9lcyBub3Qgc3VwcG9ydCBtVExTLCB0aGVuIHRoYXQgbWV0YWRh dGEgdmlvbGF0ZXMgODQxNC4gWW91IGNvdWxkIGFkZHJlc3MgdGhpcw0KIGJ5IGFkZGluZyBhIHRv a2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgcGFyYW1ldGVyIHRvIHRoZSBtdGxz X2VuZHBvaW50cyBvYmplY3QsIGFuZCBsaWtld2lzZSBmb3IgdGhlIG90aGVyIGVuZHBvaW50cyBh bmQgYXV0aCBtZXRob2RzLiBJZiB5b3UgdGFrZSB0aGF0IHRvIGl0cyBsb2dpY2FsIGNvbmNsdXNp b24sIHlvdSBlbmQgdXAgd2l0aCBhIGNvbXBsZXRlIG1ldGFkYXRhIGRvY3VtZW50IGhhbmdpbmcg b2ZmIG9mIG10bHNfZW5kcG9pbnRzLg0KIEl04oCZcyB0aGF0IGxpbmUgb2YgdGhvdWdodCB0aGF0 IGxlZCBtZSB0byBzdWdnZXN0IGp1c3QgcG9pbnRpbmcgdG8gYW4gYWx0ZXJuYXRlIGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnI+DQpBc3N1bWluZyB3ZSBnbyB3aXRoIHVzaW5nIHRoZSBzYW1lIHJvb3QgYXV0aCBtZXRob2Rz IHByb3BlcnR5LCB3aGF0J3MgdGhlIGlzc3VlPyBDbGllbnRzIG5vdCBoYXZpbmcgbXRscyBjYXBh YmlsaXRpZXMgd29uJ3QgY2FyZSBhYm91dCB0aGUgYWRkaXRpb25hbCBtZXRob2QgbWVtYmVycyBi ZWluZyBwcmVzZW50LiBDbGllbnRzIHRoYXQgZG8gaW1wbGVtZW50IG10bHMgYnkgdGhlIHNwZWNp ZmljYXRpb24gd2lsbCBrbm93IHRvIGxvb2sgZm9yIG10bHNfZW5kcG9pbnRzDQogYW5kIGZhbGwg YmFjayB0byByZWd1bGFyIG9uZXMgaWYgdGhlIHNwZWNpZmljIGVuZHBvaW50IG9yIG10bHNfZW5k cG9pbnRzIHJvb3QgcHJvcGVydHkgaXMgbm90IHByZXNlbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBnYXZlIGBtdGxz X2FsdGVybmF0ZV9tZXRhZGF0YWAgcm91dGUgYSB0aG91Z2h0IGFuZCBkb24ndCBzZWUgaG93IGl0 IGhlbHBzLCBnaXZlbiB0aGUgdHdvIGFib3ZlIGFyZSBub24taXNzdWVzIChteSAkLjAyKSBhbm90 aGVyIGRpc2NvdmVyeSBkb2N1bWVudCBvbmx5IGJyaW5ncyBtb3JlIG9mIHRoZW0gc2luY2UNCiBl dmVyeSBwcm9wZXJ0eSBjYW4gbm93IGJlIGRpZmZlcmVudCwgbm90IGp1c3QgdGhlIGVuZHBvaW50 cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlMgcG96ZHJhdmVtLDxicj4NCjxiPkZpbGlwIFNrb2thbjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gV2VkLCAxMyBGZWIgMjAxOSBhdCAwMDowMCwgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0 LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZXJlIGlz IG9uZSBleGFtcGxlLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSDigJxzdHJhdyBt YW7igJ0gZm9ybWF0IHByZXNlbnRlZCBpbiB0aGlzIHRocmVhZDogUkZDODQxNCBkZWZpbmVzIHRo ZSB2YWx1ZSBvZiB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIGFzIGEg4oCc SlNPTg0KIGFycmF5IGNvbnRhaW5pbmcgYSBsaXN0IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBt ZXRob2RzIHN1cHBvcnRlZCBieSB0aGlzIHRva2VuIGVuZHBvaW50LuKAnSBJZiB0aGF0IGFycmF5 IGNvbnRhaW5zIOKAnHRsc19jbGllbnRfYXV0aOKAnSBhbmQgdGhlIGVuZHBvaW50IHNwZWNpZmll ZCBpbiB0b2tlbl9lbmRwb2ludCBkb2VzIG5vdCBzdXBwb3J0IG1UTFMsIHRoZW4gdGhhdCBtZXRh ZGF0YSB2aW9sYXRlcyA4NDE0LiBZb3UgY291bGQgYWRkcmVzcyB0aGlzDQogYnkgYWRkaW5nIGEg dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhlIG10 bHNfZW5kcG9pbnRzIG9iamVjdCwgYW5kIGxpa2V3aXNlIGZvciB0aGUgb3RoZXIgZW5kcG9pbnRz IGFuZCBhdXRoIG1ldGhvZHMuIElmIHlvdSB0YWtlIHRoYXQgdG8gaXRzIGxvZ2ljYWwgY29uY2x1 c2lvbiwgeW91IGVuZCB1cCB3aXRoIGEgY29tcGxldGUgbWV0YWRhdGEgZG9jdW1lbnQgaGFuZ2lu ZyBvZmYgb2YgbXRsc19lbmRwb2ludHMuDQogSXTigJlzIHRoYXQgbGluZSBvZiB0aG91Z2h0IHRo YXQgbGVkIG1lIHRvIHN1Z2dlc3QganVzdCBwb2ludGluZyB0byBhbiBhbHRlcm5hdGUgZG9jdW1l bnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWRkaXRpb25hbGx5 LCBhIG1ldGFkYXRhIGRvY3VtZW50IHRoYXQgb21pdHMgdG9rZW5fZW5kcG9pbnQgaW4gZmF2b3Ig b2YgbXRsc19lbmRwb2ludHMgc2luY2Ugb25seSBtVExTIGlzIHN1cHBvcnRlZCB3b3VsZCB2aW9s YXRlIDg0MTQsIGFzIDg0MTQgc2F5cyB0b2tlbl9lbmRwb2ludCDigJxpcyBSRVFVSVJFRA0KIHVu bGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ08bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBwb3NzaWJsZSB0byBkZWZp bmUgdGhlIG10bHNfZW5kcG9pbnRzIHBhcmFtZXRlciBzdWNoIHRoYXQgdGhlIGFib3ZlIHVzZSBj YXNlcyBhcmUgaW52YWxpZCwgYnV0IHRoYXQgZG9lcyBtYWtlIHRoZSBkb2N1bWVudCBtb3JlIGNv bXBsaWNhdGVkLi4gSWYgd2UgZ28gdGhlIOKAnG10bHNfYWx0ZXJuYXRlX21ldGFkYXRh4oCdDQog cm91dGUsIHdlIGNhbiBza2lwIHBhc3QgYWxsIG9mIHRoZXNlIGlzc3VlcywgYmVjYXVzZSBpdCBi cmluZ3MgdXMgYmFjayB0byBqdXN0IHBhcnNpbmcgdGhlIHNhbWUgbWV0YWRhdGEgdGhhdCB3ZSBk byB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBC YWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwYW52YS5pcEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5wYW52YS5pcEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRh dGU6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxOSBhdCAxOjEzIFBNPGJyPg0KPGI+VG86 PC9iPiAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9 PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBC cmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0 eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Oywgb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYuLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2ludCAmYW1wOyBkaXNj b3Zlcnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBBbm5hYmVsbGUsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Y2FuIHlvdSBlbGFib3JhdGUgd2hhdCB3b3VsZCBiZSB0aGUgdmlvbGF0aW9u IC8gbmVnYXRpdmUgaW1wYWN0IG9mIHVzYWdlIG9mIFJGQzg0MTQ/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMg aXQgYWxyZWFkeSBtYWtlcyB1c2Ugb2YgYHNpZ25lZF9tZXRhZGF0YWAgYW5kIHRoaXMgbGFuZ3Vh Z2UgaXMgcHJlc2VudCAuLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZuYnNwO0NvbnN1bWVycyBvZiB0 aGUgbWV0YWRhdGEgTUFZIGlnbm9yZSB0aGUgc2lnbmVkIG1ldGFkYXRhIGlmIHRoZXkgZG8gbm90 IHN1cHBvcnQgdGhpcyBmZWF0dXJlLiZuYnNwOyBJZiB0aGUgY29uc3VtZXIgb2YgdGhlIG1ldGFk YXRhIHN1cHBvcnRzIHNpZ25lZCBtZXRhZGF0YSwgbWV0YWRhdGEgdmFsdWVzIGNvbnZleWVkDQog aW4gdGhlIHNpZ25lZCBtZXRhZGF0YSBNVVNUIHRha2UgcHJlY2VkZW5jZSBvdmVyIHRoZSBjb3Jy ZXNwb25kaW5nIHZhbHVlcyBjb252ZXllZCB1c2luZyBwbGFpbiBKU09OIGVsZW1lbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPi4uLi4gd291bGQgbXRsc19lbmRwb2ludHMgYmUgYW55IGRpZmZlcmVudD8gQ2xp ZW50cyBhcmUgZnJlZSB0byBpZ25vcmUgdGhpcyBpZiB0aGV5IGRvbid0IHN1cHBvcnQvdXNlIG10 bHMsIGFuZCBpZiB0aGV5IGRvIHRob3NlIHZhbHVlcyBtdXN0IHRha2UgcHJlY2VkZW5jZSBvdmVy IHRoZSByb290IG9uZXMuDQogdGhlIHVzZSBvZiBtdGxzX2VuZHBvaW50cyB3b3VsZCBub3QgYmUg cmVjb21tZW5kZWQgZm9yIG10bHMtb25seSBBUyBidXQgcmVjb21tZW5kZWQgZm9yIG9uZSB3aXRo IGJvdGggbXRscy9yZWd1bGFyIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuIHRva2VuX2VuZHBvaW50 IHJlbWFpbnMgcmVxdWlyZWQgZm9yIGFsbCBpbnRlbnRzIGFuZCBwdXJwb3Nlcy4gQW5kIGFzIGZv ciB0aGUgdXNhYmxlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIC0gdGhleQ0KIHNob3Vs ZCBhbGwgYmUgbGlzdGVkLCBvciBkbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHNlcGFyYXRlIHRoZSBv bmVzIGZvciBlYWNoIGhvc3RuYW1lL3BvcnQgbG9jYXRpb24/IFRvIHdoYXQgZW5kPyBJcyB0aGVy ZSBhIHJpc2sgaGF2aW5nIHRoZSBtdGxzIGhvc3RuYW1lL3BvcnQgYWNjZXB0aW5nIHJlZ3VsYXIg cmVxdWVzdHM/IE90aGVyIHRoZW4gc2VjcmV0L2tleSBfand0IGF1dGggbWV0aG9kcyBhc3NlcnRp b24gYXVkIGNsYWltIHRoZSBlbmRwb2ludA0KIGxvY2F0aW9uIGRvZXNuJ3QgcGxheSBhIHJvbGUg aW4gdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVzdCw8YnI+DQo8Yj5GaWxpcDwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIDEyIEZlYiAyMDE5IGF0 IDIwOjQ3LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0i bWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBub3Qgb3Bw b3NlZCB0byBpbnRyb2R1Y2luZyBhIG1ldGFkYXRhIGNoYW5nZSwgaWYgdGhlIHNjZW5hcmlvIGlz IHJlbGV2YW50IGFuZCBvdGhlciBhcHByb2FjaGVzIGNhbuKAmXQgYWRlcXVhdGVseSBhZGRyZXNz IGl0IOKAkyBhbmQgSeKAmWxsIHJlYWRpbHkgZ3JhbnQgdGhhdCB3ZSBwcm9iYWJseSBkb27igJl0 IHdhbnQNCiB0byBkZXBlbmQgb24gY29uc2lzdGVuY3kgb2YgYnJvd3NlciBiZWhhdmlvciBhdCB0 aGUgaW50ZXJzZWN0aW9uIG9mIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYW5kIEFjY2Vzcy1Db250cm9s LUFsbG93LUNyZWRlbnRpYWxzLiBCdXQgY2FyZSBuZWVkcyB0byBiZSB0YWtlbiBpbiBkZXNpZ25p bmcgdGhhdCBtZXRhZGF0YSB0byBhdm9pZCB2aW9sYXRpbmcgb3Igb3RoZXJ3aXNlIG5lZ2F0aXZl bHkgaW1wYWN0aW5nIHVzYWdlIG9mIFJGQzg0MTQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QWxvbmcgdGhvc2UgbGluZXMsIGluc3RlYWQgb2YgYWRkaW5nIGFuIOKA nG10bHNfZW5kcG9pbnRz4oCdIG1ldGFkYXRhIHBhcmFtZXRlciwgd2UgY291bGQgYWRkIGFuIOKA nG10bHNfYWx0ZXJuYXRlX21ldGFkYXRh4oCdIHBhcmFtZXRlciB3aG9zZSB2YWx1ZSBpcyB0aGUg VVJMIG9mIGFuIGFsdGVybmF0ZSBtZXRhZGF0YQ0KIGRvY3VtZW50IGludGVuZGVkIGZvciBjbGll bnRzIHVzaW5nIG1UTFMuIEFuIG1UTFMtb3B0aW9uYWwgQVMgY291bGQgaGF2ZSB0d28gZGlmZmVy ZW50IG1ldGFkYXRhIGRvY3VtZW50cyBmb3IgbVRMUyBhbmQgbm9uLW1UTFMgY2xpZW50cywgcmVk dWNpbmcgdGhlIG1UTFMtb3B0aW9uYWwgc2NlbmFyaW8gdG8gdGhlIG1UTFMtb25seSBzY2VuYXJp by4gVGhpcyBzaWRlc3RlcHMgdGhlIGNoYWxsZW5nZXMgb2YgYWxpZ25pbmcgdGhlIOKAnGVpdGhl ci9vcuKAnQ0KIHNlbWFudGljcyBvZiBtVExTLW9wdGlvbmFsIHdpdGggc29tZSBvZiB0aGUgcmln aWQgcGFyYW1ldGVyIGRlZmluaXRpb25zIGluIFJGQzg0MTQgKHNlZTogdG9rZW5fZW5kcG9pbnQs IHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQpLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElkZW50 aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206 PC9zcGFuPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PQXV0aCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0 aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsICZs dDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE5IGF0IDEw OjU4IEFNPGJyPg0KPGI+VG86PC9iPiBEb21pbmljayBCYWllciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYmFpZXJAbGVhc3Rw cml2aWxlZ2UuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE1UTFMgdG9rZW4gZW5kb2lu dCAmYW1wOyBkaXNjb3Zlcnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoYW5rcyBmb3IgdGhlIGlucHV0LCBEb21pbmljay48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J J2Qgc2FpZCBwcmV2aW91c2x5IHRoYXQgSSB3YXMgaGF2aW5nIHRyb3VibGUgYWRlcXVhdGVseSBn YXVnaW5nIHdoZXRoZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28g YWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBJIHdhcyBldmVuIHRoaW5raW5nIG9mIGFza2luZyB0aGUg Y2hhaXJzDQogYWJvdXQgYSBjb25zZW5zdXMgY2FsbCBkdXJpbmcgdGhlIG9mZmljZSBob3VycyBt ZWV0aW5nIHllc3RlcmRheS4gQnV0IGl0IGdvdCBjYW5jZWxlZC4gQW5kIGxvb2tpbmcgYWdhaW4g YmFjayBvdmVyIHRoZSBkaXNjdXNzaW9uLCBJIGRvbid0IGJlbGlldmUgYSBjb25zZW5zdXMgY2Fs bCBpcyBuZWNlc3NhcnkuIFRoZXJlJ3MgYmVlbiBhIGxvdCBvZiBnZW5lcmFsIGRpc2N1c3Npb24g b3ZlciB0aGUgbGFzdCBzZXZlcmFsIHdlZWtzIGR1cmluZyB3aGljaA0KIHNldmVyYWwgZm9sa3Mg aGF2ZSBzdGF0ZWQgc3VwcG9ydCBmb3IgdGhlIHByb3Bvc2FsIHdoaWxlIHRoZXJlJ3MgYmVlbiBv bmx5IG9uZSB2b2ljZSBvZiBkaXJlY3QgZGlzc2VudC4gVGhhdCBzZWVtcyBsaWtlIHJvdWdoIGVu b3VnaCBjb25zZW5zdXMgYW5kLCBhcyBzdWNoLCBJIHBsYW4gdG8gbWFrZSB0aGUgY2hhbmdlIGlu IHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudCAod2hpY2ggc2hvdWxkIGJlIGRvbmUg c29vbikuIENoYWlycywNCiBwbGVhc2UgbGV0IG1lIGtub3csIGlmIHlvdSBiZWxpZXZlIHRoZSBz aXR1YXRpb24gd2FycmFudHMgYSBkaWZmZXJlbnQgY291cnNlIG9mIGFjdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gTW9uLCBGZWIgMTEsIDIwMTkgYXQgMTE6MDEgUE0gRG9taW5pY2sgQmFpZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPklNSE8gdGhhdOKA mXMgYSByZWFzb25hYmxlIGFuZCBwcmFnbWF0aWMgb3B0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei PlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+4oCU4oCU4oCUPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Eb21pbmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0 MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgw bTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMx OTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYx MTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSI+DQpPbiAxMS4gRmVicnVhcnkgMjAxOSBhdCAx MzoyNjozNywgQnJpYW4gQ2FtcGJlbGwgKDxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9h Pikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SXQncyBi ZWVuIHBvaW50ZWQgb3V0IHRoYXQgdGhlIHBvdGVudGlhbCBpc3N1ZSBpcyBub3QgaXNvbGF0ZWQg dG8gdGhlIGp1c3QgdG9rZW4gZW5kcG9pbnQgYnV0IHRoYXQgcmV2b2NhdGlvbiwgaW50cm9zcGVj dGlvbiwgZXRjLiBjb3VsZCBiZSBpbXBhY3RlZCBhcyB3ZWxsLiBTbywmbmJzcDsgYXQgdGhpcyBw b2ludCwgdGhlIHByb3Bvc2FsDQogb24gdGhlIHRhYmxlIGlzIHRvIGFkZCBhIG5ldyBvcHRpb25h bCBBUyBtZXRhZGF0YSBwYXJhbWV0ZXIgbmFtZWQgJ210bHNfZW5kcG9pbnRzJyB0aGF0J3MgdmFs dWUgd2UgYmUgYSBKU09OIG9iamVjdCB3aGljaCBpdHNlbGYgY29udGFpbnMgZW5kcG9pbnRzIHRo YXQsIHdoZW4gcHJlc2VudCwgYSBjbGllbnQgZG9pbmcgTVRMUyB3b3VsZCB1c2UgcmF0aGVyIHRo YW4gdGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiZuYnNwOyBBIHN0cmF3LW1hbiBleGFtcGxlIG1pZ2h0 DQogbG9vayBsaWtlIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij57PGJyPg0KJm5ic3A7ICZxdW90O2lzc3VlciZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczov L3NlcnZlci5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZlci5leGFt cGxlLmNvbTwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O2F1dGhvcml6YXRpb25fZW5kcG9p bnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aHoi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRoejwvYT4mcXVv dDssPGJyPg0KJm5ic3A7ICZxdW90O3Rva2VuX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW48L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDt0 b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkJnF1b3Q7OlsgJm5ic3A7JnF1b3Q7 Y2xpZW50X3NlY3JldF9iYXNpYyZxdW90OywmcXVvdDt0bHNfY2xpZW50X2F1dGgmcXVvdDssICZx dW90O25vbmUmcXVvdDtdLDxicj4NCiZuYnNwOyAmcXVvdDt1c2VyaW5mb19lbmRwb2ludCZxdW90 OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS91c2VyaW5mbyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3VzZXJpbmZvPC9hPiZxdW90 Oyw8YnI+DQombmJzcDsgJnF1b3Q7cmV2b2NhdGlvbl9lbmRwb2ludCZxdW90OzomcXVvdDs8YSBo cmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZXZvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2bzwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90 O2p3a3NfdXJpJnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29t L2p3a3MuanNvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3 a3MuanNvbjwvYT4mcXVvdDssPGJyPg0KJm5ic3A7IDxiPiZxdW90O210bHNfZW5kcG9pbnRzJnF1 b3Q7Ons8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O3Rva2VuX2VuZHBvaW50JnF1b3Q7OiZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS90b2tlbiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS90b2tlbjwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZu YnNwOyAmcXVvdDt1c2VyaW5mb19lbmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczov L210bHMuZXhhbXBsZS5jb20vdXNlcmluZm8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL210bHMu ZXhhbXBsZS5jb20vdXNlcmluZm88L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7 cmV2b2NhdGlvbl9lbmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL210bHMuLi4u Li4uZXhhbXBsZS5jb20vcmV2byIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbXRscy5leGFtcGxl LmNvbS9yZXZvPC9hPiZxdW90Ozxicj4NCiZuYnNwOyB9PC9iPjxicj4NCn08bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BIGNsaWVudCBkb2luZyBNVExTIHdvdWxkIGxvb2sgZm9yIGFuZCBn aXZlIHByZWNlZGVuY2UgdG8gYW4gZW5kcG9pbnQgdW5kZXIgJnF1b3Q7bXRsc19lbmRwb2ludHMm cXVvdDsgd2hpbGUgZmFsbGluZyBiYWNrIHRvIHVzZSB0aGUgbm9ybWFsIGVuZHBvaW50IGZyb20g dGhlIHRvcCBsZXZlbCBvZiBtZXRhZGF0YSB3aGVuL2lmDQogaXRzIG5vdCBpbiAmcXVvdDttdGxz X2VuZHBvaW50cyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGJyPg0KVGhlIGlkZWEgYmVpbmcgdGhhdCAmcXVvdDtyZWd1bGFyJnF1 b3Q7IGNsaWVudHMgKHRob3NlIG5vdCBkb2luZyBNVExTKSB3aWxsIHVzZSB0aGUgcmVndWxhciBl bmRwb2ludHMuIEFuZCBvbmx5IHRoZSBob3N0L3BvcnQgb2YgdGhlIGVuZHBvaW50cyBsaXN0ZWQg aW4gbXRsc19lbmRwb2ludHMgd2lsbCBiZSBzZXQgdXAgdG8gcmVxdWVzdCBUTFMgY2xpZW50IGNl cnRpZmljYXRlcyBkdXJpbmcgaGFuZHNoYWtlLiBUaHVzIGFueSBwb3RlbnRpYWwgaW1wYWN0IG9m IHRoZQ0KIENlcnRpZmljYXRlUmVxdWVzdCBtZXNzYWdlIGJlaW5nIHNlbnQgaW4gdGhlIFRMUyBo YW5kc2hha2UgY2FuIGJlIGF2b2lkZWQgZm9yIGFsbCB0aGUgb3RoZXIgcmVndWxhciBjbGllbnRz IHRoYXQgYXJlIG5vdCBnb2luZyB0byBkbyBNVExTIC0gaW5jbHVkaW5nIGFuZCBtb3N0IGltcG9y dGFudGx5IGluLWJyb3dzZXIgamF2YXNjcmlwdCBjbGllbnRzIHdoZXJlIHRoZXJlIGNhbiBiZSBs ZXNzIHRoYW4gZGVzaXJhYmxlIFVJIHByZXNlbnRlZCB0bw0KIHRoZSBlbmQtdXNlci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JJ20gc3RydWdnbGluZywgaG93ZXZlciwgdG8gYWRlcXVhdGVseSBnYXVnZSB3aGV0 aGVyIG9yIG5vdCB0aGVyZSdzIHN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvIGdvIGFoZWFkIHdpdGgg dGhlIHVwZGF0ZS4gVGhlcmUncyBiZWVuIHNvbWUgc3VwcG9ydCBmb3IgaXQgdm9pY2VkLiBBcyB3 ZWxsIGFzIHRhbGsgb2YNCiBvdGhlciBhcHByb2FjaGVzIHRoYXQgY291bGQgYmUgYWx0ZXJuYXRp dmVzIG9yIGFkZGl0aW9uYWwgbWVhc3VyZXMuIEFuZCBhbHNvIHNvbWUgdm9jYWwgb3Bwb3NpdGlv biB0byBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g U2F0LCBGZWIgOSwgMjAxOSBhdCAzOjA5IEFNIERvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJt YWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWllckBs ZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5XZSBhcmUgY3VycmVudGx5IGltcGxl bWVudGluZyBNVExTIGluIElkZW50aXR5U2VydmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPk91ciBh cHByb2FjaCB3aWxsIGJlIHRoYXQgd2XigJlsbCBvZmZlciBhIHNlcGFyYXRlIHRva2VuIGVuZHBv aW50IHRoYXQgc3VwcG9ydHMgY2xpZW50IGNlcnRzLiBBcmUgeW91IHBsYW5uaW5nIG9uIGFkZGlu ZyBhbiBvZmZpY2lhbA0KIGVuZHBvaW50IG5hbWUgZm9yIGRpc2NvdmVyeT8gUmlnaHQgbm93IHdl IGFyZSB1c2luZyDigJxtdGxzX3Rva2VuX2VuZHBvaW504oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei PlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+4oCU4oCU4oCUPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Eb21pbmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0 MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgw bTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMx OTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYx MTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSI+DQpPbiA3LiBGZWJydWFyeSAyMDE5IGF0IDIy OjM2OjU1LCBCcmlhbiBDYW1wYmVsbCAoPGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbD00MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGw9NDBw aW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BaCB5ZXMsIHRoYXQgbWFrZXMgc2Vuc2UuIFRoYW5rcyBmb3IgY2xhcmlmeWluZy4gQW5k IGl0IGlzIGluZGVlZCBhIGdvb2QgcmVtaW5kZXIgdGhhdCBldmVuIGEgc2VlbWluZ2x5IGlubm9j dW91cyBjaGFuZ2UgdGhhdCBzaG91bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgY2FuIGJyZWFr IHRoaW5ncyB1bmV4cGVjdGVkbHkuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUaHUsIEZlYiA3LCAyMDE5IGF0IDg6NTcgQU0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY2FzZSBJ4oCZbSBy ZWZlcmVuY2luZyBkaWRu4oCZdCBzcGVjaWZpY2FsbHkgaW52b2x2ZSBBUyBtZXRhZGF0YS4gV2Ug aGFkIGNsaWVudHMgaW4gdGhlIHdpbGQgdGhhdCBhc3N1bWVkIHRoYXQgYWxsIHRoZSBwcm9wZXJ0 aWVzIGluIHRoZSBKU09OIG9iamVjdCByZXR1cm5lZCBmcm9tIG91ciB1c2VyaW5mbyBlbmRwb2lu dA0KIHdlcmUgc2NhbGFyIHN0cmluZ3MuIFRoaXMgYnJva2Ugd2hlbiB3ZSBpbnRyb2R1Y2VkIGEg bmV3IHByb3BlcnR5IHdob3NlIHZhbHVlIHdhcyBhIEpTT04gb2JqZWN0LiBJdCB3YXMgYSBnb29k IHJlbWluZGVyIHRoYXQgZXZlbiBhIHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hv dWxkIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIGNhbiBmb3JjZSBtb3JlIHdvcmsgb24gY2xpZW50 cyB0aGFuIHdlIGV4cGVjdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRp dHkuLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgNiwg MjAxOSBhdCAxMTozMCBBTTxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21A ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBvYXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5E RVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBv aW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgSSdtIGhvbmVzdGx5IHJlYWxseSBz dHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IGNvdWxkIGhhdmUgZ29uZSB3cm9uZyB3aXRoIG9yIGhvdyB0 b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYnJva2Ugc29tZXRoaW5nIHdpdGggdGhlIHVzZXIg aW5mbyBlbmRwb2ludC4gSWYgeW91IGhhdmUgdGhlIHRpbWUgYW5kL29yDQogaXQnZCBiZSBpbmZv cm1hdGl2ZSB0byB0aGlzIGhlcmUgbGl0dGxlIGRpc2N1c3Npb24sIHBsZWFzZSBleHBsYWluIHRo YXQgb25lIGEgYml0IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgRmViIDYsIDIwMTkgYXQgMTI6MTUgUE0g QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVu dGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtmYXImcXVvdDsgc2hvdWxkIGhhdmUg c2FpZCAmcXVvdDtmYWlyJnF1b3Q7IGluIHRoZSBwcmV2aW91cyBtZXNzYWdlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiA1LCAyMDE5IGF0IDQ6MzUgUE0gQnJpYW4gQ2FtcGJl bGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJy ZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JdCBtYXkgd2VsbCBiZSBkdWUgdG8gbXkgb3duIGludGVsbGVjdHVh bCBzaG9ydGNvbWluZ3MgYnV0IHRoZXNlIGlzc3Vlcy9xdWVzdGlvbnMvY29uZnVzaW9uLXBvaW50 cyBhcmUgbm90IHJlc29uYXRpbmcgZm9yIG1lIGFzIGJlaW5nIHByb2JsZW1hdGljLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZSBtb3JlIGdlbmVyYWwgc3RhbmNlIG9mICZxdW90O3RoaXMgaXNuJ3QgbmVlZGVk IG9yIHdvcnRoIGl0IGluIHRoaXMgZG9jdW1lbnQmcXVvdDsgKEkgdGhpbmsgdGhhdCdzIGZhcj8p IGlzIGJlaW5nIGhlYXJkIHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQy IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYT08YSBocmVmPSJtYWls dG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhbWF6 b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9y ZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3IKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigy MDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihUTDtE UjogcHVudCBBUyBtZXRhZGF0YSB0byBhIHNlcGFyYXRlIGRyYWZ0KTxicj4NCjxicj4NCkFTIHBv aW50cyAjMS0zIGFyZSBhbGwgcXVlc3Rpb25zIEkgd291bGQgaGF2ZSBhcyBhbiBpbXBsZW1lbnRl cjo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Imdt YWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwt bS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgx MzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2 MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUw OWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM4NDE0LTIzc2VjdGlvbi0yRDImYW1wO2Q9RHdNRmFR JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT14ZUhmWU1D YXdXOWwxaE9IcnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJmFtcDtzPWdmTDdlUEFQb0pObFlY QXVXMXhmY3JaTDBNa2dpYnVueVZnSVVyaEdPR2cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+U2Vj dGlvbg0KIDIgb2YgUkZDODQxNDwvYT4gc2F5cyB0b2tlbl9lbmRwb2ludCDigJxpcyBSRVFVSVJF RCB1bmxlc3Mgb25seSB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBpcyBzdXBwb3J0ZWQu4oCdIFNv IHdoYXQgZG9lcyB0aGUgbVRMUy1vbmx5IEFTIHB1dCBoZXJlPw0KPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2 MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4 ODBtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAz MzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYx NjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KVGhlIGNsYWltcyBmb3IgdGhlc2Ugb3RoZXIgZW5kcG9pbnRzIGFyZSBPUFRJT05B TCwgcG90ZW50aWFsbHkgbGVhZGluZyB0byBpbmNvbnNpc3RlbmN5IGRlcGVuZGluZyBvbiBob3cg IzEgZ2V0cyBkZWNpZGVkLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS0yOTE5 OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3 NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMy Z21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWls LW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIx OTY1MzI1NDMxIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIGV4YW1wbGUg dXNhZ2Ugb2YgdGhlIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBwcm9wZXJ0eSBnaXZlbiBl YXJsaWVyIGlzIGluY29tcGF0aWJsZSB3aXRoIFJGQzg0MTQsIHNpbmNlIHNvbWUgb2YgaXRzIGNv bnRlbnRzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbm9uLW1UTFMgZW5kcG9pbnRzLCBhbmQgb3Ro ZXJzIGFyZSBvbmx5IHZhbGlkIGZvciB0aGUgbVRMUyBlbmRwb2ludHMuIEhlbmNlIHRoaXMgcXVl c3Rpb24uDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tLTI5MTk5NTgzMjM5MTcy MTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4 N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQx MzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4 MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzEi IHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGlzIGludHJvZHVjZXMgYSBuZXcg bWV0YWRhdGEgcHJvcGVydHkgdGhhdCBjb3VsZCBpbXBhY3QgaG93IG90aGVyIHNwZWNzIHNob3Vs ZCBleHRlbmQgQVMgbWV0YWRhdGEuIFRoYXQgbmVlZHMgdG8gYmUgYWRkcmVzc2VkLg0KPG86cD48 L286cD48L2xpPjwvb2w+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBjb3VsZCBnbyBvbiBm b3IgY2xpZW50IHBvaW50cyBidXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdoIEni gJlsbCBzaGFyZSB0aGF0ICMzIGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwgYmFj ayBhbiB1cGRhdGUgdG8gdGhlIExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW504oCm Z29vZA0KIHRpbWVzLiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3Ig RW1vamkmcXVvdDsiPiYjMTI4NTE1Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEg cHJvcGVydHkgaXMgd3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJv bHRpbmcgYSBsYXllciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZ dCBkZXNpZ25lZCBmb3IgdGhhdCwgYW5kIEkNCiBkb27igJl0IHRoaW5rIHRoZSBtZXRhZGF0YSBw cm9wb3NhbCBhcyBpdOKAmXMgYmVlbiBkaXNjdXNzZWQgaGVyZSBzdWZmaWNpZW50bHkgZGVhbHMg d2l0aCB0aGUgZmFsbG91dCBmcm9tIHRoYXQuIEluIG15IHZpZXcgdGhpcyBpcyBhIGNvbXBsZXgg ZW5vdWdoIGlzc3VlIGFuZCBpdOKAmXMgZm9yIGEgbnVhbmNlZCBlbm91Z2ggdXNlIGNhc2UgKGFz IGZhciBhcyBJIGNhbiB0ZWxsIGZyb20gZGlzY3Vzc2lvbj8gUGxlYXNlIGNvcnJlY3QgbWUgaWYg SeKAmW0gd3JvbmcpDQogdGhhdCB3ZSBzaG91bGQgcHVudCBpdCB0byBhIHNlcGFyYXRlIGRyYWZ0 IChlLmcuLCDigJxBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSBFeHRlbnNpb25zIGZvciBt VExTIEh5YnJpZHPigJ0pIGFuZCBnZXQgbVRMUyBvdXQgdGhlIGRvb3IuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRl bnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8L3Nw YW4+PC9iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9BdXRoICZsdDs8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgJmx0O2Jj YW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5EYXRlOjwvYj4gTW9uZGF5LCBGZWJydWFyeSA0LCAyMDE5IGF0IDU6MjggQU08 YnI+DQo8Yj5Ubzo8L2I+ICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZs dDtyaWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IE1UTFMgYW5kIGluLWJyb3dzZXIg Y2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRob3NlIHBvaW50cyBvZiBjb25mdXNpb24gc3RyaWtl IG1lIGFzIHNvbWV3aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQgeW91ciBnZW5l cmFsIHBvaW50IGlzIHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFudGkgYWRkaXRp b25hbCBtZXRhZGF0YSBvbiB0aGlzIGlzc3VlIGlzDQogbm90ZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxs IG9mIHdoaWNoIGxlYXZlcyBtZSBhIGJpdCB1bmNlcnRhaW4gYWJvdXQgaG93IHRvIHByb2NlZWQu IFRoZXJlIHNlZW0gdG8gYmUgYSByYW5nZSBvZiBvcGluaW9ucyBvbiB0aGlzIHBvaW50IGFuZCBn YXVnaW5nIGNvbnNlbnN1cyBpcyBwcm92aW5nIGVsdXNpdmUgZm9yIG1lLiBUaGF0J3MgY29uZm91 bmRlZA0KIGJ5IG15IG93biBvcGluaW9uIG9uIGl0IGJlaW5nIHNvbWV3aGF0IGZsdWlkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkFuZCBJJ2QgcmVhbGx5IGxpa2UgdG8gcG9zdCBhbiB1cGRhdGUgdG8gdGhpcyBk cmFmdCBhYm91dCBhIG1vbnRoIG9yIHR3byBhZ28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDEsIDIw MTkgYXQgNTowMyBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEg aHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4uLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNv bG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Db25mdXNpb24gZnJvbSB0aGUgQVPigJlzIHBlcnNwZWN0aXZlOjxvOnA+PC9vOnA+PC9w Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iZ21haWwtbS0yOTE5OTU4MzIz OTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQz NDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwt bTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0 MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1 NDMxIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KSWYgSSBvbmx5IHN1cHBvcnQg bVRMUywgZG8gSSBuZWVkIHRvIGluY2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91cmkgYW5kIG10 bHNfZW5kcG9pbnRzPyBTaG91bGQgSSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8gT3Igc2V0IGl0 IHRvIHRoZSBlbXB0eSBzdHJpbmc/DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1t LTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3 OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1 MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAw Z21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFp bC1tMjE5NjUzMjU0MzEiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQpXaGF0IGlm IEkgb25seSBzdXBwb3J0IG1UTFMgZm9yIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IG5vdCByZXZv Y2F0aW9uIG9yIHVzZXIgaW5mbz8NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0t MjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5 NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUw OTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBn bWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWls LW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8yIj4NCkhvdyBkbyBJ IHNwZWNpZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1UTFMgdG9rZW4gZW5kcG9p bnQ/IERvZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5IHRvIGJvdGggdGhlIG1U TFMgYW5kIG5vbi1tVExTIGVuZHBvaW50cz8NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Imdt YWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwt bS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgx MzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2 MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUw OWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8yIj4NCkni gJltIHVzaW5nIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cuIERvIEkgaW5jbHVkZSBhIG1UTFMt ZW5hYmxlZCBkZXZpY2VfYXV0aG9yaXphdGlvbl9lbmRwb2ludCB1bmRlciBtdGxzX2VuZHBvaW50 cz8NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbmZ1 c2lvbiBmcm9tIHRoZSBjbGllbnTigJlzIHBlcnNwZWN0aXZlOjxvOnA+PC9vOnA+PC9wPg0KPG9s IHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEy NDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdn bWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0 NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1 NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxIiBz dHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KQXMgZmFyIGFzIEkga25vdywgSeKAmW0g YSBwdWJsaWMgY2xpZW50LCBhbmQgZG9u4oCZdCBrbm93IGFueXRoaW5nIGFib3V0IG1UTFMsIGJ1 dCB0aGUgSVQgYWRtaW5zIGluc3RhbGxlZCBjbGllbnQgY2VydHMgaW4gdGhlaXIgdXNlcnPigJkg YnJvd3NlcnMgYW5kIHRoZSBBUyBleHBlY3RzIHRvIHVzZSB0aGF0IHRvIGF1dGhlbnRpY2F0ZSBt ZS4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQw OGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21h aWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1 Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5 Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5 bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCk15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFz aGVkIGJlY2F1c2UgdGhlIG1UTFMtb25seSBBUyBvbWl0dGVkIHRva2VuX2VuZHBvaW50X3VyaS4u DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0MDhn bWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWls LW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5 OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5 NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzEiIHN0eWxl PSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hl ZCBiZWNhdXNlIGl0IGRpZG7igJl0IGV4cGVjdCB0byBlbmNvdW50ZXIgYSBKU09OIG9iamVjdCBh cyBhIHBhcmFtZXRlciB2YWx1ZS4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0t MjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5 NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUw OTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBn bWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWls LW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSBtVExT LW9ubHkgQVMgZGlkbuKAmXQgcHJvdmlkZSBhIHZhbHVlIGZvciBtdGxzX2VuZHBvaW50cywgd2hh dCBkbyBJIGRvPyA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tLTI5MTk5NTgzMjM5 MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0 ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1t NjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQz MTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0 MzEiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpJIGRvbuKAmXQga25vdyB3aGF0 IHRoYXQg4oCcbeKAnSBtZWFucywgYnV0IHRoZXkgdG9sZCBtZSB0byB1c2UgSFRUUFMsIHNvIEkg c2hvdWxkIHVzZSB0aGUgb25lIHdpdGgg4oCcdGxz4oCdIGluIGl0cyBuYW1lLCByaWdodD8NCjxv OnA+PC9vOnA+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgeW91IGNh biB3cml0ZSBub3JtYXRpdmUgdGV4dCB0aGF0IGFuc3dlcnMgbW9zdCBvZiB0aGVzZS4gQnV0IHlv deKAmWxsIGhhdmUgdG8gY2xlYXJseSBjb3ZlciBhIGxvdCBvZiBzaW1pbGFyLWJ1dC1zbGlnaHRs eS1kaWZmZXJlbnQgc2NlbmFyaW9zIGFuZCBiZSB2ZXJ5IGV4cGxpY2l0LiBBbmQgaW1wbGVtZW50 ZXJzDQogd2lsbCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9k dWNlcyBvcHBvcnR1bml0aWVzIGZvciBjb25mdXNpb24gYW5kIGZhaWx1cmUgdGhhdCBkbyBub3Qg ZXhpc3Qgbm93LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZlcnlvbmUgd2hvIHN1cHBvcnRzIG1UTFMu IEluIGNvbnRyYXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlzIG9ubHkgcmVxdWlyZWQgd2hlbiBhbiBB UyB3YW50cyB0byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1bmFtYmlndW91cw0KIGluIGl0cyBiZWhh dmlvciBhbmQgbWVhbmluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4t LSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJ ZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjwv c3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QnJpYW4gQ2FtcGJlbGwg Jmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxLCAyMDE5IGF0IDM6 MTcgUE08YnI+DQo8Yj5Ubzo8L2I+ICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gR2VvcmdlIEZs ZXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmdmZmxldGNoQGFvbC5jb208L2E+Jmd0Oywgb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBNVExT IGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgZG9lc24ndCBzZWVtIGxpa2UgdGhhdCBjb25m dXNpbmcgb3IgbGFyZ2Ugb2YgYSBjaGFuZ2UgdG8gbWUgLSBpZiB0aGUgY2xpZW50IGlzIGRvaW5n IE1UTFMgYW5kIHRoZSBnaXZlbiBlbmRwb2ludCBpcyBwcmVzZW50IGluIGBtdGxzX2VuZHBvaW50 c2AsIHRoZW4gaXQgdXNlcyB0aGF0IG9uZS4mbmJzcDsgT3RoZXJ3aXNlDQogaXQgdXNlcyB0aGUg cmVndWxhciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4gQVMgYSBsb3Qgb2YgZmxleGliaWxpdHkgaW4g ZGVwbG95bWVudCBvcHRpb25zLiBJIHBlcnNvbmFsbHkgdGhpbmsgZ2V0dGluZyBhIDMwNyBhcHBy b2FjaCBkZXBsb3llZCBhbmQgd29ya2luZyB3b3VsZCBiZSBtb3JlIGNvbXBsaWNhdGVkIGFuZCBl cnJvciBwcm9uZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBhIG1pbm9yaXR5IHVzZSBjYXNl IGF0IHRoZSBtb21lbnQgYnV0IHRoZXJlIGFyZSBmb3JjZXMgaW4gcGxheSwgbGlrZSB0aGUgcHVz aCBmb3IgaW5jcmVhc2VkIHNlY3VyaXR5IGluIGdlbmVyYWwgYW5kIHRvIGhhdmUgamF2YXNjcmlw dCBjbGllbnRzIHVzZSB0aGUgY29kZSBmbG93LCB0aGF0IHN1Z2dlc3QNCiBpdCB3b24ndCBiZSB0 ZXJyaWJseSB1bnVzdWFsIHRvIHNlZSBhbiBBUyB0aGF0IHdhbnRzIHRvIHN1cHBvcnQgTVRMUyBj bGllbnRzIGFuZCBqYXZhc2NyaXB0L3NwYSBjbGllbnRzIGF0IHRoZSBzYW1lIHRpbWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SSd2ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQgZm9ydGggaW4gdGhpcyB0 aHJlYWQgb24gd2hldGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0YWRhdGEgKG9yIHNvbWV0 aGluZyBsaWtlIGl0KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkga2luZGEgZXhwbGFpbmVk IHNvbWV3aGVyZSBiYWNrDQogaW4gdGhlIDQwIG9yIHNvIG1lc3NhZ2VzIHRoYXQgbWFrZSB1cCB0 aGlzIHRocmVhZC4mbmJzcDsgQnV0IGl0IHNlZW1zIGxpa2UgdGhlIHJvdWdoIGNvbnNlbnN1cyBv ZiB0aGUgZ3JvdXAgaGVyZSBpcyBpbiBmYXZvciBvZiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZy aSwgRmViIDEsIDIwMTkgYXQgMzoxOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7 cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4uLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xv cgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQg Y29uZnVzaW5nIGNoYW5nZSB0byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1 c2UgY2FzZS4gSeKAmW0gZ2V0dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhl IHRleHQgbmVlZGVkIHRvIGNsYXJpZnkgd2hlbg0KIHRoZSBBUyBzaG91bGQgcHJvdmlkZSBgbXRs c19lbmRwb2ludHNgIGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGF0IHZlcnN1cyB1 c2luZyBgdG9rZW5fZW5kcG9pbnQuYCBXaHkgaXMgdGhlIDMwNyBzdGF0dXMgY29kZSBpbnN1ZmZp Y2llbnQgdG8gY292ZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgQVMgc3VwcG9ydHMgYm90aCBt VExTIGFuZCBub24tbVRMUz88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0 MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdp ZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBGcmlk YXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQgMTozMSBQTTxicj4NCjxiPlRvOjwvYj4gR2VvcmdlIEZs ZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86NDBhb2wuY29tQGRtYXJjLi4uLi4u Li4uLi4uaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVz aW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHRoYXQgd291 bGQgd29yay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBGZWIgMSwgMjAxOSBhdCAyOjI4IFBNIEdlb3Jn ZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2g9PGEgaHJlZj0ibWFpbHRvOjQwYW9sLmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW9sLmNvbUBkbWFyYy5pZXRmLi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJy ZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5XaGF0IGlmIHRo ZSBBUyB3YW50cyB0byBPTkxZIHN1cHBvcnQgTVRMUyBjb25uZWN0aW9ucy4gRG9lcyBpdCBub3Qg c3BlY2lmeSB0aGUgb3B0aW9uYWwgJnF1b3Q7bXRsc19lbmRwb2ludHMmcXVvdDsgYW5kIGp1c3Qg dXNlIHRoZSBub3JtYWwgbWV0YWRhdGEgdmFsdWVzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEvMTUvMTkgODo0OCBBTSwgQnJpYW4gQ2Ft cGJlbGwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCB3b3VsZCBkZWZpbml0ZWx5IGJlIG9wdGlvbmFs LCBhcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgbWFkZSBjbGVhci4uIEl0J2QgYmUgc29tZXRoaW5n IHRvIHRoZSBlZmZlY3Qgb2Ygb3B0aW9uYWwgZm9yIHRoZSBBUyB0byBpbmNsdWRlIGFuZCBjbGll bnRzIGRvaW5nIE1UTFMgd291bGQgdXNlIGl0IHdoZW4NCiBwcmVzZW50IGluIEFTIG1ldGFkYXRh LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0IEFNIERhdmUgVG9uZ2UgJmx0Ozxh IGhyZWY9Im1haWx0bzpkYXZlLnRvbmdlQG1vbWVudHVtZnQuY28udWsiIHRhcmdldD0iX2JsYW5r Ij5kYXZlLnRvbmdlQG1vbWVudHVtZnQuY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7 LHNhbnMtc2VyaWYiPkknbSBpbiBmYXZvdXIgb2YgdGhlIGBtdGxzX2VuZHBvaW50c2AgbWV0YWRh dGEgcGFyYW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxkIGJlIG9wdGlvbmFsLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBl bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUNCiByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX29hdXRoJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3 UEp4YyZhbXA7cz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxp PkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbg0KIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5k IGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbg0KIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCjxiPjxpPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5i c3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbg0KIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4g VGhhbmsgeW91LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+ DQo8Yj48aT5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9y IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbg0KIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3Nh Z2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91 LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbg0KIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFj aG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvaT48L2I+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19vYXV0aCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJmFtcDttPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMm YW1wO3M9Z0NjOXRKTFZ1dUs3Q1hVZ3pBXzE5ZkVUX1c2OVN5VnZMcHBrOWRUdVhxQSZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5P VElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQg bWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4NCiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPkNPTkZJREVOVElBTElUWSBO T1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk IG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g QW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbg0KIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvaT48L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1 dGgmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZhbXA7bT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJmFtcDtz PWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdCA8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuLmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJ eGhJMS1ZdmJPa2lnczdxTHdQSnhjJmFtcDtzPWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlT eVZ2THBwazlkVHVYcUEmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tp Z3M3cUx3UEp4YyZhbXA7cz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1 WHFBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgm YW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFw SV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZh bXA7bT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJmFtcDtzPWdD Yzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChz KS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlDQogcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFj aG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3TUZhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3 VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZhbXA7cz1nQ2M5dEpMVnV1SzdDWFVn ekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmYW1w O2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7 bT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJmFtcDtzPWdDYzl0 SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_B1A6967E17D742FC9C67613084CA2F65amazoncom_-- From nobody Mon Feb 18 13:55:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A898131051 for ; Mon, 18 Feb 2019 13:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPT4NZej9293 for ; Mon, 18 Feb 2019 13:54:54 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86841274D0 for ; Mon, 18 Feb 2019 13:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1550526893; x=1582062893; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D50OD0qS1zSBezUz86Dzuqg6u8LVbv5XcU8skvgYoTw=; b=qAS+do3Jf2Wq/L44bxHJIgSIL/QWyqa9nYQ5Nsy9zWlfJ/TnUjiE23LL AuQeLKQFiEK6zVOsfk8RpRypho3il2ki+9oNboZSai9r1S8LFDEf8TqOz Czi/SNM86Wd4FF5Jq67dza9jUWPDrczHUwQYPRylDgprsw+G/62d2W9eA A=; X-IronPort-AV: E=Sophos;i="5.58,385,1544486400"; d="scan'208,217";a="788414664" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2019 21:54:50 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id x1ILsksv020389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Feb 2019 21:54:48 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Feb 2019 21:54:47 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Feb 2019 21:54:47 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 18 Feb 2019 21:54:47 +0000 From: "Richard Backman, Annabelle" To: Neil Madden , George Fletcher CC: oauth Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery Thread-Index: AQHUxImcYGYvMmjDYECA9hOXj77UKKXf6zgAgAFU2QCAAAFSAIAAAquAgAAEM4CAAAmrgIAESAWA Date: Mon, 18 Feb 2019 21:54:47 +0000 Message-ID: <10A7B95E-D7AD-4BED-AABD-A05F8C9ABFD8@amazon.com> References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com> In-Reply-To: <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.24] Content-Type: multipart/alternative; boundary="_000_10A7B95ED7AD4BEDAABDA05F8C9ABFD8amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 21:55:00 -0000 --_000_10A7B95ED7AD4BEDAABDA05F8C9ABFD8amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmVpbOKAmXMgZXhhbXBsZSBkZW1vbnN0cmF0ZXMgaG93IHRoZSBtdGxzX2VuZHBvaW50cyBhcHBy b2FjaCBsZWFkcyB0byBjb25mdXNpb24uIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgbWV0YWRhdGEg ZnJhZ21lbnQ6DQoNCnsNCiAg4oCcdG9rZW5fZW5kcG9pbnTigJ06IOKAnGh0dHBzOi8vYXMuZXhh bXBsZS5jb20vdG9rZW7igJ0sDQrigJx0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9y dGVk4oCdOiBbIOKAnGNsaWVudF9zZWNyZXRfYmFzaWPigJ0sIOKAnHRsc19jbGllbnRfYXV0aOKA nSBdLA0K4oCcbXRsc19lbmRwb2ludHPigJ06IHsNCiAg4oCcdG9rZW5fZW5kcG9pbnTigJ06IOKA nGh0dHBzOi8vYXMuZXhhbXBsZS5jb20vbXRscy90b2tlbuKAnQ0KfQ0KfQ0KDQpXaGljaCBvZiB0 aGVzZSBzdGF0ZW1lbnRzIGFib3V0IGVuZHBvaW50cyBvbiBodHRwczovL2FzLmV4YW1wbGUuY29t LyBhcmUgdHJ1ZT8NCg0KICAxLiAgVGhlIC90b2tlbiBlbmRwb2ludCBvbmx5IHN1cHBvcnRzIGNs aWVudF9zZWNyZXRfYmFzaWMsIGFuZCAvbXRscy90b2tlbiBvbmx5IHN1cHBvcnRzIHRsc19jbGll bnRfYXV0aC4NCiAgMi4gIFRoZSAvdG9rZW4gZW5kcG9pbnQgc3VwcG9ydHMgYm90aCBtZXRob2Rz LCBhbmQgL210bHMvdG9rZW4gb25seSBzdXBwb3J0cyB0bHNfY2xpZW50X2F1dGguDQogIDMuICBC b3RoIC90b2tlbiBhbmQgL210bHMvdG9rZW4gc3VwcG9ydCBib3RoIG1ldGhvZHMuDQoNCkFsbCBv ZiB0aGVzZSBjb3VsZCBiZSByZWFzb25hYmxlIGludGVycHJldGF0aW9ucyBvZiB0aGlzIG1ldGFk YXRhLiBXaGVuIHByb3BlcnRpZXMgbWVhbiBkaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBj b250ZXh0cywgYW1iaWd1aXR5IGFib3VuZHMuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPg0K RGF0ZTogRnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxOSBhdCAxMjozMyBQTQ0KVG86IEdlb3JnZSBG bGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IG9hdXRoIDxv YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFtVTlZFUklGSUVEIFNFTkRF Ul0gUmU6IE1UTFMgdG9rZW4gZW5kb2ludCAmIGRpc2NvdmVyeQ0KDQpBcyBhbm90aGVyIGNhc2Ug LSBpZiB0aGUgY2xpZW50IHdhbnRzIGNlcnRpZmljYXRlLWJvdW5kIGFjY2VzcyB0b2tlbnMgYnV0 IHN0aWxsIGF1dGhlbnRpY2F0ZXMgd2l0aCBjbGllbnRfc2VjcmV0X2Jhc2ljIG9yIGlzIGEgcHVi bGljIGNsaWVudCAoYXMgcGVyIFsxXSksIHByZXN1bWFibHkgaXQgY2FuIHVzZSB0aGUgbXRscy1z cGVjaWZpYyBlbmRwb2ludHMgYW5kIGFzc3VtZSB0aGV5IHN1cHBvcnQgYWxsIHRoZSBvdGhlciBh dXRoZW50aWNhdGlvbiBtZXRob2RzIGFzIHRoZSBub3JtYWwgZW5kcG9pbnRzPw0KDQpCdXQgc28g bG9uZyBhcyB3ZSBjYW4gZGVmaW5lIHNvbWUgaGFsZi1zZW5zaWJsZSBiZWhhdmlvdXIgZm9yIHRo ZXNlIGNhc2VzLCBJ4oCZbSBoYXBweSB3aXRoIHRoaXMgcHJvcG9zYWwuDQoNClsxXSBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1tdGxzLTEyI3NlY3Rpb24tNC4z DQoNCk9uIDE1IEZlYiAyMDE5LCBhdCAxOTo1NywgR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00 MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5p ZXRmLm9yZz4+IHdyb3RlOg0KSnVzdCB0byBtYWtlIHN1cmUgSSB1bmRlcnN0YW5kLi4uDQoNCklm IHRoZSBBUyBPTkxZIHN1cHBvcnRzIE1UTFMgZW5kcG9pbnRzLCB0aGVuIGl0Li4uDQogICAqIHNl dHMgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQnIHRvICd0bHNfY2xpZW50 X2F1dGgnDQogICAqIGRvZXMgTk9UIHNwZWNpZnkgdGhlIG1sdHNfZW5kcG9pbnRzIHNlY3Rpb24N Cg0KSWYgdGhlIEFTIGRvZXMgTk9UIHN1cHBvcnQgTVRMUyBlbmRwb2ludHMsIHRoZW4gaXQuLi4N CiAgICAqIGRvZXMgTk9UIHNwZWNpZnkgYSB2YWx1ZSBvZiAndGxzX2NsaWVudF9hdXRoJyBpbiB0 aGUgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQnDQogICAgKiBkb2VzIE5P VCBzcGVjaWZ5IHRoZSBtbHRzX2VuZHBvaW50cyBzZWN0aW9uDQoNCklmIHRoZSBBUyBzdXBwb3J0 cyBCT1RIICJyZWd1bGFyIiBhbmQgTVRMUyBlbmRwb2ludHMsIHRoZW4gaXQuLi4NCiAgICAqIHNl dHMgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQnIHRvICJjbGllbnRfc2Vj cmV0X2Jhc2ljIHRsc19jbGllbnRfYXV0aCIgKGFzIGFuIGV4YW1wbGUpDQogICAgKiBzcGVjaWZp ZXMgbXRsc19lbmRwb2ludHMgaW4gYWRkaXRpb24gdG8gdGhlIGVuZHBvaW50cyBub3JtYWxseSBk ZWZpbmVkIGZvciB0aGUgQVMNCg0KRm9yIHRoZSBjbGllbnQsIGlmIGl0IHN1cHBvcnRzIG10bHMg QU5EIGlmIGl0IGZpbmRzICd0bHNfY2xpZW50X2F1dGgnIGluIHRoZSAndG9rZW5fZW5kcG9pbnRf YXV0aF9tZXRob2RzX3N1cHBvcnRlZCcgdGhlbiBpdCBmaXJzdCBsb29rcyB0byBzZWUgaWYgYW4g bXRsc19lbmRwb2ludHMgb2JqZWN0IGlzIHByb3ZpZGVkIGFuZCBpZiBzbyB1c2VzIHRob3NlIGVu ZHBvaW50cywgb3RoZXJ3aXNlIGl0IGFzc3VtZXMgdGhlIFJGQyA4NDE0IGRlZmluZWQgZW5kcG9p bnRzIHN1cHBvcnQgTUxUUy4NCg0KTm93IGlmIHRoZSAnbXRsc19lbmRwb2ludHMnIHNlY3Rpb24g ZGVmaW5lcyBhICdtdGxzX3Rva2VuX2VuZHBvaW50JyBidXQgbm90IGFuICdpbnRyb3NwZWN0aW9u X2VuZHBvaW50JyBidXQgdGhlIFJGQyA4NDE0IG1ldGEtZGF0YSBkb2VzIHNwZWNpZnkgYW4gJ2lu dHJvc3BlY3Rpb25fZW5kcG9pbnQnLCBpcyB0aGUgY2xpZW50IHN1cHBvc2VkIHRvIGFzc3VtZSB0 aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludCBhbHNvIHN1cHBvcnRzIE1UTFMgZXZlbiB0aG91Z2gg aXQgd2Fzbid0IGxpc3RlZCBpbiB0aGUgJ210bHNfZW5kcG9pbnRzJyBvYmplY3Q/IG9yIHNob3Vs ZCBpdCBhc3N1bWUgdGhhdCBlbmRwb2ludCBkb2VzIE5PVCBzdXBwb3J0IE1UTFMgYmVjYXVzZSBp dCdzIG5vdCBwYXJ0IG9mIHRoZSAnbXRsc19lbmRwb2ludHMnIG9iamVjdD8NCg0KSXQgd2lsbCB3 b3JrLCB0aG91Z2ggaXQgc3RpbGwgZmVlbHMgImhhY2t5IiBhbmQgb3Zlcmx5IGNvbXBsZXguDQoN ClRoYW5rcywNCkdlb3JnZQ0KT24gMi8xNS8xOSAyOjQyIFBNLCBQaGlsIEh1bnQgd3JvdGU6DQpU aGlzIGlzIHdoYXQgSSB3b3VsZCBleHBlY3QuDQpQaGlsDQoNCk9uIEZlYiAxNSwgMjAxOSwgYXQg MTE6MzIgQU0sIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52YS5p cEBnbWFpbC4uY29tPj4gd3JvdGU6DQpIZWxsbyBHZW9yZ2UsDQoNCldoYXQgZG8geW91IHRoaW5r IGFib3V0IHdoYXQgaSB3cm90ZSBlYXJsaWVyPw0KDQpjbGllbnRzIG5vdCBoYXZpbmcgbXRscyBj YXBhYmlsaXRpZXMgd29uJ3QgY2FyZSBhYm91dCB0aGUgYWRkaXRpb25hbCBtZXRob2QgbWVtYmVy cyBiZWluZyBwcmVzZW50LiBDbGllbnRzIHRoYXQgZG8gaW1wbGVtZW50IG10bHMgYnkgdGhlIHNw ZWNpZmljYXRpb24gd2lsbCBrbm93IHRvIGxvb2sgZm9yIG10bHNfZW5kcG9pbnRzIGFuZCBmYWxs IGJhY2sgdG8gcmVndWxhciBvbmVzIGlmIHRoZSBzcGVjaWZpYyBlbmRwb2ludCBvciBtdGxzX2Vu ZHBvaW50cyByb290IHByb3BlcnR5IGlzIG5vdCBwcmVzZW50Lg0KDQpTIHBvemRyYXZlbSwNCkZp bGlwIFNrb2thbg0KDQoNCk9uIEZyaSwgMTUgRmViIDIwMTkgYXQgMjA6MjksIEdlb3JnZSBGbGV0 Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFvbC5jb21A ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkgc3RpbGwgZG9uJ3Qgc2VlIGhvdyB3ZSBzb2x2ZSBv bmUgb2YgdGhlIHVzZSBjYXNlcyBBbm5hYmVsbGUgYnJvdWdodCB1cC4NCg0KSWYgdGhlICdtdGxz X2VuZHBvaW50cycgb2JqZWN0IGp1c3QgY29udGFpbnMgZW5kcG9pbnRzLCB0aGVuIGluIHRoZSBt YWluIG1ldGEtZGF0YSBzZWN0aW9uLCBzaG91bGQgJ3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9k c19zdXBwb3J0ZWQnIGluY2x1ZGUgYW4gaW5kaWNhdGlvbiBvZiAndGxzX2NsaWVudF9hdXRoJyBl dmVuIHRob3VnaCB0aGUgZW5kcG9pbnQgc3BlY2lmaWVkIGJ5ICd0b2tlbl9lbmRwb2ludCcgZG9l cyBOT1Qgc3VwcG9ydCBNVExTPw0KDQpUaGFua3MsDQpHZW9yZ2UNCk9uIDIvMTQvMTkgNjowOCBQ TSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQpNYXliZSBJJ20gd3JvbmcgaGVyZSAoaXQncyBuZXZl ciBvdXQgb2YgdGhlIHF1ZXN0aW9uKSBidXQgYmFzZWQgb24gdGhpcyBwcmV2aW91cyBtZXNzYWdl PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFp bGFyY2hpdmUuaWV0Zi5vcmdfYXJjaF9tc2dfb2F1dGhfZXFPVHE3NGhiSHo5TXYtNUZVemhrdmkz emdFUU0mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZ TUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1zV0dFVE96WGJJN0xaei1v UWJHcU8ya0VEUWtIRXJtcm1BYWthRWVHSUl3JmU9PiBhbmQgdGhpcyBvbmU8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRm Lm9yZ19hcmNoX21zZ19vYXV0aF9OSnFXOWtJdnhMUmstMkQ0cGlDOS0yREhzUjd3bHJNJmQ9RHdN RmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT14ZUhmWU1DYXdXOWwxaE9I cnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQSnhjJnM9VnRVWGNMbElQcG4tdFdoWG4xbjA2c0xRc21P WjZ2anBDSlVIMkh2b2VBTSZlPT4gSSBiZWxpZXZlIHRoYXQgYWN0dWFsbHkgeW91IGFyZSBib3Ro IGluIGZhdm9yIChnZW5lcmFsbHkgYW55d2F5KSBvZiB0aGUgcHJvcG9zYWwgd2l0aCB0aGUgb3B0 aW9uYWwgIm10bHNfZW5kcG9pbnRzIiBwYXJhbWV0ZXIuIFdoaWxlIEkgYmVsaWV2ZSB0aGF0IHRo ZSBjb21tZW50IGFib3V0IG9wdGlvbmFsaXR5IGFuZCBjb21wbGV4aXR5IHdhcyBtZWFudCB0byBi ZSBhIG1vcmUgZ2VuZXJhbCByZW1hcmsuIFdoaWxlIEkgY2FuIGNlcnRhaW5seSBhcHByZWNpYXRl IGEgZGVzaXJlIHRvIGtlZXAgdGhpbmdzIHNpbXBsZSwgSSBkbyByZWdyZXQgdGhhdCB0aGlzIHRo cmVhZCB0b29rIGEgdHVybiB0b3dhcmRzIHBlcnNvbmFsLiBXaGV0aGVyIGl0IHdhcyB0aGUgaW50 ZW50IG9yIG5vdCwgdGhlcmUncyBhbiBpbXBhY3QuDQoNCg0KDQpPbiBUaHUsIEZlYiAxNCwgMjAx OSBhdCAxMDoyMCBBTSBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkkgZmVlbCBJIGhhdmUgdG8gZGlzYWdyZWUuICBJ IGFncmVlIHRoYXQgb3B0aW9uYWxpdHkgaXMgb2Z0ZW4gY29tcGxleGl0eSBhbmQgc2hvdWxkIGJl IGF2b2lkZWQuIEJ1dCwgSSB0aGluayB0aGUgb3B0aW9uYWxpdHkgaGVyZSBpcyBhbiBhZ2lsaXR5 IGZlYXR1cmUgYWxsb3dpbmcgbXRscyB0byB3b3JrIGFjcm9zcyBhIGRpdmVyc2lmaWVkIG1hcmtl dCBvZiBkaWZmZXJlbnQgdHlwZXMgb2YgdGxzIHRlcm1pbmF0b3JzIHdpdGggdmFyeWluZyBjYXBh YmlsaXR5LiBMYWNrIG9mIGFwcHJvcHJpYXRlIGRpc2NvdmVyeS9vcHRpb25zIGNvdWxkIHNlcnZl IHRvIG1ha2UgdGhlIHNwZWMgdW51c2FibGUgaW4gbWFueSBjYXNlcy4NCg0KQSBjb21wbGljYXRp bmcgZmFjdG9yIHdpdGggdGxzIGlzIHRoYXQgYSB0bHMgbGF5ZXIgZmFpbHVyZSBwcmV2ZW50cyB0 aGUgQVMgZnJvbSBpc3N1aW5nIGEgY29ycmVjdGluZyBkaXJlY3RpdmUgbGlrZSBhbiBodHRwIGVy cm9yIG9yIGh0dHAgcmVkaXJlY3QuDQoNCldlIGhhdmUgdG8gYmUgc3VyZSBub3QgdG8gYnJlYWsg ZXhpc3RpbmcgY2xpZW50cyBzbyB3ZSBtYXkgaW4gc29tZSBjYXNlcyBuZWVkIG10bHMgb25seSBl bmRwb2ludHMuIEkgYW0gbm90IGZhciBlbm91Z2ggYWxvbmcgdG8ga25vdyBmb3Igc3VyZS4gQnV0 IEkgdGVuZCB0byBhZ3JlZSB3aXRoIEJyaWFuIG9uIHRoaXMuDQoNClRoaXMgbWF5IGJlIGEgc2ln biB3ZSBuZWVkIG1vcmUgaW1wbGVtZW50YXRpb24gZGF0YSAoaW5jbHVkaW5nIGZyb20gdGxzIHdn KSB0byBtYWtlIHRoZSByaWdodCBjYWxsLg0KDQpQaGlsDQoNCk9uIEZlYiAxNCwgMjAxOSwgYXQg ODo1NiBBTSwgRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRv OmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNClNvcnJ5IC0gdGhpcyB3YXMgbm90 IG1lYW50IHRvIGJlIHNuaWRlIGF0IGFsbC4NCg0KSXQgd2FzIGhvbmVzdCBmZWVkYmFjayB0aGF0 IHlvdSBhbHNvIG5lZWQgdG8ga2VlcCBzb2Z0d2FyZSBjb21wbGV4aXR5IGluIG1pbmQgd2hlbiBj cmVhdGluZyBhIHNwZWMuIEV2ZXJ5IE1BWSBvciBPUFRJT05BTCwgb3IgZG8gaXQgbGlrZSB0aGlz IE9SIHRoYXQsIG9yIHNlbmQgdmFsdWVzIGluIGFyYml0cmFyeSBvcmRlciBhZGRzIHRvIGNvbXBs ZXhpdHkuIENvbXBsZXhpdHkgaXMgdGhlIG5hdHVyYWwgZW5lbXkgb2Ygc2VjdXJpdHkuDQoNCkNo ZWVycw0K4oCU4oCU4oCUDQpEb21pbmljaw0KDQoNCk9uIDEzLiBGZWJydWFyeSAyMDE5IGF0IDIw OjM5OjE2LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAocmljaGFubmFAYW1hem9uLmNvbTxt YWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4pIHdyb3RlOg0KVGhlIGlzc3VlIGlzIHRoYXQgdGhl IHByb3Bvc2FsIHZpb2xhdGVzIHRoZSBzdGFuZGFyZCBieSBjaGFuZ2luZyB0aGUgc2VtYW50aWNz IG9mIGEgcGFyYW1ldGVyIGl0IGRlZmluZXMuIFdlIHNob3VsZCBiZSB2ZXJ5LCB2ZXJ5LCBWRVJZ IGNhcmVmdWwgYWJvdXQgdGVsbGluZyBpbXBsZW1lbnRlcnMgdG8gdmlvbGF0ZSBhbiBleGlzdGlu ZyBzdGFuZGFyZC4uLiBUaGlzIGNoYW5nZSBtaWdodCBwcm92ZSBpbmNvbXBhdGlibGUgd2l0aCBl eGlzdGluZyBvciBmdXR1cmUgaW1wbGVtZW50YXRpb25zIG9mIDg0MTQsIGl0IG1pZ2h0IG5vdCwg YnV0IGJ5IHZpb2xhdGluZyB0aGUgc3RhbmRhcmQgdGhlIHByb3Bvc2FsIGNyZWF0ZXMgYW4gb3Bw b3J0dW5pdHkgZm9yIGluY29tcGF0aWJpbGl0eSB0aGF0IGRpZG7igJl0IGV4aXN0IGJlZm9yZS4N Cg0KQXMgZmFyIGFzIHNpbXBsaWNpdHkgaXMgY29uY2VybmVkLCBJIGZpbmQgYSBzb2x1dGlvbiB0 aGF0IHJldXNlcyB0aGUgZXhpc3RpbmcgZGF0YSBtb2RlbCBhbmQgbmF0dXJhbGx5IHN1cHBvcnRz IGV4aXN0aW5nIGFuZCBmdXR1cmUgZXh0ZW5zaW9ucyB0byBiZSBmYXIgc2ltcGxlciB0aGFuIG9u ZSB0aGF0IGludHJvZHVjZXMgYW1iaWd1b3VzIHNlbWFudGljcyB0byBleGlzdGluZyBwYXJhbWV0 ZXJzLiBHZW5lcmFsbHkgc3BlYWtpbmcsIGRhdGEgbW9kZWxzIHdpdGggcHJvcGVydGllcyB0aGF0 IG1lYW4gZGlmZmVyZW50IHRoaW5ncyBpbiBkaWZmZXJlbnQgY29udGV4dHMgdGVuZCB0byBiZSBm cmFnaWxlIGFuZCByZXF1aXJlIG1vcmUgY29tcGxleCBjb2RlIHRvIHdvcmsgd2l0aC4gQnV0IHRo YXTigJlzIGp1c3QgbXkgZXhwZXJpZW5jZSBhcywgeW91IGtub3csIGFuIGFjdHVhbCBkZXZlbG9w ZXIuDQoNCkxldOKAmXMga2VlcCB0aGUgYXNzdW1wdGlvbnMgYW5kIHNuaWRlIHJlbWFya3MgYWJv dXQgb3RoZXJz4oCZIGJhY2tncm91bmRzIG9mZiB0aGUgbGlzdCwgcGxlYXNlLg0KDQotLQ0KQW5u YWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogRG9taW5pY2sg QmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZp bGVnZS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSAxMywgMjAxOSBhdCA0OjE4IEFN DQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxt YWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBGaWxpcCBTa29rYW4gPHBhbnZhLmlwQGdtYWls LmNvbTxtYWlsdG86cGFudmEuLmlwQGdtYWlsLmNvbT4+DQpDYzogQnJpYW4gQ2FtcGJlbGwgPGJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bT4+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1h aWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRI LVdHXSBNVExTIHRva2VuIGVuZG9pbnQgJiBkaXNjb3ZlcnkNCg0KSSBhbSBmb3Iga2VlcGluZyBp dCBzaW1wbGUgYW5kIG5vdCBpbnRyb2R1Y2luZyBhbm90aGVyIGxpbmsgdG8gZm9sbG93Lg0KDQpJ IHNvbWV0aW1lcyB3b25kZXIgaG93IG1hbnkgb2YgdGhlIHNwZWMgYXV0aG9ycyBhcmUgYWN0dWFs bHkgZGV2ZWxvcGVycyAtIHRoZXNlIHN1Z2dlc3Rpb25zIG1ha2Ugc29mdHdhcmUgdW5uZWNlc3Nh cnkgY29tcGxleCA7KQ0KDQrigJTigJTigJQNCkRvbWluaWNrDQoNCg0KT24gMTMuIEZlYnJ1YXJ5 IDIwMTkgYXQgMTI6MjU6MTMsIEZpbGlwIFNrb2thbiAocGFudmEuaXBAZ21haWwuY29tPG1haWx0 bzpwYW52YS5pcEBnbWFpbC5jb20+KSB3cm90ZToNCkhlbGxvLA0KDQpBZGRpdGlvbmFsbHksIGEg bWV0YWRhdGEgZG9jdW1lbnQgdGhhdCBvbWl0cyB0b2tlbl9lbmRwb2ludCBpbiBmYXZvciBvZiBt dGxzX2VuZHBvaW50cyBzaW5jZSBvbmx5IG1UTFMgaXMgc3VwcG9ydGVkIHdvdWxkIHZpb2xhdGUg ODQxNCwgYXMgODQxNCBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBv bmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0NCg0KbXRscyBvbmx5 IEFTIGRvZXNuJ3QgZ2V0IGFueXRoaW5nIG91dCBvZiB1c2luZyBtdGxzX2VuZHBvaW50cywgaXRz IHVzZSBzaG91bGQgbm90IGJlIHJlY29tbWVuZGVkIGZvciBzdWNoIEFTIGFuZCByZWd1bGFyIGVu ZHBvaW50cyB3aWxsIGJlIHVzZWQsIHRoaXMgc2F0aXNmaWVzIHRoZSByZXF1aXJlbWVudA0KSGVy ZSBpcyBvbmUgZXhhbXBsZSwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg4oCcc3Ry YXcgbWFu4oCdIGZvcm1hdCBwcmVzZW50ZWQgaW4gdGhpcyB0aHJlYWQ6IFJGQzg0MTQgZGVmaW5l cyB0aGUgdmFsdWUgb2YgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBhcyBh IOKAnEpTT04gYXJyYXkgY29udGFpbmluZyBhIGxpc3Qgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9u IG1ldGhvZHMgc3VwcG9ydGVkIGJ5IHRoaXMgdG9rZW4gZW5kcG9pbnQu4oCdIElmIHRoYXQgYXJy YXkgY29udGFpbnMg4oCcdGxzX2NsaWVudF9hdXRo4oCdIGFuZCB0aGUgZW5kcG9pbnQgc3BlY2lm aWVkIGluIHRva2VuX2VuZHBvaW50IGRvZXMgbm90IHN1cHBvcnQgbVRMUywgdGhlbiB0aGF0IG1l dGFkYXRhIHZpb2xhdGVzIDg0MTQuIFlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgYnkgYWRkaW5nIGEg dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhlIG10 bHNfZW5kcG9pbnRzIG9iamVjdCwgYW5kIGxpa2V3aXNlIGZvciB0aGUgb3RoZXIgZW5kcG9pbnRz IGFuZCBhdXRoIG1ldGhvZHMuIElmIHlvdSB0YWtlIHRoYXQgdG8gaXRzIGxvZ2ljYWwgY29uY2x1 c2lvbiwgeW91IGVuZCB1cCB3aXRoIGEgY29tcGxldGUgbWV0YWRhdGEgZG9jdW1lbnQgaGFuZ2lu ZyBvZmYgb2YgbXRsc19lbmRwb2ludHMuIEl04oCZcyB0aGF0IGxpbmUgb2YgdGhvdWdodCB0aGF0 IGxlZCBtZSB0byBzdWdnZXN0IGp1c3QgcG9pbnRpbmcgdG8gYW4gYWx0ZXJuYXRlIGRvY3VtZW50 Lg0KDQpBc3N1bWluZyB3ZSBnbyB3aXRoIHVzaW5nIHRoZSBzYW1lIHJvb3QgYXV0aCBtZXRob2Rz IHByb3BlcnR5LCB3aGF0J3MgdGhlIGlzc3VlPyBDbGllbnRzIG5vdCBoYXZpbmcgbXRscyBjYXBh YmlsaXRpZXMgd29uJ3QgY2FyZSBhYm91dCB0aGUgYWRkaXRpb25hbCBtZXRob2QgbWVtYmVycyBi ZWluZyBwcmVzZW50LiBDbGllbnRzIHRoYXQgZG8gaW1wbGVtZW50IG10bHMgYnkgdGhlIHNwZWNp ZmljYXRpb24gd2lsbCBrbm93IHRvIGxvb2sgZm9yIG10bHNfZW5kcG9pbnRzIGFuZCBmYWxsIGJh Y2sgdG8gcmVndWxhciBvbmVzIGlmIHRoZSBzcGVjaWZpYyBlbmRwb2ludCBvciBtdGxzX2VuZHBv aW50cyByb290IHByb3BlcnR5IGlzIG5vdCBwcmVzZW50Lg0KDQpJIGdhdmUgYG10bHNfYWx0ZXJu YXRlX21ldGFkYXRhYCByb3V0ZSBhIHRob3VnaHQgYW5kIGRvbid0IHNlZSBob3cgaXQgaGVscHMs IGdpdmVuIHRoZSB0d28gYWJvdmUgYXJlIG5vbi1pc3N1ZXMgKG15ICQuMDIpIGFub3RoZXIgZGlz Y292ZXJ5IGRvY3VtZW50IG9ubHkgYnJpbmdzIG1vcmUgb2YgdGhlbSBzaW5jZSBldmVyeSBwcm9w ZXJ0eSBjYW4gbm93IGJlIGRpZmZlcmVudCwgbm90IGp1c3QgdGhlIGVuZHBvaW50cy4NCg0KUyBw b3pkcmF2ZW0sDQpGaWxpcCBTa29rYW4NCg0KDQpPbiBXZWQsIDEzIEZlYiAyMDE5IGF0IDAwOjAw LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KSGVyZSBpcyBvbmUgZXhhbXBsZSwgYmFzZWQg b24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg4oCcc3RyYXcgbWFu4oCdIGZvcm1hdCBwcmVzZW50 ZWQgaW4gdGhpcyB0aHJlYWQ6IFJGQzg0MTQgZGVmaW5lcyB0aGUgdmFsdWUgb2YgdG9rZW5fZW5k cG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBhcyBhIOKAnEpTT04gYXJyYXkgY29udGFpbmlu ZyBhIGxpc3Qgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgc3VwcG9ydGVkIGJ5IHRo aXMgdG9rZW4gZW5kcG9pbnQu4oCdIElmIHRoYXQgYXJyYXkgY29udGFpbnMg4oCcdGxzX2NsaWVu dF9hdXRo4oCdIGFuZCB0aGUgZW5kcG9pbnQgc3BlY2lmaWVkIGluIHRva2VuX2VuZHBvaW50IGRv ZXMgbm90IHN1cHBvcnQgbVRMUywgdGhlbiB0aGF0IG1ldGFkYXRhIHZpb2xhdGVzIDg0MTQuIFlv dSBjb3VsZCBhZGRyZXNzIHRoaXMgYnkgYWRkaW5nIGEgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRo b2RzX3N1cHBvcnRlZCBwYXJhbWV0ZXIgdG8gdGhlIG10bHNfZW5kcG9pbnRzIG9iamVjdCwgYW5k IGxpa2V3aXNlIGZvciB0aGUgb3RoZXIgZW5kcG9pbnRzIGFuZCBhdXRoIG1ldGhvZHMuIElmIHlv dSB0YWtlIHRoYXQgdG8gaXRzIGxvZ2ljYWwgY29uY2x1c2lvbiwgeW91IGVuZCB1cCB3aXRoIGEg Y29tcGxldGUgbWV0YWRhdGEgZG9jdW1lbnQgaGFuZ2luZyBvZmYgb2YgbXRsc19lbmRwb2ludHMu IEl04oCZcyB0aGF0IGxpbmUgb2YgdGhvdWdodCB0aGF0IGxlZCBtZSB0byBzdWdnZXN0IGp1c3Qg cG9pbnRpbmcgdG8gYW4gYWx0ZXJuYXRlIGRvY3VtZW50Lg0KDQpBZGRpdGlvbmFsbHksIGEgbWV0 YWRhdGEgZG9jdW1lbnQgdGhhdCBvbWl0cyB0b2tlbl9lbmRwb2ludCBpbiBmYXZvciBvZiBtdGxz X2VuZHBvaW50cyBzaW5jZSBvbmx5IG1UTFMgaXMgc3VwcG9ydGVkIHdvdWxkIHZpb2xhdGUgODQx NCwgYXMgODQxNCBzYXlzIHRva2VuX2VuZHBvaW50IOKAnGlzIFJFUVVJUkVEIHVubGVzcyBvbmx5 IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ0NCg0KSXQgaXMgcG9zc2li bGUgdG8gZGVmaW5lIHRoZSBtdGxzX2VuZHBvaW50cyBwYXJhbWV0ZXIgc3VjaCB0aGF0IHRoZSBh Ym92ZSB1c2UgY2FzZXMgYXJlIGludmFsaWQsIGJ1dCB0aGF0IGRvZXMgbWFrZSB0aGUgZG9jdW1l bnQgbW9yZSBjb21wbGljYXRlZC4uIElmIHdlIGdvIHRoZSDigJxtdGxzX2FsdGVybmF0ZV9tZXRh ZGF0YeKAnSByb3V0ZSwgd2UgY2FuIHNraXAgcGFzdCBhbGwgb2YgdGhlc2UgaXNzdWVzLCBiZWNh dXNlIGl0IGJyaW5ncyB1cyBiYWNrIHRvIGp1c3QgcGFyc2luZyB0aGUgc2FtZSBtZXRhZGF0YSB0 aGF0IHdlIGRvIHRvZGF5Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElk ZW50aXR5DQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRmlsaXAgU2tva2FuIDxwYW52YS5p cEBnbWFpbC5jb208bWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBG ZWJydWFyeSAxMiwgMjAxOSBhdCAxOjEzIFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIiA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpv bi5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBw aW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21A ZG1hcmMuaWV0Zi5vcmc+Piwgb2F1dGggPG9hdXRoQGlldGYuLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTVRMUyB0b2tlbiBlbmRvaW50ICYgZGlz Y292ZXJ5DQoNCkhpIEFubmFiZWxsZSwNCg0KY2FuIHlvdSBlbGFib3JhdGUgd2hhdCB3b3VsZCBi ZSB0aGUgdmlvbGF0aW9uIC8gbmVnYXRpdmUgaW1wYWN0IG9mIHVzYWdlIG9mIFJGQzg0MTQ/DQoN CkFzIGl0IGFscmVhZHkgbWFrZXMgdXNlIG9mIGBzaWduZWRfbWV0YWRhdGFgIGFuZCB0aGlzIGxh bmd1YWdlIGlzIHByZXNlbnQgLi4uDQoNCj4gQ29uc3VtZXJzIG9mIHRoZSBtZXRhZGF0YSBNQVkg aWdub3JlIHRoZSBzaWduZWQgbWV0YWRhdGEgaWYgdGhleSBkbyBub3Qgc3VwcG9ydCB0aGlzIGZl YXR1cmUuICBJZiB0aGUgY29uc3VtZXIgb2YgdGhlIG1ldGFkYXRhIHN1cHBvcnRzIHNpZ25lZCBt ZXRhZGF0YSwgbWV0YWRhdGEgdmFsdWVzIGNvbnZleWVkIGluIHRoZSBzaWduZWQgbWV0YWRhdGEg TVVTVCB0YWtlIHByZWNlZGVuY2Ugb3ZlciB0aGUgY29ycmVzcG9uZGluZyB2YWx1ZXMgY29udmV5 ZWQgdXNpbmcgcGxhaW4gSlNPTiBlbGVtZW50cy4NCg0KLi4uLiB3b3VsZCBtdGxzX2VuZHBvaW50 cyBiZSBhbnkgZGlmZmVyZW50PyBDbGllbnRzIGFyZSBmcmVlIHRvIGlnbm9yZSB0aGlzIGlmIHRo ZXkgZG9uJ3Qgc3VwcG9ydC91c2UgbXRscywgYW5kIGlmIHRoZXkgZG8gdGhvc2UgdmFsdWVzIG11 c3QgdGFrZSBwcmVjZWRlbmNlIG92ZXIgdGhlIHJvb3Qgb25lcy4gdGhlIHVzZSBvZiBtdGxzX2Vu ZHBvaW50cyB3b3VsZCBub3QgYmUgcmVjb21tZW5kZWQgZm9yIG10bHMtb25seSBBUyBidXQgcmVj b21tZW5kZWQgZm9yIG9uZSB3aXRoIGJvdGggbXRscy9yZWd1bGFyIGF1dGhlbnRpY2F0aW9uIG1l dGhvZHMuIHRva2VuX2VuZHBvaW50IHJlbWFpbnMgcmVxdWlyZWQgZm9yIGFsbCBpbnRlbnRzIGFu ZCBwdXJwb3Nlcy4gQW5kIGFzIGZvciB0aGUgdXNhYmxlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBt ZXRob2RzIC0gdGhleSBzaG91bGQgYWxsIGJlIGxpc3RlZCwgb3IgZG8geW91IHRoaW5rIHdlIHNo b3VsZCBzZXBhcmF0ZSB0aGUgb25lcyBmb3IgZWFjaCBob3N0bmFtZS9wb3J0IGxvY2F0aW9uPyBU byB3aGF0IGVuZD8gSXMgdGhlcmUgYSByaXNrIGhhdmluZyB0aGUgbXRscyBob3N0bmFtZS9wb3J0 IGFjY2VwdGluZyByZWd1bGFyIHJlcXVlc3RzPyBPdGhlciB0aGVuIHNlY3JldC9rZXkgX2p3dCBh dXRoIG1ldGhvZHMgYXNzZXJ0aW9uIGF1ZCBjbGFpbSB0aGUgZW5kcG9pbnQgbG9jYXRpb24gZG9l c24ndCBwbGF5IGEgcm9sZSBpbiB0aGUgYXV0aGVudGljYXRpb24gcHJvY2Vzcy4NCg0KQmVzdCwN CkZpbGlwDQoNCg0KT24gVHVlLCAxMiBGZWIgMjAxOSBhdCAyMDo0NywgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJ4oCZbSBub3Qgb3Bwb3NlZCB0 byBpbnRyb2R1Y2luZyBhIG1ldGFkYXRhIGNoYW5nZSwgaWYgdGhlIHNjZW5hcmlvIGlzIHJlbGV2 YW50IGFuZCBvdGhlciBhcHByb2FjaGVzIGNhbuKAmXQgYWRlcXVhdGVseSBhZGRyZXNzIGl0IOKA kyBhbmQgSeKAmWxsIHJlYWRpbHkgZ3JhbnQgdGhhdCB3ZSBwcm9iYWJseSBkb27igJl0IHdhbnQg dG8gZGVwZW5kIG9uIGNvbnNpc3RlbmN5IG9mIGJyb3dzZXIgYmVoYXZpb3IgYXQgdGhlIGludGVy c2VjdGlvbiBvZiBjbGllbnQgY2VydGlmaWNhdGVzIGFuZCBBY2Nlc3MtQ29udHJvbC1BbGxvdy1D cmVkZW50aWFscy4gQnV0IGNhcmUgbmVlZHMgdG8gYmUgdGFrZW4gaW4gZGVzaWduaW5nIHRoYXQg bWV0YWRhdGEgdG8gYXZvaWQgdmlvbGF0aW5nIG9yIG90aGVyd2lzZSBuZWdhdGl2ZWx5IGltcGFj dGluZyB1c2FnZSBvZiBSRkM4NDE0Lg0KDQpBbG9uZyB0aG9zZSBsaW5lcywgaW5zdGVhZCBvZiBh ZGRpbmcgYW4g4oCcbXRsc19lbmRwb2ludHPigJ0gbWV0YWRhdGEgcGFyYW1ldGVyLCB3ZSBjb3Vs ZCBhZGQgYW4g4oCcbXRsc19hbHRlcm5hdGVfbWV0YWRhdGHigJ0gcGFyYW1ldGVyIHdob3NlIHZh bHVlIGlzIHRoZSBVUkwgb2YgYW4gYWx0ZXJuYXRlIG1ldGFkYXRhIGRvY3VtZW50IGludGVuZGVk IGZvciBjbGllbnRzIHVzaW5nIG1UTFMuIEFuIG1UTFMtb3B0aW9uYWwgQVMgY291bGQgaGF2ZSB0 d28gZGlmZmVyZW50IG1ldGFkYXRhIGRvY3VtZW50cyBmb3IgbVRMUyBhbmQgbm9uLW1UTFMgY2xp ZW50cywgcmVkdWNpbmcgdGhlIG1UTFMtb3B0aW9uYWwgc2NlbmFyaW8gdG8gdGhlIG1UTFMtb25s eSBzY2VuYXJpby4gVGhpcyBzaWRlc3RlcHMgdGhlIGNoYWxsZW5nZXMgb2YgYWxpZ25pbmcgdGhl IOKAnGVpdGhlci9vcuKAnSBzZW1hbnRpY3Mgb2YgbVRMUy1vcHRpb25hbCB3aXRoIHNvbWUgb2Yg dGhlIHJpZ2lkIHBhcmFtZXRlciBkZWZpbml0aW9ucyBpbiBSRkM4NDE0IChzZWU6IHRva2VuX2Vu ZHBvaW50LCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkKS4NCg0KLS0NCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxv YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0K RGF0ZTogVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQgMTA6NTggQU0NClRvOiBEb21pbmlj ayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJp dmlsZWdlLmNvbT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNVExTIHRva2VuIGVuZG9pbnQgJiBkaXNj b3ZlcnkNCg0KVGhhbmtzIGZvciB0aGUgaW5wdXQsIERvbWluaWNrLg0KDQpJJ2Qgc2FpZCBwcmV2 aW91c2x5IHRoYXQgSSB3YXMgaGF2aW5nIHRyb3VibGUgYWRlcXVhdGVseSBnYXVnaW5nIHdoZXRo ZXIgb3Igbm90IHRoZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0 aGUgdXBkYXRlLiBJIHdhcyBldmVuIHRoaW5raW5nIG9mIGFza2luZyB0aGUgY2hhaXJzIGFib3V0 IGEgY29uc2Vuc3VzIGNhbGwgZHVyaW5nIHRoZSBvZmZpY2UgaG91cnMgbWVldGluZyB5ZXN0ZXJk YXkuIEJ1dCBpdCBnb3QgY2FuY2VsZWQuIEFuZCBsb29raW5nIGFnYWluIGJhY2sgb3ZlciB0aGUg ZGlzY3Vzc2lvbiwgSSBkb24ndCBiZWxpZXZlIGEgY29uc2Vuc3VzIGNhbGwgaXMgbmVjZXNzYXJ5 LiBUaGVyZSdzIGJlZW4gYSBsb3Qgb2YgZ2VuZXJhbCBkaXNjdXNzaW9uIG92ZXIgdGhlIGxhc3Qg c2V2ZXJhbCB3ZWVrcyBkdXJpbmcgd2hpY2ggc2V2ZXJhbCBmb2xrcyBoYXZlIHN0YXRlZCBzdXBw b3J0IGZvciB0aGUgcHJvcG9zYWwgd2hpbGUgdGhlcmUncyBiZWVuIG9ubHkgb25lIHZvaWNlIG9m IGRpcmVjdCBkaXNzZW50LiBUaGF0IHNlZW1zIGxpa2Ugcm91Z2ggZW5vdWdoIGNvbnNlbnN1cyBh bmQsIGFzIHN1Y2gsIEkgcGxhbiB0byBtYWtlIHRoZSBjaGFuZ2UgaW4gdGhlIG5leHQgcmV2aXNp b24gb2YgdGhlIGRvY3VtZW50ICh3aGljaCBzaG91bGQgYmUgZG9uZSBzb29uKS4gQ2hhaXJzLCBw bGVhc2UgbGV0IG1lIGtub3csIGlmIHlvdSBiZWxpZXZlIHRoZSBzaXR1YXRpb24gd2FycmFudHMg YSBkaWZmZXJlbnQgY291cnNlIG9mIGFjdGlvbi4NCg0KDQoNCk9uIE1vbiwgRmViIDExLCAyMDE5 IGF0IDExOjAxIFBNIERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1h aWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQpJTUhPIHRoYXTigJlzIGEg cmVhc29uYWJsZSBhbmQgcHJhZ21hdGljIG9wdGlvbi4NCg0KVGhhbmtzDQrigJTigJTigJQNCkRv bWluaWNrDQoNCg0KT24gMTEuIEZlYnJ1YXJ5IDIwMTkgYXQgMTM6MjY6MzcsIEJyaWFuIENhbXBi ZWxsIChiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+KSB3cm90ZToNCkl0J3MgYmVlbiBwb2ludGVkIG91dCB0aGF0IHRoZSBwb3RlbnRp YWwgaXNzdWUgaXMgbm90IGlzb2xhdGVkIHRvIHRoZSBqdXN0IHRva2VuIGVuZHBvaW50IGJ1dCB0 aGF0IHJldm9jYXRpb24sIGludHJvc3BlY3Rpb24sIGV0Yy4gY291bGQgYmUgaW1wYWN0ZWQgYXMg d2VsbC4gU28sICBhdCB0aGlzIHBvaW50LCB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlIGlzIHRv IGFkZCBhIG5ldyBvcHRpb25hbCBBUyBtZXRhZGF0YSBwYXJhbWV0ZXIgbmFtZWQgJ210bHNfZW5k cG9pbnRzJyB0aGF0J3MgdmFsdWUgd2UgYmUgYSBKU09OIG9iamVjdCB3aGljaCBpdHNlbGYgY29u dGFpbnMgZW5kcG9pbnRzIHRoYXQsIHdoZW4gcHJlc2VudCwgYSBjbGllbnQgZG9pbmcgTVRMUyB3 b3VsZCB1c2UgcmF0aGVyIHRoYW4gdGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiAgQSBzdHJhdy1tYW4g ZXhhbXBsZSBtaWdodCBsb29rIGxpa2UgdGhpcw0Kew0KICAiaXNzdWVyIjoiaHR0cHM6Ly9zZXJ2 ZXIuZXhhbXBsZS5jb20iLA0KICAiYXV0aG9yaXphdGlvbl9lbmRwb2ludCI6Imh0dHBzOi8vc2Vy dmVyLmV4YW1wbGUuY29tL2F1dGh6IiwNCiAgInRva2VuX2VuZHBvaW50IjoiaHR0cHM6Ly9zZXJ2 ZXIuZXhhbXBsZS5jb20vdG9rZW4iLA0KICAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1 cHBvcnRlZCI6WyAgImNsaWVudF9zZWNyZXRfYmFzaWMiLCJ0bHNfY2xpZW50X2F1dGgiLCAibm9u ZSJdLA0KICAidXNlcmluZm9fZW5kcG9pbnQiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS91 c2VyaW5mbyIsDQogICJyZXZvY2F0aW9uX2VuZHBvaW50IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb20vcmV2byIsDQogICJqd2tzX3VyaSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3 a3MuanNvbiIsDQogICJtdGxzX2VuZHBvaW50cyI6ew0KICAgICJ0b2tlbl9lbmRwb2ludCI6Imh0 dHBzOi8vbXRscy5leGFtcGxlLmNvbS90b2tlbiIsDQogICAgInVzZXJpbmZvX2VuZHBvaW50Ijoi aHR0cHM6Ly9tdGxzLmV4YW1wbGUuY29tL3VzZXJpbmZvIiwNCiAgICAicmV2b2NhdGlvbl9lbmRw b2ludCI6Imh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS9yZXZvPGh0dHBzOi8vbXRscy4uLi4uLi5l eGFtcGxlLmNvbS9yZXZvPiINCiAgfQ0KfQ0KDQpBIGNsaWVudCBkb2luZyBNVExTIHdvdWxkIGxv b2sgZm9yIGFuZCBnaXZlIHByZWNlZGVuY2UgdG8gYW4gZW5kcG9pbnQgdW5kZXIgIm10bHNfZW5k cG9pbnRzIiB3aGlsZSBmYWxsaW5nIGJhY2sgdG8gdXNlIHRoZSBub3JtYWwgZW5kcG9pbnQgZnJv bSB0aGUgdG9wIGxldmVsIG9mIG1ldGFkYXRhIHdoZW4vaWYgaXRzIG5vdCBpbiAibXRsc19lbmRw b2ludHMiLg0KDQpUaGUgaWRlYSBiZWluZyB0aGF0ICJyZWd1bGFyIiBjbGllbnRzICh0aG9zZSBu b3QgZG9pbmcgTVRMUykgd2lsbCB1c2UgdGhlIHJlZ3VsYXIgZW5kcG9pbnRzLiBBbmQgb25seSB0 aGUgaG9zdC9wb3J0IG9mIHRoZSBlbmRwb2ludHMgbGlzdGVkIGluIG10bHNfZW5kcG9pbnRzIHdp bGwgYmUgc2V0IHVwIHRvIHJlcXVlc3QgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZXMgZHVyaW5nIGhh bmRzaGFrZS4gVGh1cyBhbnkgcG90ZW50aWFsIGltcGFjdCBvZiB0aGUgQ2VydGlmaWNhdGVSZXF1 ZXN0IG1lc3NhZ2UgYmVpbmcgc2VudCBpbiB0aGUgVExTIGhhbmRzaGFrZSBjYW4gYmUgYXZvaWRl ZCBmb3IgYWxsIHRoZSBvdGhlciByZWd1bGFyIGNsaWVudHMgdGhhdCBhcmUgbm90IGdvaW5nIHRv IGRvIE1UTFMgLSBpbmNsdWRpbmcgYW5kIG1vc3QgaW1wb3J0YW50bHkgaW4tYnJvd3NlciBqYXZh c2NyaXB0IGNsaWVudHMgd2hlcmUgdGhlcmUgY2FuIGJlIGxlc3MgdGhhbiBkZXNpcmFibGUgVUkg cHJlc2VudGVkIHRvIHRoZSBlbmQtdXNlci4NCg0KSSdtIHN0cnVnZ2xpbmcsIGhvd2V2ZXIsIHRv IGFkZXF1YXRlbHkgZ2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUncyBzdWZmaWNpZW50IGNvbnNl bnN1cyB0byBnbyBhaGVhZCB3aXRoIHRoZSB1cGRhdGUuIFRoZXJlJ3MgYmVlbiBzb21lIHN1cHBv cnQgZm9yIGl0IHZvaWNlZC4gQXMgd2VsbCBhcyB0YWxrIG9mIG90aGVyIGFwcHJvYWNoZXMgdGhh dCBjb3VsZCBiZSBhbHRlcm5hdGl2ZXMgb3IgYWRkaXRpb25hbCBtZWFzdXJlcy4gQW5kIGFsc28g c29tZSB2b2NhbCBvcHBvc2l0aW9uIHRvIGl0Lg0KDQoNCk9uIFNhdCwgRmViIDksIDIwMTkgYXQg MzowOSBBTSBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86 ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+IHdyb3RlOg0KV2UgYXJlIGN1cnJlbnRseSBpbXBs ZW1lbnRpbmcgTVRMUyBpbiBJZGVudGl0eVNlcnZlci4NCg0KT3VyIGFwcHJvYWNoIHdpbGwgYmUg dGhhdCB3ZeKAmWxsIG9mZmVyIGEgc2VwYXJhdGUgdG9rZW4gZW5kcG9pbnQgdGhhdCBzdXBwb3J0 cyBjbGllbnQgY2VydHMuIEFyZSB5b3UgcGxhbm5pbmcgb24gYWRkaW5nIGFuIG9mZmljaWFsIGVu ZHBvaW50IG5hbWUgZm9yIGRpc2NvdmVyeT8gUmlnaHQgbm93IHdlIGFyZSB1c2luZyDigJxtdGxz X3Rva2VuX2VuZHBvaW504oCdLg0KDQpUaGFua3MNCuKAlOKAlOKAlA0KRG9taW5pY2sNCg0KDQpP biA3LiBGZWJydWFyeSAyMDE5IGF0IDIyOjM2OjU1LCBCcmlhbiBDYW1wYmVsbCAoYmNhbXBiZWxs PTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86YmNhbXBiZWxsPTQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZz4pIHdyb3RlOg0KQWggeWVzLCB0aGF0IG1ha2Vz IHNlbnNlLiBUaGFua3MgZm9yIGNsYXJpZnlpbmcuIEFuZCBpdCBpcyBpbmRlZWQgYSBnb29kIHJl bWluZGVyIHRoYXQgZXZlbiBhIHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hvdWxk IGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIGNhbiBicmVhayB0aGluZ3MgdW5leHBlY3RlZGx5Li4N Cg0KDQoNCg0KDQpPbiBUaHUsIEZlYiA3LCAyMDE5IGF0IDg6NTcgQU0gUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5j b20+PiB3cm90ZToNClRoZSBjYXNlIEnigJltIHJlZmVyZW5jaW5nIGRpZG7igJl0IHNwZWNpZmlj YWxseSBpbnZvbHZlIEFTIG1ldGFkYXRhLiBXZSBoYWQgY2xpZW50cyBpbiB0aGUgd2lsZCB0aGF0 IGFzc3VtZWQgdGhhdCBhbGwgdGhlIHByb3BlcnRpZXMgaW4gdGhlIEpTT04gb2JqZWN0IHJldHVy bmVkIGZyb20gb3VyIHVzZXJpbmZvIGVuZHBvaW50IHdlcmUgc2NhbGFyIHN0cmluZ3MuIFRoaXMg YnJva2Ugd2hlbiB3ZSBpbnRyb2R1Y2VkIGEgbmV3IHByb3BlcnR5IHdob3NlIHZhbHVlIHdhcyBh IEpTT04gb2JqZWN0LiBJdCB3YXMgYSBnb29kIHJlbWluZGVyIHRoYXQgZXZlbiBhIHNlZW1pbmds eSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIGNh biBmb3JjZSBtb3JlIHdvcmsgb24gY2xpZW50cyB0aGFuIHdlIGV4cGVjdC4NCg0KLS0NCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5Li5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxOSBhdCAxMTozMCBB TQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4NCkNj OiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVS XSBSZTogTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2lu dA0KDQpBbmQgSSdtIGhvbmVzdGx5IHJlYWxseSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IGNvdWxk IGhhdmUgZ29uZSB3cm9uZyB3aXRoIG9yIGhvdyB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMg YnJva2Ugc29tZXRoaW5nIHdpdGggdGhlIHVzZXIgaW5mbyBlbmRwb2ludC4gSWYgeW91IGhhdmUg dGhlIHRpbWUgYW5kL29yIGl0J2QgYmUgaW5mb3JtYXRpdmUgdG8gdGhpcyBoZXJlIGxpdHRsZSBk aXNjdXNzaW9uLCBwbGVhc2UgZXhwbGFpbiB0aGF0IG9uZSBhIGJpdCBtb3JlLg0KDQpPbiBXZWQs IEZlYiA2LCAyMDE5IGF0IDEyOjE1IFBNIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCiJm YXIiIHNob3VsZCBoYXZlIHNhaWQgImZhaXIiIGluIHRoZSBwcmV2aW91cyBtZXNzYWdlDQoNCg0K DQoNCg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCA0OjM1IFBNIEJyaWFuIENhbXBiZWxsIDxiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+ PiB3cm90ZToNCkl0IG1heSB3ZWxsIGJlIGR1ZSB0byBteSBvd24gaW50ZWxsZWN0dWFsIHNob3J0 Y29taW5ncyBidXQgdGhlc2UgaXNzdWVzL3F1ZXN0aW9ucy9jb25mdXNpb24tcG9pbnRzIGFyZSBu b3QgcmVzb25hdGluZyBmb3IgbWUgYXMgYmVpbmcgcHJvYmxlbWF0aWMuDQoNClRoZSBtb3JlIGdl bmVyYWwgc3RhbmNlIG9mICJ0aGlzIGlzbid0IG5lZWRlZCBvciB3b3J0aCBpdCBpbiB0aGlzIGRv Y3VtZW50IiAoSSB0aGluayB0aGF0J3MgZmFyPykgaXMgYmVpbmcgaGVhcmQgdGhvdWdoLg0KDQoN Cg0KT24gVHVlLCBGZWIgNSwgMjAxOSBhdCAxOjQyIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLi4uLm9yZz4+IHdyb3RlOg0KKFRMO0RSOiBwdW50IEFTIG1ldGFkYXRh IHRvIGEgc2VwYXJhdGUgZHJhZnQpDQoNCkFTIHBvaW50cyAjMS0zIGFyZSBhbGwgcXVlc3Rpb25z IEkgd291bGQgaGF2ZSBhcyBhbiBpbXBsZW1lbnRlcjoNCg0KICAxLiAgU2VjdGlvbiAyIG9mIFJG Qzg0MTQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X190b29scy5pZXRmLm9yZ19odG1sX3JmYzg0MTQtMjNzZWN0aW9uLTJEMiZkPUR3TUZhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5x V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXho STEtWXZiT2tpZ3M3cUx3UEp4YyZzPWdmTDdlUEFQb0pObFlYQXVXMXhmY3JaTDBNa2dpYnVueVZn SVVyaEdPR2cmZT0+IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlSRUQgdW5sZXNzIG9u bHkgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKAnSBTbyB3aGF0IGRvZXMg dGhlIG1UTFMtb25seSBBUyBwdXQgaGVyZT8NCiAgMi4gIFRoZSBjbGFpbXMgZm9yIHRoZXNlIG90 aGVyIGVuZHBvaW50cyBhcmUgT1BUSU9OQUwsIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8gaW5jb25z aXN0ZW5jeSBkZXBlbmRpbmcgb24gaG93ICMxIGdldHMgZGVjaWRlZC4NCiAgMy4gIFRoZSBleGFt cGxlIHVzYWdlIG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgcHJvcGVydHkgZ2l2 ZW4gZWFybGllciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0LCBzaW5jZSBzb21lIG9mIGl0 cyBjb250ZW50cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1tVExTIGVuZHBvaW50cywgYW5k IG90aGVycyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5kcG9pbnRzLiBIZW5jZSB0aGlz IHF1ZXN0aW9uLg0KICA0LiAgVGhpcyBpbnRyb2R1Y2VzIGEgbmV3IG1ldGFkYXRhIHByb3BlcnR5 IHRoYXQgY291bGQgaW1wYWN0IGhvdyBvdGhlciBzcGVjcyBzaG91bGQgZXh0ZW5kIEFTIG1ldGFk YXRhLiBUaGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4NCg0KSSBjb3VsZCBnbyBvbiBmb3IgY2xp ZW50IHBvaW50cyBidXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdoIEnigJlsbCBz aGFyZSB0aGF0ICMzIGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwgYmFjayBhbiB1 cGRhdGUgdG8gdGhlIExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW504oCmZ29vZCB0 aW1lcy4g8J+Ygw0KDQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgdGhpbmsgYW4gQVMgbWV0YWRhdGEg cHJvcGVydHkgaXMgd3JvbmcgcGVyIHNlLCBidXQgdW5kZXJzdGFuZCB0aGF0IHlvdeKAmXJlIGJv bHRpbmcgYSBsYXllciBvZiBmbGV4aWJpbGl0eSBvbnRvIGEgc3RhbmRhcmQgdGhhdCB3YXNu4oCZ dCBkZXNpZ25lZCBmb3IgdGhhdCwgYW5kIEkgZG9u4oCZdCB0aGluayB0aGUgbWV0YWRhdGEgcHJv cG9zYWwgYXMgaXTigJlzIGJlZW4gZGlzY3Vzc2VkIGhlcmUgc3VmZmljaWVudGx5IGRlYWxzIHdp dGggdGhlIGZhbGxvdXQgZnJvbSB0aGF0LiBJbiBteSB2aWV3IHRoaXMgaXMgYSBjb21wbGV4IGVu b3VnaCBpc3N1ZSBhbmQgaXTigJlzIGZvciBhIG51YW5jZWQgZW5vdWdoIHVzZSBjYXNlIChhcyBm YXIgYXMgSSBjYW4gdGVsbCBmcm9tIGRpc2N1c3Npb24/IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEni gJltIHdyb25nKSB0aGF0IHdlIHNob3VsZCBwdW50IGl0IHRvIGEgc2VwYXJhdGUgZHJhZnQgKGUu Zy4sIOKAnEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIEV4dGVuc2lvbnMgZm9yIG1UTFMg SHlicmlkc+KAnSkgYW5kIGdldCBtVExTIG91dCB0aGUgZG9vci4NCg0KLS0NCkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogTW9u ZGF5LCBGZWJydWFyeSA0LCAyMDE5IGF0IDU6MjggQU0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUiIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbVU5WRVJJRklF RCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2Vu IGVuZHBvaW50DQoNClRob3NlIHBvaW50cyBvZiBjb25mdXNpb24gc3RyaWtlIG1lIGFzIHNvbWV3 aGF0IGh5cG90aGV0aWNhbCBvciBoeXBlcmJvbGljLiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlz IHRha2VuIGFuZCB5b3VyIHBvc2l0aW9uIG9mIGJlaW5nIGFudGkgYWRkaXRpb25hbCBtZXRhZGF0 YSBvbiB0aGlzIGlzc3VlIGlzIG5vdGVkLg0KDQpBbGwgb2Ygd2hpY2ggbGVhdmVzIG1lIGEgYml0 IHVuY2VydGFpbiBhYm91dCBob3cgdG8gcHJvY2VlZC4gVGhlcmUgc2VlbSB0byBiZSBhIHJhbmdl IG9mIG9waW5pb25zIG9uIHRoaXMgcG9pbnQgYW5kIGdhdWdpbmcgY29uc2Vuc3VzIGlzIHByb3Zp bmcgZWx1c2l2ZSBmb3IgbWUuIFRoYXQncyBjb25mb3VuZGVkIGJ5IG15IG93biBvcGluaW9uIG9u IGl0IGJlaW5nIHNvbWV3aGF0IGZsdWlkLg0KDQpBbmQgSSdkIHJlYWxseSBsaWtlIHRvIHBvc3Qg YW4gdXBkYXRlIHRvIHRoaXMgZHJhZnQgYWJvdXQgYSBtb250aCBvciB0d28gYWdvLg0KDQoNCg0K DQoNCg0KT24gRnJpLCBGZWIgMSwgMjAxOSBhdCA1OjAzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW1h em9uLmNvbUBkbWFyYy5pZXRmLi4uLm9yZz4+IHdyb3RlOg0KQ29uZnVzaW9uIGZyb20gdGhlIEFT 4oCZcyBwZXJzcGVjdGl2ZToNCg0KICAxLiAgSWYgSSBvbmx5IHN1cHBvcnQgbVRMUywgZG8gSSBu ZWVkIHRvIGluY2x1ZGUgYm90aCB0b2tlbl9lbmRwb2ludF91cmkgYW5kIG10bHNfZW5kcG9pbnRz PyBTaG91bGQgSSBvbWl0IHRva2VuX2VuZHBvaW50X3VyaT8gT3Igc2V0IGl0IHRvIHRoZSBlbXB0 eSBzdHJpbmc/DQogIDIuICBXaGF0IGlmIEkgb25seSBzdXBwb3J0IG1UTFMgZm9yIHRoZSB0b2tl biBlbmRwb2ludCwgYnV0IG5vdCByZXZvY2F0aW9uIG9yIHVzZXIgaW5mbz8NCiAgMy4gIEhvdyBk byBJIHNwZWNpZnkgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3IgdGhlIG1UTFMgdG9rZW4gZW5k cG9pbnQ/IERvZXMgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzIGFwcGx5IHRvIGJvdGggdGhl IG1UTFMgYW5kIG5vbi1tVExTIGVuZHBvaW50cz8NCiAgNC4gIEnigJltIHVzaW5nIHRoZSBPQXV0 aCAyLjAgRGV2aWNlIEZsb3cuIERvIEkgaW5jbHVkZSBhIG1UTFMtZW5hYmxlZCBkZXZpY2VfYXV0 aG9yaXphdGlvbl9lbmRwb2ludCB1bmRlciBtdGxzX2VuZHBvaW50cz8NCg0KQ29uZnVzaW9uIGZy b20gdGhlIGNsaWVudOKAmXMgcGVyc3BlY3RpdmU6DQoNCiAgMS4gIEFzIGZhciBhcyBJIGtub3cs IEnigJltIGEgcHVibGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBt VExTLCBidXQgdGhlIElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRzIGluIHRoZWlyIHVz ZXJz4oCZIGJyb3dzZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhhdCB0byBhdXRoZW50 aWNhdGUgbWUuDQogIDIuICBNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBiZWNhdXNlIHRo ZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuLi4NCiAgMy4gIE15IEFT IG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJlY2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRvIGVu Y291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEgcGFyYW1ldGVyIHZhbHVlLg0KICA0LiAgVGhlIG1U TFMtb25seSBBUyBkaWRu4oCZdCBwcm92aWRlIGEgdmFsdWUgZm9yIG10bHNfZW5kcG9pbnRzLCB3 aGF0IGRvIEkgZG8/DQogIDUuICBJIGRvbuKAmXQga25vdyB3aGF0IHRoYXQg4oCcbeKAnSBtZWFu cywgYnV0IHRoZXkgdG9sZCBtZSB0byB1c2UgSFRUUFMsIHNvIEkgc2hvdWxkIHVzZSB0aGUgb25l IHdpdGgg4oCcdGxz4oCdIGluIGl0cyBuYW1lLCByaWdodD8NCg0KWWVzLCB5b3UgY2FuIHdyaXRl IG5vcm1hdGl2ZSB0ZXh0IHRoYXQgYW5zd2VycyBtb3N0IG9mIHRoZXNlLiBCdXQgeW914oCZbGwg aGF2ZSB0byBjbGVhcmx5IGNvdmVyIGEgbG90IG9mIHNpbWlsYXItYnV0LXNsaWdodGx5LWRpZmZl cmVudCBzY2VuYXJpb3MgYW5kIGJlIHZlcnkgZXhwbGljaXQuIEFuZCBpbXBsZW1lbnRlcnMgd2ls bCBzdGlsbCBnZXQgaXQgd3JvbmcuIFRoZSBtZXRhZGF0YSBjaGFuZ2UgaW50cm9kdWNlcyBvcHBv cnR1bml0aWVzIGZvciBjb25mdXNpb24gYW5kIGZhaWx1cmUgdGhhdCBkbyBub3QgZXhpc3Qgbm93 LCBhbmQgZm9yY2VzIHRoZW0gb24gZXZlcnlvbmUgd2hvIHN1cHBvcnRzIG1UTFMuIEluIGNvbnRy YXN0LCB0aGUgMzA3IHJlZGlyZWN0IGlzIG9ubHkgcmVxdWlyZWQgd2hlbiBhbiBBUyB3YW50cyB0 byBzdXBwb3J0IGJvdGgsIGFuZCBpcyB1bmFtYmlndW91cyBpbiBpdHMgYmVoYXZpb3IgYW5kIG1l YW5pbmcuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0K DQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPj4NCkRh dGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAzOjE3IFBNDQpUbzogIlJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1h em9uLmNvbT4+DQpDYzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1haWx0bzpn ZmZsZXRjaEBhb2wuY29tPj4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW09BVVRILVdHXSBNVExT IGFuZCBpbi1icm93c2VyIGNsaWVudHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50DQoNCkl0IGRv ZXNuJ3Qgc2VlbSBsaWtlIHRoYXQgY29uZnVzaW5nIG9yIGxhcmdlIG9mIGEgY2hhbmdlIHRvIG1l IC0gaWYgdGhlIGNsaWVudCBpcyBkb2luZyBNVExTIGFuZCB0aGUgZ2l2ZW4gZW5kcG9pbnQgaXMg cHJlc2VudCBpbiBgbXRsc19lbmRwb2ludHNgLCB0aGVuIGl0IHVzZXMgdGhhdCBvbmUuICBPdGhl cndpc2UgaXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4gQVMgYSBsb3Qg b2YgZmxleGliaWxpdHkgaW4gZGVwbG95bWVudCBvcHRpb25zLiBJIHBlcnNvbmFsbHkgdGhpbmsg Z2V0dGluZyBhIDMwNyBhcHByb2FjaCBkZXBsb3llZCBhbmQgd29ya2luZyB3b3VsZCBiZSBtb3Jl IGNvbXBsaWNhdGVkIGFuZCBlcnJvciBwcm9uZS4NCg0KSXQgaXMgYSBtaW5vcml0eSB1c2UgY2Fz ZSBhdCB0aGUgbW9tZW50IGJ1dCB0aGVyZSBhcmUgZm9yY2VzIGluIHBsYXksIGxpa2UgdGhlIHB1 c2ggZm9yIGluY3JlYXNlZCBzZWN1cml0eSBpbiBnZW5lcmFsIGFuZCB0byBoYXZlIGphdmFzY3Jp cHQgY2xpZW50cyB1c2UgdGhlIGNvZGUgZmxvdywgdGhhdCBzdWdnZXN0IGl0IHdvbid0IGJlIHRl cnJpYmx5IHVudXN1YWwgdG8gc2VlIGFuIEFTIHRoYXQgd2FudHMgdG8gc3VwcG9ydCBNVExTIGNs aWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNhbWUgdGltZS4NCg0KSSd2 ZSBwZXJzb25hbGx5IHdhdmVyZWQgYmFjayBhbmQgZm9ydGggaW4gdGhpcyB0aHJlYWQgb24gd2hl dGhlciBvciBub3QgdG8gYWRkIHRoZSBuZXcgbWV0YWRhdGEgKG9yIHNvbWV0aGluZyBsaWtlIGl0 KS4gV2l0aCBteSByZWFzb25pbmcgZWFjaCB3YXkga2luZGEgZXhwbGFpbmVkIHNvbWV3aGVyZSBi YWNrIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0aHJlYWQuICBC dXQgaXQgc2VlbXMgbGlrZSB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSBncm91cCBoZXJlIGlz IGluIGZhdm9yIG9mIGl0Lg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxLCAyMDE5IGF0IDM6MTggUE0g UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi4ub3JnPj4gd3JvdGU6DQpU aGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVzaW5nIGNoYW5nZSB0 byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2FzZS4gSeKAmW0gZ2V0 dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQgbmVlZGVkIHRvIGNs YXJpZnkgd2hlbiB0aGUgQVMgc2hvdWxkIHByb3ZpZGUgYG10bHNfZW5kcG9pbnRzYCBhbmQgd2hl biB0aGUgY2xpZW50IHNob3VsZCB1c2UgdGhhdCB2ZXJzdXMgdXNpbmcgYHRva2VuX2VuZHBvaW50 LmAgV2h5IGlzIHRoZSAzMDcgc3RhdHVzIGNvZGUgaW5zdWZmaWNpZW50IHRvIGNvdmVyIHRoZSBj YXNlIHdoZXJlIGEgc2luZ2xlIEFTIHN1cHBvcnRzIGJvdGggbVRMUyBhbmQgbm9uLW1UTFM/DQoN Ci0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBP QXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYu b3JnPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSBhdCAxOjMxIFBNDQpUbzogR2Vv cmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw YW9sLmNvbUBkbWFyYy4uLi4uLi4uLi4uLmlldGYub3JnPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1U TFMgYW5kIGluLWJyb3dzZXIgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQNCg0KWWVz LCB0aGF0IHdvdWxkIHdvcmsuDQoNCk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQTSBHZW9y Z2UgRmxldGNoZXIgPGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLi5vcmc8bWFpbHRvOjQw YW9sLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KV2hhdCBpZiB0aGUgQVMgd2FudHMgdG8g T05MWSBzdXBwb3J0IE1UTFMgY29ubmVjdGlvbnMuIERvZXMgaXQgbm90IHNwZWNpZnkgdGhlIG9w dGlvbmFsICJtdGxzX2VuZHBvaW50cyIgYW5kIGp1c3QgdXNlIHRoZSBub3JtYWwgbWV0YWRhdGEg dmFsdWVzPw0KT24gMS8xNS8xOSA4OjQ4IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCkl0IHdv dWxkIGRlZmluaXRlbHkgYmUgb3B0aW9uYWwsIGFwb2xvZ2llcyBpZiB0aGF0IHdhc24ndCBtYWRl IGNsZWFyLi4gSXQnZCBiZSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiBvcHRpb25hbCBmb3Ig dGhlIEFTIHRvIGluY2x1ZGUgYW5kIGNsaWVudHMgZG9pbmcgTVRMUyB3b3VsZCB1c2UgaXQgd2hl biBwcmVzZW50IGluIEFTIG1ldGFkYXRhLg0KDQpPbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0 IEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9tZW50dW1mdC5jby51azxtYWlsdG86ZGF2ZS50 b25nZUBtb21lbnR1bWZ0LmNvLnVrPj4gd3JvdGU6DQpJJ20gaW4gZmF2b3VyIG9mIHRoZSBgbXRs c19lbmRwb2ludHNgIG1ldGFkYXRhIHBhcmFtZXRlciAtIGFsdGhvdWdoIGl0IHNob3VsZCBiZSBv cHRpb25hbC4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlv biBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1 dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpo OEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFh TGNMTjRLWk5BJm09eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZz PWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmZT0+DQoNCg0KQ09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBh dHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFM SVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElD RTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0 ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkg cmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFp bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlv dXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBl bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Lg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAg SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg eW91LiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1nQ2M5 dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmU9Pg0KDQpDT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3Ro ZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNv bW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVu dHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTRE cGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2 Yk9raWdzN3FMd1BKeGMmcz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1 WHFBJmU9Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYuLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuLmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMm cz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmU9Pg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC4uY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19vYXV0aCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFw SV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09eGVI ZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZzPWdDYzl0SkxWdXVLN0NY VWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmZT0+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmZD1Ed01GYVEm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRX bWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXhlSGZZTUNhd1c5bDFoT0hycUt0 d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmcz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lW dkxwcGs5ZFR1WHFBJmU9Pg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhl IG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhh bmsgeW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJm09eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3 cUx3UEp4YyZzPWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmZT0+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJm09eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZzPWdDYzl0 SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmZT0+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_10A7B95ED7AD4BEDAABDA05F8C9ABFD8amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <03611C18AC88364E8CDA8B5FF0C3B73C@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBs aS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJp b3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4t Ym90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5nbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdt YWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MGFpcm1h aWxvbiwgbGkuZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2 MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4 ODBhaXJtYWlsb24sIGRpdi5nbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3 MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAz NzE0NTc2Mzg4MGFpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy0yOTE5OTU4MzIz OTE3MjEyNDA4Z21haWwtbV84NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbV8tOTA3OTc3MTc3NDAy NDM0ODY4N2dtYWlsLW1fLTQwNzU2NzYwMzcxNDU3NjM4ODBhaXJtYWlsX29uOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0 MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dt YWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MGFpcm1haWxvbjAsIGxpLmdtYWlsLW0tMjkxOTk1ODMy MzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0 MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwYWlybWFpbG9uMCwgZGl2LmdtYWlsLW0t MjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5 NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwYWlybWFpbG9uMA0KCXtt c28tc3R5bGUtbmFtZTpnbWFpbC1tXy0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbV84NDYzNTcy MTE0MjE0NjE0MDUwZ21haWwtbV8tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW1fLTQwNzU2NzYw MzcxNDU3NjM4ODBhaXJtYWlsb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLmdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0 MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgw bTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMx OTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYx MTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSwgbGkuZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEy NDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdn bWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0 NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1 NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxLCBk aXYuZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBn bWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5 MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5Njkz Nzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMx ODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxDQoJe21zby1zdHlsZS1uYW1lOiJnbWFpbC1tXy0yOTE5 OTU4MzIzOTE3MjEyNDA4Z21haWwtbV84NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbV8tOTA3OTc3 MTc3NDAyNDM0ODY4N2dtYWlsLW1fLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5 MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdt YWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwt bTIxOTY1MzI1NDMxIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MDI1 NTUxMzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0z MTgwMTUxNCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDo2MzIxMDU1OTA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNzkw NjM3MjQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTM3NjA4MjkzMDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTIxMzM4NjYwODt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNzQ3OTE1 NTk3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjM5NjEzNzMyO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmVpbOKAmXMgZXhh bXBsZSBkZW1vbnN0cmF0ZXMgaG93IHRoZSBtdGxzX2VuZHBvaW50cyBhcHByb2FjaCBsZWFkcyB0 byBjb25mdXNpb24uIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgbWV0YWRhdGEgZnJhZ21lbnQ6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPns8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyDigJx0b2tlbl9lbmRwb2ludOKAnTog4oCcaHR0cHM6Ly9hcy5leGFtcGxlLmNv bS90b2tlbuKAnSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDo1LjI1cHQiPuKAnHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0 ZWTigJ06IFsg4oCcY2xpZW50X3NlY3JldF9iYXNpY+KAnSwg4oCcdGxzX2NsaWVudF9hdXRo4oCd IF0sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRl bnQ6NS4yNXB0Ij7igJxtdGxzX2VuZHBvaW50c+KAnTogezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+Jm5ic3A7IOKAnHRva2Vu X2VuZHBvaW504oCdOiDigJxodHRwczovL2FzLmV4YW1wbGUuY29tL210bHMvdG9rZW7igJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1 cHQiPn08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hpY2ggb2YgdGhlc2Ugc3RhdGVtZW50cyBhYm91dCBlbmRwb2ludHMgb24g PGEgaHJlZj0iaHR0cHM6Ly9hcy5leGFtcGxlLmNvbS8iPg0KaHR0cHM6Ly9hcy5leGFtcGxlLmNv bS88L2E+IGFyZSB0cnVlPzxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij5UaGUgL3Rva2VuIGVu ZHBvaW50IG9ubHkgc3VwcG9ydHMgY2xpZW50X3NlY3JldF9iYXNpYywgYW5kIC9tdGxzL3Rva2Vu IG9ubHkgc3VwcG9ydHMgdGxzX2NsaWVudF9hdXRoLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzQiPlRoZSAvdG9rZW4gZW5kcG9pbnQgc3VwcG9ydHMgYm90aCBtZXRob2RzLCBhbmQg L210bHMvdG9rZW4gb25seSBzdXBwb3J0cyB0bHNfY2xpZW50X2F1dGguPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvNCI+Qm90aCAvdG9rZW4gYW5kIC9tdGxzL3Rva2VuIHN1cHBvcnQg Ym90aCBtZXRob2RzLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgb2YgdGhlc2Ug Y291bGQgYmUgcmVhc29uYWJsZSBpbnRlcnByZXRhdGlvbnMgb2YgdGhpcyBtZXRhZGF0YS4gV2hl biBwcm9wZXJ0aWVzIG1lYW4gZGlmZmVyZW50IHRoaW5ncyBpbiBkaWZmZXJlbnQgY29udGV4dHMs IGFtYmlndWl0eSBhYm91bmRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg TmVpbCBNYWRkZW4gJmx0O25laWwubWFkZGVuQGZvcmdlcm9jay5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPkZyaWRheSwgRmVicnVhcnkgMTUsIDIwMTkgYXQgMTI6MzMgUE08YnI+DQo8Yj5Ubzog PC9iPkdlb3JnZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExT IHRva2VuIGVuZG9pbnQgJmFtcDsgZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbm90aGVyIGNhc2UgLSBpZiB0 aGUgY2xpZW50IHdhbnRzIGNlcnRpZmljYXRlLWJvdW5kIGFjY2VzcyB0b2tlbnMgYnV0IHN0aWxs IGF1dGhlbnRpY2F0ZXMgd2l0aCBjbGllbnRfc2VjcmV0X2Jhc2ljIG9yIGlzIGEgcHVibGljIGNs aWVudCAoYXMgcGVyIFsxXSksIHByZXN1bWFibHkgaXQgY2FuIHVzZSB0aGUgbXRscy1zcGVjaWZp YyBlbmRwb2ludHMgYW5kIGFzc3VtZSB0aGV5IHN1cHBvcnQgYWxsIHRoZQ0KIG90aGVyIGF1dGhl bnRpY2F0aW9uIG1ldGhvZHMgYXMgdGhlIG5vcm1hbCBlbmRwb2ludHM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBzbyBsb25nIGFzIHdl IGNhbiBkZWZpbmUgc29tZSBoYWxmLXNlbnNpYmxlIGJlaGF2aW91ciBmb3IgdGhlc2UgY2FzZXMs IEnigJltIGhhcHB5IHdpdGggdGhpcyBwcm9wb3NhbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbXRscy0xMiNzZWN0aW9u LTQuMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbXRscy0x MiNzZWN0aW9uLTQuMzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMTUgRmVi IDIwMTksIGF0IDE5OjU3LCBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZs ZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciPmdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkp1c3QgdG8g bWFrZSBzdXJlIEkgdW5kZXJzdGFuZC4uLjxicj4NCjxicj4NCklmIHRoZSBBUyBPTkxZIHN1cHBv cnRzIE1UTFMgZW5kcG9pbnRzLCB0aGVuIGl0Li4uPGJyPg0KJm5ic3A7Jm5ic3A7ICogc2V0cyAn dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCcgdG8gJ3Rsc19jbGllbnRfYXV0 aCc8YnI+DQombmJzcDsmbmJzcDsgKiBkb2VzIE5PVCBzcGVjaWZ5IHRoZSBtbHRzX2VuZHBvaW50 cyBzZWN0aW9uPGJyPg0KPGJyPg0KSWYgdGhlIEFTIGRvZXMgTk9UIHN1cHBvcnQgTVRMUyBlbmRw b2ludHMsIHRoZW4gaXQuLi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgKiBkb2VzIE5PVCBzcGVj aWZ5IGEgdmFsdWUgb2YgJ3Rsc19jbGllbnRfYXV0aCcgaW4gdGhlICd0b2tlbl9lbmRwb2ludF9h dXRoX21ldGhvZHNfc3VwcG9ydGVkJzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAqIGRvZXMgTk9U IHNwZWNpZnkgdGhlIG1sdHNfZW5kcG9pbnRzIHNlY3Rpb248YnI+DQo8YnI+DQpJZiB0aGUgQVMg c3VwcG9ydHMgQk9USCAmcXVvdDtyZWd1bGFyJnF1b3Q7IGFuZCBNVExTIGVuZHBvaW50cywgdGhl biBpdC4uLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAqIHNldHMgJ3Rva2VuX2VuZHBvaW50X2F1 dGhfbWV0aG9kc19zdXBwb3J0ZWQnIHRvICZxdW90O2NsaWVudF9zZWNyZXRfYmFzaWMgdGxzX2Ns aWVudF9hdXRoJnF1b3Q7IChhcyBhbiBleGFtcGxlKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAq IHNwZWNpZmllcyBtdGxzX2VuZHBvaW50cyBpbiBhZGRpdGlvbiB0byB0aGUgZW5kcG9pbnRzIG5v cm1hbGx5IGRlZmluZWQgZm9yIHRoZSBBUzxicj4NCjxicj4NCkZvciB0aGUgY2xpZW50LCBpZiBp dCBzdXBwb3J0cyBtdGxzIEFORCBpZiBpdCBmaW5kcyAndGxzX2NsaWVudF9hdXRoJyBpbiB0aGUg J3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQnIHRoZW4gaXQgZmlyc3QgbG9v a3MgdG8gc2VlIGlmIGFuIG10bHNfZW5kcG9pbnRzIG9iamVjdCBpcyBwcm92aWRlZCBhbmQgaWYg c28gdXNlcyB0aG9zZSBlbmRwb2ludHMsIG90aGVyd2lzZSBpdCBhc3N1bWVzIHRoZSBSRkMgODQx NCBkZWZpbmVkDQogZW5kcG9pbnRzIHN1cHBvcnQgTUxUUy48YnI+DQo8YnI+DQpOb3cgaWYgdGhl ICdtdGxzX2VuZHBvaW50cycgc2VjdGlvbiBkZWZpbmVzIGEgJ210bHNfdG9rZW5fZW5kcG9pbnQn IGJ1dCBub3QgYW4gJ2ludHJvc3BlY3Rpb25fZW5kcG9pbnQnIGJ1dCB0aGUgUkZDIDg0MTQgbWV0 YS1kYXRhIGRvZXMgc3BlY2lmeSBhbiAnaW50cm9zcGVjdGlvbl9lbmRwb2ludCcsIGlzIHRoZSBj bGllbnQgc3VwcG9zZWQgdG8gYXNzdW1lIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGFsc28g c3VwcG9ydHMgTVRMUyBldmVuDQogdGhvdWdoIGl0IHdhc24ndCBsaXN0ZWQgaW4gdGhlICdtdGxz X2VuZHBvaW50cycgb2JqZWN0PyBvciBzaG91bGQgaXQgYXNzdW1lIHRoYXQgZW5kcG9pbnQgZG9l cyBOT1Qgc3VwcG9ydCBNVExTIGJlY2F1c2UgaXQncyBub3QgcGFydCBvZiB0aGUgJ210bHNfZW5k cG9pbnRzJyBvYmplY3Q/PGJyPg0KPGJyPg0KSXQgd2lsbCB3b3JrLCB0aG91Z2ggaXQgc3RpbGwg ZmVlbHMgJnF1b3Q7aGFja3kmcXVvdDsgYW5kIG92ZXJseSBjb21wbGV4Ljxicj4NCjxicj4NClRo YW5rcyw8YnI+DQpHZW9yZ2U8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAyLzE1LzE5IDI6NDIgUE0sIFBoaWwgSHVudCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPlRoaXMgaXMgd2hhdCBJIHdvdWxkIGV4cGVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAxNSwgMjAxOSwgYXQgMTE6MzIgQU0s IEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLi5jb20iPnBh bnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gR2VvcmdlLCA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8geW91IHRoaW5r IGFib3V0IHdoYXQgaSB3cm90ZSBlYXJsaWVyPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Y2xpZW50cyBub3QgaGF2aW5nIG10bHMgY2FwYWJpbGl0aWVzIHdvbid0IGNhcmUgYWJvdXQgdGhl IGFkZGl0aW9uYWwgbWV0aG9kIG1lbWJlcnMgYmVpbmcgcHJlc2VudC4gQ2xpZW50cyB0aGF0IGRv IGltcGxlbWVudCBtdGxzIGJ5IHRoZSBzcGVjaWZpY2F0aW9uIHdpbGwga25vdyB0byBsb29rIGZv ciBtdGxzX2VuZHBvaW50cyBhbmQgZmFsbCBiYWNrIHRvIHJlZ3VsYXINCiBvbmVzIGlmIHRoZSBz cGVjaWZpYyBlbmRwb2ludCBvciBtdGxzX2VuZHBvaW50cyByb290IHByb3BlcnR5IGlzIG5vdCBw cmVzZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UyBwb3pkcmF2ZW0sPGJyPg0KPGI+RmlsaXAg U2tva2FuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCAxNSBGZWIgMjAxOSBhdCAyMDoyOSwg R2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBocmVmPSJtYWlsdG86NDBhb2wuY29tQGRt YXJjLmlldGYub3JnIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpIZWx2ZXRpY2EiPkkgc3RpbGwgZG9uJ3Qgc2VlIGhvdyB3ZSBzb2x2ZSBvbmUgb2YgdGhlIHVz ZSBjYXNlcyBBbm5hYmVsbGUgYnJvdWdodCB1cC48YnI+DQo8YnI+DQpJZiB0aGUgJ210bHNfZW5k cG9pbnRzJyBvYmplY3QganVzdCBjb250YWlucyBlbmRwb2ludHMsIHRoZW4gaW4gdGhlIG1haW4g bWV0YS1kYXRhIHNlY3Rpb24sIHNob3VsZCAndG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1 cHBvcnRlZCcgaW5jbHVkZSBhbiBpbmRpY2F0aW9uIG9mICd0bHNfY2xpZW50X2F1dGgnIGV2ZW4g dGhvdWdoIHRoZSBlbmRwb2ludCBzcGVjaWZpZWQgYnkgJ3Rva2VuX2VuZHBvaW50JyBkb2VzIE5P VCBzdXBwb3J0IE1UTFM/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzE0LzE5IDY6MDgg UE0sIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUg SSdtIHdyb25nIGhlcmUgKGl0J3MgbmV2ZXIgb3V0IG9mIHRoZSBxdWVzdGlvbikgYnV0IGJhc2Vk IG9uDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYub3JnX2FyY2hfbXNnX29hdXRoX2VxT1RxNzRoYkh6 OU12LTVGVXpoa3ZpM3pnRVFNJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tp Z3M3cUx3UEp4YyZhbXA7cz1zV0dFVE96WGJJN0xaei1vUWJHcU8ya0VEUWtIRXJtcm1BYWthRWVH SUl3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcmV2aW91cyBtZXNzYWdlPC9hPiBh bmQgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19vYXV0aF9OSnFXOWtJdnhMUmst MkQ0cGlDOS0yREhzUjd3bHJNJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tp Z3M3cUx3UEp4YyZhbXA7cz1WdFVYY0xsSVBwbi10V2hYbjFuMDZzTFFzbU9aNnZqcENKVUgySHZv ZUFNJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBvbmU8L2E+IEkgYmVsaWV2ZSB0aGF0 IGFjdHVhbGx5IHlvdSBhcmUgYm90aCBpbiBmYXZvciAoZ2VuZXJhbGx5IGFueXdheSkgb2YgdGhl IHByb3Bvc2FsIHdpdGggdGhlIG9wdGlvbmFsICZxdW90O210bHNfZW5kcG9pbnRzJnF1b3Q7IHBh cmFtZXRlci4gV2hpbGUgSSBiZWxpZXZlIHRoYXQgdGhlIGNvbW1lbnQgYWJvdXQgb3B0aW9uYWxp dHkgYW5kIGNvbXBsZXhpdHkgd2FzIG1lYW50IHRvIGJlIGEgbW9yZSBnZW5lcmFsDQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+DQpyZW1hcms8L3NwYW4+LiBX aGlsZSBJIGNhbiBjZXJ0YWlubHkgYXBwcmVjaWF0ZSBhIGRlc2lyZSB0byBrZWVwIHRoaW5ncyBz aW1wbGUsIEkgZG8gcmVncmV0IHRoYXQgdGhpcyB0aHJlYWQgdG9vayBhIHR1cm4gdG93YXJkcyBw ZXJzb25hbC4gV2hldGhlciBpdCB3YXMgdGhlIGludGVudCBvciBub3QsIHRoZXJlJ3MgYW4gaW1w YWN0Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAxNCwgMjAxOSBhdCAxMDoyMCBBTSBQaGlsIEh1 bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnBoaWwuaHVudEBvcmFjbGUuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZmVlbCBJ IGhhdmUgdG8gZGlzYWdyZWUuJm5ic3A7IEkgYWdyZWUgdGhhdCBvcHRpb25hbGl0eSBpcyBvZnRl biBjb21wbGV4aXR5IGFuZCBzaG91bGQgYmUgYXZvaWRlZC4gQnV0LCBJIHRoaW5rIHRoZSBvcHRp b25hbGl0eSBoZXJlIGlzIGFuIGFnaWxpdHkgZmVhdHVyZSBhbGxvd2luZyBtdGxzIHRvIHdvcmsg YWNyb3NzIGEgZGl2ZXJzaWZpZWQgbWFya2V0IG9mIGRpZmZlcmVudCB0eXBlcyBvZiB0bHMgdGVy bWluYXRvcnMNCiB3aXRoIHZhcnlpbmcgY2FwYWJpbGl0eS4gTGFjayBvZiBhcHByb3ByaWF0ZSBk aXNjb3Zlcnkvb3B0aW9ucyBjb3VsZCBzZXJ2ZSB0byBtYWtlIHRoZSBzcGVjIHVudXNhYmxlIGlu IG1hbnkgY2FzZXMuICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BIGNvbXBsaWNhdGluZyBmYWN0b3Igd2l0aCB0bHMgaXMgdGhhdCBhIHRscyBs YXllciBmYWlsdXJlIHByZXZlbnRzIHRoZSBBUyBmcm9tIGlzc3VpbmcgYSBjb3JyZWN0aW5nIGRp cmVjdGl2ZSBsaWtlIGFuIGh0dHAgZXJyb3Igb3IgaHR0cCByZWRpcmVjdC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSB0 byBiZSBzdXJlIG5vdCB0byBicmVhayBleGlzdGluZyBjbGllbnRzIHNvIHdlIG1heSBpbiBzb21l IGNhc2VzIG5lZWQgbXRscyBvbmx5IGVuZHBvaW50cy4gSSBhbSBub3QgZmFyIGVub3VnaCBhbG9u ZyB0byBrbm93IGZvciBzdXJlLiBCdXQgSSB0ZW5kIHRvIGFncmVlIHdpdGggQnJpYW4gb24gdGhp cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBtYXkgYmUgYSBzaWduIHdlIG5lZWQgbW9yZSBpbXBsZW1lbnRhdGlvbiBkYXRh IChpbmNsdWRpbmcgZnJvbSB0bHMgd2cpIHRvIG1ha2UgdGhlIHJpZ2h0IGNhbGwuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImdtYWlsLW1fLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFp bC1tXzg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tXy05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwt bV8tNDA3NTY3NjAzNzE0NTc2Mzg4MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAxNCwgMjAx OSwgYXQgODo1NiBBTSwgRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJA bGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj5Tb3JyeSAtIHRoaXMgd2FzIG5vdCBtZWFudCB0byBiZSBzbmlk ZSBhdCBhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPkl0IHdhcyBob25lc3QgZmVlZGJhY2sgdGhhdCB5b3UgYWxzbyBuZWVkIHRv IGtlZXAgc29mdHdhcmUgY29tcGxleGl0eSBpbiBtaW5kIHdoZW4gY3JlYXRpbmcgYSBzcGVjLiBF dmVyeSBNQVkgb3IgT1BUSU9OQUwsIG9yIGRvIGl0IGxpa2UgdGhpcyBPUiB0aGF0LCBvciBzZW5k IHZhbHVlcyBpbiBhcmJpdHJhcnkgb3JkZXINCiBhZGRzIHRvIGNvbXBsZXhpdHkuIENvbXBsZXhp dHkgaXMgdGhlIG5hdHVyYWwgZW5lbXkgb2Ygc2VjdXJpdHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkNoZWVycyZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKA lOKAlOKAlCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb21p bmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIx MjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3 Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwYWlybWFpbG9uIj4NCk9uIDEzLiBGZWJydWFyeSAy MDE5IGF0IDIwOjM5OjE2LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAoPGEgaHJlZj0ibWFp bHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGlzc3VlIGlzIHRoYXQgdGhlIHByb3Bvc2FsIHZpb2xh dGVzIHRoZSBzdGFuZGFyZCBieSBjaGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIGEgcGFyYW1ldGVy IGl0IGRlZmluZXMuIFdlIHNob3VsZCBiZSB2ZXJ5LCB2ZXJ5LCBWRVJZIGNhcmVmdWwgYWJvdXQg dGVsbGluZyBpbXBsZW1lbnRlcnMgdG8gdmlvbGF0ZQ0KIGFuIGV4aXN0aW5nIHN0YW5kYXJkLi4u IFRoaXMgY2hhbmdlIG1pZ2h0IHByb3ZlIGluY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIG9yIGZ1 dHVyZSBpbXBsZW1lbnRhdGlvbnMgb2YgODQxNCwgaXQgbWlnaHQgbm90LCBidXQgYnkgdmlvbGF0 aW5nIHRoZSBzdGFuZGFyZCB0aGUgcHJvcG9zYWwgY3JlYXRlcyBhbiBvcHBvcnR1bml0eSBmb3Ig aW5jb21wYXRpYmlsaXR5IHRoYXQgZGlkbuKAmXQgZXhpc3QgYmVmb3JlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QXMgZmFyIGFzIHNpbXBsaWNpdHkgaXMgY29uY2VybmVkLCBJIGZpbmQg YSBzb2x1dGlvbiB0aGF0IHJldXNlcyB0aGUgZXhpc3RpbmcgZGF0YSBtb2RlbCBhbmQgbmF0dXJh bGx5IHN1cHBvcnRzIGV4aXN0aW5nIGFuZCBmdXR1cmUgZXh0ZW5zaW9ucyB0byBiZSBmYXIgc2lt cGxlciB0aGFuIG9uZSB0aGF0IGludHJvZHVjZXMNCiBhbWJpZ3VvdXMgc2VtYW50aWNzIHRvIGV4 aXN0aW5nIHBhcmFtZXRlcnMuIEdlbmVyYWxseSBzcGVha2luZywgZGF0YSBtb2RlbHMgd2l0aCBw cm9wZXJ0aWVzIHRoYXQgbWVhbiBkaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBjb250ZXh0 cyB0ZW5kIHRvIGJlIGZyYWdpbGUgYW5kIHJlcXVpcmUgbW9yZSBjb21wbGV4IGNvZGUgdG8gd29y ayB3aXRoLiBCdXQgdGhhdOKAmXMganVzdCBteSBleHBlcmllbmNlIGFzLCB5b3Uga25vdywgYW4g YWN0dWFsDQogZGV2ZWxvcGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV04oCZcyBr ZWVwIHRoZSBhc3N1bXB0aW9ucyBhbmQgc25pZGUgcmVtYXJrcyBhYm91dCBvdGhlcnPigJkgYmFj a2dyb3VuZHMgb2ZmIHRoZSBsaXN0LCBwbGVhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RG9taW5pY2sgQmFpZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5l c2RheSwgRmVicnVhcnkgMTMsIDIwMTkgYXQgNDoxOCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7 UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNo YW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4m Z3Q7LCBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwYW52YS4uaXBAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+cGFudmEuaXBAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzog PC9iPkJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4m Z3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6 b24uY29tPC9hPiZndDssIG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPltVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtPQVVUSC1XR10gTVRMUyB0b2tlbiBlbmRvaW50 ICZhbXA7IGRpc2NvdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYSI+SSBhbSBmb3Iga2VlcGluZyBpdCBzaW1wbGUgYW5kIG5vdCBp bnRyb2R1Y2luZyBhbm90aGVyIGxpbmsgdG8gZm9sbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SSBzb21ldGltZXMgd29u ZGVyIGhvdyBtYW55IG9mIHRoZSBzcGVjIGF1dGhvcnMgYXJlIGFjdHVhbGx5IGRldmVsb3BlcnMg LSB0aGVzZSBzdWdnZXN0aW9ucyBtYWtlIHNvZnR3YXJlIHVubmVjZXNzYXJ5IGNvbXBsZXgNCiA7 KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAlOKA lOKAlA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb21p bmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0yOTE5OTU4MzIzOTE3 MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2 ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBhaXJtYWlsb24wIj4NCk9uIDEzLiBGZWJydWFy eSAyMDE5IGF0IDEyOjI1OjEzLCBGaWxpcCBTa29rYW4gKDxhIGhyZWY9Im1haWx0bzpwYW52YS5p cEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wYW52YS5pcEBnbWFpbC5jb208L2E+KSB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGVsbG8sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29s b3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJy ZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWRkaXRpb25hbGx5 LCBhIG1ldGFkYXRhIGRvY3VtZW50IHRoYXQgb21pdHMgdG9rZW5fZW5kcG9pbnQgaW4gZmF2b3Ig b2YgbXRsc19lbmRwb2ludHMgc2luY2Ugb25seSBtVExTIGlzIHN1cHBvcnRlZCB3b3VsZCB2aW9s YXRlIDg0MTQsIGFzIDg0MTQgc2F5cyB0b2tlbl9lbmRwb2ludCDigJxpcyBSRVFVSVJFRA0KIHVu bGVzcyBvbmx5IHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ08bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KbXRscyBvbmx5 IEFTIGRvZXNuJ3QgZ2V0IGFueXRoaW5nIG91dCBvZiB1c2luZyBtdGxzX2VuZHBvaW50cywgaXRz IHVzZSBzaG91bGQgbm90IGJlIHJlY29tbWVuZGVkIGZvciBzdWNoIEFTIGFuZCByZWd1bGFyIGVu ZHBvaW50cyB3aWxsIGJlIHVzZWQsIHRoaXMgc2F0aXNmaWVzIHRoZSByZXF1aXJlbWVudDxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlcmUgaXMgb25lIGV4YW1wbGUsIGJhc2VkIG9uIG15IHVu ZGVyc3RhbmRpbmcgb2YgdGhlIOKAnHN0cmF3IG1hbuKAnSBmb3JtYXQgcHJlc2VudGVkIGluIHRo aXMgdGhyZWFkOiBSRkM4NDE0IGRlZmluZXMgdGhlIHZhbHVlIG9mIHRva2VuX2VuZHBvaW50X2F1 dGhfbWV0aG9kc19zdXBwb3J0ZWQgYXMgYSDigJxKU09ODQogYXJyYXkgY29udGFpbmluZyBhIGxp c3Qgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgc3VwcG9ydGVkIGJ5IHRoaXMgdG9r ZW4gZW5kcG9pbnQu4oCdIElmIHRoYXQgYXJyYXkgY29udGFpbnMg4oCcdGxzX2NsaWVudF9hdXRo 4oCdIGFuZCB0aGUgZW5kcG9pbnQgc3BlY2lmaWVkIGluIHRva2VuX2VuZHBvaW50IGRvZXMgbm90 IHN1cHBvcnQgbVRMUywgdGhlbiB0aGF0IG1ldGFkYXRhIHZpb2xhdGVzIDg0MTQuIFlvdSBjb3Vs ZCBhZGRyZXNzIHRoaXMNCiBieSBhZGRpbmcgYSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNf c3VwcG9ydGVkIHBhcmFtZXRlciB0byB0aGUgbXRsc19lbmRwb2ludHMgb2JqZWN0LCBhbmQgbGlr ZXdpc2UgZm9yIHRoZSBvdGhlciBlbmRwb2ludHMgYW5kIGF1dGggbWV0aG9kcy4gSWYgeW91IHRh a2UgdGhhdCB0byBpdHMgbG9naWNhbCBjb25jbHVzaW9uLCB5b3UgZW5kIHVwIHdpdGggYSBjb21w bGV0ZSBtZXRhZGF0YSBkb2N1bWVudCBoYW5naW5nIG9mZiBvZiBtdGxzX2VuZHBvaW50cy4NCiBJ dOKAmXMgdGhhdCBsaW5lIG9mIHRob3VnaHQgdGhhdCBsZWQgbWUgdG8gc3VnZ2VzdCBqdXN0IHBv aW50aW5nIHRvIGFuIGFsdGVybmF0ZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KQXNzdW1pbmcgd2UgZ28gd2l0aCB1 c2luZyB0aGUgc2FtZSByb290IGF1dGggbWV0aG9kcyBwcm9wZXJ0eSwgd2hhdCdzIHRoZSBpc3N1 ZT8gQ2xpZW50cyBub3QgaGF2aW5nIG10bHMgY2FwYWJpbGl0aWVzIHdvbid0IGNhcmUgYWJvdXQg dGhlIGFkZGl0aW9uYWwgbWV0aG9kIG1lbWJlcnMgYmVpbmcgcHJlc2VudC4gQ2xpZW50cyB0aGF0 IGRvIGltcGxlbWVudCBtdGxzIGJ5IHRoZSBzcGVjaWZpY2F0aW9uIHdpbGwga25vdyB0byBsb29r IGZvciBtdGxzX2VuZHBvaW50cw0KIGFuZCBmYWxsIGJhY2sgdG8gcmVndWxhciBvbmVzIGlmIHRo ZSBzcGVjaWZpYyBlbmRwb2ludCBvciBtdGxzX2VuZHBvaW50cyByb290IHByb3BlcnR5IGlzIG5v dCBwcmVzZW50Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSBnYXZlIGBtdGxzX2FsdGVybmF0ZV9tZXRhZGF0YWAgcm91dGUgYSB0aG91Z2h0IGFu ZCBkb24ndCBzZWUgaG93IGl0IGhlbHBzLCBnaXZlbiB0aGUgdHdvIGFib3ZlIGFyZSBub24taXNz dWVzIChteSAkLjAyKSBhbm90aGVyIGRpc2NvdmVyeSBkb2N1bWVudCBvbmx5IGJyaW5ncyBtb3Jl IG9mIHRoZW0gc2luY2UNCiBldmVyeSBwcm9wZXJ0eSBjYW4gbm93IGJlIGRpZmZlcmVudCwgbm90 IGp1c3QgdGhlIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlMgcG96ZHJhdmVtLDxicj4NCjxiPkZpbGlwIFNrb2th bjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFdlZCwgMTMgRmViIDIwMTkgYXQgMDA6MDAsIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdp bmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDti b3JkZXItY29sb3I6Y3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3IKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0 KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVyZSBpcyBvbmUgZXhh bXBsZSwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg4oCcc3RyYXcgbWFu4oCdIGZv cm1hdCBwcmVzZW50ZWQgaW4gdGhpcyB0aHJlYWQ6IFJGQzg0MTQgZGVmaW5lcyB0aGUgdmFsdWUg b2YgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCBhcyBhIOKAnEpTT04NCiBh cnJheSBjb250YWluaW5nIGEgbGlzdCBvZiBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBz dXBwb3J0ZWQgYnkgdGhpcyB0b2tlbiBlbmRwb2ludC7igJ0gSWYgdGhhdCBhcnJheSBjb250YWlu cyDigJx0bHNfY2xpZW50X2F1dGjigJ0gYW5kIHRoZSBlbmRwb2ludCBzcGVjaWZpZWQgaW4gdG9r ZW5fZW5kcG9pbnQgZG9lcyBub3Qgc3VwcG9ydCBtVExTLCB0aGVuIHRoYXQgbWV0YWRhdGEgdmlv bGF0ZXMgODQxNC4gWW91IGNvdWxkIGFkZHJlc3MgdGhpcw0KIGJ5IGFkZGluZyBhIHRva2VuX2Vu ZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQgcGFyYW1ldGVyIHRvIHRoZSBtdGxzX2VuZHBv aW50cyBvYmplY3QsIGFuZCBsaWtld2lzZSBmb3IgdGhlIG90aGVyIGVuZHBvaW50cyBhbmQgYXV0 aCBtZXRob2RzLiBJZiB5b3UgdGFrZSB0aGF0IHRvIGl0cyBsb2dpY2FsIGNvbmNsdXNpb24sIHlv dSBlbmQgdXAgd2l0aCBhIGNvbXBsZXRlIG1ldGFkYXRhIGRvY3VtZW50IGhhbmdpbmcgb2ZmIG9m IG10bHNfZW5kcG9pbnRzLg0KIEl04oCZcyB0aGF0IGxpbmUgb2YgdGhvdWdodCB0aGF0IGxlZCBt ZSB0byBzdWdnZXN0IGp1c3QgcG9pbnRpbmcgdG8gYW4gYWx0ZXJuYXRlIGRvY3VtZW50LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWRkaXRpb25hbGx5LCBhIG1ldGFkYXRhIGRvY3VtZW50 IHRoYXQgb21pdHMgdG9rZW5fZW5kcG9pbnQgaW4gZmF2b3Igb2YgbXRsc19lbmRwb2ludHMgc2lu Y2Ugb25seSBtVExTIGlzIHN1cHBvcnRlZCB3b3VsZCB2aW9sYXRlIDg0MTQsIGFzIDg0MTQgc2F5 cyB0b2tlbl9lbmRwb2ludCDigJxpcyBSRVFVSVJFRA0KIHVubGVzcyBvbmx5IHRoZSBpbXBsaWNp dCBncmFudCB0eXBlIGlzIHN1cHBvcnRlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pkl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgbXRsc19lbmRwb2ludHMgcGFyYW1ldGVyIHN1 Y2ggdGhhdCB0aGUgYWJvdmUgdXNlIGNhc2VzIGFyZSBpbnZhbGlkLCBidXQgdGhhdCBkb2VzIG1h a2UgdGhlIGRvY3VtZW50IG1vcmUgY29tcGxpY2F0ZWQuLiBJZiB3ZSBnbyB0aGUg4oCcbXRsc19h bHRlcm5hdGVfbWV0YWRhdGHigJ0NCiByb3V0ZSwgd2UgY2FuIHNraXAgcGFzdCBhbGwgb2YgdGhl c2UgaXNzdWVzLCBiZWNhdXNlIGl0IGJyaW5ncyB1cyBiYWNrIHRvIGp1c3QgcGFyc2luZyB0aGUg c2FtZSBtZXRhZGF0YSB0aGF0IHdlIGRvIHRvZGF5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9y Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlw QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE5IGF0IDE6MTMgUE08YnI+ DQo8Yj5Ubzo8L2I+ICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDty aWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQwcGlu Z2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lkZW50 aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7LCBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi4ub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTVRMUyB0b2tlbiBlbmRvaW50ICZh bXA7IGRpc2NvdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQW5uYWJlbGxlLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Y2FuIHlv dSBlbGFib3JhdGUgd2hhdCB3b3VsZCBiZSB0aGUgdmlvbGF0aW9uIC8gbmVnYXRpdmUgaW1wYWN0 IG9mIHVzYWdlIG9mIFJGQzg0MTQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBpdCBhbHJlYWR5IG1ha2VzIHVzZSBvZiBgc2lnbmVk X21ldGFkYXRhYCBhbmQgdGhpcyBsYW5ndWFnZSBpcyBwcmVzZW50IC4uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZuYnNwO0Nv bnN1bWVycyBvZiB0aGUgbWV0YWRhdGEgTUFZIGlnbm9yZSB0aGUgc2lnbmVkIG1ldGFkYXRhIGlm IHRoZXkgZG8gbm90IHN1cHBvcnQgdGhpcyBmZWF0dXJlLiZuYnNwOyBJZiB0aGUgY29uc3VtZXIg b2YgdGhlIG1ldGFkYXRhIHN1cHBvcnRzIHNpZ25lZCBtZXRhZGF0YSwgbWV0YWRhdGEgdmFsdWVz IGNvbnZleWVkDQogaW4gdGhlIHNpZ25lZCBtZXRhZGF0YSBNVVNUIHRha2UgcHJlY2VkZW5jZSBv dmVyIHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlcyBjb252ZXllZCB1c2luZyBwbGFpbiBKU09OIGVs ZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Li4uLiB3b3VsZCBtdGxzX2VuZHBvaW50cyBiZSBhbnkgZGlmZmVyZW50PyBDbGll bnRzIGFyZSBmcmVlIHRvIGlnbm9yZSB0aGlzIGlmIHRoZXkgZG9uJ3Qgc3VwcG9ydC91c2UgbXRs cywgYW5kIGlmIHRoZXkgZG8gdGhvc2UgdmFsdWVzIG11c3QgdGFrZSBwcmVjZWRlbmNlIG92ZXIg dGhlIHJvb3Qgb25lcy4NCiB0aGUgdXNlIG9mIG10bHNfZW5kcG9pbnRzIHdvdWxkIG5vdCBiZSBy ZWNvbW1lbmRlZCBmb3IgbXRscy1vbmx5IEFTIGJ1dCByZWNvbW1lbmRlZCBmb3Igb25lIHdpdGgg Ym90aCBtdGxzL3JlZ3VsYXIgYXV0aGVudGljYXRpb24gbWV0aG9kcy4gdG9rZW5fZW5kcG9pbnQg cmVtYWlucyByZXF1aXJlZCBmb3IgYWxsIGludGVudHMgYW5kIHB1cnBvc2VzLiBBbmQgYXMgZm9y IHRoZSB1c2FibGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgLSB0aGV5DQogc2hvdWxk IGFsbCBiZSBsaXN0ZWQsIG9yIGRvIHlvdSB0aGluayB3ZSBzaG91bGQgc2VwYXJhdGUgdGhlIG9u ZXMgZm9yIGVhY2ggaG9zdG5hbWUvcG9ydCBsb2NhdGlvbj8gVG8gd2hhdCBlbmQ/IElzIHRoZXJl IGEgcmlzayBoYXZpbmcgdGhlIG10bHMgaG9zdG5hbWUvcG9ydCBhY2NlcHRpbmcgcmVndWxhciBy ZXF1ZXN0cz8gT3RoZXIgdGhlbiBzZWNyZXQva2V5IF9qd3QgYXV0aCBtZXRob2RzIGFzc2VydGlv biBhdWQgY2xhaW0gdGhlIGVuZHBvaW50DQogbG9jYXRpb24gZG9lc24ndCBwbGF5IGEgcm9sZSBp biB0aGUgYXV0aGVudGljYXRpb24gcHJvY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0LDxicj4NCjxiPkZpbGlwPC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBUdWUsIDEyIEZlYiAyMDE5IGF0IDIwOjQ3LCBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5J4oCZbSBub3Qgb3Bwb3NlZCB0byBpbnRyb2R1Y2luZyBhIG1ldGFk YXRhIGNoYW5nZSwgaWYgdGhlIHNjZW5hcmlvIGlzIHJlbGV2YW50IGFuZCBvdGhlciBhcHByb2Fj aGVzIGNhbuKAmXQgYWRlcXVhdGVseSBhZGRyZXNzIGl0IOKAkyBhbmQgSeKAmWxsIHJlYWRpbHkg Z3JhbnQgdGhhdCB3ZSBwcm9iYWJseSBkb27igJl0IHdhbnQNCiB0byBkZXBlbmQgb24gY29uc2lz dGVuY3kgb2YgYnJvd3NlciBiZWhhdmlvciBhdCB0aGUgaW50ZXJzZWN0aW9uIG9mIGNsaWVudCBj ZXJ0aWZpY2F0ZXMgYW5kIEFjY2Vzcy1Db250cm9sLUFsbG93LUNyZWRlbnRpYWxzLiBCdXQgY2Fy ZSBuZWVkcyB0byBiZSB0YWtlbiBpbiBkZXNpZ25pbmcgdGhhdCBtZXRhZGF0YSB0byBhdm9pZCB2 aW9sYXRpbmcgb3Igb3RoZXJ3aXNlIG5lZ2F0aXZlbHkgaW1wYWN0aW5nIHVzYWdlIG9mIFJGQzg0 MTQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbG9uZyB0aG9zZSBsaW5lcywgaW5zdGVh ZCBvZiBhZGRpbmcgYW4g4oCcbXRsc19lbmRwb2ludHPigJ0gbWV0YWRhdGEgcGFyYW1ldGVyLCB3 ZSBjb3VsZCBhZGQgYW4g4oCcbXRsc19hbHRlcm5hdGVfbWV0YWRhdGHigJ0gcGFyYW1ldGVyIHdo b3NlIHZhbHVlIGlzIHRoZSBVUkwgb2YgYW4gYWx0ZXJuYXRlIG1ldGFkYXRhDQogZG9jdW1lbnQg aW50ZW5kZWQgZm9yIGNsaWVudHMgdXNpbmcgbVRMUy4gQW4gbVRMUy1vcHRpb25hbCBBUyBjb3Vs ZCBoYXZlIHR3byBkaWZmZXJlbnQgbWV0YWRhdGEgZG9jdW1lbnRzIGZvciBtVExTIGFuZCBub24t bVRMUyBjbGllbnRzLCByZWR1Y2luZyB0aGUgbVRMUy1vcHRpb25hbCBzY2VuYXJpbyB0byB0aGUg bVRMUy1vbmx5IHNjZW5hcmlvLiBUaGlzIHNpZGVzdGVwcyB0aGUgY2hhbGxlbmdlcyBvZiBhbGln bmluZyB0aGUg4oCcZWl0aGVyL29y4oCdDQogc2VtYW50aWNzIG9mIG1UTFMtb3B0aW9uYWwgd2l0 aCBzb21lIG9mIHRoZSByaWdpZCBwYXJhbWV0ZXIgZGVmaW5pdGlvbnMgaW4gUkZDODQxNCAoc2Vl OiB0b2tlbl9lbmRwb2ludCwgdG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4t LSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJ ZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6 Y3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDs8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwg Jmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMTIsIDIwMTkgYXQg MTA6NTggQU08YnI+DQo8Yj5Ubzo8L2I+IERvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJtYWls dG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWllckBsZWFz dHByaXZpbGVnZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTVRMUyB0b2tlbiBlbmRv aW50ICZhbXA7IGRpc2NvdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFua3MgZm9yIHRoZSBpbnB1dCwgRG9taW5pY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ2Qgc2FpZCBwcmV2aW91c2x5IHRoYXQg SSB3YXMgaGF2aW5nIHRyb3VibGUgYWRlcXVhdGVseSBnYXVnaW5nIHdoZXRoZXIgb3Igbm90IHRo ZXJlJ3Mgc3VmZmljaWVudCBjb25zZW5zdXMgdG8gZ28gYWhlYWQgd2l0aCB0aGUgdXBkYXRlLiBJ IHdhcyBldmVuIHRoaW5raW5nIG9mIGFza2luZyB0aGUgY2hhaXJzDQogYWJvdXQgYSBjb25zZW5z dXMgY2FsbCBkdXJpbmcgdGhlIG9mZmljZSBob3VycyBtZWV0aW5nIHllc3RlcmRheS4gQnV0IGl0 IGdvdCBjYW5jZWxlZC4gQW5kIGxvb2tpbmcgYWdhaW4gYmFjayBvdmVyIHRoZSBkaXNjdXNzaW9u LCBJIGRvbid0IGJlbGlldmUgYSBjb25zZW5zdXMgY2FsbCBpcyBuZWNlc3NhcnkuIFRoZXJlJ3Mg YmVlbiBhIGxvdCBvZiBnZW5lcmFsIGRpc2N1c3Npb24gb3ZlciB0aGUgbGFzdCBzZXZlcmFsIHdl ZWtzIGR1cmluZyB3aGljaA0KIHNldmVyYWwgZm9sa3MgaGF2ZSBzdGF0ZWQgc3VwcG9ydCBmb3Ig dGhlIHByb3Bvc2FsIHdoaWxlIHRoZXJlJ3MgYmVlbiBvbmx5IG9uZSB2b2ljZSBvZiBkaXJlY3Qg ZGlzc2VudC4gVGhhdCBzZWVtcyBsaWtlIHJvdWdoIGVub3VnaCBjb25zZW5zdXMgYW5kLCBhcyBz dWNoLCBJIHBsYW4gdG8gbWFrZSB0aGUgY2hhbmdlIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRo ZSBkb2N1bWVudCAod2hpY2ggc2hvdWxkIGJlIGRvbmUgc29vbikuIENoYWlycywNCiBwbGVhc2Ug bGV0IG1lIGtub3csIGlmIHlvdSBiZWxpZXZlIHRoZSBzaXR1YXRpb24gd2FycmFudHMgYSBkaWZm ZXJlbnQgY291cnNlIG9mIGFjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gTW9uLCBGZWIgMTEsIDIwMTkgYXQgMTE6MDEgUE0gRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJh aWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPklNSE8gdGhhdOKAmXMgYSBy ZWFzb25hYmxlIGFuZCBwcmFnbWF0aWMgb3B0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJTigJTi gJQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvbWluaWNr PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0 MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dt YWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3 NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0 OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzEiPg0K T24gMTEuIEZlYnJ1YXJ5IDIwMTkgYXQgMTM6MjY6MzcsIEJyaWFuIENhbXBiZWxsICg8YSBocmVm PSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPkl0J3MgYmVlbiBwb2ludGVkIG91dCB0aGF0IHRoZSBwb3RlbnRp YWwgaXNzdWUgaXMgbm90IGlzb2xhdGVkIHRvIHRoZSBqdXN0IHRva2VuIGVuZHBvaW50IGJ1dCB0 aGF0IHJldm9jYXRpb24sIGludHJvc3BlY3Rpb24sIGV0Yy4gY291bGQgYmUgaW1wYWN0ZWQgYXMg d2VsbC4gU28sJm5ic3A7IGF0IHRoaXMgcG9pbnQsIHRoZSBwcm9wb3NhbA0KIG9uIHRoZSB0YWJs ZSBpcyB0byBhZGQgYSBuZXcgb3B0aW9uYWwgQVMgbWV0YWRhdGEgcGFyYW1ldGVyIG5hbWVkICdt dGxzX2VuZHBvaW50cycgdGhhdCdzIHZhbHVlIHdlIGJlIGEgSlNPTiBvYmplY3Qgd2hpY2ggaXRz ZWxmIGNvbnRhaW5zIGVuZHBvaW50cyB0aGF0LCB3aGVuIHByZXNlbnQsIGEgY2xpZW50IGRvaW5n IE1UTFMgd291bGQgdXNlIHJhdGhlciB0aGFuIHRoZSByZWd1bGFyIGVuZHBvaW50cy4mbmJzcDsg QSBzdHJhdy1tYW4gZXhhbXBsZSBtaWdodA0KIGxvb2sgbGlrZSB0aGlzPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ezxicj4NCiZuYnNwOyAmcXVvdDtpc3N1ZXImcXVv dDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbTwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZx dW90O2F1dGhvcml6YXRpb25fZW5kcG9pbnQmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9z ZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aHoiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZlci5l eGFtcGxlLmNvbS9hdXRoejwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O3Rva2VuX2VuZHBv aW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2Vu IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW48L2E+JnF1 b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9y dGVkJnF1b3Q7OlsgJm5ic3A7JnF1b3Q7Y2xpZW50X3NlY3JldF9iYXNpYyZxdW90OywmcXVvdDt0 bHNfY2xpZW50X2F1dGgmcXVvdDssICZxdW90O25vbmUmcXVvdDtdLDxicj4NCiZuYnNwOyAmcXVv dDt1c2VyaW5mb19lbmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5l eGFtcGxlLmNvbS91c2VyaW5mbyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2VydmVyLmV4YW1w bGUuY29tL3VzZXJpbmZvPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7cmV2b2NhdGlvbl9l bmRwb2ludCZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9y ZXZvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmV2bzwvYT4m cXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O2p3a3NfdXJpJnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0 dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2p3a3MuanNvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vc2VydmVyLmV4YW1wbGUuY29tL2p3a3MuanNvbjwvYT4mcXVvdDssPGJyPg0KJm5ic3A7IDxi PiZxdW90O210bHNfZW5kcG9pbnRzJnF1b3Q7Ons8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O3Rv a2VuX2VuZHBvaW50JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vbXRscy5leGFtcGxlLmNv bS90b2tlbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS90b2tlbjwv YT4mcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVvdDt1c2VyaW5mb19lbmRwb2ludCZxdW90 OzomcXVvdDs8YSBocmVmPSJodHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL210bHMuZXhhbXBsZS5jb20vdXNlcmluZm88L2E+JnF1b3Q7LDxi cj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7cmV2b2NhdGlvbl9lbmRwb2ludCZxdW90OzomcXVvdDs8 YSBocmVmPSJodHRwczovL210bHMuLi4uLi4uZXhhbXBsZS5jb20vcmV2byIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vbXRscy5leGFtcGxlLmNvbS9yZXZvPC9hPiZxdW90Ozxicj4NCiZuYnNwOyB9 PC9iPjxicj4NCn08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgY2xpZW50IGRvaW5nIE1UTFMgd291bGQgbG9v ayBmb3IgYW5kIGdpdmUgcHJlY2VkZW5jZSB0byBhbiBlbmRwb2ludCB1bmRlciAmcXVvdDttdGxz X2VuZHBvaW50cyZxdW90OyB3aGlsZSBmYWxsaW5nIGJhY2sgdG8gdXNlIHRoZSBub3JtYWwgZW5k cG9pbnQgZnJvbSB0aGUgdG9wIGxldmVsIG9mIG1ldGFkYXRhIHdoZW4vaWYNCiBpdHMgbm90IGlu ICZxdW90O210bHNfZW5kcG9pbnRzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGUgaWRlYSBiZWluZyB0aGF0ICZxdW90 O3JlZ3VsYXImcXVvdDsgY2xpZW50cyAodGhvc2Ugbm90IGRvaW5nIE1UTFMpIHdpbGwgdXNlIHRo ZSByZWd1bGFyIGVuZHBvaW50cy4gQW5kIG9ubHkgdGhlIGhvc3QvcG9ydCBvZiB0aGUgZW5kcG9p bnRzIGxpc3RlZCBpbiBtdGxzX2VuZHBvaW50cyB3aWxsIGJlIHNldCB1cCB0byByZXF1ZXN0IFRM UyBjbGllbnQgY2VydGlmaWNhdGVzIGR1cmluZyBoYW5kc2hha2UuIFRodXMgYW55IHBvdGVudGlh bCBpbXBhY3Qgb2YgdGhlDQogQ2VydGlmaWNhdGVSZXF1ZXN0IG1lc3NhZ2UgYmVpbmcgc2VudCBp biB0aGUgVExTIGhhbmRzaGFrZSBjYW4gYmUgYXZvaWRlZCBmb3IgYWxsIHRoZSBvdGhlciByZWd1 bGFyIGNsaWVudHMgdGhhdCBhcmUgbm90IGdvaW5nIHRvIGRvIE1UTFMgLSBpbmNsdWRpbmcgYW5k IG1vc3QgaW1wb3J0YW50bHkgaW4tYnJvd3NlciBqYXZhc2NyaXB0IGNsaWVudHMgd2hlcmUgdGhl cmUgY2FuIGJlIGxlc3MgdGhhbiBkZXNpcmFibGUgVUkgcHJlc2VudGVkIHRvDQogdGhlIGVuZC11 c2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSdtIHN0cnVnZ2xpbmcsIGhvd2V2ZXIsIHRvIGFkZXF1YXRlbHkgZ2F1Z2Ugd2hldGhl ciBvciBub3QgdGhlcmUncyBzdWZmaWNpZW50IGNvbnNlbnN1cyB0byBnbyBhaGVhZCB3aXRoIHRo ZSB1cGRhdGUuIFRoZXJlJ3MgYmVlbiBzb21lIHN1cHBvcnQgZm9yIGl0IHZvaWNlZC4gQXMgd2Vs bCBhcyB0YWxrIG9mDQogb3RoZXIgYXBwcm9hY2hlcyB0aGF0IGNvdWxkIGJlIGFsdGVybmF0aXZl cyBvciBhZGRpdGlvbmFsIG1lYXN1cmVzLiBBbmQgYWxzbyBzb21lIHZvY2FsIG9wcG9zaXRpb24g dG8gaXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTYXQsIEZlYiA5LCAyMDE5IGF0IDM6MDkgQU0g RG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2Uu Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2EiPldlIGFyZSBjdXJyZW50bHkgaW1wbGVtZW50aW5nIE1UTFMgaW4gSWRlbnRpdHlTZXJ2 ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj5PdXIgYXBwcm9hY2ggd2lsbCBiZSB0aGF0IHdl4oCZbGwgb2ZmZXIgYSBzZXBh cmF0ZSB0b2tlbiBlbmRwb2ludCB0aGF0IHN1cHBvcnRzIGNsaWVudCBjZXJ0cy4gQXJlIHlvdSBw bGFubmluZyBvbiBhZGRpbmcgYW4gb2ZmaWNpYWwNCiBlbmRwb2ludCBuYW1lIGZvciBkaXNjb3Zl cnk/IFJpZ2h0IG5vdyB3ZSBhcmUgdXNpbmcg4oCcbXRsc190b2tlbl9lbmRwb2ludOKAnS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+4oCU4oCU4oCUPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Eb21pbmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21h aWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1t LTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEz NzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYy MjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5 Z21haWwtbTIxOTY1MzI1NDMxIj4NCk9uIDcuIEZlYnJ1YXJ5IDIwMTkgYXQgMjI6MzY6NTUsIEJy aWFuIENhbXBiZWxsICg8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbD00MHBpbmdpZGVudGl0 eS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFoIHll cywgdGhhdCBtYWtlcyBzZW5zZS4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nLiBBbmQgaXQgaXMgaW5k ZWVkIGEgZ29vZCByZW1pbmRlciB0aGF0IGV2ZW4gYSBzZWVtaW5nbHkgaW5ub2N1b3VzIGNoYW5n ZSB0aGF0IHNob3VsZCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSBjYW4gYnJlYWsgdGhpbmdzIHVu ZXhwZWN0ZWRseS4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEZlYiA3LCAyMDE5 IGF0IDg6NTcgQU0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY2FzZSBJ4oCZbSByZWZlcmVuY2luZyBkaWRu4oCZ dCBzcGVjaWZpY2FsbHkgaW52b2x2ZSBBUyBtZXRhZGF0YS4gV2UgaGFkIGNsaWVudHMgaW4gdGhl IHdpbGQgdGhhdCBhc3N1bWVkIHRoYXQgYWxsIHRoZSBwcm9wZXJ0aWVzIGluIHRoZSBKU09OIG9i amVjdCByZXR1cm5lZCBmcm9tIG91ciB1c2VyaW5mbyBlbmRwb2ludA0KIHdlcmUgc2NhbGFyIHN0 cmluZ3MuIFRoaXMgYnJva2Ugd2hlbiB3ZSBpbnRyb2R1Y2VkIGEgbmV3IHByb3BlcnR5IHdob3Nl IHZhbHVlIHdhcyBhIEpTT04gb2JqZWN0LiBJdCB3YXMgYSBnb29kIHJlbWluZGVyIHRoYXQgZXZl biBhIHNlZW1pbmdseSBpbm5vY3VvdXMgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIGJhY2t3YXJkcyBj b21wYXRpYmxlIGNhbiBmb3JjZSBtb3JlIHdvcmsgb24gY2xpZW50cyB0aGFuIHdlIGV4cGVjdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0t Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QVdTIElk ZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QnJpYW4gQ2FtcGJlbGwgJmx0 OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+ IFdlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxOSBhdCAxMTozMCBBTTxicj4NCjxiPlRvOjwvYj4g JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhy ZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7 UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNo YW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4m Z3Q7LCBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBbVU5WRVJJRklFRCBTRU5ERVJdIFJlOiBNVExTIGFuZCBpbi1icm93c2VyIGNsaWVu dHMgdXNpbmcgdGhlIHRva2VuIGVuZHBvaW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBJJ20gaG9uZXN0 bHkgcmVhbGx5IHN0cnVnZ2xpbmcgdG8gc2VlIHdoYXQgY291bGQgaGF2ZSBnb25lIHdyb25nIHdp dGggb3IgaG93IHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kcyBicm9rZSBzb21ldGhpbmcgd2l0 aCB0aGUgdXNlciBpbmZvIGVuZHBvaW50LiBJZiB5b3UgaGF2ZSB0aGUgdGltZSBhbmQvb3INCiBp dCdkIGJlIGluZm9ybWF0aXZlIHRvIHRoaXMgaGVyZSBsaXR0bGUgZGlzY3Vzc2lvbiwgcGxlYXNl IGV4cGxhaW4gdGhhdCBvbmUgYSBiaXQgbW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEZlYiA2LCAyMDE5IGF0IDEyOjE1IFBNIEJy aWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRj b2xvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7ZmFyJnF1b3Q7IHNob3VsZCBoYXZlIHNh aWQgJnF1b3Q7ZmFpciZxdW90OyBpbiB0aGUgcHJldmlvdXMgbWVzc2FnZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgNDozNSBQTSBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkl0IG1heSB3ZWxsIGJlIGR1ZSB0byBteSBvd24gaW50ZWxsZWN0dWFsIHNob3J0Y29t aW5ncyBidXQgdGhlc2UgaXNzdWVzL3F1ZXN0aW9ucy9jb25mdXNpb24tcG9pbnRzIGFyZSBub3Qg cmVzb25hdGluZyBmb3IgbWUgYXMgYmVpbmcgcHJvYmxlbWF0aWMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgbW9yZSBnZW5lcmFs IHN0YW5jZSBvZiAmcXVvdDt0aGlzIGlzbid0IG5lZWRlZCBvciB3b3J0aCBpdCBpbiB0aGlzIGRv Y3VtZW50JnF1b3Q7IChJIHRoaW5rIHRoYXQncyBmYXI/KSBpcyBiZWluZyBoZWFyZCB0aG91Z2gu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDUsIDIwMTkgYXQgMTo0MiBQTSBS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLi4uLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1j b2xvcjpjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIw NCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oVEw7RFI6IHB1 bnQgQVMgbWV0YWRhdGEgdG8gYSBzZXBhcmF0ZSBkcmFmdCk8YnI+DQo8YnI+DQpBUyBwb2ludHMg IzEtMyBhcmUgYWxsIHF1ZXN0aW9ucyBJIHdvdWxkIGhhdmUgYXMgYW4gaW1wbGVtZW50ZXI6PG86 cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJnbWFpbC1t LTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3 OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1 MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAw Z21haWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFp bC1tMjE5NjUzMjU0MzEiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv b2xzLmlldGYub3JnX2h0bWxfcmZjODQxNC0yM3NlY3Rpb24tMkQyJmFtcDtkPUR3TUZhUSZhbXA7 Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3Vzls MWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZhbXA7cz1nZkw3ZVBBUG9KTmxZWEF1VzF4 ZmNyWkwwTWtnaWJ1bnlWZ0lVcmhHT0dnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24N CiAyIG9mIFJGQzg0MTQ8L2E+IHNheXMgdG9rZW5fZW5kcG9pbnQg4oCcaXMgUkVRVUlSRUQgdW5s ZXNzIG9ubHkgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgaXMgc3VwcG9ydGVkLuKAnSBTbyB3aGF0 IGRvZXMgdGhlIG1UTFMtb25seSBBUyBwdXQgaGVyZT8NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUw Z21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5 OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5 Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMz MTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8x Ij4NClRoZSBjbGFpbXMgZm9yIHRoZXNlIG90aGVyIGVuZHBvaW50cyBhcmUgT1BUSU9OQUwsIHBv dGVudGlhbGx5IGxlYWRpbmcgdG8gaW5jb25zaXN0ZW5jeSBkZXBlbmRpbmcgb24gaG93ICMxIGdl dHMgZGVjaWRlZC4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMy MzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0 MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUwOTMzMmdtYWls LW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4 NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMy NTQzMSIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NClRoZSBleGFtcGxlIHVzYWdl IG9mIHRoZSB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgcHJvcGVydHkgZ2l2ZW4gZWFybGll ciBpcyBpbmNvbXBhdGlibGUgd2l0aCBSRkM4NDE0LCBzaW5jZSBzb21lIG9mIGl0cyBjb250ZW50 cyBhcmUgb25seSB2YWxpZCBmb3IgdGhlIG5vbi1tVExTIGVuZHBvaW50cywgYW5kIG90aGVycyBh cmUgb25seSB2YWxpZCBmb3IgdGhlIG1UTFMgZW5kcG9pbnRzLiBIZW5jZSB0aGlzIHF1ZXN0aW9u Lg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4 Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFp bC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2 OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3 OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxIiBzdHls ZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPg0KVGhpcyBpbnRyb2R1Y2VzIGEgbmV3IG1ldGFk YXRhIHByb3BlcnR5IHRoYXQgY291bGQgaW1wYWN0IGhvdyBvdGhlciBzcGVjcyBzaG91bGQgZXh0 ZW5kIEFTIG1ldGFkYXRhLiBUaGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4NCjxvOnA+PC9vOnA+ PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBjb3VsZCBnbyBvbiBmb3IgY2xpZW50IHBvaW50cyBi dXQgeW91IGFscmVhZHkgZ2V0IHRoZSBwb2ludC4gVGhvdWdoIEnigJlsbCBzaGFyZSB0aGF0ICMz IGlzIHJlYWwgYW5kIG9uY2UgZm9yY2VkIG1lIHRvIHJvbGwgYmFjayBhbiB1cGRhdGUgdG8gdGhl IExvZ2luIHdpdGggQW1hem9uIHVzZXJpbmZvIGVuZHBvaW504oCmZ29vZA0KIHRpbWVzLiA8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPiYjMTI4 NTE1Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9u4oCZdCBuZWNlc3Nh cmlseSB0aGluayBhbiBBUyBtZXRhZGF0YSBwcm9wZXJ0eSBpcyB3cm9uZyBwZXIgc2UsIGJ1dCB1 bmRlcnN0YW5kIHRoYXQgeW914oCZcmUgYm9sdGluZyBhIGxheWVyIG9mIGZsZXhpYmlsaXR5IG9u dG8gYSBzdGFuZGFyZCB0aGF0IHdhc27igJl0IGRlc2lnbmVkIGZvciB0aGF0LCBhbmQgSQ0KIGRv buKAmXQgdGhpbmsgdGhlIG1ldGFkYXRhIHByb3Bvc2FsIGFzIGl04oCZcyBiZWVuIGRpc2N1c3Nl ZCBoZXJlIHN1ZmZpY2llbnRseSBkZWFscyB3aXRoIHRoZSBmYWxsb3V0IGZyb20gdGhhdC4gSW4g bXkgdmlldyB0aGlzIGlzIGEgY29tcGxleCBlbm91Z2ggaXNzdWUgYW5kIGl04oCZcyBmb3IgYSBu dWFuY2VkIGVub3VnaCB1c2UgY2FzZSAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgZnJvbSBkaXNjdXNz aW9uPyBQbGVhc2UgY29ycmVjdCBtZSBpZiBJ4oCZbSB3cm9uZykNCiB0aGF0IHdlIHNob3VsZCBw dW50IGl0IHRvIGEgc2VwYXJhdGUgZHJhZnQgKGUuZy4sIOKAnEF1dGhvcml6YXRpb24gU2VydmVy IE1ldGFkYXRhIEV4dGVuc2lvbnMgZm9yIG1UTFMgSHlicmlkc+KAnSkgYW5kIGdldCBtVExTIG91 dCB0aGUgZG9vci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bh bj48L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGgg Jmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1w YmVsbCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkg YXQgNToyOCBBTTxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUmcXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogTVRMUyBhbmQg aW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaG9zZSBwb2ludHMgb2YgY29uZnVzaW9uIHN0cmlrZSBt ZSBhcyBzb21ld2hhdCBoeXBvdGhldGljYWwgb3IgaHlwZXJib2xpYy4gQnV0IHlvdXIgZ2VuZXJh bCBwb2ludCBpcyB0YWtlbiBhbmQgeW91ciBwb3NpdGlvbiBvZiBiZWluZyBhbnRpIGFkZGl0aW9u YWwgbWV0YWRhdGEgb24gdGhpcyBpc3N1ZSBpcw0KIG5vdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxsIG9mIHdoaWNoIGxlYXZl cyBtZSBhIGJpdCB1bmNlcnRhaW4gYWJvdXQgaG93IHRvIHByb2NlZWQuIFRoZXJlIHNlZW0gdG8g YmUgYSByYW5nZSBvZiBvcGluaW9ucyBvbiB0aGlzIHBvaW50IGFuZCBnYXVnaW5nIGNvbnNlbnN1 cyBpcyBwcm92aW5nIGVsdXNpdmUgZm9yIG1lLiBUaGF0J3MgY29uZm91bmRlZA0KIGJ5IG15IG93 biBvcGluaW9uIG9uIGl0IGJlaW5nIHNvbWV3aGF0IGZsdWlkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIEknZCByZWFsbHkgbGlr ZSB0byBwb3N0IGFuIHVwZGF0ZSB0byB0aGlzIGRyYWZ0IGFib3V0IGEgbW9udGggb3IgdHdvIGFn by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBG ZWIgMSwgMjAxOSBhdCA1OjAzIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNo YW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYuLi4ub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvcgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGNvbG9yCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj dXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkNvbmZ1c2lvbiBmcm9tIHRoZSBBU+KAmXMgcGVyc3BlY3RpdmU6PG86cD48 L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTI5 MTk5NTgzMjM5MTcyMTI0MDhnbWFpbC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3 MTc3NDAyNDM0ODY4N2dtYWlsLW0tNDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkz MzJnbWFpbC1tNjQxMzQ3NTY5OTczOTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21h aWwtbTYwODQzMTQ4MDU0OTc5NDk3MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1t MjE5NjUzMjU0MzEiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQpJZiBJIG9ubHkg c3VwcG9ydCBtVExTLCBkbyBJIG5lZWQgdG8gaW5jbHVkZSBib3RoIHRva2VuX2VuZHBvaW50X3Vy aSBhbmQgbXRsc19lbmRwb2ludHM/IFNob3VsZCBJIG9taXQgdG9rZW5fZW5kcG9pbnRfdXJpPyBP ciBzZXQgaXQgdG8gdGhlIGVtcHR5IHN0cmluZz8NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21h aWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMy ODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3 OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0 NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1zby1saXN0OmwzIGxldmVsMSBsZm8yIj4N CldoYXQgaWYgSSBvbmx5IHN1cHBvcnQgbVRMUyBmb3IgdGhlIHRva2VuIGVuZHBvaW50LCBidXQg bm90IHJldm9jYXRpb24gb3IgdXNlciBpbmZvPw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i Z21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFp bC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4 ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5 NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0 NTA5Z21haWwtbTIxOTY1MzI1NDMxIiBzdHlsZT0ibXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIiPg0K SG93IGRvIEkgc3BlY2lmeSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGZvciB0aGUgbVRMUyB0b2tl biBlbmRwb2ludD8gRG9lcyB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHMgYXBwbHkgdG8gYm90 aCB0aGUgbVRMUyBhbmQgbm9uLW1UTFMgZW5kcG9pbnRzPw0KPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iZ21haWwtbS0yOTE5OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQw NTBnbWFpbC1tLTkwNzk3NzE3NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBt MTk5MzI4ODEzNzA4NTA5MzMyZ21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5 NjkzNzc5NzYyMjMwMGdtYWlsLW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjEx MzMxODQ0NTA5Z21haWwtbTIxOTY1MzI1NDMxIiBzdHlsZT0ibXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzIiPg0KSeKAmW0gdXNpbmcgdGhlIE9BdXRoIDIuMCBEZXZpY2UgRmxvdy4gRG8gSSBpbmNsdWRl IGEgbVRMUy1lbmFibGVkIGRldmljZV9hdXRob3JpemF0aW9uX2VuZHBvaW50IHVuZGVyIG10bHNf ZW5kcG9pbnRzPw0KPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db25mdXNpb24g ZnJvbSB0aGUgY2xpZW504oCZcyBwZXJzcGVjdGl2ZTo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFy dD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdt YWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwt bS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5 NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0 OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5bGU9 Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkFzIGZhciBhcyBJIGtub3csIEnigJltIGEgcHVi bGljIGNsaWVudCwgYW5kIGRvbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBtVExTLCBidXQgdGhl IElUIGFkbWlucyBpbnN0YWxsZWQgY2xpZW50IGNlcnRzIGluIHRoZWlyIHVzZXJz4oCZIGJyb3dz ZXJzIGFuZCB0aGUgQVMgZXhwZWN0cyB0byB1c2UgdGhhdCB0byBhdXRoZW50aWNhdGUgbWUuDQo8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tLTI5MTk5NTgzMjM5MTcyMTI0MDhnbWFp bC1tODQ2MzU3MjExNDIxNDYxNDA1MGdtYWlsLW0tOTA3OTc3MTc3NDAyNDM0ODY4N2dtYWlsLW0t NDA3NTY3NjAzNzE0NTc2Mzg4MG0xOTkzMjg4MTM3MDg1MDkzMzJnbWFpbC1tNjQxMzQ3NTY5OTcz OTA1Nzc5NWdtYWlsLW0yMDMzMTk2OTM3Nzk3NjIyMzAwZ21haWwtbTYwODQzMTQ4MDU0OTc5NDk3 MjJnbWFpbC1tLTIzODY1NjE2MTEzMzE4NDQ1MDlnbWFpbC1tMjE5NjUzMjU0MzEiIHN0eWxlPSJt c28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpNeSBBUyBtZXRhZGF0YSBwYXJzZXIgY3Jhc2hlZCBi ZWNhdXNlIHRoZSBtVExTLW9ubHkgQVMgb21pdHRlZCB0b2tlbl9lbmRwb2ludF91cmkuLi4NCjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIxMjQwOGdtYWls LW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3Z21haWwtbS00 MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEzNDc1Njk5NzM5 MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgwNTQ5Nzk0OTcy MmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSIgc3R5bGU9Im1z by1saXN0OmwxIGxldmVsMSBsZm8zIj4NCk15IEFTIG1ldGFkYXRhIHBhcnNlciBjcmFzaGVkIGJl Y2F1c2UgaXQgZGlkbuKAmXQgZXhwZWN0IHRvIGVuY291bnRlciBhIEpTT04gb2JqZWN0IGFzIGEg cGFyYW1ldGVyIHZhbHVlLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS0yOTE5 OTU4MzIzOTE3MjEyNDA4Z21haWwtbTg0NjM1NzIxMTQyMTQ2MTQwNTBnbWFpbC1tLTkwNzk3NzE3 NzQwMjQzNDg2ODdnbWFpbC1tLTQwNzU2NzYwMzcxNDU3NjM4ODBtMTk5MzI4ODEzNzA4NTA5MzMy Z21haWwtbTY0MTM0NzU2OTk3MzkwNTc3OTVnbWFpbC1tMjAzMzE5NjkzNzc5NzYyMjMwMGdtYWls LW02MDg0MzE0ODA1NDk3OTQ5NzIyZ21haWwtbS0yMzg2NTYxNjExMzMxODQ0NTA5Z21haWwtbTIx OTY1MzI1NDMxIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KVGhlIG1UTFMtb25s eSBBUyBkaWRu4oCZdCBwcm92aWRlIGEgdmFsdWUgZm9yIG10bHNfZW5kcG9pbnRzLCB3aGF0IGRv IEkgZG8/IDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0tMjkxOTk1ODMyMzkxNzIx MjQwOGdtYWlsLW04NDYzNTcyMTE0MjE0NjE0MDUwZ21haWwtbS05MDc5NzcxNzc0MDI0MzQ4Njg3 Z21haWwtbS00MDc1Njc2MDM3MTQ1NzYzODgwbTE5OTMyODgxMzcwODUwOTMzMmdtYWlsLW02NDEz NDc1Njk5NzM5MDU3Nzk1Z21haWwtbTIwMzMxOTY5Mzc3OTc2MjIzMDBnbWFpbC1tNjA4NDMxNDgw NTQ5Nzk0OTcyMmdtYWlsLW0tMjM4NjU2MTYxMTMzMTg0NDUwOWdtYWlsLW0yMTk2NTMyNTQzMSIg c3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkkgZG9u4oCZdCBrbm93IHdoYXQgdGhh dCDigJxt4oCdIG1lYW5zLCBidXQgdGhleSB0b2xkIG1lIHRvIHVzZSBIVFRQUywgc28gSSBzaG91 bGQgdXNlIHRoZSBvbmUgd2l0aCDigJx0bHPigJ0gaW4gaXRzIG5hbWUsIHJpZ2h0Pw0KPG86cD48 L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIHlvdSBjYW4gd3JpdGUgbm9ybWF0aXZl IHRleHQgdGhhdCBhbnN3ZXJzIG1vc3Qgb2YgdGhlc2UuIEJ1dCB5b3XigJlsbCBoYXZlIHRvIGNs ZWFybHkgY292ZXIgYSBsb3Qgb2Ygc2ltaWxhci1idXQtc2xpZ2h0bHktZGlmZmVyZW50IHNjZW5h cmlvcyBhbmQgYmUgdmVyeSBleHBsaWNpdC4gQW5kIGltcGxlbWVudGVycw0KIHdpbGwgc3RpbGwg Z2V0IGl0IHdyb25nLiBUaGUgbWV0YWRhdGEgY2hhbmdlIGludHJvZHVjZXMgb3Bwb3J0dW5pdGll cyBmb3IgY29uZnVzaW9uIGFuZCBmYWlsdXJlIHRoYXQgZG8gbm90IGV4aXN0IG5vdywgYW5kIGZv cmNlcyB0aGVtIG9uIGV2ZXJ5b25lIHdobyBzdXBwb3J0cyBtVExTLiBJbiBjb250cmFzdCwgdGhl IDMwNyByZWRpcmVjdCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYW4gQVMgd2FudHMgdG8gc3VwcG9y dCBib3RoLCBhbmQgaXMgdW5hbWJpZ3VvdXMNCiBpbiBpdHMgYmVoYXZpb3IgYW5kIG1lYW5pbmcu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmlj aGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGw9PGEgaHJlZj0ibWFpbHRvOjQw cGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IEZyaWRh eSwgRmVicnVhcnkgMSwgMjAxOSBhdCAzOjE3IFBNPGJyPg0KPGI+VG86PC9iPiAmcXVvdDtSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxl dGNoQGFvbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nZmZsZXRjaEBhb2wuY29tPC9hPiZndDssIG9h dXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5v YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtVTlZFUklGSUVEIFNF TkRFUl0gUmU6IFtPQVVUSC1XR10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRo ZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgZG9lc24ndCBzZWVtIGxp a2UgdGhhdCBjb25mdXNpbmcgb3IgbGFyZ2Ugb2YgYSBjaGFuZ2UgdG8gbWUgLSBpZiB0aGUgY2xp ZW50IGlzIGRvaW5nIE1UTFMgYW5kIHRoZSBnaXZlbiBlbmRwb2ludCBpcyBwcmVzZW50IGluIGBt dGxzX2VuZHBvaW50c2AsIHRoZW4gaXQgdXNlcyB0aGF0IG9uZS4mbmJzcDsgT3RoZXJ3aXNlDQog aXQgdXNlcyB0aGUgcmVndWxhciBlbmRwb2ludC4gSXQgZ2l2ZXMgYW4gQVMgYSBsb3Qgb2YgZmxl eGliaWxpdHkgaW4gZGVwbG95bWVudCBvcHRpb25zLiBJIHBlcnNvbmFsbHkgdGhpbmsgZ2V0dGlu ZyBhIDMwNyBhcHByb2FjaCBkZXBsb3llZCBhbmQgd29ya2luZyB3b3VsZCBiZSBtb3JlIGNvbXBs aWNhdGVkIGFuZCBlcnJvciBwcm9uZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIGEgbWlub3JpdHkgdXNlIGNhc2Ug YXQgdGhlIG1vbWVudCBidXQgdGhlcmUgYXJlIGZvcmNlcyBpbiBwbGF5LCBsaWtlIHRoZSBwdXNo IGZvciBpbmNyZWFzZWQgc2VjdXJpdHkgaW4gZ2VuZXJhbCBhbmQgdG8gaGF2ZSBqYXZhc2NyaXB0 IGNsaWVudHMgdXNlIHRoZSBjb2RlIGZsb3csIHRoYXQgc3VnZ2VzdA0KIGl0IHdvbid0IGJlIHRl cnJpYmx5IHVudXN1YWwgdG8gc2VlIGFuIEFTIHRoYXQgd2FudHMgdG8gc3VwcG9ydCBNVExTIGNs aWVudHMgYW5kIGphdmFzY3JpcHQvc3BhIGNsaWVudHMgYXQgdGhlIHNhbWUgdGltZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUg cGVyc29uYWxseSB3YXZlcmVkIGJhY2sgYW5kIGZvcnRoIGluIHRoaXMgdGhyZWFkIG9uIHdoZXRo ZXIgb3Igbm90IHRvIGFkZCB0aGUgbmV3IG1ldGFkYXRhIChvciBzb21ldGhpbmcgbGlrZSBpdCku IFdpdGggbXkgcmVhc29uaW5nIGVhY2ggd2F5IGtpbmRhIGV4cGxhaW5lZCBzb21ld2hlcmUgYmFj aw0KIGluIHRoZSA0MCBvciBzbyBtZXNzYWdlcyB0aGF0IG1ha2UgdXAgdGhpcyB0aHJlYWQuJm5i c3A7IEJ1dCBpdCBzZWVtcyBsaWtlIHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhlIGdyb3VwIGhl cmUgaXMgaW4gZmF2b3Igb2YgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDEs IDIwMTkgYXQgMzoxOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmE9 PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLi4uLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRjb2xvcgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVu dGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGlzIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IHByb21pbmVudCBhbmQgY29uZnVzaW5n IGNoYW5nZSB0byBzdXBwb3J0IHdoYXQgc2VlbXMgdG8gYmUgYSBtaW5vcml0eSB1c2UgY2FzZS4g SeKAmW0gZ2V0dGluZyBhIGhlYWRhY2hlIGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhlIHRleHQgbmVl ZGVkIHRvIGNsYXJpZnkgd2hlbg0KIHRoZSBBUyBzaG91bGQgcHJvdmlkZSBgbXRsc19lbmRwb2lu dHNgIGFuZCB3aGVuIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGF0IHZlcnN1cyB1c2luZyBgdG9r ZW5fZW5kcG9pbnQuYCBXaHkgaXMgdGhlIDMwNyBzdGF0dXMgY29kZSBpbnN1ZmZpY2llbnQgdG8g Y292ZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgQVMgc3VwcG9ydHMgYm90aCBtVExTIGFuZCBu b24tbVRMUz88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48 L2I+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0 OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVs bCAmbHQ7YmNhbXBiZWxsPTxhIGhyZWY9Im1haWx0bzo0MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIwMTkgYXQg MTozMSBQTTxicj4NCjxiPlRvOjwvYj4gR2VvcmdlIEZsZXRjaGVyICZsdDtnZmZsZXRjaD08YSBo cmVmPSJtYWlsdG86NDBhb2wuY29tQGRtYXJjLi4uLi4uLi4uLi4uaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g b2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gTVRMUyBhbmQgaW4tYnJvd3NlciBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlllcywgdGhhdCB3b3VsZCB3b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDEsIDIwMTkgYXQgMjoyOCBQ TSBHZW9yZ2UgRmxldGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21A ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFvbC5jb21AZG1hcmMuaWV0Zi4ub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xv cgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY3VycmVudGNvbG9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjdXJyZW50Y29sb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+V2hh dCBpZiB0aGUgQVMgd2FudHMgdG8gT05MWSBzdXBwb3J0IE1UTFMgY29ubmVjdGlvbnMuIERvZXMg aXQgbm90IHNwZWNpZnkgdGhlIG9wdGlvbmFsICZxdW90O210bHNfZW5kcG9pbnRzJnF1b3Q7IGFu ZCBqdXN0IHVzZSB0aGUgbm9ybWFsIG1ldGFkYXRhIHZhbHVlcz88L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxLzE1LzE5IDg6NDggQU0sIEJy aWFuIENhbXBiZWxsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgd291bGQgZGVmaW5pdGVseSBiZSBv cHRpb25hbCwgYXBvbG9naWVzIGlmIHRoYXQgd2Fzbid0IG1hZGUgY2xlYXIuLiBJdCdkIGJlIHNv bWV0aGluZyB0byB0aGUgZWZmZWN0IG9mIG9wdGlvbmFsIGZvciB0aGUgQVMgdG8gaW5jbHVkZSBh bmQgY2xpZW50cyBkb2luZyBNVExTIHdvdWxkIHVzZSBpdCB3aGVuDQogcHJlc2VudCBpbiBBUyBt ZXRhZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBUdWUsIEphbiAxNSwgMjAxOSBhdCAyOjA0IEFNIERhdmUgVG9uZ2UgJmx0OzxhIGhyZWY9 Im1haWx0bzpkYXZlLnRvbmdlQG1vbWVudHVtZnQuY28udWsiIHRhcmdldD0iX2JsYW5rIj5kYXZl LnRvbmdlQG1vbWVudHVtZnQuY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMt c2VyaWYiPkknbSBpbiBmYXZvdXIgb2YgdGhlIGBtdGxzX2VuZHBvaW50c2AgbWV0YWRhdGEgcGFy YW1ldGVyIC0gYWx0aG91Z2ggaXQgc2hvdWxkIGJlIG9wdGlvbmFsLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4mbmJzcDsgSWYgeW91IGhhdmUNCiByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X29hdXRoJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN VUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmYW1wO209eGVIZllNQ2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZh bXA7cz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5P VElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQg bWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uDQogaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVu dHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4m bmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uDQogaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVy LiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uDQogaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9pPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjxpPkNPTkZJREVOVElB TElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2 aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhl cnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluDQogZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0 YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uDQogaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5k IGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNv bXB1dGVyLiBUaGFuayB5b3UuPC9pPjwvYj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3TUZh USZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDty PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllN Q2F3VzlsMWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZhbXA7cz1nQ2M5dEpMVnV1SzdD WFVnekFfMTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YnI+DQo8Yj48aT5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu Jm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbg0KIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uDQogaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZhbXA7ZD1Ed01GYVEmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVG VnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXhlSGZZTUNhd1c5 bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmYW1wO3M9Z0NjOXRKTFZ1dUs3Q1hVZ3pB XzE5ZkVUX1c2OVN5VnZMcHBrOWRUdVhxQSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0IDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuLmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fb2F1dGgmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZhbXA7bT14ZUhmWU1DYXdXOWwxaE9IcnFLdHdJeGhJMS1ZdmJPa2lnczdxTHdQ SnhjJmFtcDtzPWdDYzl0SkxWdXVLN0NYVWd6QV8xOWZFVF9XNjlTeVZ2THBwazlkVHVYcUEmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC4u Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0 aCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkxLVl2Yk9raWdzN3FMd1BKeGMmYW1wO3M9 Z0NjOXRKTFZ1dUs3Q1hVZ3pBXzE5ZkVUX1c2OVN5VnZMcHBrOWRUdVhxQSZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3TUZhUSZhbXA7 Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3Vzls MWhPSHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZhbXA7cz1nQ2M5dEpMVnV1SzdDWFVnekFf MTlmRVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZQ0KIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg Y29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERw Y3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXhlSGZZTUNhd1c5bDFoT0hycUt0d0l4aEkx LVl2Yk9raWdzN3FMd1BKeGMmYW1wO3M9Z0NjOXRKTFZ1dUs3Q1hVZ3pBXzE5ZkVUX1c2OVN5VnZM cHBrOWRUdVhxQSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3TUZhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJU V21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209eGVIZllNQ2F3VzlsMWhP SHJxS3R3SXhoSTEtWXZiT2tpZ3M3cUx3UEp4YyZhbXA7cz1nQ2M5dEpMVnV1SzdDWFVnekFfMTlm RVRfVzY5U3lWdkxwcGs5ZFR1WHFBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_10A7B95ED7AD4BEDAABDA05F8C9ABFD8amazoncom_-- From nobody Mon Feb 18 15:43:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB051310E0 for ; Mon, 18 Feb 2019 15:43:06 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=reminetworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go3g97-z6nF2 for ; Mon, 18 Feb 2019 15:43:04 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C761310E3 for ; Mon, 18 Feb 2019 15:43:04 -0800 (PST) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 50A7E217487 for ; Mon, 18 Feb 2019 16:27:42 -0700 (MST) Received: from host125.hostmonster.com ([74.220.207.125]) by cmsmtp with ESMTP id vsK6gsbr5szDUvsK6gBBT6; Mon, 18 Feb 2019 16:27:42 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fdP5bZjRlzMSHZO7yLc0huEyZfcQxHS3CKcD4UHGS9g=; b=ogcphjjD9CuVtXt3pxKlz6bcWx pm0d5lMsXTgBSyBKmcHQlEYB2hpogW2SbhJMji54EA3PRhOHp/onJV5aRAeUFRmkJE3rrTzfFozi9 liI2LJGZUXuW+SkH76VwA8M/L; Received: from 162-206-229-38.lightspeed.tukrga.sbcglobal.net ([162.206.229.38]:62138 helo=DESKTOPLIOIB6R) by host125.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gvsK5-000f8G-Q1 for oauth@ietf.org; Mon, 18 Feb 2019 16:27:41 -0700 From: To: References: In-Reply-To: Date: Mon, 18 Feb 2019 18:27:41 -0500 Message-ID: <03b201d4c7e1$8bed9800$a3c8c800$@reminetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQErWirTTUl8AHe6BiEtuDEL7H69zKc5Drpw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host125.hostmonster.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - reminetworks.com X-BWhitelist: no X-Source-IP: 162.206.229.38 X-Source-L: No X-Exim-ID: 1gvsK5-000f8G-Q1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 162-206-229-38.lightspeed.tukrga.sbcglobal.net (DESKTOPLIOIB6R) [162.206.229.38]:62138 X-Source-Auth: donald.coffin@reminetworks.com X-Email-Count: 1 X-Source-Cap: cmVtaW5ldHc7cmVtaW5ldHc7aG9zdDEyNS5ob3N0bW9uc3Rlci5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 124, Issue 61 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 23:43:10 -0000 +1 Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Xing #E Dunwoody, GA 30338-8221 Phone:=A0=A0=A0=A0=A0 (949) 636-8571 Email:=A0=A0=A0=A0=A0=A0 donald.coffin@reminetworks.com -----Original Message----- From: OAuth On Behalf Of oauth-request@ietf.org Sent: February 18, 2019 04:55 PM To: oauth@ietf.org Subject: OAuth Digest, Vol 124, Issue 61 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." From nobody Tue Feb 19 10:47:58 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9591D1277CC; Tue, 19 Feb 2019 10:47:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155060207758.20788.4713378113655815391@ietfa.amsl.com> Date: Tue, 19 Feb 2019 10:47:57 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 18:47:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-02.txt Pages : 11 Date : 2019-02-19 Abstract: This draft proposes an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 19 13:00:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1B128701 for ; Tue, 19 Feb 2019 13:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5_SFglx7naO for ; Tue, 19 Feb 2019 13:00:29 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA1D12426E for ; Tue, 19 Feb 2019 13:00:29 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id l15so9787188iti.4 for ; Tue, 19 Feb 2019 13:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OzgqgPiTO6qaT28Xtquf/M/IXhDI/F4HsQ9Tgw9eoGg=; b=J4dR0n0j26hePDE0+DVYDtUgFtNa84eznI7h7qYzoNsiYHvsRaou6akyK2A4Zvl1ik dk0TweFZLIgXThU3iF56kRpIGctkZJAJWmBdeGCgrSIoJ6tWC/Q9UT/C/iVsaoZ06YNN xVawjXlxGFWW06G6OjU+8fGTjggbWwv2LAmEQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OzgqgPiTO6qaT28Xtquf/M/IXhDI/F4HsQ9Tgw9eoGg=; b=F6ac1MNM2kyUGzHR/TxqZp8HjVFzGunjsLCoE9FBNHAMLKEQKHDgm/QQnaDzLMPDcq RxNDPSXNl1oSSV+JTKAppQKDf1g9YEoFSp7bvRY2qizA6r2uRZEGnpQNZG3hO7ve2DGY eKLavKHu3C8LPP0qCsw9uAlfpt7U+cTeuWmokiqqmstb8XwegPLOxvNa3Avw9Lk1wCeC OWmvAXcoBvxSMiKn8kOhbrGfvY3YlmmDbLnidZHnucOTtgYjO1iw7PASlcg7mvq1d31P XK1vXDNyMe3y8i6FQOjQwWH72koQkqWSrfikidZYWq/fIKxSfAPjPOV8Casl+wPUWNyk PAOg== X-Gm-Message-State: AHQUAub2Z+okwgJhqbBRN/D3OnqY+rb23+1TnPTcMx5+DGQhWoepe+Af etrOoE6qAlqfLjSGu+kWxWzYASF8ViQCfw57qDwXgygQ+CxHIsRkriA/rQX4MkYF8SDmICct3t0 6JDM/QFGz2oZ+fA== X-Google-Smtp-Source: AHgI3IaSHfo7S3GEwQoDz414gg45bPukXy3vwYMNFMW5gosHcR3UP9XJSBM+bT1NLK+TnMKEmd5V4lwX7X381xIWW0o= X-Received: by 2002:a6b:b408:: with SMTP id d8mr15600467iof.138.1550610028293; Tue, 19 Feb 2019 13:00:28 -0800 (PST) MIME-Version: 1.0 References: <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com> In-Reply-To: <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com> From: Brian Campbell Date: Tue, 19 Feb 2019 14:00:02 -0700 Message-ID: To: Neil Madden Cc: George Fletcher , oauth Content-Type: multipart/alternative; boundary="000000000000ec27bf0582458729" Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 21:00:32 -0000 --000000000000ec27bf0582458729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the upcoming revision of the draft I've reworked and moved that section [1] so that it is more focused on public clients and certificate bound tokens (see [a]). But yes, I think it comes down to saying that a client that is expecting to use MTLS (for whatever reason: bound tokens or client auth or both) for something would use the mtls-specific endpoint when making the request (or the regular endpoint, if no mtls-specific endpoint is present). And yeah the AS would accept other client auth methods (including none for public clients) at the mtls token endpoint. Maybe a hundred messages back in this whole thread, at one point anyway, I used the word alias for the endpoint to try and capture the idea that it would most likely be the same application logic and the mtls endpoint would just be on a different host/port to allow the TLS layer to be set up differently for the different context. Maybe that name and/or idea should resurface? [a] https://github.com/ietf-oauth-mtls/i-d/commit/d1c1db18e62db2cf7665f69d3162a= 391ba1aa03c On Fri, Feb 15, 2019 at 1:33 PM Neil Madden wrote: > As another case - if the client wants certificate-bound access tokens but > still authenticates with client_secret_basic or is a public client (as pe= r > [1]), presumably it can use the mtls-specific endpoints and assume they > support all the other authentication methods as the normal endpoints? > > But so long as we can define some half-sensible behaviour for these cases= , > I=E2=80=99m happy with this proposal. > > [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-12#section-4.3 > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ec27bf0582458729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the upcoming revision of the draf= t I've reworked and moved that=20 section [1] so that it is more focused on public clients and certificate bound tokens (see [a]). But yes, I think it comes down to saying that a client that is expecting to use MTLS (for whatever reason: bound tokens or client auth or both) for something would use the mtls-specific=20 endpoint when making the request (or the regular endpoint, if no=20 mtls-specific endpoint is present).=C2=A0 And yeah the AS would accept othe= r=20 client auth methods (including none for public clients) at the mtls=20 token endpoint. Maybe a hundred messages back in this whole thread, at=20 one point anyway, I used the word alias for the endpoint to try and=20 capture the idea that it would most likely be the same application logic and the mtls endpoint would just be on a different host/port to allow=20 the TLS layer to be set up differently for the different context. Maybe=20 that name and/or idea should resurface?

[a] <= a href=3D"https://github.com/ietf-oauth-mtls/i-d/commit/d1c1db18e62db2cf766= 5f69d3162a391ba1aa03c" target=3D"_blank">https://github.com/ietf-oauth-mtls= /i-d/commit/d1c1db18e62db2cf7665f69d3162a391ba1aa03c

On Fri, Feb 1= 5, 2019 at 1:33 PM Neil Madden <neil.madden@forgerock.com> wrote:
As another case - if the client wants certificate-bound access= tokens but still authenticates with client_secret_basic or is a public cli= ent (as per [1]), presumably it can use the mtls-specific endpoints and ass= ume they support all the other authentication methods as the normal endpoin= ts?

But so long as we can = define some half-sensible behaviour for these cases, I=E2=80=99m happy with= this proposal.=C2=A0



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ec27bf0582458729-- From nobody Wed Feb 20 07:11:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0812E036 for ; Wed, 20 Feb 2019 07:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YI62nfX5hg3 for ; Wed, 20 Feb 2019 07:10:57 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAA7127AC2 for ; Wed, 20 Feb 2019 07:10:57 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id z124so16253822itc.2 for ; Wed, 20 Feb 2019 07:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:cc; bh=32IC2eVBUvcFAkQzEU689VayOau+tCHQvLSfnBH8Yok=; b=SopqlrjNg/or1evRdth66X8Ant9elvxZ5AeRD3ubBUfUteT9ruTCpFPS3wWL1C5Z21 fwm/AxTVtNneeDWgqpFjySMpSCQRJY56z0JLNESPOAy7bKeAG+On4MXeUi0RdOW2dTyb iD30WCGB91ka8bRw2LAgeOvDJdxes4/OoFtvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:cc; bh=32IC2eVBUvcFAkQzEU689VayOau+tCHQvLSfnBH8Yok=; b=ECz/jOsFTPY3TmI8t+T/ltlnSklX4cd4kBQXk59ok9uo73d7LCWEGSsm45hc8Gim7d XzQ559hKNevyz2P3eVIxOHKEkXHU6wOyjZ0rv0hcu7dC/DHioXTZSmjL8t096VMf3FnA d8mjE113NF6M1ENDXlEK1KXhNdB9xIk2fpc4FxL83QmhE3VkaFwhZuI/E1Dl5stgDGZt OgRebLe4ctVLiaEPfDeNePJ/ps6U+jPaAPG3Y3sHN+v5kSLgvmA9oyngcdAC2EVPCFWo 9SA26NDLWs4PHUqpSDNyZRMe5rjpdXkxL8ePINWXPGOYg4VM4TKGfQ0wbWZGfgCbUuBa MD9A== X-Gm-Message-State: AHQUAuYNxlE82ncntTlzjDPBhQW4Y8Lj1E7HYKOioPKw+xfwZpd+zyLQ BEOu7bjvmjB7MMNKMxXzyP9AUUgYK0kuwFw73qCYdrt7FGmjkJok4eIClGzn9MmQ1Ylw/klbMpG 1Ynh2auU5vo8VqvfFEEo= X-Google-Smtp-Source: AHgI3IbACDYjYGKWfSRblxXFo1EEk+AycRAT5lTvQod+8+ib8owsLTyB6f05j0AtXDfjDoY4QFa2scDeEcPn4tmSjSQ= X-Received: by 2002:a02:c893:: with SMTP id m19mr20018137jao.28.1550675455758; Wed, 20 Feb 2019 07:10:55 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Wed, 20 Feb 2019 08:10:28 -0700 Message-ID: Cc: oauth Content-Type: multipart/alternative; boundary="000000000000b3fc0e058254c3ad" Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:11:01 -0000 --000000000000b3fc0e058254c3ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS. In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use. I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-technolo= gy-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00. Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ. It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case), opinions can differ about what actually constitutes simplicity. It seems that's where we are now. My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals. On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle wrote: > Neil=E2=80=99s example demonstrates how the mtls_endpoints approach leads= to > confusion. Consider the following metadata fragment: > > > > { > > =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/token= =E2=80=9D, > > =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclien= t_secret_basic=E2=80=9D, > =E2=80=9Ctls_client_auth=E2=80=9D ], > > =E2=80=9Cmtls_endpoints=E2=80=9D: { > > =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/= token=E2=80=9D > > } > > } > > > > Which of these statements about endpoints on https://as.example.com/ are > true? > > 1. The /token endpoint only supports client_secret_basic, and > /mtls/token only supports tls_client_auth. > 2. The /token endpoint supports both methods, and /mtls/token only > supports tls_client_auth. > 3. Both /token and /mtls/token support both methods. > > > > All of these could be reasonable interpretations of this metadata. When > properties mean different things in different contexts, ambiguity abounds= . > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b3fc0e058254c3ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The objective is to allow the AS to provide MTLS n= egotiating endpoints on a different host and/or port so that any non-desira= ble side effects of requesting client certificates during the TLS handshake= can be avoided for 'regular' clients that are not doing any MTLS. =

In all likelihood, I'd expect that any pa= ir of MTLS and regular endpoints have the same application logic behind the= m. And that just the TLS setup that differs to accommodate the aforemention= ed objective. That means that they'd support the same client authentica= tion methods but the MTLS endpoint would just be set up so as to get MTLS t= o work. When first considering it, that seemed a bit overreaching for the s= pec to come out and say and more of a deployment thing for the AS. But mayb= e being more prescriptive would reduce some of the professed problematic am= biguity. As mentioned in a previous message, referring to the mtls endpoint= s as aliases might be useful in indicating that they are the same endpoint = that is just known and accessed differently based on the context of use.=C2= =A0

I'll grant that so= me of the wording in RFC 8414 can be awkward with respect to this kind of e= xtension. Calling it a violation is a bit over the top though. And as much = as we might try to write specs that are the final word, there's the rea= lities of how usage and understanding unfold in practice. As one example, t= here's some discussion of the treatment of some of the metadata in this= =C2=A0 section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-te= chnology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.=C2=A0 M= aybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's bei= ng pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these=20 specifications is kinda hard. Even when people share the same objective=20 (and that's often not even the case), opinions can differ about what=20 actually constitutes simplicity. It seems that's where we are now.
=

My stance as an individual is that th= e mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and prag= matic and the most straightforward and simple of the options put forth (i.e= . vs a metadata parameter linking to or well-known locations to completely = separate metadata documents). As an editor, I acknowledge that there's = been disagreement about it while also noting again that the dissenting voic= es come from a vocal minority of a few individuals.

=C2=A0


On Mon, Feb 18, 2019 at = 2:55 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

Neil=E2=80=99s example demonstrates how the mtls_end= points approach leads to confusion. Consider the following metadata fragmen= t:

=C2=A0

{

=C2=A0 =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example= .com/token=E2=80=9D,

=E2=80=9Ctoken_endpoint= _auth_methods_supported=E2=80=9D: [ =E2=80=9Cclient_secret_basic=E2=80=9D, = =E2=80=9Ctls_client_auth=E2=80=9D ],

=E2=80=9Cmtls_endpoints= =E2=80=9D: {

=C2=A0 =E2=80=9Ctoken_e= ndpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/token=E2=80=9D

}

}

=C2=A0

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token e= ndpoint only supports client_secret_basic, and /mtls/token only supports tl= s_client_auth.
  2. The /token endpoint supports both methods, and /mtls/t= oken only supports tls_client_auth.
  3. Both /token and /mtls/token suppo= rt both methods.

=C2=A0

All of these could be reasonable interpretations of = this metadata. When properties mean different things in different contexts,= ambiguity abounds.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000b3fc0e058254c3ad-- From nobody Wed Feb 20 07:53:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD65130DD3 for ; Wed, 20 Feb 2019 07:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzhj6wbF4Zjy for ; Wed, 20 Feb 2019 07:53:04 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24BB127AC2 for ; Wed, 20 Feb 2019 07:53:03 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1KFiIgw046244; Wed, 20 Feb 2019 15:53:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=L4MfEG58Lij/Nynl9EdNy52C5B9kclUDdqLEzJ4I5C4=; b=g1sw2OHm9qTJRQyTBrFdv63JYaWh1SUCIoGwmXprSKetkh3aF27R23fxeOlX9SDq3xII Lvtid0VE0ZSiv1iWTflfUnBN3DEiba2Js5FuIfN1UFwFRdvFvLK8v1E90+WpKkBd8w1p hyhm2w0p9BgBzSWab4IlOWyMfdpCNMcNO87liQ9/4h5cuxVuwdiegJg4R96EHhB2Y2LE 2oAobtIrvEW3udRSq60oQL7Qo2Z8+W8E+Nf849TdgGNm1AG1Y7AgTKdq4kgJmBNi3FZa yEVGnmB+XAULIr4fGD/IVsfFBMRep7/jKybna1Fiev32DazcIbVSONGkllsmtFTw8QKL Wg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2qp81eakp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Feb 2019 15:53:01 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1KFr1hs013150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Feb 2019 15:53:01 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1KFr1FI009073; Wed, 20 Feb 2019 15:53:01 GMT Received: from [10.228.234.234] (/24.244.23.196) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2019 07:53:00 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-B9F8CDCD-61EF-495A-8F0B-39467106C4E5 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Wed, 20 Feb 2019 07:52:59 -0800 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: <978D1C5E-7303-46EA-B66B-A2E33B1B7B28@oracle.com> References: To: Brian Campbell X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9173 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902200113 Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:53:06 -0000 --Apple-Mail-B9F8CDCD-61EF-495A-8F0B-39467106C4E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to Brian=E2=80=99s recommendations.=20 The recommendations provide practical help especially to facilitate real wor= ld migration where bearer and non-bearer must co-exist without confusing end= users. Phil > On Feb 20, 2019, at 7:10 AM, Brian Campbell wrote: >=20 > The objective is to allow the AS to provide MTLS negotiating endpoints on a= different host and/or port so that any non-desirable side effects of reques= ting client certificates during the TLS handshake can be avoided for 'regula= r' clients that are not doing any MTLS.=20 >=20 > In all likelihood, I'd expect that any pair of MTLS and regular endpoints h= ave the same application logic behind them. And that just the TLS setup that= differs to accommodate the aforementioned objective. That means that they'd= support the same client authentication methods but the MTLS endpoint would j= ust be set up so as to get MTLS to work. When first considering it, that see= med a bit overreaching for the spec to come out and say and more of a deploy= ment thing for the AS. But maybe being more prescriptive would reduce some o= f the professed problematic ambiguity. As mentioned in a previous message, r= eferring to the mtls endpoints as aliases might be useful in indicating that= they are the same endpoint that is just known and accessed differently base= d on the context of use.=20 >=20 > I'll grant that some of the wording in RFC 8414 can be awkward with respec= t to this kind of extension. Calling it a violation is a bit over the top th= ough. And as much as we might try to write specs that are the final word, th= ere's the realities of how usage and understanding unfold in practice. As on= e example, there's some discussion of the treatment of some of the metadata i= n this section of a blog post about a different spec being developed https:= //medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2= 019-explained-by-an-implementer-d1e0ac1311b4#8a00. Maybe that's in violatio= n of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circum= stances. I suppose opinions will differ.=20 >=20 > It turns out that writing these specifications is kinda hard. Even when pe= ople share the same objective (and that's often not even the case), opinions= can differ about what actually constitutes simplicity. It seems that's wher= e we are now.=20 >=20 > My stance as an individual is that the mtls_endpoints (or mtls_endpoint_al= iases) approach is reasonable and pragmatic and the most straightforward and= simple of the options put forth (i.e.. vs a metadata parameter linking to o= r well-known locations to completely separate metadata documents). As an edi= tor, I acknowledge that there's been disagreement about it while also noting= again that the dissenting voices come from a vocal minority of a few indivi= duals.=20 >=20 > =20 >=20 >=20 >> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle wrote: >> Neil=E2=80=99s example demonstrates how the mtls_endpoints approach leads= to confusion. Consider the following metadata fragment: >>=20 >> =20 >>=20 >> { >>=20 >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..com/toke= n=E2=80=9D, >>=20 >> =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclien= t_secret_basic=E2=80=9D, =E2=80=9Ctls_client_auth=E2=80=9D ], >>=20 >> =E2=80=9Cmtls_endpoints=E2=80=9D: { >>=20 >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/= token=E2=80=9D >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> Which of these statements about endpoints on https://as.example.com/ are t= rue? >>=20 >> The /token endpoint only supports client_secret_basic, and /mtls/token on= ly supports tls_client_auth. >> The /token endpoint supports both methods, and /mtls/token only supports t= ls_client_auth. >> Both /token and /mtls/token support both methods. >> =20 >>=20 >> All of these could be reasonable interpretations of this metadata. When p= roperties mean different things in different contexts, ambiguity abounds. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >>=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&= r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DQSgiEfkL8zIrq58HrPnZs-RW= mE0KhOwmKb5vMcx3a_w&s=3D8TDp70QLsXKRqdjOL2tp_BMuebnBYHFisPg7H6XYJ8A&e=3D --Apple-Mail-B9F8CDCD-61EF-495A-8F0B-39467106C4E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to Brian=E2=80=99s recommendations. = ;

The recommendations provide practical help especially t= o facilitate real world migration where bearer and non-bearer must co-exist w= ithout confusing end users.

Phil

On Feb 20, 2019, at 7:10 AM, Brian Camp= bell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:

The objective i= s to allow the AS to provide MTLS negotiating endpoints on a different host a= nd/or port so that any non-desirable side effects of requesting client certi= ficates during the TLS handshake can be avoided for 'regular' clients that a= re not doing any MTLS.

In all likelihood, I'd e= xpect that any pair of MTLS and regular endpoints have the same application l= ogic behind them. And that just the TLS setup that differs to accommodate th= e aforementioned objective. That means that they'd support the same client a= uthentication methods but the MTLS endpoint would just be set up so as to ge= t MTLS to work. When first considering it, that seemed a bit overreaching fo= r the spec to come out and say and more of a deployment thing for the AS. Bu= t maybe being more prescriptive would reduce some of the professed problemat= ic ambiguity. As mentioned in a previous message, referring to the mtls endp= oints as aliases might be useful in indicating that they are the same endpoi= nt that is just known and accessed differently based on the context of use.&= nbsp;

I'll grant that some o= f the wording in RFC 8414 can be awkward with respect to this kind of extens= ion. Calling it a violation is a bit over the top though. And as much as we m= ight try to write specs that are the final word, there's the realities of ho= w usage and understanding unfold in practice. As one example, there's some d= iscussion of the treatment of some of the metadata in this  section of a= blog post about a different spec being developed https://mediu= m.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-exp= lained-by-an-implementer-d1e0ac1311b4#8a00.  Maybe that's in violat= ion of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circ= umstances. I suppose opinions will differ.

It turns out that wri= ting these=20 specifications is kinda hard. Even when people share the same objective=20 (and that's often not even the case), opinions can differ about what=20 actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls= _endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic a= nd the most straightforward and simple of the options put forth (i.e.. vs a m= etadata parameter linking to or well-known locations to completely separate m= etadata documents). As an editor, I acknowledge that there's been disagreeme= nt about it while also noting again that the dissenting voices come from a v= ocal minority of a few individuals.

 


On Mon, Feb 18, 2019 at 2:55 PM Richard Back= man, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Neil=E2=80=99s example demonstrates how the mtls_endp= oints approach leads to confusion. Consider the following metadata fragment:=

 

{

  =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..c= om/token=E2=80=9D,

=E2=80=9Ctoken_endpoint_= auth_methods_supported=E2=80=9D: [ =E2=80=9Cclient_secret_basic=E2=80=9D, =E2= =80=9Ctls_client_auth=E2=80=9D ],

=E2=80=9Cmtls_endpoints=E2= =80=9D: {

  =E2=80=9Ctoken_en= dpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/token=E2=80=9D

}

}

 

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token end= point only supports client_secret_basic, and /mtls/token only supports tls_c= lient_auth.
  2. The /token endpoint supports both methods, and /mtls/token o= nly supports tls_client_auth.
  3. Both /token and /mtls/token support both m= ethods.

 

All of these could be reasonable interpretations of t= his metadata. When properties mean different things in different contexts, a= mbiguity abounds.

 

-- 

Annabelle Richard Backman

AWS Identity

 



CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.
= --Apple-Mail-B9F8CDCD-61EF-495A-8F0B-39467106C4E5-- From nobody Wed Feb 20 08:59:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E8112870E for ; Wed, 20 Feb 2019 08:59:19 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bODFsqeIB0ol for ; Wed, 20 Feb 2019 08:59:16 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43692130DC4 for ; Wed, 20 Feb 2019 08:59:16 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id x7so7325777wmj.0 for ; Wed, 20 Feb 2019 08:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PMSxtmQ0KpquVs2YsiI1/GYn+E3hikv89MvAfbSKNNc=; b=FX5PXvDu/yx4R9gFmG+GKvQLhY76/3CPM1eadyON3bdm/l0kJx9ecLJe3vFRzlpHvE M+xGYV5EfSw6nX2ItmhyBezPAvl3OUHcwfoBuXMHtLYFqMG3v2P3mHz2chm+9GkNKYst qbQDIRu01QMqfvaGQeNRFXX0F2JTgj2Svxnrx+30UchynsPBLBViAL9YVHCKdZZUctus 0JfcDTQfBqFyKyttdQPecy/xZQxH4OegrKWVLZkY9FBOK/GJ8j7HqLrt///WmcjE8lGH CK69blNkI1ULDmVeGh0GhRtv7cyLBG8WYlXsCiGZUzqnrYe6nSlrxHeOpRcyGyhRF1b+ JwOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PMSxtmQ0KpquVs2YsiI1/GYn+E3hikv89MvAfbSKNNc=; b=nYlboTaDgwuE+7N6y0zMohuklhhVfFzEPHL8q+vWl3dNpU/LzeOwZvnkFPCxIaExnU guvI0I40jjeq3LkMp/zJFl7v0pn7LslFLwdgULIGNGQIH+eeeUT5sApDJ46jDX0jtz56 45X6BKE0LQ+e6VZN9UvvAWn5rFd4m0NtpK8gIVmE9F2jPQDv+Tfo64YAgqi4CohyoOTQ hVjj6S5n1Tq1xlJ8wFiYwG2AvDJvWxzxpyZQqKOEUAC2lCkJpCAMDN0LE6gXeeKLcC2j 4P26VWVGUUvDKqUCULeZ8psr+e1toINQjryyzmZ5CXPyC/st9fE84z6LqKGj5tE13S0u cYNA== X-Gm-Message-State: AHQUAuaoYBRQai2IvhOJP03gnx2y5RrYsmskhSI7z8lKOChtFx3i3mcH KagyTjwWtODSd0KSRIOOUtao0Ho= X-Google-Smtp-Source: AHgI3IbijN29Dn4+FWXdSzyxNEAXx3CcjLUB5SAUjugKiTntJyyZrrnuXJOMOyMZu8iQ+/y3gLGEvQ== X-Received: by 2002:a7b:c146:: with SMTP id z6mr2923945wmi.145.1550681953873; Wed, 20 Feb 2019 08:59:13 -0800 (PST) Received: from [192.168.0.95] (ip-78-45-222-80.net.upcbroadband.cz. [78.45.222.80]) by smtp.gmail.com with ESMTPSA id a8sm9102258wmh.26.2019.02.20.08.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 08:59:12 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-7A56EC9C-B338-4858-A507-8FF52F6D1B9C Mime-Version: 1.0 (1.0) From: Filip Skokan X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Wed, 20 Feb 2019 17:59:11 +0100 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> References: To: Brian Campbell Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:59:19 -0000 --Apple-Mail-7A56EC9C-B338-4858-A507-8FF52F6D1B9C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1, great summary Odesl=C3=A1no z iPhonu 20. 2. 2019 v 16:10, Brian Campbell : > The objective is to allow the AS to provide MTLS negotiating endpoints on a= different host and/or port so that any non-desirable side effects of reques= ting client certificates during the TLS handshake can be avoided for 'regula= r' clients that are not doing any MTLS.=20 >=20 > In all likelihood, I'd expect that any pair of MTLS and regular endpoints h= ave the same application logic behind them. And that just the TLS setup that= differs to accommodate the aforementioned objective. That means that they'd= support the same client authentication methods but the MTLS endpoint would j= ust be set up so as to get MTLS to work. When first considering it, that see= med a bit overreaching for the spec to come out and say and more of a deploy= ment thing for the AS. But maybe being more prescriptive would reduce some o= f the professed problematic ambiguity. As mentioned in a previous message, r= eferring to the mtls endpoints as aliases might be useful in indicating that= they are the same endpoint that is just known and accessed differently base= d on the context of use.=20 >=20 > I'll grant that some of the wording in RFC 8414 can be awkward with respec= t to this kind of extension. Calling it a violation is a bit over the top th= ough. And as much as we might try to write specs that are the final word, th= ere's the realities of how usage and understanding unfold in practice. As on= e example, there's some discussion of the treatment of some of the metadata i= n this section of a blog post about a different spec being developed https:= //medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2= 019-explained-by-an-implementer-d1e0ac1311b4#8a00. Maybe that's in violatio= n of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circum= stances. I suppose opinions will differ.=20 >=20 > It turns out that writing these specifications is kinda hard. Even when pe= ople share the same objective (and that's often not even the case), opinions= can differ about what actually constitutes simplicity. It seems that's wher= e we are now.=20 >=20 > My stance as an individual is that the mtls_endpoints (or mtls_endpoint_al= iases) approach is reasonable and pragmatic and the most straightforward and= simple of the options put forth (i.e.. vs a metadata parameter linking to o= r well-known locations to completely separate metadata documents). As an edi= tor, I acknowledge that there's been disagreement about it while also noting= again that the dissenting voices come from a vocal minority of a few indivi= duals.=20 >=20 > =20 >=20 >=20 >> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle wrote: >> Neil=E2=80=99s example demonstrates how the mtls_endpoints approach leads= to confusion. Consider the following metadata fragment: >>=20 >> =20 >>=20 >> { >>=20 >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..com/toke= n=E2=80=9D, >>=20 >> =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclien= t_secret_basic=E2=80=9D, =E2=80=9Ctls_client_auth=E2=80=9D ], >>=20 >> =E2=80=9Cmtls_endpoints=E2=80=9D: { >>=20 >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/= token=E2=80=9D >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> Which of these statements about endpoints on https://as.example.com/ are t= rue? >>=20 >> The /token endpoint only supports client_secret_basic, and /mtls/token on= ly supports tls_client_auth. >> The /token endpoint supports both methods, and /mtls/token only supports t= ls_client_auth. >> Both /token and /mtls/token support both methods. >> =20 >>=20 >> All of these could be reasonable interpretations of this metadata. When p= roperties mean different things in different contexts, ambiguity abounds. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >>=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-7A56EC9C-B338-4858-A507-8FF52F6D1B9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1, great summary

Odesl=C3=A1no z iPhonu
<= br>20. 2. 2019 v 16:10, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf= .org>:

The objective is to allow the AS to provide MTLS negotiating= endpoints on a different host and/or port so that any non-desirable side ef= fects of requesting client certificates during the TLS handshake can be avoi= ded for 'regular' clients that are not doing any MTLS.

In all likelihood, I'd expect that any pair of MTLS and regular end= points have the same application logic behind them. And that just the TLS se= tup that differs to accommodate the aforementioned objective. That means tha= t they'd support the same client authentication methods but the MTLS endpoin= t would just be set up so as to get MTLS to work. When first considering it,= that seemed a bit overreaching for the spec to come out and say and more of= a deployment thing for the AS. But maybe being more prescriptive would redu= ce some of the professed problematic ambiguity. As mentioned in a previous m= essage, referring to the mtls endpoints as aliases might be useful in indica= ting that they are the same endpoint that is just known and accessed differe= ntly based on the context of use. 

I'll grant that some of the wording in RFC 8414 can be awkward w= ith respect to this kind of extension. Calling it a violation is a bit over t= he top though. And as much as we might try to write specs that are the final= word, there's the realities of how usage and understanding unfold in practi= ce. As one example, there's some discussion of the treatment of some of the m= etadata in this  section of a blog post about a different spec being de= veloped https://medium.com/@darutk/ciba-a-new-authentication-author= ization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00= .  Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's bei= ng pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these=20 specifications is kinda hard. Even when people share the same objective=20 (and that's often not even the case), opinions can differ about what=20 actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls= _endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic a= nd the most straightforward and simple of the options put forth (i.e.. vs a m= etadata parameter linking to or well-known locations to completely separate m= etadata documents). As an editor, I acknowledge that there's been disagreeme= nt about it while also noting again that the dissenting voices come from a v= ocal minority of a few individuals.

 


On Mon, Feb 18, 2019 at 2:55 PM Richard Back= man, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Neil=E2=80=99s example demonstrates how the mtls_endp= oints approach leads to confusion. Consider the following metadata fragment:=

 

{

  =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..c= om/token=E2=80=9D,

=E2=80=9Ctoken_endpoint_= auth_methods_supported=E2=80=9D: [ =E2=80=9Cclient_secret_basic=E2=80=9D, =E2= =80=9Ctls_client_auth=E2=80=9D ],

=E2=80=9Cmtls_endpoints=E2= =80=9D: {

  =E2=80=9Ctoken_en= dpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/token=E2=80=9D

}

}

 

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token end= point only supports client_secret_basic, and /mtls/token only supports tls_c= lient_auth.
  2. The /token endpoint supports both methods, and /mtls/token o= nly supports tls_client_auth.
  3. Both /token and /mtls/token support both m= ethods.

 

All of these could be reasonable interpretations of t= his metadata. When properties mean different things in different contexts, a= mbiguity abounds.

 

-- 

Annabelle Richard Backman

AWS Identity

 



CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.
______________________________________________= _
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-7A56EC9C-B338-4858-A507-8FF52F6D1B9C-- From nobody Wed Feb 20 14:04:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24862129C6A for ; Wed, 20 Feb 2019 14:04: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=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpek3eTykXFz for ; Wed, 20 Feb 2019 14:04:24 -0800 (PST) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A85A12426E for ; Wed, 20 Feb 2019 14:04:24 -0800 (PST) Received: from [91.13.151.23] (helo=[192.168.71.126]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gwZyW-0000cV-Cx; Wed, 20 Feb 2019 23:04:20 +0100 Content-Type: multipart/signed; boundary=Apple-Mail-839FC754-E9DF-4E27-9BB8-25041141D2FA; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16C50) In-Reply-To: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> Date: Wed, 20 Feb 2019 23:04:19 +0100 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> References: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> To: Filip Skokan X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 22:04:29 -0000 --Apple-Mail-839FC754-E9DF-4E27-9BB8-25041141D2FA Content-Type: multipart/alternative; boundary=Apple-Mail-A6753651-687B-4751-8BDC-F29D67B58E9A Content-Transfer-Encoding: 7bit --Apple-Mail-A6753651-687B-4751-8BDC-F29D67B58E9A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 for defining an optional mtls endpoints section I first leaned towards a second metadata file, mainly due to the potential t= oken endpoint authentication method issue. But adding a secondary metadata c= onfiguration just for this purpose seems a bit over engineered and would tak= e a lot of normative language to get it right. Just as an example: does the s= econd configuration overload or replace the primary one? On the other hand, a= ny client using looking for mtls based token endpoint authentication methods= must be aware of the potential mtls endpoints section. So I think their is n= o real issue. > Am 20.02.2019 um 17:59 schrieb Filip Skokan : >=20 > +1, great summary >=20 > Odesl=C3=A1no z iPhonu >=20 > 20. 2. 2019 v 16:10, Brian Campbell : >=20 >> The objective is to allow the AS to provide MTLS negotiating endpoints on= a different host and/or port so that any non-desirable side effects of requ= esting client certificates during the TLS handshake can be avoided for 'regu= lar' clients that are not doing any MTLS.=20 >>=20 >> In all likelihood, I'd expect that any pair of MTLS and regular endpoints= have the same application logic behind them. And that just the TLS setup th= at differs to accommodate the aforementioned objective. That means that they= 'd support the same client authentication methods but the MTLS endpoint woul= d just be set up so as to get MTLS to work. When first considering it, that s= eemed a bit overreaching for the spec to come out and say and more of a depl= oyment thing for the AS. But maybe being more prescriptive would reduce some= of the professed problematic ambiguity. As mentioned in a previous message,= referring to the mtls endpoints as aliases might be useful in indicating th= at they are the same endpoint that is just known and accessed differently ba= sed on the context of use.=20 >>=20 >> I'll grant that some of the wording in RFC 8414 can be awkward with respe= ct to this kind of extension. Calling it a violation is a bit over the top t= hough. And as much as we might try to write specs that are the final word, t= here's the realities of how usage and understanding unfold in practice. As o= ne example, there's some discussion of the treatment of some of the metadata= in this section of a blog post about a different spec being developed http= s://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in= -2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. Maybe that's in viola= tion of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given cir= cumstances. I suppose opinions will differ.=20 >>=20 >> It turns out that writing these specifications is kinda hard. Even when p= eople share the same objective (and that's often not even the case), opinion= s can differ about what actually constitutes simplicity. It seems that's whe= re we are now.=20 >>=20 >> My stance as an individual is that the mtls_endpoints (or mtls_endpoint_a= liases) approach is reasonable and pragmatic and the most straightforward an= d simple of the options put forth (i.e.. vs a metadata parameter linking to o= r well-known locations to completely separate metadata documents). As an edi= tor, I acknowledge that there's been disagreement about it while also noting= again that the dissenting voices come from a vocal minority of a few indivi= duals.=20 >>=20 >> =20 >>=20 >>=20 >>> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle wrote: >>> Neil=E2=80=99s example demonstrates how the mtls_endpoints approach lead= s to confusion. Consider the following metadata fragment: >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..com/tok= en=E2=80=9D, >>>=20 >>> =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclie= nt_secret_basic=E2=80=9D, =E2=80=9Ctls_client_auth=E2=80=9D ], >>>=20 >>> =E2=80=9Cmtls_endpoints=E2=80=9D: { >>>=20 >>> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls= /token=E2=80=9D >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> Which of these statements about endpoints on https://as.example.com/ are= true? >>>=20 >>> The /token endpoint only supports client_secret_basic, and /mtls/token o= nly supports tls_client_auth. >>> The /token endpoint supports both methods, and /mtls/token only supports= tls_client_auth. >>> Both /token and /mtls/token support both methods. >>> =20 >>>=20 >>> All of these could be reasonable interpretations of this metadata. When p= roperties mean different things in different contexts, ambiguity abounds. >>>=20 >>> =20 >>>=20 >>> --=20 >>>=20 >>> Annabelle Richard Backman >>>=20 >>> AWS Identity >>>=20 >>> =20 >>>=20 >>>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >> _______________________________________________ >> OAuth mailing 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-A6753651-687B-4751-8BDC-F29D67B58E9A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 f= or defining an optional mtls endpoints section

I first leaned towards a second metadata file, mainly du= e to the potential token endpoint authentication method issue. But adding a s= econdary metadata configuration just for this purpose seems a bit over engin= eered and would take a lot of normative language to get it right. Just as an= example: does the second configuration overload or replace the primary one?= On the other hand, any client using looking for mtls based token endpoint a= uthentication methods must be aware of the potential mtls endpoints section.= So I think their is no real issue.

Am 20.02.2019 u= m 17:59 schrieb Filip Skokan <panva= .ip@gmail.com>:

= +1, great summary

Odesl=C3= =A1no z iPhonu

20. 2. 2019 v 16:10, Bria= n Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf..org>:

The objective i= s to allow the AS to provide MTLS negotiating endpoints on a different host a= nd/or port so that any non-desirable side effects of requesting client certi= ficates during the TLS handshake can be avoided for 'regular' clients that a= re not doing any MTLS.

In all likelihood, I'd e= xpect that any pair of MTLS and regular endpoints have the same application l= ogic behind them. And that just the TLS setup that differs to accommodate th= e aforementioned objective. That means that they'd support the same client a= uthentication methods but the MTLS endpoint would just be set up so as to ge= t MTLS to work. When first considering it, that seemed a bit overreaching fo= r the spec to come out and say and more of a deployment thing for the AS. Bu= t maybe being more prescriptive would reduce some of the professed problemat= ic ambiguity. As mentioned in a previous message, referring to the mtls endp= oints as aliases might be useful in indicating that they are the same endpoi= nt that is just known and accessed differently based on the context of use.&= nbsp;

I'll grant that some o= f the wording in RFC 8414 can be awkward with respect to this kind of extens= ion. Calling it a violation is a bit over the top though. And as much as we m= ight try to write specs that are the final word, there's the realities of ho= w usage and understanding unfold in practice. As one example, there's some d= iscussion of the treatment of some of the metadata in this  section of a= blog post about a different spec being developed https://medium.c= om/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explai= ned-by-an-implementer-d1e0ac1311b4#8a00..  Maybe that's in violatio= n of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circum= stances. I suppose opinions will differ.

It turns out that writi= ng these=20 specifications is kinda hard. Even when people share the same objective=20 (and that's often not even the case), opinions can differ about what=20 actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls= _endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic a= nd the most straightforward and simple of the options put forth (i.e.. vs a m= etadata parameter linking to or well-known locations to completely separate m= etadata documents). As an editor, I acknowledge that there's been disagreeme= nt about it while also noting again that the dissenting voices come from a v= ocal minority of a few individuals.

 


On Mon, Feb 18, 2019 at 2:55 PM Richard Back= man, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Neil=E2=80=99s example demonstrates how the mtls_endp= oints approach leads to confusion. Consider the following metadata fragment:=

 

{

  =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..c= om/token=E2=80=9D,

=E2=80=9Ctoken_endpoint_= auth_methods_supported=E2=80=9D: [ =E2=80=9Cclient_secret_basic=E2=80=9D, =E2= =80=9Ctls_client_auth=E2=80=9D ],

=E2=80=9Cmtls_endpoints=E2= =80=9D: {

  =E2=80=9Ctoken_en= dpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/token=E2=80=9D

}

}

 

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token end= point only supports client_secret_basic, and /mtls/token only supports tls_c= lient_auth.
  2. The /token endpoint supports both methods, and /mtls/token o= nly supports tls_client_auth.
  3. Both /token and /mtls/token support both m= ethods.

 

All of these could be reasonable interpretations of t= his metadata. When properties mean different things in different contexts, a= mbiguity abounds.

 

-- 

Annabelle Richard Backman

AWS Identity

 



CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited..  If= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.
______________________________________________= _
OAuth mailing 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-A6753651-687B-4751-8BDC-F29D67B58E9A-- --Apple-Mail-839FC754-E9DF-4E27-9BB8-25041141D2FA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCnQw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBTowggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0G CSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0x ODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSm v9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+pUy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7 P3GcYleN1waJRH981U81XzH2clCg9+YRnIUpvof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UO VblWAeQvGCvsV2TlPNCOXOtphvG137/0s048LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5 sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btpWfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb 2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCCAekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStx SF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCB iwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA67MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZby CyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQkoKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/u U092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0n NI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQb k4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJeQ0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggPJ MIIDxQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwDQYJYIZIAWUDBAIBBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE5MDIyMDIyMDQxOVowLwYJKoZIhvcNAQkEMSIEILDrmy8uW+Lxj8K3 8XpeUmH3UIffvKrZ0WW34tjarvttMIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQDFvcAAicj3VrEh5eAtHX+OAf/PS2iUJ9wv0Shp DNQnv0ZRA5uFTxUmah7KIgmpxx/g+8f8Ea1a7stBii0yjdkuxo2xp8LCxdTWZG7g0g5h7uWI743m NJnzNfQ9WS0JqvFB0TDtb1MsnltpCP5FSseYuIDIL8XRrjOdxanJVsponFpc8SM90H+8xt7R588D y+NHKRAvcO+yCm/BuQDnO1lZ18yFkjNsxYDy8rZPuAlyDTpq7Kg0J2XFx0lAejRqyBOiFm+DQPTy UXTyauqfGVRfavSIXsEVxJ/8/DMgcBp0t8A4NnJhrOG2QdPIePy+vq232iRmpOM1rr54jKvZNRix AAAAAAAA --Apple-Mail-839FC754-E9DF-4E27-9BB8-25041141D2FA-- From nobody Wed Feb 20 15:09:36 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9D12D7EA for ; Wed, 20 Feb 2019 15:09:34 -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=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7qck2X9yALy for ; Wed, 20 Feb 2019 15:09:31 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EA91295D8 for ; Wed, 20 Feb 2019 15:09:31 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id p25so29123989qtb.3 for ; Wed, 20 Feb 2019 15:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=U/HTqYnjzjOvIQn+DuPPDZFwsmgORzui9b/JRWJgGBw=; b=e1JctDqcYXesrronteWK3SjHgCKOJ3O4u2q2ZQW49NHHHfoY8sYRjrvLH/5PPDXpfh 9VHk4upRDJYxmMJzHrXYP0DiPaDuj7Yhi93ybf1y6o1sl6pVEwgtumyrMLavwUKZmlTa hCoDfyddsowEHRzX5ZpK8zc9+iyPVeNlmnloQ2pr3+4EyDx6LEp7R+ksnLh/QDqiMl+y GFVU1a/41YC/mNlJoUDoychwanrG/BySuZLu1rKYPm+SGg9c2a7V6mZbKTX+Bbq1l1yc M0igahHoxdhvpZT8NrslqQiZUPB9oZ/EIPFyyq42zdLFYfHJXPkE4+pggU6l6WiH7h9K tvgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=U/HTqYnjzjOvIQn+DuPPDZFwsmgORzui9b/JRWJgGBw=; b=Z1rWmxFQc1/jp1NCCOTHH6+kyvbNZnDHl8jClZp7dY5CiAuus12WbWILakDK8i9lmE 3cwHwVvb2/Gk3iTu4OWUkAN4Y+nSQ+OmztELjkordGGzVSnnbLYCB592WA1z1bwqPAkU nfKEivw9DCopVtOB+w08qzhzB7xfOwHuxVRn8iSMPkCijKS0oCsOH52Qu5Cd1y/NY8g7 VCVP2IENsuR6GhBZWz749N9AvvMIja5uCE8/HAlR/r9Wibsa7L9t8/3I23gTNEbEY9SD 04eLRmIdRRk72muEzab7+aVGFGpYOOMcuLCQpMwonAKBfqcwTdiCr+QQTaeOv4ijfnz7 FItA== X-Gm-Message-State: AHQUAuYL8zMCEEst+E6ImReTDanSP1bZbvMAH9oCCX5RL9EAnovblFqP R/3UBVtoSz39ryNSPL2yXgVaH16otY+M1g== X-Google-Smtp-Source: AHgI3IZNTrxWVhdV18hvW4+O1CBeI6MGj7YnxsT8O2mUHUYvrXsgBCRCj/8b+u4ll3CKUFOmGr1c4A== X-Received: by 2002:ac8:581:: with SMTP id a1mr29859161qth.168.1550704169647; Wed, 20 Feb 2019 15:09:29 -0800 (PST) Received: from [192.168.8.105] ([181.203.43.26]) by smtp.gmail.com with ESMTPSA id r20sm10001413qtp.68.2019.02.20.15.09.26 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 15:09:28 -0800 (PST) To: Torsten Lodderstedt , Filip Skokan Cc: Brian Campbell , oauth References: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> From: John Bradley Message-ID: Date: Wed, 20 Feb 2019 20:09:26 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:66.0) Gecko/20100101 Thunderbird/66.0 MIME-Version: 1.0 In-Reply-To: <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------BF02B2E75CD5801071B6475C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 23:09:34 -0000 This is a multi-part message in MIME format. --------------BF02B2E75CD5801071B6475C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I agree. If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data. John B. On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: > +1 for defining an optional mtls endpoints section > > I first leaned towards a second metadata file, mainly due to the > potential token endpoint authentication method issue. But adding a > secondary metadata configuration just for this purpose seems a bit > over engineered and would take a lot of normative language to get it > right. Just as an example: does the second configuration overload or > replace the primary one? On the other hand, any client using looking > for mtls based token endpoint authentication methods must be aware of > the potential mtls endpoints section. So I think their is no real issue. > > Am 20.02.2019 um 17:59 schrieb Filip Skokan >: > >> +1, great summary >> >> Odesláno z iPhonu >> >> 20. 2. 2019 v 16:10, Brian Campbell >> > >: >> >>> The objective is to allow the AS to provide MTLS negotiating >>> endpoints on a different host and/or port so that any non-desirable >>> side effects of requesting client certificates during the TLS >>> handshake can be avoided for 'regular' clients that are not doing >>> any MTLS. >>> >>> In all likelihood, I'd expect that any pair of MTLS and regular >>> endpoints have the same application logic behind them. And that just >>> the TLS setup that differs to accommodate the aforementioned >>> objective. That means that they'd support the same client >>> authentication methods but the MTLS endpoint would just be set up so >>> as to get MTLS to work. When first considering it, that seemed a bit >>> overreaching for the spec to come out and say and more of a >>> deployment thing for the AS. But maybe being more prescriptive would >>> reduce some of the professed problematic ambiguity. As mentioned in >>> a previous message, referring to the mtls endpoints as aliases might >>> be useful in indicating that they are the same endpoint that is just >>> known and accessed differently based on the context of use. >>> >>> I'll grant that some of the wording in RFC 8414 can be awkward with >>> respect to this kind of extension. Calling it a violation is a bit >>> over the top though. And as much as we might try to write specs that >>> are the final word, there's the realities of how usage and >>> understanding unfold in practice. As one example, there's some >>> discussion of the treatment of some of the metadata in this  section >>> of a blog post about a different spec being developed >>> https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. >>> Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's >>> being pragmatic in the given circumstances. I suppose opinions will >>> differ. >>> >>> It turns out that writing these specifications is kinda hard. Even >>> when people share the same objective (and that's often not even the >>> case), opinions can differ about what actually constitutes >>> simplicity. It seems that's where we are now. >>> >>> My stance as an individual is that the mtls_endpoints (or >>> mtls_endpoint_aliases) approach is reasonable and pragmatic and the >>> most straightforward and simple of the options put forth (i.e.. vs a >>> metadata parameter linking to or well-known locations to completely >>> separate metadata documents). As an editor, I acknowledge that >>> there's been disagreement about it while also noting again that the >>> dissenting voices come from a vocal minority of a few individuals. >>> >>> >>> >>> >>> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle >>> >> > wrote: >>> >>> Neil’s example demonstrates how the mtls_endpoints approach >>> leads to confusion. Consider the following metadata fragment: >>> >>> { >>> >>> “token_endpoint”: “https://as.example..com/token >>> ”, >>> >>> “token_endpoint_auth_methods_supported”: [ >>> “client_secret_basic”, “tls_client_auth” ], >>> >>> “mtls_endpoints”: { >>> >>> “token_endpoint”: “https://as.example.com/mtls/token” >>> >>> } >>> >>> } >>> >>> Which of these statements about endpoints on >>> https://as.example.com/ are true? >>> >>> 1. The /token endpoint only supports client_secret_basic, and >>> /mtls/token only supports tls_client_auth. >>> 2. The /token endpoint supports both methods, and /mtls/token >>> only supports tls_client_auth. >>> 3. Both /token and /mtls/token support both methods. >>> >>> All of these could be reasonable interpretations of this >>> metadata. When properties mean different things in different >>> contexts, ambiguity abounds. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> /CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). >>> Any review, use, distribution or disclosure by others is strictly >>> prohibited..  If you have received this communication in error, >>> please notify the sender immediately by e-mail and delete the >>> message and any file attachments from your computer. Thank you./ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------BF02B2E75CD5801071B6475C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I agree.

If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data.

John B.

On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
+1 for defining an optional mtls endpoints section

I first leaned towards a second metadata file, mainly due to the potential token endpoint authentication method issue. But adding a secondary metadata configuration just for this purpose seems a bit over engineered and would take a lot of normative language to get it right. Just as an example: does the second configuration overload or replace the primary one? On the other hand, any client using looking for mtls based token endpoint authentication methods must be aware of the potential mtls endpoints section. So I think their is no real issue.

Am 20.02.2019 um 17:59 schrieb Filip Skokan <panva..ip@gmail.com>:

+1, great summary

Odesláno z iPhonu

20. 2. 2019 v 16:10, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf..org>:

The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS.

In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use. 

I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this  section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00..  Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case), opinions can differ about what actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e.. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals.

 


On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:

Neil’s example demonstrates how the mtls_endpoints approach leads to confusion. Consider the following metadata fragment:

 

{

  “token_endpoint”: “https://as.example..com/token”,

“token_endpoint_auth_methods_supported”: [ “client_secret_basic”, “tls_client_auth” ],

“mtls_endpoints”: {

  “token_endpoint”: “https://as.example.com/mtls/token”

}

}

 

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token endpoint only supports client_secret_basic, and /mtls/token only supports tls_client_auth.
  2. The /token endpoint supports both methods, and /mtls/token only supports tls_client_auth.
  3. Both /token and /mtls/token support both methods.

 

All of these could be reasonable interpretations of this metadata. When properties mean different things in different contexts, ambiguity abounds.

 

-- 

Annabelle Richard Backman

AWS Identity

 



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------BF02B2E75CD5801071B6475C-- From nobody Thu Feb 21 00:35:19 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5386130DC8 for ; Thu, 21 Feb 2019 00:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6P_LyVL3dr5 for ; Thu, 21 Feb 2019 00:35:14 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EADD12D4F3 for ; Thu, 21 Feb 2019 00:35:13 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id j13-v6so23284166ljc.2 for ; Thu, 21 Feb 2019 00:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vx5vip28Pk+DhgbghRnDcHJwksf20dWJ6cIBUdhb6+A=; b=CJRdhvpgFI6oW96cXHMtZsm+xtHYDF6r5qCVUUZ/eZEllShFebG5f8ujYXqLKZ4dL9 QcwyZLB2gqXmQtHyVu2UigNtKyasd8EL5ASGhgAvkw/kCeufmczsxKd7OVOyt6NKOlLO jcuV5KGVBRQcKOJN7bmVmLbLgoqkLDulPlhLw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vx5vip28Pk+DhgbghRnDcHJwksf20dWJ6cIBUdhb6+A=; b=c8oAXRvtCzLP/sFMaLoG50t9Jd7Dc9m42Sc1vjKcRIAKAMbLP3cQT3b+FGTGvfGSi0 ToWWUY6m8lVpA++D0UHFMSyFwBQyNnOhlqCcGjs7m2+CoGKGW61WCCtJg8BqyIGthP1B JEeRHpiGekda85/bHd6ybgQMtTc1DY/Rng/uoGbv6vlelrci4Ga1lz/kl+YWyG3QSTb5 fxBSPcDy3pvUcQLV4xDTtTC3ZEtgi1/nqxUi3Wh0l6HG7l4pAgWr/JO8nNkGTwHOQXLy fWzytn8kndxTGqia94JBudPqCIVVeqmtN/sv46qRYTrE3QkISJHIlvcm9gCzh4ZlhOM3 KWbg== X-Gm-Message-State: AHQUAuaG4nI0nDWZmtSvwh0LRgyuFNnzmYsB0otAGOwdfVsgeelJYEgZ IOue9hWXrZ1FRCbLsBPSbCgxdnKLirA/ixa2t8WvtA== X-Google-Smtp-Source: AHgI3IZbcS8+hysMpKJHogry8eKMOjWUOndee/x2/Nb5xaTIvSp2bQg3ERYhCrXqt+xQUDffiGBFnXae3FAoNyB7iQ0= X-Received: by 2002:a2e:99c9:: with SMTP id l9mr22891966ljj.60.1550738111253; Thu, 21 Feb 2019 00:35:11 -0800 (PST) MIME-Version: 1.0 References: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> In-Reply-To: From: Dave Tonge Date: Thu, 21 Feb 2019 09:34:59 +0100 Message-ID: To: John Bradley Cc: Torsten Lodderstedt , Filip Skokan , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000042eae80582635afa" Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 08:35:17 -0000 --00000000000042eae80582635afa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for mtls_endpoints optional metadata Dave Tonge On Thu, 21 Feb 2019 at 00:09, John Bradley wrote: > I agree. > > If someone really wants separate meta-data nothing stops them from having > a separate AS with its own meta-data. > > John B. > On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: > > +1 for defining an optional mtls endpoints section > > I first leaned towards a second metadata file, mainly due to the potentia= l > token endpoint authentication method issue. But adding a secondary metada= ta > configuration just for this purpose seems a bit over engineered and would > take a lot of normative language to get it right. Just as an example: doe= s > the second configuration overload or replace the primary one? On the othe= r > hand, any client using looking for mtls based token endpoint authenticati= on > methods must be aware of the potential mtls endpoints section. So I think > their is no real issue. > > Am 20.02.2019 um 17:59 schrieb Filip Skokan >: > > +1, great summary > > Odesl=C3=A1no z iPhonu > > 20. 2. 2019 v 16:10, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf..org > >: > > The objective is to allow the AS to provide MTLS negotiating endpoints on > a different host and/or port so that any non-desirable side effects of > requesting client certificates during the TLS handshake can be avoided fo= r > 'regular' clients that are not doing any MTLS. > > In all likelihood, I'd expect that any pair of MTLS and regular endpoints > have the same application logic behind them. And that just the TLS setup > that differs to accommodate the aforementioned objective. That means that > they'd support the same client authentication methods but the MTLS endpoi= nt > would just be set up so as to get MTLS to work. When first considering it= , > that seemed a bit overreaching for the spec to come out and say and more = of > a deployment thing for the AS. But maybe being more prescriptive would > reduce some of the professed problematic ambiguity. As mentioned in a > previous message, referring to the mtls endpoints as aliases might be > useful in indicating that they are the same endpoint that is just known a= nd > accessed differently based on the context of use. > > I'll grant that some of the wording in RFC 8414 can be awkward with > respect to this kind of extension. Calling it a violation is a bit over t= he > top though. And as much as we might try to write specs that are the final > word, there's the realities of how usage and understanding unfold in > practice. As one example, there's some discussion of the treatment of som= e > of the metadata in this section of a blog post about a different spec > being developed > https://medium.com/@darutk/ciba-a-new-authentication-authorization-techno= logy-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. > Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being > pragmatic in the given circumstances. I suppose opinions will differ. > > It turns out that writing these specifications is kinda hard. Even when > people share the same objective (and that's often not even the case), > opinions can differ about what actually constitutes simplicity. It seems > that's where we are now. > > My stance as an individual is that the mtls_endpoints (or > mtls_endpoint_aliases) approach is reasonable and pragmatic and the most > straightforward and simple of the options put forth (i.e.. vs a metadata > parameter linking to or well-known locations to completely separate > metadata documents). As an editor, I acknowledge that there's been > disagreement about it while also noting again that the dissenting voices > come from a vocal minority of a few individuals. > > > > > On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> Neil=E2=80=99s example demonstrates how the mtls_endpoints approach lead= s to >> confusion. Consider the following metadata fragment: >> >> >> >> { >> >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..com/tok= en >> =E2=80=9D, >> >> =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclie= nt_secret_basic=E2=80=9D, >> =E2=80=9Ctls_client_auth=E2=80=9D ], >> >> =E2=80=9Cmtls_endpoints=E2=80=9D: { >> >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls= /token=E2=80=9D >> >> } >> >> } >> >> >> >> Which of these statements about endpoints on https://as.example.com/ are >> true? >> >> 1. The /token endpoint only supports client_secret_basic, and >> /mtls/token only supports tls_client_auth. >> 2. The /token endpoint supports both methods, and /mtls/token only >> supports tls_client_auth. >> 3. Both /token and /mtls/token support both methods. >> >> >> >> All of these could be reasonable interpretations of this metadata. When >> properties mean different things in different contexts, ambiguity abound= s. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --00000000000042eae80582635afa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for=C2=A0mtls_endpoints optional metadata
=
=
Dave Tonge=



On Thu, 21 Feb 2019 at 00:09, John Bradley <ve7jtb@ve7jtb.com> wrote:
=20 =20 =20

I agree.

If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data.

John B.

On 2/20/2019 = 7:04 PM, Torsten Lodderstedt wrote:
=20
+1 for defining an optional mtls endpoints section

I first leaned towards a second metadata file, mainly due to the potential token endpoint authentication method issue. But adding a secondary metadata configuration just for this purpose seems a bit over engineered and would take a lot of normative language to get it right. Just as an example: does the second configuration overload or replace the primary one? On the other hand, any client using looking for mtls based token endpoint authentication methods must be aware of the potential mtls endpoints section. So I think their is no real issue.

Am 20.02.2019 um 17:59 schrieb Filip Skokan <panva..ip@gmail.com>:

=20 +1, great summary

Odesl=C3=A1no z=C2=A0iPhonu

20. 2. 2019 v=C2=A016:10, Brian Campbell <bcampbell= =3D40pingidentity.com@dmarc.ietf..org>:

The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not = doing any MTLS.

In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use.=C2=A0

I'll grant that some= of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's th= e realities of how usage and understanding unfold in practice. As one example, there's some discussio= n of the treatment of some of the metadata in this=C2=A0 section of a blo= g post about a different spec being developed https://medium.co= m/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explai= ned-by-an-implementer-d1e0ac1311b4#8a00..=C2=A0 Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case)= , opinions can differ about what actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e.. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals.

=C2=A0


On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Neil=E2= =80=99s example demonstrates how the mtls_endpoints approach leads to confusion. Consider the following metadata fragment:

=C2=A0

{

=C2=A0 =E2=80=9Ctoken_endpoint=E2=80= =9D: =E2=80=9Cht= tps://as.example..com/token=E2=80=9D,

=E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80= =9D: [ =E2=80=9Cclient_secret_basi= c=E2=80=9D, =E2=80=9Ctls_client_auth=E2= =80=9D ],

=E2=80=9Cmtls_endpoints=E2=80=9D: {

=C2=A0 =E2=80=9Ctoken_endpoint=E2=80= =9D: =E2=80=9Chttps://as.example.com/mtls/token=E2=80=9D

}

}

=C2=A0

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token endpoint only supports client_secret_basic, and /mtls/token only supports tls_client_auth.
  2. The /token endpoint supports both methods, and /mtls/token only supports tls_client_auth.
  3. Both /token and /mtls/token support both methods.

=C2=A0

All of these could be reasonable interpretations of this metadata. When properties mean different things in different contexts, ambiguity abounds.

=C2=A0

--= =C2=A0

Anna= belle Richard Backman

AWS Identity

=C2=A0



CONFIDENTIALITY NOTICE: This email = may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /span>
________________________________________= _______
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

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


--

=
--00000000000042eae80582635afa-- From nobody Thu Feb 21 01:09:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC6129524 for ; Thu, 21 Feb 2019 01:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiDCJ2zjd3OW for ; Thu, 21 Feb 2019 01:09:52 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27609130E69 for ; Thu, 21 Feb 2019 01:09:52 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id i5so3801042qkd.13 for ; Thu, 21 Feb 2019 01:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=qpu0xL/BnvkPJEJdj6lra0WxMLidB8D5g17PrGUHEZY=; b=EdujJT5uKK+GFXUHWA7JsWnKmbpq4e+KsS4JSPHpHnKebj1tdl8GSyW3LYBOHstVt5 wU3PltP9BuwPZ12wGYAG+8JSNiQpR9R8mdZLIyIycT/OmvgqOGNYIyQYiGMWdhjF1xFw 4lpa/BMOrcCwhSSceq9QF3KdwxMJOiFuMJ5mreUHwLTBXns9XD8Z0vHjdltY1QRaRzRb BxeXDHxhDpgX7CZG5Tlj3AtG7oAlvzoWUbU2042lQ0hfUuYbpQkvrN2UhCpgYcULIKNi DgV+EH4iE1EHOu40rqtuJxPc0tu1OK4DG1VRqEUu5GVbFgnCQllGHdZ1r3oTzImmkt9m Qgig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=qpu0xL/BnvkPJEJdj6lra0WxMLidB8D5g17PrGUHEZY=; b=eo3BndK6tU0tp+zOsj+ZipvDrA1fN63hunF8X9s1NZq4pbcis1/bzr6cFKFo79ZUaT eREg6zSeso/s1BZG/Bi5vtShpYyyV5fHnfLjV9EloNP3nnlZXDlqRxBYV7A11skfPR9b r2t2xrN8K0fCi2Dq7/Z+GISxoYtjC5vCjxuNb5VTAuj+1wQumfi9lfvftFJ2Cx/qQG7F aCrWzHtemdYXhgwwho5LcYwll4mbco99dtwC2he41xnis9bc59n5LjJRTvymFwzq7+1g 34XKvvAp9Xp/ZavO/LStKO3vO6LTmKDREsop7xpnXuTG4BeRfS7Y6008fKH2Dh3DoqNU ug/Q== X-Gm-Message-State: AHQUAuZQ0offHWYLE/J6ClEsoC+cWvrW+65773XcbyuYMQ76VHvnpnvR 8cOulbcdyCII5BTpuvpxq/emlAc/PVaY29+HYDbr X-Google-Smtp-Source: AHgI3Ib/sSHL2JYGI9ynE4rtFCIw39UeEBqqTEgJ2c0seIzTVBr+SVp7FZdvdHwl7RENJXoOf4IWRs0983MGxQauumM= X-Received: by 2002:a37:a407:: with SMTP id n7mr26450205qke.46.1550740190962; Thu, 21 Feb 2019 01:09:50 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Feb 2019 04:09:49 -0500 From: Dominick Baier In-Reply-To: References: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> MIME-Version: 1.0 Date: Thu, 21 Feb 2019 04:09:49 -0500 Message-ID: To: Dave Tonge , John Bradley Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000038baea058263d663" Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 09:09:56 -0000 --00000000000038baea058263d663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 =E2=80=94=E2=80=94=E2=80=94 Dominick On 21. February 2019 at 09:35:35, Dave Tonge (dave.tonge@momentumft.co.uk) wrote: +1 for mtls_endpoints optional metadata Dave Tonge On Thu, 21 Feb 2019 at 00:09, John Bradley wrote: > I agree. > > If someone really wants separate meta-data nothing stops them from having > a separate AS with its own meta-data. > > John B. > On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: > > +1 for defining an optional mtls endpoints section > > I first leaned towards a second metadata file, mainly due to the potentia= l > token endpoint authentication method issue. But adding a secondary metada= ta > configuration just for this purpose seems a bit over engineered and would > take a lot of normative language to get it right. Just as an example: doe= s > the second configuration overload or replace the primary one? On the othe= r > hand, any client using looking for mtls based token endpoint authenticati= on > methods must be aware of the potential mtls endpoints section. So I think > their is no real issue. > > Am 20.02.2019 um 17:59 schrieb Filip Skokan >: > > +1, great summary > > Odesl=C3=A1no z iPhonu > > 20. 2. 2019 v 16:10, Brian Campbell < > bcampbell=3D40pingidentity.com@dmarc.ietf..org > >: > > The objective is to allow the AS to provide MTLS negotiating endpoints on > a different host and/or port so that any non-desirable side effects of > requesting client certificates during the TLS handshake can be avoided fo= r > 'regular' clients that are not doing any MTLS. > > In all likelihood, I'd expect that any pair of MTLS and regular endpoints > have the same application logic behind them. And that just the TLS setup > that differs to accommodate the aforementioned objective. That means that > they'd support the same client authentication methods but the MTLS endpoi= nt > would just be set up so as to get MTLS to work. When first considering it= , > that seemed a bit overreaching for the spec to come out and say and more = of > a deployment thing for the AS. But maybe being more prescriptive would > reduce some of the professed problematic ambiguity. As mentioned in a > previous message, referring to the mtls endpoints as aliases might be > useful in indicating that they are the same endpoint that is just known a= nd > accessed differently based on the context of use. > > I'll grant that some of the wording in RFC 8414 can be awkward with > respect to this kind of extension. Calling it a violation is a bit over t= he > top though. And as much as we might try to write specs that are the final > word, there's the realities of how usage and understanding unfold in > practice. As one example, there's some discussion of the treatment of som= e > of the metadata in this section of a blog post about a different spec > being developed > https://medium.com/@darutk/ciba-a-new-authentication-authorization-techno= logy-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. > Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being > pragmatic in the given circumstances. I suppose opinions will differ. > > It turns out that writing these specifications is kinda hard. Even when > people share the same objective (and that's often not even the case), > opinions can differ about what actually constitutes simplicity. It seems > that's where we are now. > > My stance as an individual is that the mtls_endpoints (or > mtls_endpoint_aliases) approach is reasonable and pragmatic and the most > straightforward and simple of the options put forth (i.e.. vs a metadata > parameter linking to or well-known locations to completely separate > metadata documents). As an editor, I acknowledge that there's been > disagreement about it while also noting again that the dissenting voices > come from a vocal minority of a few individuals. > > > > > On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> Neil=E2=80=99s example demonstrates how the mtls_endpoints approach lead= s to >> confusion. Consider the following metadata fragment: >> >> >> >> { >> >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..com/tok= en >> =E2=80=9D, >> >> =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclie= nt_secret_basic=E2=80=9D, >> =E2=80=9Ctls_client_auth=E2=80=9D ], >> >> =E2=80=9Cmtls_endpoints=E2=80=9D: { >> >> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls= /token=E2=80=9D >> >> } >> >> } >> >> >> >> Which of these statements about endpoints on https://as.example.com/ are >> true? >> >> 1. The /token endpoint only supports client_secret_basic, and >> /mtls/token only supports tls_client_auth. >> 2. The /token endpoint supports both methods, and /mtls/token only >> supports tls_client_auth. >> 3. Both /token and /mtls/token support both methods. >> >> >> >> All of these could be reasonable interpretations of this metadata. When >> properties mean different things in different contexts, ambiguity abound= s. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --00000000000038baea058263d663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
+1
=E2=80=94=E2=80=94=E2=80=94
Do= minick

On 21. February 2019 at 09:3= 5:35, Dave Tonge (dave.tonge= @momentumft.co.uk) wrote:

= +1 for=C2=A0mtls_end= points optional metadata
=
= Dave Tonge
=
=

On Thu, 21 Feb 2019 at 00:09, John Bradley <ve7jtb@ve7jtb.com= > wrote:

I agree.

If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data.

John B.

On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
+1 for defining an optional mtls endpoints section

I first leaned towards a second metadata file, mainly due to the potential token endpoint authentication method issue. But adding a secondary metadata configuration just for this purpose seems a bit over engineered and would take a lot of normative language to get it right. Just as an example: does the second configuration overload or replace the primary one? On the other hand, any client using looking for mtls based token endpoint authentication methods must be aware of the potential mtls endpoints section. So I think their is no real issue.

Am 20.02.2019 um 17:59 schrieb Filip Skokan <panva..ip@gmail.com>:

+1, great summary

Odesl=C3=A1no z=C2=A0iPhonu

20. 2. 2019 v=C2=A016:10, Brian Campbell <bcampbell=3D40pingiden= tity.com@dmarc.ietf..org>:

The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS.

In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use.=C2=A0

I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this=C2=A0 section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-= authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8= a00..=C2=A0 Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case), opinions can differ about what actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e.. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals.

=C2=A0


On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:<= br>

Neil=E2=80=99s example demonstrates how the mtls_endpoints approach leads to confusion. Consider the following metadata fragment:

=C2=A0

{

=C2=A0 =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example= ..com/token=E2=80=9D,

=E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Cclient_= secret_basic=E2=80=9D, =E2=80=9Ctls_client_auth=E2=80=9D ],

=E2=80=9Cmtls_endpoints= =E2=80=9D: {

=C2=A0 =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mtls/token=E2=80= =9D

}

}

=C2=A0

Which of these statements about endpoints on https://as.example.co= m/ are true?

  1. The /token endpoint only supports client_secret_basic, and /mtls/token only supports tls_client_auth.
  2. The /token endpoint supports both methods, and /mtls/token only supports tls_client_auth.
  3. Both /token and /mtls/token support both methods.

=C2=A0

All of these could be reasonable interpretations of this metadata. When properties mean different things in different contexts, ambiguity abounds.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


--

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--00000000000038baea058263d663-- From nobody Thu Feb 21 01:33:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A0A12DD85 for ; Thu, 21 Feb 2019 01:33:03 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4scca_e-NmvF for ; Thu, 21 Feb 2019 01:32:59 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D4C128B36 for ; Thu, 21 Feb 2019 01:32:58 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id a62so9521243wmh.4 for ; Thu, 21 Feb 2019 01:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/fM3sL23hV+lv7BsfJz/EpoUtd6HjepOMmKspDhIdA8=; b=LyWMrQNpo6LL04+M+Mv0foBpwa7oJS5xGoUEq/Xk24pviwtiQpVNp81R44BPsr45TR hlUNU4E1coAyacpOevhDcJ+8fAOEsFoaNe9usrYOD/cV3Fqd+CxV2aXCC62bVRkBNxwL vVigX16o/M0A2+svZc1bODKGMewpBLxaUWy7w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/fM3sL23hV+lv7BsfJz/EpoUtd6HjepOMmKspDhIdA8=; b=FKqWFCSpsTZJinBgxOuzePV5nFRdw3qkmNIJdQ6mE+7e1a0mRnjHbxhH/DtFhdvQme YYBCHLUThR14rV4mxzxFWjPo7PpVtgVPqDEuF982dkmNsgF2J7WmTSzD6Gcc2WoAEoHc qOYYfqZGuN6EhgE7dlK60Cq6mL3bh2hR6Byoglklbm+JVI+8B1KKWYepor9d8PhVnmBk wr6fB7J2mRNCurHLsudLferRkrn64O+Kc3bpvzRXBz1SD54DQUonGl9sWchVVtndV/I9 s1p0t0Y8yJmqFW4w/S0E8kehB3gULnornbqMT34aE5V25OBLlkZ0Ip2O3bsnmaZmr0pH hl4Q== X-Gm-Message-State: AHQUAubplzCISPP+QuwD6Rv0cDS4Zwbdy3GcezDlkQYWommJXRjjMV21 qlopHqeIJLtnnGDtv8FrIE0dhw== X-Google-Smtp-Source: AHgI3IYU6tA5sCa5a+SLPTkzhn5pIkbfTL7AgXXZp+148iyBxtGSlFcoMP/+Ft839p9x+yBjDVvGOA== X-Received: by 2002:a1c:b189:: with SMTP id a131mr10054965wmf.38.1550741577106; Thu, 21 Feb 2019 01:32:57 -0800 (PST) Received: from [192.168.1.65] (173.132.93.209.dyn.plus.net. [209.93.132.173]) by smtp.gmail.com with ESMTPSA id a62sm6480001wmf.47.2019.02.21.01.32.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 01:32:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9D2BA75C-2402-448B-9BF3-E49B0AE0CE26 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Thu, 21 Feb 2019 09:32:55 +0000 Cc: Torsten Lodderstedt , Filip Skokan , Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <05CD431E-CEB8-4E73-B9FC-C2D60D0FEBEB@forgerock.com> References: <86C3D832-23BA-4300-AD55-4EEF9991AE88@gmail.com> <13687681-50E8-4F2D-A081-E3712A5FFFC6@lodderstedt.net> To: John Bradley Archived-At: Subject: Re: [OAUTH-WG] MTLS endpoints & discovery (was something else) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 09:33:03 -0000 --Apple-Mail-9D2BA75C-2402-448B-9BF3-E49B0AE0CE26 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed.=20 > On 20 Feb 2019, at 23:09, John Bradley wrote: >=20 > I agree. >=20 > If someone really wants separate meta-data nothing stops them from having a= separate AS with its own meta-data. >=20 > John B. >=20 >> On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: >> +1 for defining an optional mtls endpoints section >>=20 >> I first leaned towards a second metadata file, mainly due to the potentia= l token endpoint authentication method issue. But adding a secondary metadat= a configuration just for this purpose seems a bit over engineered and would t= ake a lot of normative language to get it right. Just as an example: does th= e second configuration overload or replace the primary one? On the other han= d, any client using looking for mtls based token endpoint authentication met= hods must be aware of the potential mtls endpoints section. So I think their= is no real issue. >>=20 >> Am 20.02.2019 um 17:59 schrieb Filip Skokan : >>=20 >>> +1, great summary >>>=20 >>> Odesl=C3=A1no z iPhonu >>>=20 >>> 20. 2. 2019 v 16:10, Brian Campbell : >>>=20 >>>> The objective is to allow the AS to provide MTLS negotiating endpoints o= n a different host and/or port so that any non-desirable side effects of req= uesting client certificates during the TLS handshake can be avoided for = 'regular' clients that are not doing any MTL= S.=20 >>>>=20 >>>> In all likelihood, I'd expect that any pair of MTLS and regular endpoin= ts have the same application logic behind them. And that just the TLS setup t= hat differs to accommodate the aforementioned objective. That means that the= y'd support the same client authentication methods but the MTLS endpoint wou= ld just be set up so as to get MTLS to work. When first considering it, that= seemed a bit overreaching for the spec to come out and say and more of a de= ployment thing for the AS. But maybe being more prescriptive would reduce so= me of the professed problematic ambiguity. As mentioned in a previous messag= e, referring to the mtls endpoints as aliases might be useful in indicating t= hat they are the same endpoint that is just known and accessed differently b= ased on the context of use.=20 >>>>=20 >>>> I'll grant that some of the wording in RFC 8414 can be awkward with res= pect to this kind of extension. Calling it a violation is a bit over the top= though. And as much as we might try to write specs that are the final word,= there's the realities of how usage and understanding unfold in practice. As= one example, there's some discussion of the treatment of some of the metada= ta in this section of a blog post about a different spec being developed ht= tps://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-= in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. Maybe that's in vio= lation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given c= ircumstances. I suppose opinions will differ.=20 >>>>=20 >>>> It turns out that writing these specifications is = kinda hard. Even when people share the same objective (an= d that's often not even the case), opinions can differ about what actually c= onstitutes simplicity. It seems that's where we are now.=20 >>>>=20 >>>> My stance as an individual is that the mtls_endpoints (or mtls_endpoint= _aliases) approach is reasonable and pragmatic and the most straightforward a= nd simple of the options put forth (i.e.. vs a metadata parameter linking to= or well-known locations to completely separate metadata documents). As an e= ditor, I acknowledge that there's been disagreement about it while also noti= ng again that the dissenting voices come from a vocal minority of a few indi= viduals.=20 >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>>> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle wrote: >>>>> Neil=E2=80=99s example demonstrates how the mtls_endpoints approach le= ads to confusion. Consider the following metadata fragment: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> { >>>>>=20 >>>>> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example..com/t= oken=E2=80=9D, >>>>>=20 >>>>> =E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D: [ =E2=80=9Ccl= ient_secret_basic=E2=80=9D, =E2=80=9Ctls_client_auth=E2=80=9D ], >>>>>=20 >>>>> =E2=80=9Cmtls_endpoints=E2=80=9D: { >>>>>=20 >>>>> =E2=80=9Ctoken_endpoint=E2=80=9D: =E2=80=9Chttps://as.example.com/mt= ls/token=E2=80=9D >>>>>=20 >>>>> } >>>>>=20 >>>>> } >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Which of these statements about endpoints on https://as.example.com/ a= re true? >>>>>=20 >>>>> The /token endpoint only supports client_secret_basic, and /mtls/token= only supports tls_client_auth. >>>>> The /token endpoint supports both methods, and /mtls/token only suppor= ts tls_client_auth. >>>>> Both /token and /mtls/token support both methods. >>>>> =20 >>>>>=20 >>>>> All of these could be reasonable interpretations of this metadata. Whe= n properties mean different things in different contexts, ambiguity abounds.= >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Annabelle Richard Backman >>>>>=20 >>>>> AWS Identity >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(= s). Any review, use, distribution or disclosure by others is strictly prohib= ited.. If you have received this communication in error, please notify the s= ender immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you. >>>> _______________________________________________ >>>> OAuth mailing 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 --Apple-Mail-9D2BA75C-2402-448B-9BF3-E49B0AE0CE26 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agr= eed. 

On 20 Feb 2019, at 23:09, John Bradley &= lt;ve7jtb@ve7jtb.com> wrote:
=
=20 =20 =20

I agree.

If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data.

John B.

On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
+1 for defining an optional mtls endpoints section

I first leaned towards a second metadata file, mainly due to the potential token endpoint authentication method issue. But adding a secondary metadata configuration just for this purpose seems a bit over engineered and would take a lot of normative language to get it right. Just as an example: does the second configuration overload or replace the primary one? On the other hand, any client using looking for mtls based token endpoint authentication methods must be aware of the potential mtls endpoints section. So I think their is no real issue.

Am 20.02.2019 um 17:59 schrieb Filip Skokan <panva..ip@gmail.com>:

+1, great summary

Odesl=C3=A1no z iP= honu

20. 2. 2019 v 16:10, Brian Campbell <bcamp= bell=3D40pingidentity.com@dmarc.ietf..org>:

The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS.

In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use. 

I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this  section of a blog= post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-tech= nology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00..  Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ.

It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case), opinions can differ about what actually constitutes simplicity. It seems that's where we are now.

My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e.. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals.

 


= On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna=3D40amazo= n.com@dmarc.ietf.org> wrote:

Neil=E2=80= =99s example demonstrates how the mtls_endpoints approach leads to confusion. Consider the following metadata fragment:

 

{

  =E2=80=9Ctoken_endpoint=E2=80=9D= : =E2=80=9Chttps://as.example..com/token=E2=80=9D,

=E2=80=9Ctoken_endpoint_auth_methods_supported=E2=80=9D:= [ =E2=80=9Cclient_secret_basic= =E2=80=9D, =E2=80=9Ctls_client_auth=E2=80= =9D ],

=E2=80=9Cmtls_endpoints=E2=80=9D: {

  =E2=80=9Ctoken_endpoint=E2=80=9D= : =E2=80=9Chttps://as.example.com/mtls/token=E2=80=9D

}

}

 

Which of these statements about endpoints on https://as.example.com/ are true?

  1. The /token endpoint only supports client_secret_basic, and /mtls/token only supports tls_client_auth.
  2. The /token endpoint supports both methods, and /mtls/token only supports tls_client_auth.
  3. Both /token and /mtls/token support both methods.

 

All of these could be reasonable interpretations of this metadata. When properties mean different things in different contexts, ambiguity abounds.

 

--&nbs= p;

Annabe= lle Richard Backman

=

AWS Identity

 



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_____________________________________________= __
OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br> 

_______________________________=
________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth
=20
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-9D2BA75C-2402-448B-9BF3-E49B0AE0CE26-- From nobody Thu Feb 21 13:55:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104D513123B for ; Thu, 21 Feb 2019 13:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f0IpKXWOXvm for ; Thu, 21 Feb 2019 13:55:46 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BB3131250 for ; Thu, 21 Feb 2019 13:55:43 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id x3so132399ior.6 for ; Thu, 21 Feb 2019 13:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/m/b9+neTYytfaevgJYARfQVuRWqQyh9AWqAjIalcM4=; b=fJ9DAFVvTi4e3AjGxgcO3WkpjwrXsGMBhaWD8FezI3sEjlYR/Vm/sWU5ZD+V9oUaMP RkP5dgH1i9ad1rm+P7S6J9eDvHWS8nAupwqKroJhvV4qDo6NV/fa933+kNN1q80tsY30 TN5N9Pmd/0ldNeqq4M6+EWms/q+8d9DT7Msj5KJk9NwWlx/5RbB9b1uL3qND7UCO1ikQ bHQgeQLRxaxFe+qcAN/XitdElwx9NpP0S4mZyqQ4V7AOo4/LCU/nsdgUNOvC429BxSze Wh4wPEOfQx9R1bDp4hDbeK4b/HbrQS2jUpMCyco+y2OznfK2g0xT2EzghxZG0X0KaBv7 JHDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/m/b9+neTYytfaevgJYARfQVuRWqQyh9AWqAjIalcM4=; b=f9XMRKhP/MXg4ATkMNHKHwllc7wTf767w1jPHhyflGdl6iYy3mx1bYffZToyHUKYw6 3J8frJBNhA5vI8tA717zBQUmxlb3oxpPT9ccZmuVHLLyK+TGrjHQT3RdMIodYmW0V7cB SonY6qHeSdia4nCUfZs/opBqSoYl6yFR7tvrTZULowASogIyOc9Xj4SLURKOpJCPU5+6 JOBDdFUJHKrr1MGXYW6/216c0VIS4Q7y4zOYHIL7NtnowtJHZ57WgbN6jt8w746JsGqy 0Y2XqImyAZnuqjjLvmKGuP4dQ7BYmpcw1s11PpVCn01+2Ev86EBSj9VERF1ySCO/ItHL OsYw== X-Gm-Message-State: AHQUAub1RbKri/ekYmvW0qIAJTCsb0bqtgOfhufCIdI+Cb2sbpocmstG m/Kky17+nDOhzLqETUB3ipDtTDtLmCKmpT/gbzpwJQ== X-Google-Smtp-Source: AHgI3Ib0hVVZznKDY5FsQB1GlXhbd2eD41JlF3Yyn7wDMwMY8hPnv1GvqKOioQ1cV8UwNofo84s4nqvoik9AeDeFmiY= X-Received: by 2002:a6b:8fd7:: with SMTP id r206mr499748iod.5.1550786142124; Thu, 21 Feb 2019 13:55:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Thu, 21 Feb 2019 13:55:30 -0800 Message-ID: To: Kristian Antic Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002022ed05826e8956" Archived-At: Subject: Re: [OAUTH-WG] Remark on OAuth 2.0 Device Flow name X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 21:55:55 -0000 --0000000000002022ed05826e8956 Content-Type: text/plain; charset="UTF-8" Kristian, Thanks for the feedback & sorry for the delay. You make a good point, I'm going to discuss this with my co-authors. Best, William On Tue, Nov 27, 2018 at 1:04 PM Kristian Antic wrote: > Dear all, > > I've been working through the OAuth 2.0 Device Flow spec since early > draft versions > and noticed the name change in draft-ietf-oauth-device-flow-04. > > As the OAuth 2.0 Device flow is an OAuth 2.0 authorization grant/OAuth > 2.0 extension grant, I always wonder why it is called OAuth 2.0 Device > flow. > > Could you tell me why you called it OAuth 2.0 Device Flow for > Browserless and Input Constrained Devices and not OAuth 2.0 Device > Grant for Browserless and Input Constrained Devices? > > >From my point of view this would better fit into the naming scheme of > the OAuth 2.0 framework. > > Best regards, > > Kristian > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000002022ed05826e8956 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kristian,

Thanks for the feedback &= sorry for the delay. You make a good point, I'm going to discuss this = with my co-authors.

Best,
William
<= /div>
O= n Tue, Nov 27, 2018 at 1:04 PM Kristian Antic <kristian.antic@gmail.com> wrote:
Dear all,

I've been working through the OAuth 2.0 Device Flow spec since early draft versions
and noticed the name change in draft-ietf-oauth-device-flow-04.

As the OAuth 2.0 Device flow is an OAuth 2.0 authorization grant/OAuth
2.0 extension grant, I always wonder why it is called OAuth 2.0 Device
flow.

Could you tell me why you called it OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices and not OAuth 2.0 Device
Grant for Browserless and Input Constrained Devices?

>From my point of view this would better fit into the naming scheme of the OAuth 2.0 framework.

Best regards,

Kristian

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002022ed05826e8956-- From nobody Thu Feb 21 21:57:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7912DF71 for ; Thu, 21 Feb 2019 21:57:23 -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=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2NKdcI23j16 for ; Thu, 21 Feb 2019 21:57:21 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DF31275F3 for ; Thu, 21 Feb 2019 21:57:21 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id p18so886690ioh.5 for ; Thu, 21 Feb 2019 21:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vqp+KM1MstwLtEI5kRtLB87i6c0HKH5UwT6mU7UTK18=; b=pba0y/chOZ2GAue/YOPrQk3AKgos7wU+HDw5FGbyKJAA3UwoxCVduyX1nj+xLXCnlg NNn+xiKjAuLIPqZ78oB+r0Ry96NSnIhIXdxqlixXU5r4LexMAhas6dbdJIKrvM4T/OCh aNik3tz9wKBzp+182+LQQ33QX2TW+IVfjBhAEucruS3nahFKZsdh9Ph7H5/o5d0AVh5P gS5boEciuEWTs/FwIFhnp+Jp0U1gujQSJKNNs+W5+RqssxUDyPVTXeHan6VvI2WxADJC pJKslUTLZF6LJuNVJMBIOAv2CBPKXjEgUpUXkLYJQ0gx53XrZBRD0HQhMgjjRZmIENs+ nAjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vqp+KM1MstwLtEI5kRtLB87i6c0HKH5UwT6mU7UTK18=; b=eVyAPGQnjt2IuUPzJNKNq4wvg+0TOywqkd7psnypw6riyuTeHIsDhYeaDtCcAGZYMo A55zRmBfZg+9yXA+0OoURX3qq2gz4t0xm5OY4hHZvCT5WcCEeMgKHTQP93nnQFFcHVcT acvrbqpPrakIKmkVSDThVbk3pPGEpq2OkRRqSR516sJ3SOO/WXIHa3M6aW/qbu+bwEED +VTm35NNdmNcuHgjIy4dxICvshM/rDHQz2UH1sk1fIaCm9xcimamfRAyeU2FqAMwfVX1 JBHrhVz4HoMa+h0fWnd2ZCOD5JZTXm68AAmMAE7PODgXuLOKLR3AcKq2wcjLZ9p0ASIv L4bA== X-Gm-Message-State: AHQUAubw2JaBNUsOGu08ZNairwSIxvfYu3ctLfxzEQynhu+N5aUCIojC Qr273ADL+dZyQL7GCOmxenPVOWuomnA= X-Google-Smtp-Source: AHgI3IYvWCwzZySt2k1mjzDbXT2jZvCWVk5EHZWpf5B5oIbR2iJhb4QQBEbC6VQwYRh6l73z43O6lw== X-Received: by 2002:a6b:710e:: with SMTP id q14mr1335018iog.210.1550815040088; Thu, 21 Feb 2019 21:57:20 -0800 (PST) Received: from mail-it1-f180.google.com (mail-it1-f180.google.com. [209.85.166.180]) by smtp.gmail.com with ESMTPSA id c1sm280719itd.23.2019.02.21.21.57.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 21:57:19 -0800 (PST) Received: by mail-it1-f180.google.com with SMTP id g137so10696262ita.0 for ; Thu, 21 Feb 2019 21:57:19 -0800 (PST) X-Received: by 2002:a05:6638:44e:: with SMTP id r14mr1406890jap.65.1550815039096; Thu, 21 Feb 2019 21:57:19 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Thu, 21 Feb 2019 21:57:08 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="00000000000084904405827543df" Archived-At: Subject: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 05:57:23 -0000 --00000000000084904405827543df Content-Type: text/plain; charset="UTF-8" The OAuth password grant section mentions taking appropriate measures to rate limit password requests at the token endpoint. However the error responses section ( https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an error code to use if the request is being rate limited. What's the recommended practice here? Thanks! Aaron -- ---- Aaron Parecki aaronparecki.com @aaronpk --00000000000084904405827543df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The OAuth password grant section mentions taking appropri= ate measures to rate limit password requests at the token endpoint. However= the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) do= esn't mention an error code to use if the request is being rate limited= . What's the recommended practice here? Thanks!
=
Aaron

--=
----
Aaron Parecki

--00000000000084904405827543df-- From nobody Thu Feb 21 23:09:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB18130E58 for ; Thu, 21 Feb 2019 23:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-RxtNZegJer for ; Thu, 21 Feb 2019 23:09:12 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id C873012F1A5 for ; Thu, 21 Feb 2019 23:09:12 -0800 (PST) Received: from [IPv6:2601:282:202:b210:219e:ff3b:9f20:9550] (unknown [IPv6:2601:282:202:b210:219e:ff3b:9f20:9550]) by alkaline-solutions.com (Postfix) with ESMTPSA id AC9C231694; Fri, 22 Feb 2019 07:09:10 +0000 (UTC) From: David Waite Message-Id: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BBE552BB-F49B-4496-B699-60EA4099412E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Fri, 22 Feb 2019 00:09:09 -0700 In-Reply-To: Cc: OAuth WG To: Aaron Parecki References: X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 07:09:14 -0000 --Apple-Mail=_BBE552BB-F49B-4496-B699-60EA4099412E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t believe that any of the currently registered error codes = are appropriate for indicating that the password request is invalid, let = alone a more specific behavior like rate limiting. It is also my opinion that 400 Bad Request shouldn=E2=80=99t be used for = known transient errors, but rather for malformed requests - the request = could very well be correct (and have the correct password), but it is = being rejected due to temporal limits placed on the client or network = address/domain. So I would propose a different statuses such 401 to indicate the = username/password were invalid, and either 429 (Too many requests) or = 403 (Forbidden) when rate limited or denied due to too many attempts. = Thats not to say that the body of the response can=E2=80=99t be an = OAuth-format JSON error, possibly with a standardized code - but again I = don=E2=80=99t think the currently registered codes would be appropriate = for conveying that. That said, I don=E2=80=99t know what interest there would be in = standardizing such codes, considering the existing recommendations = against using this grant type. -DW > On Feb 21, 2019, at 10:57 PM, Aaron Parecki wrote: >=20 > The OAuth password grant section mentions taking appropriate measures = to rate limit password requests at the token endpoint. However the error = responses section ( > https://tools.ietf.org/html/rfc6749#section-5.2 = ) doesn't mention an = error code to use if the request is being rate limited.. What's the = recommended practice here? Thanks! >=20 > Aaron >=20 > --=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BBE552BB-F49B-4496-B699-60EA4099412E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I don=E2=80=99t believe that any of the currently registered = error codes are appropriate for indicating that the password request is = invalid, let alone a more specific behavior like rate = limiting.

It is also my = opinion that 400 Bad Request shouldn=E2=80=99t be used for known = transient errors, but rather for malformed requests - the request could = very well be correct (and have the correct password), but it is being = rejected due to temporal limits placed on the client or network = address/domain.

So I = would propose a different statuses such 401 to indicate the = username/password were invalid, and either 429 (Too many requests) or = 403 (Forbidden) when rate limited or denied due to too many attempts. = Thats not to say that the body of the response can=E2=80=99t be an = OAuth-format JSON error, possibly with a standardized code - but again I = don=E2=80=99t think the currently registered codes would be appropriate = for conveying that.

That said, I don=E2=80=99t know what interest there would be = in standardizing such codes, considering the existing recommendations = against using this grant type.

-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki = <aaron@parecki.com> wrote:

The OAuth password grant section mentions taking appropriate = measures to rate limit password requests at the token endpoint. However = the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't = mention an error code to use if the request is being rate limited.. = What's the recommended practice here? Thanks!

Aaron

--
----
Aaron Parecki
aaronparecki.com
@aaronpk

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

= --Apple-Mail=_BBE552BB-F49B-4496-B699-60EA4099412E-- From nobody Fri Feb 22 06:02:55 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68F9128766 for ; Fri, 22 Feb 2019 06:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_3dhgAJXbEU for ; Fri, 22 Feb 2019 06:02:51 -0800 (PST) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91013129A87 for ; Fri, 22 Feb 2019 06:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550844169; bh=nnkQ58sbjB0McqOAv49PEmy7E5fhQpaks6OT5jYrwEA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=fsOqmjkvf7KAv5tQl+2ZhaaQAv6c9kDP5WH2jhWHRL6qjZxTRUGTT0CABe4sE7KFaGXEFRJMxQHgq4otLRBHKr0wabOdDAXQlaheRtwcZ71odJyOOBQq1y+M/l5BfLtT+Yea98jsH/RWDdqug2ablk6QUW6SmH12IOn9BjHfK1Zn3xbvXoVClaOAvNH+wZ60Qt4uXpDr4Tjbn+LNdHbKeGqpKJgvZclXrQRd5MdKLg4eZ2MfVv7NwtT2XwAHKHRAjP0Diug/x0ZyCBj1nk2mGRoZ69PU5QzlVSkHjQ4sirLePxAd5hq4ZrLBrrDm3T2eqZjK8kfH2m/qSPIekvlvlw== X-YMail-OSG: WJGewiIVM1l6Tm9t9K73ZoT6baJjXrfqR0LEe0gvzq7w74O44gnBZLpXzNIsVQ3 s95vCRUbs5F1qIC4lB8EmBnbGQBsXRlNxkNZmeP0RgMfzJcaMspPTSee43g.4s.PGbf7r48OSuy5 06JzJNp049PYIGYdbeV6OVwR5RoCCH88F96tDy4FmybhJivFkrtc3f9TOgvq.ba1_HGb4RYCBo2Z mggtVEp2lU8g47eEzMtf.Je9IziSdcrQWGN0h.j9yufSo7q31LZzEwUlFpauIh6D2LVnaIv6FzYJ qkfcIVKqU_.mnezTOU2rLcDEwXP2xmT1aWX46pwpcHD5V2B8_phL4z47LvDTq41KfEfb85a3tY.m bsRYY41AOgsQtllAfLeUE5NB.0X15.3xDGISxCSUsRxknRPs.SuEdVeQDOlvynKE5m0YWWQ2b8A2 sHLjbMtgVrl_J9GPr6PXOmOt.BaY6evAmfH6_EQhyp_n1UlxVqCem5KKXut8G7IBQy4aJ9Jj4Fqv 5Xe8nGnKpuwFH3YHmNGyq6cd0Z3YHxFEQmz4tx935EjzITRdrjrs1I__CW4ZGXeW7vAp5AOZdC9N rLsrxAtcEHXvEL7wCYHMhlJz86fxHVZrXNwMbPVIkxqUEZEkWogrZ7sZmVyh4NEEHs_Sx.ncJruc Kq9y6Z4w6WFGNAhgn2ZXPYY8YGez3KntxJ2mRx37kv5s90jb4.yHHH5kZnRE9cYEgzLvd1s9vVd0 dyT8aGz.nvMpuCCAtxnXDA4y7VZDdvAsIz4NCaT39x.ACqic9py7mYxq8HSmKw7J1aN6IRJEywqt zZHWQbuZyzEAvH30lLE2qF_lfM.rp0w9muPjpGZws3dLcrIiQEzWFAqNFSEYl12fLMx81zud6.rX 7oXoQOK.2onFVEGPjBb4KYKsHwDIk5Sb80I_N1djkVhIylx_Sr4brEmXn7wUDv4tjkVEo6fV3nEJ FWNKUqr_mgJWpU8v1dLUdQcq7y4Q3mUsWpqO9Xp.NBz3Ax.cwzn0zEAgDMfYrlZek0aSv6NPrjhz 3w9.t8_VEggVQmPaerqQSNikGGd9ueDEmqFdkOhZzDUBcyB_6kn2tynYKabstboSfTtB00A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 22 Feb 2019 14:02:49 +0000 Received: from 208.72.78.175 (EHLO [192.168.50.169]) ([208.72.78.175]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cf6527408162a17b70d3840d2a68d4aa; Fri, 22 Feb 2019 14:02:49 +0000 (UTC) To: David Waite , Aaron Parecki Cc: OAuth WG References: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> From: George Fletcher Organization: AOL LLC Message-ID: <3367c77f-e635-3443-1833-b23018e6795e@aol.com> Date: Fri, 22 Feb 2019 09:02:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="------------C08123472035EAB02EAB482C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 14:02:54 -0000 This is a multi-part message in MIME format. --------------C08123472035EAB02EAB482C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 for using 429 On 2/22/19 2:09 AM, David Waite wrote: > I don’t believe that any of the currently registered error codes are > appropriate for indicating that the password request is invalid, let > alone a more specific behavior like rate limiting. > > It is also my opinion that 400 Bad Request shouldn’t be used for known > transient errors, but rather for malformed requests - the request > could very well be correct (and have the correct password), but it is > being rejected due to temporal limits placed on the client or network > address/domain. > > So I would propose a different statuses such 401 to indicate the > username/password were invalid, and either 429 (Too many requests) or > 403 (Forbidden) when rate limited or denied due to too many attempts. > Thats not to say that the body of the response can’t be an > OAuth-format JSON error, possibly with a standardized code - but again > I don’t think the currently registered codes would be appropriate for > conveying that. > > That said, I don’t know what interest there would be in standardizing > such codes, considering the existing recommendations against using > this grant type. > > -DW > >> On Feb 21, 2019, at 10:57 PM, Aaron Parecki > > wrote: >> >> The OAuth password grant section mentions taking appropriate measures >> to rate limit password requests at the token endpoint. However the >> error responses section ( >> https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an >> error code to use if the request is being rate limited.. What's the >> recommended practice here? Thanks! >> >> Aaron >> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------C08123472035EAB02EAB482C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1 for using 429

On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn’t be used for known transient errors, but rather for malformed requests - the request could very well be correct (and have the correct password), but it is being rejected due to temporal limits placed on the client or network address/domain.

So I would propose a different statuses such 401 to indicate the username/password were invalid, and either 429 (Too many requests) or 403 (Forbidden) when rate limited or denied due to too many attempts. Thats not to say that the body of the response can’t be an OAuth-format JSON error, possibly with a standardized code - but again I don’t think the currently registered codes would be appropriate for conveying that.

That said, I don’t know what interest there would be in standardizing such codes, considering the existing recommendations against using this grant type.

-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki <aaron@parecki.com> wrote:

The OAuth password grant section mentions taking appropriate measures to rate limit password requests at the token endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an error code to use if the request is being rate limited.. What's the recommended practice here? Thanks!

Aaron

--
----
Aaron Parecki

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


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

--------------C08123472035EAB02EAB482C-- From nobody Fri Feb 22 06:53:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ABC1200D7 for ; Fri, 22 Feb 2019 06:53:23 -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=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tapvoTSI2o9n for ; Fri, 22 Feb 2019 06:53:20 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6799130DBE for ; Fri, 22 Feb 2019 06:53:19 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id e24so3287852itl.1 for ; Fri, 22 Feb 2019 06:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbJQFzibWcjjFHIWTK8XGj44bKGAbG49iabZ7Xq0AtU=; b=wvmG1eMUwxCJOnZsBfL2btYV6b8SHJ7MCCqi6SonGTfRGjymqIkQhzjVGKOCKUYTY1 l3KOD5psZJI8zR5u7IuLl4cXf5CfwbDJjr8EiRa4AOUmI/rR34FK4BDua1Q4JbOMTR9V litkDtSvgymXY/mE0Uujqw/dSkknk/tTkmuuAG58oOTKagqKe5vfOplI9YznzIuPucFl GAkzV5RyNGVYik9ekT0YU0orR5imprjvkmwpEgy33VzGmeNugMB1+XvO5iOs3D+fKrq/ Bm4x38ijLkLk/iLAthX2dCqszpeEw5Jq5snQp06uT1om0Nos769z7Pys/D1k6N3Sa600 X5Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbJQFzibWcjjFHIWTK8XGj44bKGAbG49iabZ7Xq0AtU=; b=ZFaNx2H7VOe/bygIToYiSZ5cRltWNlGYaKPyLJx4kHRJ3PKbxkK0ubbtv2goZGd8/g GuH8SMhJiRMgYaREsRUiXVDrPFjnv7x4TX8iUa2VkY+g/FGxBKLXNfsXyRvctRiGubsQ qaN7uozKd/+WQiPsQuUaTxwZg2P2SoKUSX/2dZpwBiRg5QH0wli+Xgy2BItmXqFKn2g8 t6/Be88wbDnzh93t3PBvNV6cwj1NJGgq+jACFP/7xl4q+Ug3BVDB/8pEgE6+qW2elmUF 1Q2EPpiY3/PZiZ2RymdpUViPuOP8NKHhdJ8SC5LlqkP23h83IEUiUNOFvfaSHXrDU6j3 Mrmw== X-Gm-Message-State: AHQUAuaptlN2/vWOn/a33T+ccQsp5ym4CZz5HNYjeTDNS7JN1sIPl4EN oXo6cFCfnT7E01cQEBRI7VCYb4jRCfA= X-Google-Smtp-Source: AHgI3IaW9fSYreRnYtMIyHlH2Evecm8O4EwkDGoBm8wbwhFy/aQC84xQzIpcF4v7xFu3Y8jcjZlykg== X-Received: by 2002:a05:660c:d4:: with SMTP id q20mr2561137itk.21.1550847198537; Fri, 22 Feb 2019 06:53:18 -0800 (PST) Received: from mail-it1-f173.google.com (mail-it1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id u24sm577304ior.59.2019.02.22.06.53.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 06:53:16 -0800 (PST) Received: by mail-it1-f173.google.com with SMTP id x131so3269656itc.3 for ; Fri, 22 Feb 2019 06:53:16 -0800 (PST) X-Received: by 2002:a02:308:: with SMTP id y8mr2563189jad.142.1550847196645; Fri, 22 Feb 2019 06:53:16 -0800 (PST) MIME-Version: 1.0 References: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> <3367c77f-e635-3443-1833-b23018e6795e@aol.com> In-Reply-To: <3367c77f-e635-3443-1833-b23018e6795e@aol.com> From: Aaron Parecki Date: Fri, 22 Feb 2019 06:53:05 -0800 X-Gmail-Original-Message-ID: Message-ID: To: George Fletcher Cc: David Waite , OAuth WG Content-Type: multipart/alternative; boundary="00000000000041d02d05827cc050" Archived-At: Subject: Re: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 14:53:24 -0000 --00000000000041d02d05827cc050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HTTP 429 sounds fine for the HTTP response code, but what about the OAuth error code string? "invalid_grant" seems closest but doesn't sound right because if the app tries the same request again later it would be valid. On Fri, Feb 22, 2019 at 6:02 AM George Fletcher wrote: > +1 for using 429 > > > On 2/22/19 2:09 AM, David Waite wrote: > > I don=E2=80=99t believe that any of the currently registered error codes = are > appropriate for indicating that the password request is invalid, let alon= e > a more specific behavior like rate limiting. > > It is also my opinion that 400 Bad Request shouldn=E2=80=99t be used for = known > transient errors, but rather for malformed requests - the request could > very well be correct (and have the correct password), but it is being > rejected due to temporal limits placed on the client or network > address/domain. > > So I would propose a different statuses such 401 to indicate the > username/password were invalid, and either 429 (Too many requests) or 403 > (Forbidden) when rate limited or denied due to too many attempts. Thats n= ot > to say that the body of the response can=E2=80=99t be an OAuth-format JSO= N error, > possibly with a standardized code - but again I don=E2=80=99t think the c= urrently > registered codes would be appropriate for conveying that. > > That said, I don=E2=80=99t know what interest there would be in standardi= zing such > codes, considering the existing recommendations against using this grant > type. > > -DW > > On Feb 21, 2019, at 10:57 PM, Aaron Parecki wrote: > > The OAuth password grant section mentions taking appropriate measures to > rate limit password requests at the token endpoint. However the error > responses section ( > https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an error > code to use if the request is being rate limited.. What's the recommended > practice here? Thanks! > > Aaron > > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- ---- Aaron Parecki aaronparecki.com @aaronpk --00000000000041d02d05827cc050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HTTP 429 sounds fine for the HTTP response code, but= what about the OAuth error code string? "invalid_grant" seems cl= osest but doesn't sound right because if the app tries the same request= again later it would be valid.



On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <= gffletch@aol.com> wrote:
=20 =20 =20
+1 for using 429


On 2/22/19 2:09 AM,= David Waite wrote:
=20
I don=E2=80=99t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn=E2=80=99t be used = for known transient errors, but rather for malformed requests - the request could very well be correct (and have the correct password), but it is being rejected due to temporal limits placed on the client or network address/domain.

So I would propose a different statuses such 401 to indicate the username/password were invalid, and either 429 (Too many requests) or 403 (Forbidden) when rate limited or denied due to too many attempts. Thats not to say that the body of the response can=E2=80=99t be an OAuth-format JSON error, possibly with= a standardized code - but again I don=E2=80=99t think the currently registered codes would be appropriate for conveying that.

That said, I don=E2=80=99t know what interest there would be in standardizing such codes, considering the existing recommendations against using this grant type.

-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki <aa= ron@parecki.com> wrote:

The OAuth password grant section mentions taking appropriate measures to rate limit password requests at the token endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2= ) doesn't mention an error code to use if the request i= s being rate limited.. What's the recommended practice here? Thanks!

Aaron

--
----
Aaron Parecki

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


___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth

--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--00000000000041d02d05827cc050-- From nobody Fri Feb 22 07:30:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94271276D0 for ; Fri, 22 Feb 2019 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxJ1zZaNyCzN for ; Fri, 22 Feb 2019 07:29:55 -0800 (PST) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6CE130E95 for ; Fri, 22 Feb 2019 07:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550849391; bh=LIPHt4pxq4x233UpDXCysm3ci9f3FL2CNumiBjgqbqM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=YwClaR1bMwUd3MMd3AkaeooyTkTV0rnqnerE0MBTTUNRE7gs8d8vPX25IOJDiWAjgmH1HmBXQwu4jimXo5Uus3XOoKKw2J3CywdDrFPaWrz/MMKJ+do8Apn9TXOaTruS5kbGBOIyaFfob3lzHxTFVMjgxlaqjIofyuG9hT5d3feLtg9tpzVXvhSyLCdHGzIJVRYfZOV3/fytoVJW+cBzOmw+VjPqFZPkfaBSMdu0VQK9Iq5We4UUmnxC3LNo1ChayDEUGMPTWcycUTeG4V1/vDMipBZHMmqVkSw8HHN22kiIgxajBtJ62Ph1Igp2QhyHk6/8hDoFK6l5/Y38POgO8w== X-YMail-OSG: ExZscJIVM1k.eGenzxWiaML9mZ8nBUVC6VFZNcRfSzgCN4YIhvbJrfLQnsbA3T2 aIV4X5JoEJBOxYQv_To22lvQ7sdt9_xtlsFBNWk6AXgQjAGV2HCWCctVcWJ3BjAGR6CRem_qGa.1 H_49UNzd8ZiVKzSeOGBeFBtTq_tRRaf7IqyXejjCajEOM8T5v61NKciB7ZJlBiv6l6bb1C5FyZ82 0kIPBn9Vrgo0OrgKa609YD.cGwCF_pyoB30tu.Fw.Yu4ylYEtAu5Z4kFL3xukcOHfq4S54vPzWD2 rQU4HjG7p4BGI_sRJWv9ydcTDNP3XNzdWGl7tOD0k22en0qbOepObyK0QIAzFCC1Hk9cs8xi4qe0 WRw3z3tSbR4gMIvdPI6D74M4gXwtN2z7cS9Won3VBkNxDLCmnZffFdtIjh78MvT8jy4P8IBxtPs4 q6_udx7RwvqlICMPXAmak3j7FQE0VUu29BhgSw96sLS3cvmz0zGUCRg4_Ft0jct2CaKl5IE9DORV MRXZvna.RyhVnUDn2PrOEX0jqLAdyDI8J83fDvCy2RTL64cBwahHKVDnAF3n0PRuOj54CDfLZ79T iEUdSc7Ia..a16JBMFXiq_RX0bcWaDBgm_DXKoZ7vve6QQSoUumzCeO5pfTvkscmRyBvDFtKcCg9 Uv9A2bg2IbhNgxJ434Aly.log7pG_NhVLmDBNoeGL.5Izw6T1h8cfHYFwsqL32Kgm66J1VcKJEnL 0IO_Kr5F44qwl1uQyE54zf5z1x8ZwEu1XHlL7iB_ZU5GsieW.M3yrwXO2J9mUZeixdBXgL22vKjt O1P1HV3DcDkQOgfrqoS7mmDbpnM97VIbiELYwsLgDWt3yRl.P5myS2d564FALvWGNWdDnXQEz8YO mC1K5b.El9pN8W1E90g2lMI0GiEQO..JYsMqmOYyk3a.PU3Vhs72C4zo48qAF712vTFbMR5r9quv mC5k94VqpZqLvMR31Men3cK8zbTmagexlp_6qNDa8eKl.kP4e_ZrLRBWAQKr1eG4w0TlE8RS1s6p C630_dJld44uQISyqK5pG90ziL7EixttacpuB149ILyXJgaW6.UhxdvTgqvb.oENRYHl.vWY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 22 Feb 2019 15:29:51 +0000 Received: from nat-vpn-users1.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.141.144]) ([184.165.8.96]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 80ac816fc015f527b3a33a66092ea95e; Fri, 22 Feb 2019 15:29:48 +0000 (UTC) To: Aaron Parecki Cc: David Waite , OAuth WG References: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> <3367c77f-e635-3443-1833-b23018e6795e@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 22 Feb 2019 10:29:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C2AC670F448DCF3903DFBFA4" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:30:02 -0000 This is a multi-part message in MIME format. --------------C2AC670F448DCF3903DFBFA4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I believe Torsten proposed an "authentication_failed" error response in a different context. Possibly we could use that? Alternatively, OpenID Connect defines a 'login_required' error that could work in this context as well. It doesn't fit the semantic as defined in the OIDC spec, but as an error would work. If we need to use an existing OAuth2 error code, then I'd recommend 'invalid_request' in that the request is invalid because there are too many of them which is indicated by the 429 HTTP error code. On 2/22/19 9:53 AM, Aaron Parecki wrote: > HTTP 429 sounds fine for the HTTP response code, but what about the > OAuth error code string? "invalid_grant" seems closest but doesn't > sound right because if the app tries the same request again later it > would be valid. > > > > On Fri, Feb 22, 2019 at 6:02 AM George Fletcher > wrote: > > +1 for using 429 > > > On 2/22/19 2:09 AM, David Waite wrote: >> I don’t believe that any of the currently registered error codes >> are appropriate for indicating that the password request is >> invalid, let alone a more specific behavior like rate limiting. >> >> It is also my opinion that 400 Bad Request shouldn’t be used for >> known transient errors, but rather for malformed requests - the >> request could very well be correct (and have the correct >> password), but it is being rejected due to temporal limits placed >> on the client or network address/domain. >> >> So I would propose a different statuses such 401 to indicate the >> username/password were invalid, and either 429 (Too many >> requests) or 403 (Forbidden) when rate limited or denied due to >> too many attempts. Thats not to say that the body of the response >> can’t be an OAuth-format JSON error, possibly with a standardized >> code - but again I don’t think the currently registered codes >> would be appropriate for conveying that. >> >> That said, I don’t know what interest there would be in >> standardizing such codes, considering the existing >> recommendations against using this grant type. >> >> -DW >> >>> On Feb 21, 2019, at 10:57 PM, Aaron Parecki >> > wrote: >>> >>> The OAuth password grant section mentions taking appropriate >>> measures to rate limit password requests at the token endpoint. >>> However the error responses section ( >>> https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention >>> an error code to use if the request is being rate limited.. >>> What's the recommended practice here? Thanks! >>> >>> Aaron >>> >>> -- >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > --------------C2AC670F448DCF3903DFBFA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I believe Torsten proposed an "authentication_failed" error response in a different context. Possibly we could use that?

Alternatively, OpenID Connect defines a 'login_required' error that could work in this context as well. It doesn't fit the semantic as defined in the OIDC spec, but as an error would work.

If we need to use an existing OAuth2 error code, then I'd recommend 'invalid_request' in that the request is invalid because there are too many of them which is indicated by the 429 HTTP error code.

On 2/22/19 9:53 AM, Aaron Parecki wrote:
HTTP 429 sounds fine for the HTTP response code, but what about the OAuth error code string? "invalid_grant" seems closest but doesn't sound right because if the app tries the same request again later it would be valid.



On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <gffletch@aol.com> wrote:
+1 for using 429


On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn’t be used for known transient errors, but rather for malformed requests - the request could very well be correct (and have the correct password), but it is being rejected due to temporal limits placed on the client or network address/domain.

So I would propose a different statuses such 401 to indicate the username/password were invalid, and either 429 (Too many requests) or 403 (Forbidden) when rate limited or denied due to too many attempts. Thats not to say that the body of the response can’t be an OAuth-format JSON error, possibly with a standardized code - but again I don’t think the currently registered codes would be appropriate for conveying that.

That said, I don’t know what interest there would be in standardizing such codes, considering the existing recommendations against using this grant type.

-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki <aaron@parecki.com> wrote:

The OAuth password grant section mentions taking appropriate measures to rate limit password requests at the token endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an error code to use if the request is being rate limited.. What's the recommended practice here? Thanks!

Aaron

--
----
Aaron Parecki

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


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

--
----
Aaron Parecki


--------------C2AC670F448DCF3903DFBFA4-- From nobody Fri Feb 22 07:34:30 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A97130E62 for ; Fri, 22 Feb 2019 07:34:28 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=Hos0mqGF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dsh2tE5U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E_-1F5qls5P for ; Fri, 22 Feb 2019 07:34:25 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA0B130E27 for ; Fri, 22 Feb 2019 07:34:25 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 81637236D0 for ; Fri, 22 Feb 2019 10:34:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 22 Feb 2019 10:34:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=7NPcAE/m7+zrHDHA+cY2x2Yo ZNnNm0ND3jW35dFZPRo=; b=Hos0mqGFB9mQbzLbRlHQHZPWjT+7YTzWiemKHKeD U55Hq/qbOAW53a0jYtZ4aLnRp+47OpzKtvyn26ZB+87lFCHL0ieabYqPClJ3BKsh gFA5bVvXaMbnZRSQaJRi9BWnOW1HudlB63mX/9bxHCjAwtSAGM3QPQV+QnAz9ba4 WzU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7NPcAE /m7+zrHDHA+cY2x2YoZNnNm0ND3jW35dFZPRo=; b=dsh2tE5UbRL7vkpTvYYYAJ xEV0mz6cm/WvqinXtQb5dmJNsyHFMbZalue808PrkEgPnf0tj2WxYSr5m2icFivG f/l52LVCLARdFV+3XGorR9QNhleFllsJarggQhQKwq2gAZ/1eNpJZ+CZsePuPRNv 66bWUMaVeGYUJ2fx3kgW6tXTbnDoxU3yhefEK+7CSTt15VCXrgc6NqfM7iEdEhN2 k0lTz9aKfRTkX9VoLD6aMcsRv6Mwt1na69vc7RIlOO3EPHbI0o/taCrAru5QN4vX lxuEwj5sK7hOuy9LgfPlnmyZs7tuEj+p6wWqYM54n3MXKiGkOlQC4uSjDhb6Nq2Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddruddtgdektdculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucffohhmrghinhepthifihhtthgvrhdrtghomhdpihgvthhfrdhorhhgpdgrrg hrohhnphgrrhgvtghkihdrtghomhenucfkphepudeivddrvdegledrudeifedrfedvnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesvghvvghrthhpohhtrdgtohhmnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.88.111.14] (unknown [162.249.163.32]) by mail.messagingengine.com (Postfix) with ESMTPA id 5961AE40C1 for ; Fri, 22 Feb 2019 10:34:23 -0500 (EST) To: oauth@ietf.org References: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> <3367c77f-e635-3443-1833-b23018e6795e@aol.com> From: Evert Pot Openpgp: preference=signencrypt Autocrypt: addr=me@evertpot.com; keydata= mQINBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAlQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFbkCDQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAYkCPAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA Message-ID: <9b8c80d8-9068-c7da-93eb-4c00f5e8a604@evertpot.com> Date: Fri, 22 Feb 2019 10:34:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B58C4CA750208F7349501BDF" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:34:28 -0000 This is a multi-part message in MIME format. --------------B58C4CA750208F7349501BDF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 2019-02-22 10:29 a.m., George Fletcher wrote: > I believe Torsten proposed an "authentication_failed" error response > in a different context. Possibly we could use that? > > Alternatively, OpenID Connect defines a 'login_required' error that > could work in this context as well. It doesn't fit the semantic as > defined in the OIDC spec, but as an error would work. > > If we need to use an existing OAuth2 error code, then I'd recommend > 'invalid_request' in that the request is invalid because there are too > many of them which is indicated by the 429 HTTP error code. What benefit would a specific request body serve? Should a client behave differently if they got a 429 from an intermediate oauth2-unaware proxy vs an oauth2 server that emits this body? > > On 2/22/19 9:53 AM, Aaron Parecki wrote: >> HTTP 429 sounds fine for the HTTP response code, but what about the >> OAuth error code string? "invalid_grant" seems closest but doesn't >> sound right because if the app tries the same request again later it >> would be valid. >> >> >> >> On Fri, Feb 22, 2019 at 6:02 AM George Fletcher > > wrote: >> >> +1 for using 429 >> >> >> On 2/22/19 2:09 AM, David Waite wrote: >>> I don’t believe that any of the currently registered error codes >>> are appropriate for indicating that the password request is >>> invalid, let alone a more specific behavior like rate limiting. >>> >>> It is also my opinion that 400 Bad Request shouldn’t be used for >>> known transient errors, but rather for malformed requests - the >>> request could very well be correct (and have the correct >>> password), but it is being rejected due to temporal limits >>> placed on the client or network address/domain. >>> >>> So I would propose a different statuses such 401 to indicate the >>> username/password were invalid, and either 429 (Too many >>> requests) or 403 (Forbidden) when rate limited or denied due to >>> too many attempts. Thats not to say that the body of the >>> response can’t be an OAuth-format JSON error, possibly with a >>> standardized code - but again I don’t think the currently >>> registered codes would be appropriate for conveying that. >>> >>> That said, I don’t know what interest there would be in >>> standardizing such codes, considering the existing >>> recommendations against using this grant type. >>> >>> -DW >>> >>>> On Feb 21, 2019, at 10:57 PM, Aaron Parecki >>> > wrote: >>>> >>>> The OAuth password grant section mentions taking appropriate >>>> measures to rate limit password requests at the token endpoint. >>>> However the error responses section ( >>>> https://tools.ietf.org/html/rfc6749#section-5.2) doesn't >>>> mention an error code to use if the request is being rate >>>> limited.. What's the recommended practice here? Thanks! >>>> >>>> Aaron >>>> >>>> -- >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------B58C4CA750208F7349501BDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 2019-02-22 10:29 a.m., George Fletcher wrote:
I believe Torsten proposed an "authentication_failed" error response in a different context. Possibly we could use that?

Alternatively, OpenID Connect defines a 'login_required' error that could work in this context as well. It doesn't fit the semantic as defined in the OIDC spec, but as an error would work.

If we need to use an existing OAuth2 error code, then I'd recommend 'invalid_request' in that the request is invalid because there are too many of them which is indicated by the 429 HTTP error code.

What benefit would a specific request body serve?

Should a client behave differently if they got a 429 from an intermediate oauth2-unaware proxy vs an oauth2 server that emits this body?



On 2/22/19 9:53 AM, Aaron Parecki wrote:
HTTP 429 sounds fine for the HTTP response code, but what about the OAuth error code string? "invalid_grant" seems closest but doesn't sound right because if the app tries the same request again later it would be valid.



On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <gffletch@aol.com> wrote:
+1 for using 429


On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn’t be used for known transient errors, but rather for malformed requests - the request could very well be correct (and have the correct password), but it is being rejected due to temporal limits placed on the client or network address/domain.

So I would propose a different statuses such 401 to indicate the username/password were invalid, and either 429 (Too many requests) or 403 (Forbidden) when rate limited or denied due to too many attempts. Thats not to say that the body of the response can’t be an OAuth-format JSON error, possibly with a standardized code - but again I don’t think the currently registered codes would be appropriate for conveying that.

That said, I don’t know what interest there would be in standardizing such codes, considering the existing recommendations against using this grant type.

-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki <aaron@parecki.com> wrote:

The OAuth password grant section mentions taking appropriate measures to rate limit password requests at the token endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an error code to use if the request is being rate limited.. What's the recommended practice here? Thanks!

Aaron

--
----
Aaron Parecki

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


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

--
----
Aaron Parecki



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------B58C4CA750208F7349501BDF-- From nobody Fri Feb 22 08:02:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474F2130E81 for ; Fri, 22 Feb 2019 08:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6Nt52JSf63A for ; Fri, 22 Feb 2019 08:02:19 -0800 (PST) Received: from sonic316-13.consmr.mail.bf2.yahoo.com (sonic316-13.consmr.mail.bf2.yahoo.com [74.6.130.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41661130E8C for ; Fri, 22 Feb 2019 08:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1550851338; bh=QneL/dsz0jClSBAaRh/HzVnppg08G57a1/Kmm3DrojY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=M+5iu2IE22/KcnfrbxMLFhhw5vqpnM3nVQXr3xWBY6Njn6vcr0gPQx4hRRpzJgw9aa66RSBMPpBcTv2yNwedReuJW6QkKM8zwOPSMt5MPH9HCylka1rTw/6VO6Zh2pG+DxOY+C43hyrsj7Fbt27BLDCNmlyxQZqt0wzKIUgH7XFvVXa0HTY4mlwFwS/TyAaUu6wXJYYPUXHOExe0gS0sCd551HKJsJRBrct6oXqcIh8REn4nI+EoCgXoNLfaRPrJzezUMYIwB427kz5K2qu15OfWu8uuRoXmosj+iFVgY0MOFcZwvwgHdHVM8Hb8IAwzqV0iaUlCHBcMYwDtYG4GQQ== X-YMail-OSG: TR829tsVM1lQSeJaGedjNw__VmlX6PjRE6wFIq2Pe.sIPdWkFdTzycU7QTynPOv m5fAvwJ5pdnYKZiBwshqZJnrecZr0x1odwy0csadnN4FCJwzf6pRyAX.S0rlKXu3pRjLdPQoIKGR DiUEysgClxqRppOE59.TtAIu5bYBKchB68OyAUBe9WsHixHQJ._g3cj8QUHHTdEJpk6vHg_nAe6U IgY_HI.zErhDuGDa096S198_sCIwAAAPXOhImla9JnwlIwoDdlvX5u323r14P1O_zAxonk23JuUK rJfVaP9nOnCk_6ZlF71UUzAeVKF7Dl362QsXTYp9oWkg9naROrmzO6o1eemT5NpOrL7M7_LHxZvA CGgXz6Y.2mHLRlTr7EadEGs3O5ONlcHymA.l7Im_aHL2BB3XGFwdW1b4oYofH89mDy49wXNuQ4eD jmEOtNpo52SujY9D3rgExJYpwuIQYXFqphcLEU4DrZcMijYV07etf8tI0ZEmL_GaRnpb.EnE0gkB kxJGCIYrS12UdeCwRmrgEFhly1XYikyn8AwNa7XwhgHheGLGfq0yNbXUg.uImOTFhItcdFmaX0iN JSwKht29.ARtM71NgYhvKXFOK8RDN2IkUH8fpvHK4QLuDTnaSyKJdoELwhozfsMMe73VuqXiphnK wPOzI.1Dx4.JHc1sEQOmwCHDTByl06vO.bdU92Zf1wMtSQ40yEQ1DUkGc3AMvdn0AZacBpeINRAc ohFobgQbugIpscCAWf0O2GuHt_8Zm94xQNVPc_fL8tgZTebVEbsd0sOpjDOHmoy8JCOpTGqPb8Bi iShKip_GkvS5Xfn6RSQq4otgeli5yiwG04RGk4k4_jZZ6cOyWN9whQuJKECPJu8sR0KkKaLY1Zlg qKW5kh0L4HEAGxPOXb4TKYKIUWU6EdtrMlvrx5i.A4x7bihfhgEng8M8K9v2dcs5Xl7deskgDVsl 7PAyulNGNG2Bu.tCEt06cbKijnmDNq6r5kcujuMQQCTB393Q8USk0Tdp.xiIba_icg1HmDGYOFhp mpsi.m24GzcN7tp0wNf3KDN1HBaX5m3lEZF_UvdaAe7YoMrY2SZsWv7K4WFsDOHQFXKFQuO8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 22 Feb 2019 16:02:18 +0000 Received: from nat-vpn-users1.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.141.144]) ([184.165.8.96]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 15359ef54e60ae263f898c7ac2b6c7b2; Fri, 22 Feb 2019 16:02:15 +0000 (UTC) To: Evert Pot , oauth@ietf.org References: <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> <3367c77f-e635-3443-1833-b23018e6795e@aol.com> <9b8c80d8-9068-c7da-93eb-4c00f5e8a604@evertpot.com> From: George Fletcher Organization: AOL LLC Message-ID: <0ab5af16-a466-e621-04ab-0f260987ba0c@aol.com> Date: Fri, 22 Feb 2019 11:02:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <9b8c80d8-9068-c7da-93eb-4c00f5e8a604@evertpot.com> Content-Type: multipart/alternative; boundary="------------65D0FDB1881B68CB8A7802BE" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Correct error code for rate limiting? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 16:02:22 -0000 This is a multi-part message in MIME format. --------------65D0FDB1881B68CB8A7802BE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Excellent point! The specs (OAuth2 and OIDC) are completely silent on what should happen if an HTTP transport error occurs. Maybe that whole space should have it's own blog post:) Regardless of the OAuth2/OIDC error code, clients already have to deal with HTTP codes like 503 "Service Unavailable", or 504 "Gateway timed out" which will not have any of the OAuth2 level error response data. Given a rate-limiting condition is a transport condition and not a protocol condition, I'd be fine with not returning any protocol error data and require the client to handle the transport conditions correctly. Thanks, George On 2/22/19 10:34 AM, Evert Pot wrote: > On 2019-02-22 10:29 a.m., George Fletcher wrote: >> I believe Torsten proposed an "authentication_failed" error response >> in a different context. Possibly we could use that? >> >> Alternatively, OpenID Connect defines a 'login_required' error that >> could work in this context as well. It doesn't fit the semantic as >> defined in the OIDC spec, but as an error would work. >> >> If we need to use an existing OAuth2 error code, then I'd recommend >> 'invalid_request' in that the request is invalid because there are >> too many of them which is indicated by the 429 HTTP error code. > > What benefit would a specific request body serve? > > Should a client behave differently if they got a 429 from an > intermediate oauth2-unaware proxy vs an oauth2 server that emits this > body? > > >> >> On 2/22/19 9:53 AM, Aaron Parecki wrote: >>> HTTP 429 sounds fine for the HTTP response code, but what about the >>> OAuth error code string? "invalid_grant" seems closest but doesn't >>> sound right because if the app tries the same request again later it >>> would be valid. >>> >>> >>> >>> On Fri, Feb 22, 2019 at 6:02 AM George Fletcher >> > wrote: >>> >>> +1 for using 429 >>> >>> >>> On 2/22/19 2:09 AM, David Waite wrote: >>>> I don’t believe that any of the currently registered error >>>> codes are appropriate for indicating that the password request >>>> is invalid, let alone a more specific behavior like rate limiting. >>>> >>>> It is also my opinion that 400 Bad Request shouldn’t be used >>>> for known transient errors, but rather for malformed requests - >>>> the request could very well be correct (and have the correct >>>> password), but it is being rejected due to temporal limits >>>> placed on the client or network address/domain. >>>> >>>> So I would propose a different statuses such 401 to indicate >>>> the username/password were invalid, and either 429 (Too many >>>> requests) or 403 (Forbidden) when rate limited or denied due to >>>> too many attempts. Thats not to say that the body of the >>>> response can’t be an OAuth-format JSON error, possibly with a >>>> standardized code - but again I don’t think the currently >>>> registered codes would be appropriate for conveying that. >>>> >>>> That said, I don’t know what interest there would be in >>>> standardizing such codes, considering the existing >>>> recommendations against using this grant type. >>>> >>>> -DW >>>> >>>>> On Feb 21, 2019, at 10:57 PM, Aaron Parecki >>>> > wrote: >>>>> >>>>> The OAuth password grant section mentions taking appropriate >>>>> measures to rate limit password requests at the token >>>>> endpoint. However the error responses section ( >>>>> https://tools.ietf.org/html/rfc6749#section-5.2) doesn't >>>>> mention an error code to use if the request is being rate >>>>> limited.. What's the recommended practice here? Thanks! >>>>> >>>>> Aaron >>>>> >>>>> -- >>>>> ---- >>>>> Aaron Parecki >>>>> aaronparecki.com >>>>> @aaronpk >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> -- >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------65D0FDB1881B68CB8A7802BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Excellent point! The specs (OAuth2 and OIDC) are completely silent on what should happen if an HTTP transport error occurs. Maybe that whole space should have it's own blog post:)

Regardless of the OAuth2/OIDC error code, clients already have to deal with HTTP codes like 503 "Service Unavailable", or 504 "Gateway timed out" which will not have any of the OAuth2 level error response data.

Given a rate-limiting condition is a transport condition and not a protocol condition, I'd be fine with not returning any protocol error data and require the client to handle the transport conditions correctly.

Thanks,
George
 

On 2/22/19 10:34 AM, Evert Pot wrote:
On 2019-02-22 10:29 a.m., George Fletcher wrote:
I believe Torsten proposed an "authentication_failed" error response in a different context. Possibly we could use that?

Alternatively, OpenID Connect defines a 'login_required' error that could work in this context as well. It doesn't fit the semantic as defined in the OIDC spec, but as an error would work.

If we need to use an existing OAuth2 error code, then I'd recommend 'invalid_request' in that the request is invalid because there are too many of them which is indicated by the 429 HTTP error code.

What benefit would a specific request body serve?

Should a client behave differently if they got a 429 from an intermediate oauth2-unaware proxy vs an oauth2 server that emits this body?



On 2/22/19 9:53 AM, Aaron Parecki wrote:
HTTP 429 sounds fine for the HTTP response code, but what about the OAuth error code string? "invalid_grant" seems closest but doesn't sound right because if the app tries the same request again later it would be valid.



On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <gffletch@aol.com> wrote:
+1 for using 429


On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error codes are appropriate for indicating that the password request is invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn’t be used for known transient errors, but rather for malformed requests - the request could very well be correct (and have the correct password), but it is being rejected due to temporal limits placed on the client or network address/domain.

So I would propose a different statuses such 401 to indicate the username/password were invalid, and either 429 (Too many requests) or 403 (Forbidden) when rate limited or denied due to too many attempts. Thats not to say that the body of the response can’t be an OAuth-format JSON error, possibly with a standardized code - but again I don’t think the currently registered codes would be appropriate for conveying that.

That said, I don’t know what interest there would be in standardizing such codes, considering the existing recommendations against using this grant type.

-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki <aaron@parecki.com> wrote:

The OAuth password grant section mentions taking appropriate measures to rate limit password requests at the token endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an error code to use if the request is being rate limited.. What's the recommended practice here? Thanks!

Aaron

--
----
Aaron Parecki

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


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

--
----
Aaron Parecki



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


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

--------------65D0FDB1881B68CB8A7802BE-- From nobody Fri Feb 22 16:26:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A073130EA7 for ; Fri, 22 Feb 2019 16:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34m6sJW_fFpk for ; Fri, 22 Feb 2019 16:26:12 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650128.outbound.protection.outlook.com [40.107.65.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DDD130E8A for ; Fri, 22 Feb 2019 16:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X1GktHGFAi9aBxX/Q8uEPoaBIHrlmo7j8TQbQJUCdUM=; b=ml6JVUp/xulycWB21iM2eVmPGn2nTPLiV80lOPlF/GDqsKIrnv9agF8xhomU/s7Qw3651hJLED0aYolCf/mymTxoWsO5lecNFQ+lRsZpffthvYnz9lzimLVsx8Wj9yTDpMUyrhfmDluYjGgplauuylSrNtO4hhl+URW58ClfuXc= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0425.namprd00.prod.outlook.com (52.132.149.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.0; Sat, 23 Feb 2019 00:26:08 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::c5ca:88ae:3151:1a2b]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::c5ca:88ae:3151:1a2b%6]) with mapi id 15.20.1691.000; Sat, 23 Feb 2019 00:26:08 +0000 From: Mike Jones To: Eric Rescorla , oauth Thread-Topic: [OAUTH-WG] Fwd: AD Review of draft-ietf-oauth-jwt-bcp Thread-Index: AQHUmgS5HCXki7ZWEES4qXJnBTIH5KXs4wrQ Date: Sat, 23 Feb 2019 00:26:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-23T00:26:05.4470465Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0aaf7f4a-3dcc-425d-be56-e398b6573d10; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-originating-ip: [2001:4898:80e8:b:e160:ebcf:ab0e:5b5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21cc8090-6bb9-43f9-bb79-08d699258162 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600126)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR00MB0425; x-ms-traffictypediagnostic: MW2PR00MB0425: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNVzJQUjAwTUIwNDI1OzIzOjZBK0czQ3hPOVdHYlEzbS94Zi9zMzF1Z243?= =?utf-8?B?TjBGM3ZsWEplUlNkUDA1ejA3RCtrQmkyUjRyL1pQQXY1QUF0NVk2c1VxY0ZM?= =?utf-8?B?U3AwM0EyZ29QZ1FDYWpoamgxQTA3ZFlTMDZHNC9nM3FkQ0lyOEtFa0tPaTMr?= =?utf-8?B?YmQ0eVZCS1dDeDJmMVlicGZKb2JwSXR2bkM3MjNuZlRmc0lIejVUNFRLUzVD?= =?utf-8?B?dzFpRk5SM1VWdGgyaUdndkVNZFhLVlowR2lBTXI1UzN3L0x1WG1lQ2hnZ0pN?= =?utf-8?B?S1dDTk94TDllYmpTVDZvK2w3QjhBbnJDaVJiei8yaWlaM1c2WlhPcVNscDJv?= =?utf-8?B?QXZjNGZqSWw2ZnJERGxyN2o1T25xMXowNzkxQkEwL2xBVWZmSzBUcUZBemdQ?= =?utf-8?B?TUkvNGhhR1R1VU15T3laSlZxdlBsQUUvT3djNk5EYWRXdFlsbjJVWXBQYnF3?= =?utf-8?B?V0ZZbGNtdWx1QkVUZndNZHZKWkt6L0JaVThQSWU0TkRvVnhWdzdoN3VYa1NY?= =?utf-8?B?OVV0bHRLRlJWanF5R0hvWjFMblR6STBJK1NwUkh1eUcrMHlvRVhyRmNhdjBj?= =?utf-8?B?bnpnNFA1T1JnczdsUkxrTy9Ub1dJdm5xWUgxUXNRN25WYzN2WkRyNFUrM2t1?= =?utf-8?B?WGQxell4d0dsQ2lDM29DOWtydWxGTGxSQ1JMZ0JKdlpwVURxWnoyUXFZdk5C?= =?utf-8?B?STNCcU9jMDE4WnAydUpBSHdEMlVWM3hUeXJKZVNNRENScFluZE01ZnAyZi9O?= =?utf-8?B?cDE1RDBjdFRkNGZxVURpSGpzY0R2REY3TWdValBjSk5PVHAxSVY1ZitoSkJR?= =?utf-8?B?YW8rSmZRaG5ObDc4Y0xlSmdqRk5mZ1BZcGRlQzlFdjJOZWpEOXhvT1M0bG13?= =?utf-8?B?b0EweFIzN3FLRmQ5V2MzTEFBNytHQW5PZmxUakR3c0FiY2ExU2FIM3lHSmc1?= =?utf-8?B?MnV0UUI1dkV0MUVhbmdIUnZDeUlOdzlGMHhEQ1pXMStnYWp0TWFOMlRMSWpD?= =?utf-8?B?TW5wT0ZuRzNrNUJOcUkxSVByRmhJVDI5VWppZndNbzc1RURjUHZhUzBHTlpm?= =?utf-8?B?ejYwLy9Wd3B3czNaakc0cDFkUHp2eGFqWlhrK0dxVGRRc0pqNWgxdU5pUDdU?= =?utf-8?B?UFEycGRXNXdvTm00Q1AwUHZDUFFHR2FJZlp2cy9yb1JNTlQ4YlJ6MUtKUExT?= =?utf-8?B?clVEeUMwanVpb0xYZFB6NDZobkMwb0xQditrUVRiazdmOXovZkpFMWhGVnp2?= =?utf-8?B?a0tDS3BkcUZ3N1JnbTEyWkFXR3BXZUgwT3lRelZhZm9aOGdab2N2SjErWDhz?= =?utf-8?B?OFFJWDl5NXREeFlqRXpLMXJkSnRBQXZkQXpucm5kUk94MlZ3dWZDSGJUaHkz?= =?utf-8?B?cXJ1bDdCTkRtSUVTTDBzOTR0VGV6RStDT09CbmcwYU4wd2RWSkRQalhjZVRw?= =?utf-8?B?ZklmeUdncmNPZEtUKzdibjk4SlhTdWZjTWxOU2l4TzBPbTQxdkE5M2kzdzVk?= =?utf-8?B?S2JzQ3VQS0pUdjY2bFVHblBwTUdaQnN0dHNBbC9ZVFNQamhMYnByRkR1OGhW?= =?utf-8?B?d0RweWt3RHFNUnUxVGtpOFpQM3dJcFkrcUJxQURYUW9QNzJhRWhwTVVaMzE4?= =?utf-8?B?d2FXVmM2NlNYY3Q0MmtHdDBvYi9VS2ZPc21PNTRIYmFSWjRPR1YwcDF6M0tq?= =?utf-8?B?N3IyaXkyaDdrWTd5NnRTbzJTMzMwZEFWaFkxRVpvZXMzWk5rM0dPS2JwQlE0?= =?utf-8?B?WHN2dWZNaEdQcnpVSnRISlEwbmJQWFhHYTYwYkJBSURObUFWY0xQc1FQWE5t?= =?utf-8?B?UXhEckU4NE1vR0pYd0F3SUU2dEJ2VWwxWEdmZHlmdGpWMjQzOFp3WjREbFNT?= =?utf-8?B?N1E0cXN2aVVVd3UxdGdYTUgydlJna2NsTkVsT3lCcTlnclNEQ1hZS3FuVjd3?= =?utf-8?B?QThKVVZGelpaK292SmhkSFN0MjZ1VXhQSlVwTlZoYWZnckdSWDRRK0poWVpF?= =?utf-8?Q?xjqt+C?= x-microsoft-antispam-prvs: x-forefront-prvs: 0957AD37A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(376002)(366004)(136003)(22974007)(199004)(189003)(256004)(86362001)(71190400001)(74316002)(8936002)(9326002)(106356001)(33656002)(86612001)(105586002)(71200400001)(53546011)(5660300002)(14444005)(10290500003)(6506007)(68736007)(72206003)(102836004)(76176011)(6346003)(790700001)(6116002)(22452003)(316002)(110136005)(8990500004)(606006)(7696005)(966005)(6246003)(478600001)(53936002)(97736004)(99286004)(81156014)(81166006)(229853002)(186003)(236005)(11346002)(6436002)(9686003)(54896002)(46003)(6306002)(486006)(446003)(476003)(8676002)(55016002)(10090500001)(25786009)(14454004)(7736002)(2906002)(52536013); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0425; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5WJ/sQ8cXMUMTfGivttjMu1byEV2Wxh7H9xDyf0QCF69ZUQzWi1UUgFAhXxMIqM8ynuLY6HpCko+Coxfs6FIhruJdFApTdNSvya+EO5i5VgBo/nLTDoezPszpWpKY6PQ/LNKU5d21tTtL8sktJ5/FYvcGpJs7VoAvjzGtSSKJmCM++LJKD/FHUAIh+ZqYTSi7go4GXIqMNl0zj2/brtRfUMA68UP1A17CVzx84JgOzftsssLUXeSJmxigC1NIn4H4r7Jsv8JnsLzsB13cGCNVUyEidHwhXEOdgNLitdPUWSfkW+EzS91sVx/hAcIBdxZPCxyevXq6jOkq+wIhaobTonwmoCXfx0xi3rWMkCghY6z0ZHX+UXDdsvKnKdoElRyEESweFWWJk1RgVdyPKtZEW/hoy68QldB2hYBzUlfLbI= Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0298833CAEA7EA389FB935F5F5780MW2PR00MB0298namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21cc8090-6bb9-43f9-bb79-08d699258162 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2019 00:26:08.1715 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0425 Archived-At: Subject: Re: [OAUTH-WG] Fwd: AD Review of draft-ietf-oauth-jwt-bcp X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:26:24 -0000 --_000_MW2PR00MB0298833CAEA7EA389FB935F5F5780MW2PR00MB0298namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KUmVwbGllcyBhcmUgaW5saW5lIGJlbG93LCBwcmVmaXhlZCBieSDigJxNaWtl PuKAnS4gIEluIHN1bW1hcnksIHVubGVzcyB5b3Ugd2FudCB0byBzZWUgYWRkaXRpb25hbCB0ZXh0 IGFkZGVkIGdpdmluZyBleGFtcGxlcyBvZiBzdWJzdGl0dXRpb24gYXR0YWNrcywgSSBiZWxpZXZl IHRoYXQgLTA0IGFkZHJlc3NlZCBhbGwgb2YgeW91ciByZXZpZXcgY29tbWVudHMuICBMZXQgdXMg a25vdywgYW5kIGlmIHNvLCB3ZeKAmWxsIHR1cm4gdGhlIGNyYW5rIGFuZCBwdWJsaXNoIGFuIC0w NSBkb2luZyBzby4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNj b3JsYQ0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDIyLCAyMDE4IDY6NDIgQU0NClRvOiBvYXV0 aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIEZ3ZDogQUQgUmV2aWV3IG9m IGRyYWZ0LWlldGYtb2F1dGgtand0LWJjcA0KDQpDQ2luZyB0aGUgV0cgYmVjYXVzZSBJIHdhcyB3 cm9uZyBhYm91dCB0aGUgYWxpYXNlcy4NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0t LS0tLS0tDQpGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZt LmNvbT4+DQpEYXRlOiBTdW4sIEF1ZyAyNiwgMjAxOCBhdCAyOjAyIFBNDQpTdWJqZWN0OiBBRCBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwDQpUbzogb2F1dGggPG9hdXRoQGlldGYu b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQoNClJpY2ggdmVyc2lvbiBvZiB0aGlzIHJldmll dyBhdDoNCmh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0NjQ5DQoN Cg0KQ09NTUVOVFMNClMgMS4yLg0KPiAgIDEuMi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBk b2N1bWVudA0KPg0KPiAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVR VUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCj4gICAgICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZA0KPiAgICAg ICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVz Y3JpYmVkIGluDQo+ICAgICAgW1JGQzIxMTldLg0KDQpZb3Ugd2lsbCB3YW50IHRvIGNpdGUgODE3 NCBoZXJlLg0KDQpNaWtlPiBUaGlzIHdhcyBkb25lIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3AtMDQuDQoNClMgMi42Lg0KPg0KPiAgIDIuNi4g IFN1YnN0aXR1dGlvbiBBdHRhY2tzDQo+DQo+ICAgICAgVGhlcmUgYXJlIGF0dGFja3MgaW4gd2hp Y2ggb25lIHJlY2lwaWVudCB3aWxsIGhhdmUgYSBKV1QgaW50ZW5kZWQgZm9yDQo+ICAgICAgaXQg YW5kIGF0dGVtcHQgdG8gdXNlIGl0IGF0IGEgZGlmZmVyZW50IHJlY2lwaWVudCB0aGF0IGl0IHdh cyBub3QNCj4gICAgICBpbnRlbmRlZCBmb3IuICBJZiBub3QgY2F1Z2h0LCB0aGVzZSBhdHRhY2tz IGNhbiByZXN1bHQgaW4gdGhlDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGF0dGFjay4gQ2Fu IHlvdSBnbyBpbnRvIG1vcmUgZGV0YWlsPw0KDQpNaWtlPiBJbiBhbiBPQXV0aCBjb250ZXh0LCBh biBhdHRhY2tlciBjYW4gcGVyZm9ybSBhIHN1YnN0aXR1dGlvbiBhdHRhY2sgYnkgb2J0YWluaW5n IGEgSldUIGFjY2VzcyB0b2tlbiBmb3IgYSByZXNvdXJjZSB0aGF0IGl0IGxlZ2l0aW1hdGVseSBo YXMgYWNjZXNzIHRvIGFuZCBwcmVzZW50aW5nIGl0IHRvIGEgZGlmZmVyZW50IHJlc291cmNlIHRo YXQgaXQgaXMgbm90IGVudGl0bGVkIHRvIGFjY2Vzcy4gIElmIHRoZSBhdWRpZW5jZSBpcyBub3Qg cHJlc2VudCBvciBub3QgY2hlY2tlZCBhbmQvb3IgdGhlIGlzc3VlciBpcyBub3QgdmFsaWRhdGVk LCB0aGlzIGtpbmQgb2YgYXR0YWNrIGNhbiBzdWNjZWVkLg0KDQpNaWtlPiBTaW1pbGFybHksIGlu IGFuIE9wZW5JRCBDb25uZWN0IGNvbnRleHQgaWYgdGhlIGltcGxpY2l0IGZsb3cgaXMgYmVpbmcg dXNlZCwgdGhlIGF0dGFja2VyIGNhbiBvYnRhaW4gYSBsZWdpdGltYXRlIElEIFRva2VuICh3aGlj aCBpcyBhIEpXVCkgd2hlbiB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgcmVkaXJlY3RzIHRvIGl0cyBy ZWRpcmVjdGlvbiBVUkksIHdpdGggdGhlIElEIFRva2VuIHBhc3NlZCBhcyBhIGZyYWdtZW50IHZh bHVlLiAgVGhlIGF0dGFja2VyIHRoYW4gdGhlbiByZWRpcmVjdCB0byBhIGRpZmZlcmVudCByZWRp cmVjdGlvbiBVUkkgZm9yIGEgZGlmZmVyZW50IHJlbHlpbmcgcGFydHkgdGhhdCBkb2VzIG5vdCBi ZWxvbmcgdG8gdGhlIGF0dGFja2VyLiAgVGhpcyBjYW4gc3VjY2VlZCBpZiB0aGUgc2lnbmF0dXJl IGlzbuKAmXQgY2hlY2tlZCBvciBpZiB0aGUgaXNzdWVyIGlzbuKAmXQgY2hlY2tlZC4NCg0KTWlr ZT4gRG9lcyB0aGlzIG5vdyBtYWtlIHNlbnNlIGFzLWlzIG9yIGRvIHlvdSB3YW50IGFkZGl0aW9u YWwgdGV4dCB0byBiZSBhZGRlZCB0byB0aGUgc3BlY2lmaWNhdGlvbiDigJMgZm9yIGluc3RhbmNl LCBtYXliZSBzb21ldGhpbmcgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9ucyBhYm92ZT8NCg0KUyAz LjIuDQo+ICAgICAgVGhlcmVmb3JlLCBhcHBsaWNhdGlvbnMgTVVTVCBvbmx5IGFsbG93IHRoZSB1 c2Ugb2YgY3J5cHRvZ3JhcGhpY2FsbHkNCj4gICAgICBjdXJyZW50IGFsZ29yaXRobXMgdGhhdCBt ZWV0IHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMgb2YgdGhlDQo+ICAgICAgYXBwbGljYXRpb24u ICBUaGlzIHNldCB3aWxsIHZhcnkgb3ZlciB0aW1lIGFzIG5ldyBhbGdvcml0aG1zIGFyZQ0KPiAg ICAgIGludHJvZHVjZWQgYW5kIGV4aXN0aW5nIGFsZ29yaXRobXMgYXJlIGRlcHJlY2F0ZWQgZHVl IHRvIGRpc2NvdmVyZWQNCj4gICAgICBjcnlwdG9ncmFwaGljIHdlYWtuZXNzZXMuICBBcHBsaWNh dGlvbnMgbXVzdCB0aGVyZWZvcmUgYmUgZGVzaWduZWQgdG8NCj4gICAgICBlbmFibGUgY3J5cHRv Z3JhcGhpYyBhZ2lsaXR5Lg0KDQpJcyB0aGlzIG11c3Qgbm9ybWF0aXZlPw0KDQpNaWtlPiBZZXMN Cg0KUyAzLjIuDQo+ICAgICAgbWF5IGJlIG5vIG5lZWQgdG8gYXBwbHkgYW5vdGhlciBsYXllciBv ZiBjcnlwdG9ncmFwaGljIHByb3RlY3Rpb25zIHRvDQo+ICAgICAgdGhlIEpXVC4gIEluIHN1Y2gg Y2FzZXMsIHRoZSB1c2Ugb2YgdGhlICJub25lIiBhbGdvcml0aG0gY2FuIGJlDQo+ICAgICAgcGVy ZmVjdGx5IGFjY2VwdGFibGUuICBKV1RzIHVzaW5nICJub25lIiBhcmUgb2Z0ZW4gdXNlZCBpbg0K PiAgICAgIGFwcGxpY2F0aW9uIGNvbnRleHRzIGluIHdoaWNoIHRoZSBjb250ZW50IGlzIG9wdGlv bmFsbHkgc2lnbmVkOyB0aGVuDQo+ICAgICAgdGhlIFVSTC1zYWZlIGNsYWltcyByZXByZXNlbnRh dGlvbiBhbmQgcHJvY2Vzc2luZyBjYW4gYmUgdGhlIHNhbWUgaW4NCj4gICAgICBib3RoIHRoZSBz aWduZWQgYW5kIHVuc2lnbmVkIGNhc2VzLg0KDQpJIHRoaW5rIHlvdSBwcm9iYWJseSBuZWVkIHRv IGhhdmUgYSBjbGVhcmVyICJkb24ndCB1c2Ugbm9uZSBieQ0KZGVmYXVsdCIgc3RhdGVtZW50IGhl cmUuDQoNCk1pa2U+IERyYWZ0IC0wNCBhZGRlZCB0aGVzZSBzdGF0ZW1lbnRzIGluIHJlc3BvbnNl IHRvIHlvdXIgY29tbWVudDoNCuKAnFRoZSAibm9uZSIgYWxnb3JpdGhtIHNob3VsZCBvbmx5IGJl IHVzZWQgd2hlbiB0aGUgSldUIGlzIGNyeXB0b2dyYXBoaWNhbGx5IHByb3RlY3RlZCBieSBvdGhl ciBtZWFucy7igJ0NCuKAnEpXVCBsaWJyYXJpZXMgU0hPVUxEIE5PVCBnZW5lcmF0ZSBKV1RzIHVz aW5nICJub25lIiB1bmxlc3MgZXhwbGljaXRseSByZXF1ZXN0ZWQgdG8gZG8gYnkgdGhlIGNhbGxl ci7igJ0uICAoUmVhZGluZyB0aGlzIG5vdywgSSBzZWUgdGhhdCB3ZSBuZWVkIHRvIGNoYW5nZSDi gJx0byBkb+KAnSB0byDigJx0byBkbyBzb+KAnS4pDQoNClMgMy40Lg0KPiAgICAgIEVDREgtRVMg ZXBoZW1lcmFsIHB1YmxpYyBrZXkgKGVwaykgaW5wdXRzIHNob3VsZCBiZSB2YWxpZGF0ZWQNCj4g ICAgICBhY2NvcmRpbmcgdG8gdGhlIHJlY2lwaWVudCdzIGNob3NlbiBlbGxpcHRpYyBjdXJ2ZS4g IEZvciB0aGUgTklTVA0KPiAgICAgIHByaW1lLW9yZGVyIGN1cnZlcyBQLTI1NiwgUC0zODQgYW5k IFAtNTIxLCB2YWxpZGF0aW9uIE1VU1QgYmUNCj4gICAgICBwZXJmb3JtZWQgYWNjb3JkaW5nIHRv IFNlY3Rpb24gNS42LjIuMy40ICJFQ0MgUGFydGlhbCBQdWJsaWMtS2V5DQo+ICAgICAgVmFsaWRh dGlvbiBSb3V0aW5lIiBvZiBOSVNUIFNwZWNpYWwgUHVibGljYXRpb24gODAwLTU2QSByZXZpc2lv biAzDQo+ICAgICAgW25pc3Qtc3AtODAwLTU2YS1yM10uDQoNCklzIHRoZXJlIGFuIFgyNTUxOSBz cGVjaWZpY2F0aW9uIGZvciBKV0U/IElmIHNvLCB5b3Ugc2hvdWxkIHByb2JhYmx5DQpzcGVjaWZ5 IHRoZSBhcHByb3ByaWF0ZSBjaGVja3MuDQoNCk1pa2U+IERyYWZ0IC0wNCBhZGRzIHRoaXMgc3Rh dGVtZW50Og0K4oCcTGlrZXdpc2UsIGlmIHRoZSAiWDI1NTE5IiBvciAiWDQ0OCIge3tSRkM4MDM3 fX0gYWxnb3JpdGhtcyBhcmUgdXNlZCwgdGhlbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg aW4ge3tSRkM4MDM3fX0gYXBwbHku4oCdDQoNClMgMy41Lg0KPiAgIDMuNS4gIEVuc3VyZSBDcnlw dG9ncmFwaGljIEtleXMgaGF2ZSBTdWZmaWNpZW50IEVudHJvcHkNCj4NCj4gICAgICBUaGUgS2V5 IEVudHJvcHkgYW5kIFJhbmRvbSBWYWx1ZXMgYWR2aWNlIGluIFNlY3Rpb24gMTAuMSBvZiBbUkZD NzUxNV0NCj4gICAgICBhbmQgdGhlIFBhc3N3b3JkIENvbnNpZGVyYXRpb25zIGluIFNlY3Rpb24g OC44IG9mIFtSRkM3NTE4XSBNVVNUIGJlDQo+ICAgICAgZm9sbG93ZWQuICBJbiBwYXJ0aWN1bGFy LCBodW1hbi1tZW1vcml6YWJsZSBwYXNzd29yZHMgTVVTVCBOT1QgYmUNCj4gICAgICBkaXJlY3Rs eSB1c2VkIGFzIHRoZSBrZXkgdG8gYSBrZXllZC1NQUMgYWxnb3JpdGhtIHN1Y2ggYXMgIkhTMjU2 Ii4NCg0KSWYgeW91IGNhbid0IHVzZSB0aGVtICJkaXJlY3RseSIgdGhhbiBob3cgc2hvdWxkIHlv dSB1c2UgdGhlbT8gRG8geW91DQp3YW50IHRvIHNheSBhbnl0aGluZyBhYm91dCBwYXNzd29yZCBo YXNoaW5nIChhcmdvbiwgZXRjLik/DQoNCk1pa2U+IERyYWZ0IC0wNCBhZGRzIHRoaXMgdGV4dCBp biByZXNwb25zZSB0byB0aGlzIGNvbW1lbnQ6DQrigJxJbiBwYXJ0aWN1bGFyLCBwYXNzd29yZHMg c2hvdWxkIG9ubHkgYmUgdXNlZCB0byBwZXJmb3JtIGtleSBlbmNyeXB0aW9uLCByYXRoZXIgdGhh biBjb250ZW50IGVuY3J5cHRpb24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuOCBvZiB7e1JG Qzc1MTh9fS4gTm90ZSB0aGF0IGV2ZW4gd2hlbiB1c2VkIGZvciBrZXkgZW5jcnlwdGlvbiwgcGFz c3dvcmQtYmFzZWQgZW5jcnlwdGlvbiBpcyBzdGlsbCBzdWJqZWN0IHRvIGJydXRlLWZvcmNlIGF0 dGFja3Mu4oCdDQoNClMgMy4xMi4NCj4gICAgICAgICBvZiBKV1RzLg0KPg0KPiAgICAgIEdpdmVu IHRoZSBicm9hZCBkaXZlcnNpdHkgb2YgSldUIHVzYWdlIGFuZCBhcHBsaWNhdGlvbnMsIHRoZSBi ZXN0DQo+ICAgICAgY29tYmluYXRpb24gb2YgdHlwZXMsIHJlcXVpcmVkIGNsYWltcywgdmFsdWVz LCBoZWFkZXIgcGFyYW1ldGVycywga2V5DQo+ICAgICAgdXNhZ2VzLCBhbmQgaXNzdWVycyB0byBk aWZmZXJlbnRpYXRlIGFtb25nIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzDQo+ICAgICAgd2lsbCwg aW4gZ2VuZXJhbCwgYmUgYXBwbGljYXRpb24gc3BlY2lmaWMuDQoNCkkgZ2V0IHRoYXQgdGhpcyBp cyB0aGUgc3RhdGUgd2UgZmluZCBvdXJzZWx2ZXMgaW4sIGJ1dCBpdCBzZWVtcyBsaWtlDQppdCdz IHVuZm9ydHVuYXRlLiBUaGlzIG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIHJlLWVtcGhhc2l6ZSB0 aGUNCnJlY29tbWVuZGF0aW9uIGZvciBleHBsaWNpdCB0eXBlcyBpbiAzLjExLg0KDQpNaWtlPiBE cmFmdCAtMDQgYWRkcyB0aGlzIHRleHQgaW4gcmVzcG9uc2UgdG8gdGhpcyBjb21tZW50Og0K4oCc Rm9yIG5ldyBKV1QgYXBwbGljYXRpb25zLCB0aGUgdXNlIG9mIGV4cGxpY2l0IHR5cGluZyBpcyBS RUNPTU1FTkRFRC7igJ0NCg== --_000_MW2PR00MB0298833CAEA7EA389FB935F5F5780MW2PR00MB0298namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5IaSBFcmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UmVwbGllcyBh cmUgaW5saW5lIGJlbG93LCBwcmVmaXhlZCBieSDigJxNaWtlJmd0O+KAnS4mbmJzcDsgSW4gc3Vt bWFyeSwgdW5sZXNzIHlvdSB3YW50IHRvIHNlZSBhZGRpdGlvbmFsIHRleHQgYWRkZWQgZ2l2aW5n IGV4YW1wbGVzIG9mIHN1YnN0aXR1dGlvbiBhdHRhY2tzLCBJIGJlbGlldmUgdGhhdCAtMDQgYWRk cmVzc2VkIGFsbCBvZiB5b3VyIHJldmlldyBjb21tZW50cy4mbmJzcDsgTGV0DQogdXMga25vdywg YW5kIGlmIHNvLCB3ZeKAmWxsIHR1cm4gdGhlIGNyYW5rIGFuZCBwdWJsaXNoIGFuIC0wNSBkb2lu ZyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWdhaW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9m IDwvYj4NCkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIERlY2VtYmVy IDIyLCAyMDE4IDY6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBGd2Q6IEFEIFJldmlldyBvZiBk cmFmdC1pZXRmLW9hdXRoLWp3dC1iY3A8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkND aW5nIHRoZSBXRyBiZWNhdXNlIEkgd2FzIHdyb25nIGFib3V0IHRoZSBhbGlhc2VzLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tIEZv cndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLTxicj4NCkZyb206IDxiPkVyaWMgUmVzY29ybGE8L2I+ ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0Ozxi cj4NCkRhdGU6IFN1biwgQXVnIDI2LCAyMDE4IGF0IDI6MDIgUE08YnI+DQpTdWJqZWN0OiBBRCBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwPGJyPg0KVG86IG9hdXRoICZsdDs8YSBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmljaCB2ZXJzaW9uIG9mIHRoaXMgcmV2 aWV3IGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3ph d3MubmV0L0Q0NjQ5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3Zj ZGV2Lm1vemF3cy5uZXQvRDQ2NDk8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQ09NTUVOVFM8YnI+DQpT IDEuMi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IDEuMi4mbmJzcDsgQ29udmVudGlvbnMgdXNlZCBp biB0aGlzIGRvY3VtZW50PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBrZXkgd29yZHMgJnF1b3Q7TVVTVCZxdW90OywgJnF1 b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZxdW90 OywgJnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7U0hPVUxEJnF1b3Q7LCAmcXVvdDtTSE9VTEQgTk9UJnF1b3Q7LCAmcXVv dDtSRUNPTU1FTkRFRCZxdW90OywgJnF1b3Q7Tk9UIFJFQ09NTUVOREVEJnF1b3Q7LCAmcXVvdDtN QVkmcXVvdDssIGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7T1BUSU9OQUwmcXVvdDsgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb UkZDMjExOV0uPGJyPg0KPGJyPg0KWW91IHdpbGwgd2FudCB0byBjaXRlIDgxNzQgaGVyZS48YnI+ DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWlrZSZndDsgVGhpcyB3YXMgZG9u ZSBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1qd3QtYmNwLTA0Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLWp3dC1iY3AtMDQ8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NClMgMi42Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyAyLjYuJm5ic3A7IFN1YnN0aXR1dGlvbiBBdHRhY2tzPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSBh dHRhY2tzIGluIHdoaWNoIG9uZSByZWNpcGllbnQgd2lsbCBoYXZlIGEgSldUIGludGVuZGVkIGZv cjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQgYW5kIGF0dGVtcHQg dG8gdXNlIGl0IGF0IGEgZGlmZmVyZW50IHJlY2lwaWVudCB0aGF0IGl0IHdhcyBub3Q8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVuZGVkIGZvci4mbmJzcDsgSWYg bm90IGNhdWdodCwgdGhlc2UgYXR0YWNrcyBjYW4gcmVzdWx0IGluIHRoZTxicj4NCjxicj4NCkkg ZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGF0dGFjay4gQ2FuIHlvdSBnbyBpbnRvIG1vcmUgZGV0YWls Pzxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ TWlrZSZndDsgSW4gYW4gT0F1dGggY29udGV4dCwgYW4gYXR0YWNrZXIgY2FuIHBlcmZvcm0gYSBz dWJzdGl0dXRpb24gYXR0YWNrIGJ5IG9idGFpbmluZyBhIEpXVCBhY2Nlc3MgdG9rZW4gZm9yIGEg cmVzb3VyY2UgdGhhdCBpdCBsZWdpdGltYXRlbHkgaGFzIGFjY2VzcyB0byBhbmQgcHJlc2VudGlu ZyBpdCB0byBhIGRpZmZlcmVudCByZXNvdXJjZSB0aGF0IGl0IGlzDQogbm90IGVudGl0bGVkIHRv IGFjY2Vzcy4mbmJzcDsgSWYgdGhlIGF1ZGllbmNlIGlzIG5vdCBwcmVzZW50IG9yIG5vdCBjaGVj a2VkIGFuZC9vciB0aGUgaXNzdWVyIGlzIG5vdCB2YWxpZGF0ZWQsIHRoaXMga2luZCBvZiBhdHRh Y2sgY2FuIHN1Y2NlZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NaWtl Jmd0OyBTaW1pbGFybHksIGluIGFuIE9wZW5JRCBDb25uZWN0IGNvbnRleHQgaWYgdGhlIGltcGxp Y2l0IGZsb3cgaXMgYmVpbmcgdXNlZCwgdGhlIGF0dGFja2VyIGNhbiBvYnRhaW4gYSBsZWdpdGlt YXRlIElEIFRva2VuICh3aGljaCBpcyBhIEpXVCkgd2hlbiB0aGUgSWRlbnRpdHkgUHJvdmlkZXIg cmVkaXJlY3RzIHRvIGl0cyByZWRpcmVjdGlvbiBVUkksIHdpdGgNCiB0aGUgSUQgVG9rZW4gcGFz c2VkIGFzIGEgZnJhZ21lbnQgdmFsdWUuJm5ic3A7IFRoZSBhdHRhY2tlciB0aGFuIHRoZW4gcmVk aXJlY3QgdG8gYSBkaWZmZXJlbnQgcmVkaXJlY3Rpb24gVVJJIGZvciBhIGRpZmZlcmVudCByZWx5 aW5nIHBhcnR5IHRoYXQgZG9lcyBub3QgYmVsb25nIHRvIHRoZSBhdHRhY2tlci4mbmJzcDsgVGhp cyBjYW4gc3VjY2VlZCBpZiB0aGUgc2lnbmF0dXJlIGlzbuKAmXQgY2hlY2tlZCBvciBpZiB0aGUg aXNzdWVyIGlzbuKAmXQgY2hlY2tlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPk1pa2UmZ3Q7IERvZXMgdGhpcyBub3cgbWFrZSBzZW5zZSBhcy1pcyBvciBkbyB5b3Ugd2Fu dCBhZGRpdGlvbmFsIHRleHQgdG8gYmUgYWRkZWQgdG8gdGhlIHNwZWNpZmljYXRpb24g4oCTIGZv ciBpbnN0YW5jZSwgbWF5YmUgc29tZXRoaW5nIGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbnMgYWJv dmU/PC9zcGFuPjxicj4NCjxicj4NClMgMy4yLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhlcmVmb3JlLCBhcHBsaWNhdGlvbnMgTVVTVCBvbmx5IGFsbG93IHRoZSB1 c2Ugb2YgY3J5cHRvZ3JhcGhpY2FsbHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGN1cnJlbnQgYWxnb3JpdGhtcyB0aGF0IG1lZXQgdGhlIHNlY3VyaXR5IHJlcXVpcmVt ZW50cyBvZiB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGxp Y2F0aW9uLiZuYnNwOyBUaGlzIHNldCB3aWxsIHZhcnkgb3ZlciB0aW1lIGFzIG5ldyBhbGdvcml0 aG1zIGFyZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50cm9kdWNl ZCBhbmQgZXhpc3RpbmcgYWxnb3JpdGhtcyBhcmUgZGVwcmVjYXRlZCBkdWUgdG8gZGlzY292ZXJl ZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGhpYyB3 ZWFrbmVzc2VzLiZuYnNwOyBBcHBsaWNhdGlvbnMgbXVzdCB0aGVyZWZvcmUgYmUgZGVzaWduZWQg dG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuYWJsZSBjcnlwdG9n cmFwaGljIGFnaWxpdHkuPGJyPg0KPGJyPg0KSXMgdGhpcyBtdXN0IG5vcm1hdGl2ZT88YnI+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWlrZSZndDsgWWVzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUyAzLjIuPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYXkgYmUgbm8gbmVlZCB0byBhcHBseSBhbm90 aGVyIGxheWVyIG9mIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbnMgdG88YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBKV1QuJm5ic3A7IEluIHN1Y2ggY2FzZXMsIHRo ZSB1c2Ugb2YgdGhlICZxdW90O25vbmUmcXVvdDsgYWxnb3JpdGhtIGNhbiBiZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVyZmVjdGx5IGFjY2VwdGFibGUuJm5ic3A7 IEpXVHMgdXNpbmcgJnF1b3Q7bm9uZSZxdW90OyBhcmUgb2Z0ZW4gdXNlZCBpbjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRpb24gY29udGV4dHMgaW4gd2hp Y2ggdGhlIGNvbnRlbnQgaXMgb3B0aW9uYWxseSBzaWduZWQ7IHRoZW48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBVUkwtc2FmZSBjbGFpbXMgcmVwcmVzZW50YXRp b24gYW5kIHByb2Nlc3NpbmcgY2FuIGJlIHRoZSBzYW1lIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBib3RoIHRoZSBzaWduZWQgYW5kIHVuc2lnbmVkIGNhc2VzLjxi cj4NCjxicj4NCkkgdGhpbmsgeW91IHByb2JhYmx5IG5lZWQgdG8gaGF2ZSBhIGNsZWFyZXIgJnF1 b3Q7ZG9uJ3QgdXNlIG5vbmUgYnk8YnI+DQpkZWZhdWx0JnF1b3Q7IHN0YXRlbWVudCBoZXJlLjxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWlr ZSZndDsgRHJhZnQgLTA0IGFkZGVkIHRoZXNlIHN0YXRlbWVudHMgaW4gcmVzcG9uc2UgdG8geW91 ciBjb21tZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMDMyRjYyO2JhY2tncm91bmQ6I0U2 RkZFRCI+VGhlICZxdW90O25vbmUmcXVvdDsgYWxnb3JpdGhtIHNob3VsZCBvbmx5IGJlIHVzZWQg d2hlbiB0aGUgSldUIGlzIGNyeXB0b2dyYXBoaWNhbGx5IHByb3RlY3RlZCBieSBvdGhlciBtZWFu cy7igJ08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7i gJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMDMyRjYyO2JhY2tncm91bmQ6I0U2RkZFRCI+SldUIGxpYnJhcmllcyBTSE9VTEQg Tk9UIGdlbmVyYXRlIEpXVHMgdXNpbmcgJnF1b3Q7bm9uZSZxdW90OyB1bmxlc3MgZXhwbGljaXRs eSByZXF1ZXN0ZWQgdG8gZG8gYnkgdGhlIGNhbGxlci48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPuKAnS4mbmJzcDsNCiAoUmVhZGluZyB0aGlzIG5vdywgSSBzZWUgdGhhdCB3ZSBu ZWVkIHRvIGNoYW5nZSDigJx0byBkb+KAnSB0byDigJx0byBkbyBzb+KAnS4pPC9zcGFuPjxicj4N Cjxicj4NClMgMy40Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRUNE SC1FUyBlcGhlbWVyYWwgcHVibGljIGtleSAoZXBrKSBpbnB1dHMgc2hvdWxkIGJlIHZhbGlkYXRl ZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWNjb3JkaW5nIHRvIHRo ZSByZWNpcGllbnQncyBjaG9zZW4gZWxsaXB0aWMgY3VydmUuJm5ic3A7IEZvciB0aGUgTklTVDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJpbWUtb3JkZXIgY3VydmVz IFAtMjU2LCBQLTM4NCBhbmQgUC01MjEsIHZhbGlkYXRpb24gTVVTVCBiZTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVyZm9ybWVkIGFjY29yZGluZyB0byBTZWN0aW9u IDUuNi4yLjMuNCAmcXVvdDtFQ0MgUGFydGlhbCBQdWJsaWMtS2V5PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWYWxpZGF0aW9uIFJvdXRpbmUmcXVvdDsgb2YgTklTVCBT cGVjaWFsIFB1YmxpY2F0aW9uIDgwMC01NkEgcmV2aXNpb24gMzxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgW25pc3Qtc3AtODAwLTU2YS1yM10uPGJyPg0KPGJyPg0KSXMg dGhlcmUgYW4gWDI1NTE5IHNwZWNpZmljYXRpb24gZm9yIEpXRT8gSWYgc28sIHlvdSBzaG91bGQg cHJvYmFibHk8YnI+DQpzcGVjaWZ5IHRoZSBhcHByb3ByaWF0ZSBjaGVja3MuPGJyPg0KPGJyPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NaWtlJmd0OyBEcmFm dCAtMDQgYWRkcyB0aGlzIHN0YXRlbWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+4oCcPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzAzMkY2 MjtiYWNrZ3JvdW5kOiNFNkZGRUQiPkxpa2V3aXNlLCBpZiB0aGUgJnF1b3Q7WDI1NTE5JnF1b3Q7 IG9yICZxdW90O1g0NDgmcXVvdDsge3tSRkM4MDM3fX0gYWxnb3JpdGhtcyBhcmUgdXNlZCwgdGhl biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4ge3tSRkM4MDM3fX0NCiBhcHBseS48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClMgMy41Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsg My41LiZuYnNwOyBFbnN1cmUgQ3J5cHRvZ3JhcGhpYyBLZXlzIGhhdmUgU3VmZmljaWVudCBFbnRy b3B5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRoZSBLZXkgRW50cm9weSBhbmQgUmFuZG9tIFZhbHVlcyBhZHZpY2UgaW4gU2Vj dGlvbiAxMC4xIG9mIFtSRkM3NTE1XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYW5kIHRoZSBQYXNzd29yZCBDb25zaWRlcmF0aW9ucyBpbiBTZWN0aW9uIDguOCBvZiBb UkZDNzUxOF0gTVVTVCBiZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Zm9sbG93ZWQuJm5ic3A7IEluIHBhcnRpY3VsYXIsIGh1bWFuLW1lbW9yaXphYmxlIHBhc3N3b3Jk cyBNVVNUIE5PVCBiZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGly ZWN0bHkgdXNlZCBhcyB0aGUga2V5IHRvIGEga2V5ZWQtTUFDIGFsZ29yaXRobSBzdWNoIGFzICZx dW90O0hTMjU2JnF1b3Q7Ljxicj4NCjxicj4NCklmIHlvdSBjYW4ndCB1c2UgdGhlbSAmcXVvdDtk aXJlY3RseSZxdW90OyB0aGFuIGhvdyBzaG91bGQgeW91IHVzZSB0aGVtPyBEbyB5b3U8YnI+DQp3 YW50IHRvIHNheSBhbnl0aGluZyBhYm91dCBwYXNzd29yZCBoYXNoaW5nIChhcmdvbiwgZXRjLik/ PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5N aWtlJmd0OyBEcmFmdCAtMDQgYWRkcyB0aGlzIHRleHQgaW4gcmVzcG9uc2UgdG8gdGhpcyBjb21t ZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMDMyRjYyO2JhY2tncm91bmQ6I0U2RkZFRCI+ SW4gcGFydGljdWxhciwgcGFzc3dvcmRzIHNob3VsZCBvbmx5IGJlIHVzZWQgdG8gcGVyZm9ybSBr ZXkgZW5jcnlwdGlvbiwgcmF0aGVyIHRoYW4gY29udGVudCBlbmNyeXB0aW9uLCBhcyBkZXNjcmli ZWQNCiBpbiBTZWN0aW9uIDQuOCBvZiB7e1JGQzc1MTh9fS4gTm90ZSB0aGF0IGV2ZW4gd2hlbiB1 c2VkIGZvciBrZXkgZW5jcnlwdGlvbiwgcGFzc3dvcmQtYmFzZWQgZW5jcnlwdGlvbiBpcyBzdGls bCBzdWJqZWN0IHRvIGJydXRlLWZvcmNlIGF0dGFja3MuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj7igJ08L3NwYW4+PGJyPg0KPGJyPg0KUyAzLjEyLjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgSldUcy48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg R2l2ZW4gdGhlIGJyb2FkIGRpdmVyc2l0eSBvZiBKV1QgdXNhZ2UgYW5kIGFwcGxpY2F0aW9ucywg dGhlIGJlc3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbWJpbmF0 aW9uIG9mIHR5cGVzLCByZXF1aXJlZCBjbGFpbXMsIHZhbHVlcywgaGVhZGVyIHBhcmFtZXRlcnMs IGtleTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNhZ2VzLCBhbmQg aXNzdWVycyB0byBkaWZmZXJlbnRpYXRlIGFtb25nIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aWxsLCBpbiBnZW5lcmFsLCBi ZSBhcHBsaWNhdGlvbiBzcGVjaWZpYy48YnI+DQo8YnI+DQpJIGdldCB0aGF0IHRoaXMgaXMgdGhl IHN0YXRlIHdlIGZpbmQgb3Vyc2VsdmVzIGluLCBidXQgaXQgc2VlbXMgbGlrZTxicj4NCml0J3Mg dW5mb3J0dW5hdGUuIFRoaXMgbWlnaHQgYmUgYSBnb29kIHRpbWUgdG8gcmUtZW1waGFzaXplIHRo ZTxicj4NCnJlY29tbWVuZGF0aW9uIGZvciBleHBsaWNpdCB0eXBlcyBpbiAzLjExLjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi Pk1pa2UmZ3Q7IERyYWZ0IC0wNCBhZGRzIHRoaXMgdGV4dCBpbiByZXNwb25zZSB0byB0aGlzIGNv bW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMwMzJGNjI7YmFja2dyb3VuZDojRTZGRkVE Ij5Gb3IgbmV3IEpXVCBhcHBsaWNhdGlvbnMsIHRoZSB1c2Ugb2YgZXhwbGljaXQgdHlwaW5nIGlz IFJFQ09NTUVOREVELjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+4oCdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MW2PR00MB0298833CAEA7EA389FB935F5F5780MW2PR00MB0298namp_-- From nobody Sat Feb 23 09:05:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505F812F19D for ; Sat, 23 Feb 2019 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLvgI89zDrmv for ; Sat, 23 Feb 2019 09:05:20 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3367C12F18C for ; Sat, 23 Feb 2019 09:05:20 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id n19so4532559wmi.1 for ; Sat, 23 Feb 2019 09:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:user-agent; bh=7KrZcjDulTzDKx5H3laLCtWdhYswe0dAm5BuxX5K19I=; b=DtknNJ2zFGAvBFXIO6D3MBwnAA574fQxiz1oSXekZj5GdZM1S1AzxjZSgANzxkprMS 5+rCQpLqBcRJi1vKT3rIw2Y1X7iY6ybMPd6WfRwx1jRooBs3RMric1PuuJQqE0b9JztQ dxZ56iI5Z00yMHZOIM7wMz5+R/C0hc/FUB70aFxDSReWtwSr94bz4YPAdpumHinrPQpf uXY9hzHVKwXdt5p6bEFIuD3n+y4dXIB9Q0YRXlIF81iEeCjhnhagtgyBHic58MA+ZT7H ISiBXcbZuo7Gp3K1AAokSuNnmv8TjwAXht9VlxgGyGuvNj5+NanBZXLI8vKD6fU3XiCR dYwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :user-agent; bh=7KrZcjDulTzDKx5H3laLCtWdhYswe0dAm5BuxX5K19I=; b=SdLRERQE9Pj4Pi0OvsFXdmmVyxtpcCyoVawDEkw+xfinJpHhm9O8VN7u5zpRhLc/Pn vPnqmpwRamPo898qSdWsSwj39iRBv3fziFeK6xIbLVJAALt9h2BoBZvVOEfh4o+QpiZ/ pSfYUkKPP6vB8/tblKmanuWVRU4KktZ6lBFrx03fAUOuduhB+t351JrSh2z/SRGuyGSu 0ISabswDbBHRXcVlnR3MR88dSC6cA0hFxLrmbCICt0+55UjCFrTLwvYbygPqBXKIX/t9 PyxAb8onrIOiiqnzkewtAnX02N1D79pTlocduFKFP9NMNdCa40Z3853pJ2DXqn+Dxkoh FtsQ== X-Gm-Message-State: AHQUAubdOAt0+AQHQBOoHug7H1LbmtacZhy3k6CG5Ca2SmZnH8DJpFGF eTA4+ArjvSnaT1A4OlAj2jRCv51JVk4= X-Google-Smtp-Source: AHgI3IaSZY2r88WVTb4Xv3n5EibEIY5+yCbiBXj09x84NHpfEB2kJd059SPWPTPGI8PB7XOPHMeb/w== X-Received: by 2002:a1c:e0d7:: with SMTP id x206mr5966784wmg.152.1550941518025; Sat, 23 Feb 2019 09:05:18 -0800 (PST) Received: from [192.168.178.41] ([62.28.200.34]) by smtp.gmail.com with ESMTPSA id 132sm7206986wmd.30.2019.02.23.09.05.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Feb 2019 09:05:16 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_47520496.268396467836" MIME-Version: 1.0 Date: Sat, 23 Feb 2019 17:05:12 +0000 Message-ID: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> From: "Brock Allen" To: "" User-Agent: Mailbird/2.5.27.0 X-Mailbird-ID: 67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com Archived-At: Subject: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 17:05:22 -0000 ------=_NextPart_47520496.268396467836 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I often have push back from customers (mainly the marketing department/UX f= olks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They as= k for examples of any other popular or well known apps that follow this pra= ctice. Does anyone on this list have examples? TIA -Brock ------=_NextPart_47520496.268396467836 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I often have push back from customers (mainly = the marketing department/UX folks) when suggesting AppAuth for native/mobil= e apps (IOW RFC8252). They ask for examples of any other popular or well kn= own apps that follow this practice. Does anyone on this list have examples?=

TIA

-Brock

------=_NextPart_47520496.268396467836-- From nobody Sun Feb 24 00:26:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0FC130EBB for ; Sun, 24 Feb 2019 00:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3Sa5yX8kCvN for ; Sun, 24 Feb 2019 00:26:15 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE01C130EF1 for ; Sun, 24 Feb 2019 00:26:14 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id z39so7312410qtz.0 for ; Sun, 24 Feb 2019 00:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=GEhyyGS2vov5gwFwEOQSF5b16+yLJvDkhdxBgF8K6pM=; b=BFAupzyZ99maYmsxtzmb41I32eSkATNcxO5U3xfIwz9OCFbBxgvHf7ZU2AEGuTxt1I XCHwcmx9UwyKAukN8pkDlEA7i7gHY0vG67VuiCniopwlc/xeydVwbs3sNAjYEQ4slCWd giwffAJtZKLNGaQyQI8q4OwgQLarDejGwgN99Gan4hVW4zBk+dZIcU6U6kC39c9rrGPc em7JH68sswKynNBeHdGHgnnGHYfmL9drJMceIrLvj9aEYN9cAK5k54UIHn5PsBZxQZcc o5NDlsadiuqKEwYMXAAaTFkjVFAOVTY8v077pb6bxauAA34F03O6FU0OuGrM2lTaOdi9 8ccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=GEhyyGS2vov5gwFwEOQSF5b16+yLJvDkhdxBgF8K6pM=; b=mRynRd/Y+mFnRWwL9dTUIEssqbTg+O8r6CgO8aoH8Ljps4+pVlluLXhFnpdo9UaPOW m9f1jmmw01KBFLYL3tqW3m6WkRZUUvC9aaiGkQO0XY0AdaRHv0rA3pWVdaMafj7f1TOz 8W67Y33uLQswxF7OmB+GP/lkD6/nbo3aDXr5HTBGEMOxIvF8+UBTpnLD5d3Ehs1pviO3 RoaarJPxw5OQ2nQIpPD8Yd+imxNG5NLmK9VFt1fGVVaMjB/54+/lHvXZ4NXN/TdMAGhq ESxSl0WHfaHeuXhf/6YD6WGlvJxNW+ZnFBee5c1XsPs441VBWyZaBPU0ZZq/qhQaritn nqXg== X-Gm-Message-State: AHQUAuZFJkaA4dWOHaCQQfFT02uFlNO6anQXKd80EYbPpO3wsndlxm5G 7bGfn6N2NSylLZWebrCz2zTp5Ztko/k8Uhwc6TGA X-Google-Smtp-Source: AHgI3IbVeXGDHVsTOXsYmfxhFXrW7T7C55cuTU2++1UxWPKxMZN6U9gBFwiuT9kw03Or7EOqKWEBhDSGFgetjWOW0Nw= X-Received: by 2002:a0c:ad67:: with SMTP id v36mr9538075qvc.5.1550996773705; Sun, 24 Feb 2019 00:26:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 24 Feb 2019 00:26:12 -0800 From: Dominick Baier In-Reply-To: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> MIME-Version: 1.0 Date: Sun, 24 Feb 2019 00:26:12 -0800 Message-ID: To: Brock Allen , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000bead6e05829f93c4" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 08:26:23 -0000 --000000000000bead6e05829f93c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Uber app uses it for their OAuth flow to PayPal e.g. =E2=80=94=E2=80=94=E2=80=94 Dominick On 23. February 2019 at 18:05:33, Brock Allen (brockallen@gmail.com) wrote: I often have push back from customers (mainly the marketing department/UX folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They ask for examples of any other popular or well known apps that follow this practice. Does anyone on this list have examples? TIA -Brock _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --000000000000bead6e05829f93c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
The = Uber app uses it for their OAuth flow to PayPal e.g.

=E2=80=94=E2=80=94=E2=80=94
Dominick
<= br>

On 23. February 2019 at 18:05:33, Brock Allen (<= a href=3D"mailto:brockallen@gmail.com">brockallen@gmail.com) wrote:

=
I often have push back from customers (mainly the marketing department/UX folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They ask for examples of any other popular or well known apps that follow this practice. Does anyone on this list have examples?

TIA

-Brock

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--000000000000bead6e05829f93c4-- From nobody Sun Feb 24 01:29:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F665130E5D for ; Sun, 24 Feb 2019 01:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z5emWow6Ycl for ; Sun, 24 Feb 2019 01:29:30 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 537F7130DE7 for ; Sun, 24 Feb 2019 01:29:30 -0800 (PST) Received: from [IPv6:2601:282:202:b210:2954:5396:35ff:c9a2] (unknown [IPv6:2601:282:202:b210:2954:5396:35ff:c9a2]) by alkaline-solutions.com (Postfix) with ESMTPSA id CFDAD315EC; Sun, 24 Feb 2019 09:29:28 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-DDA71A89-6564-4C89-9A1C-3868F3A7DAF6 Mime-Version: 1.0 (1.0) From: David Waite X-Mailer: iPad Mail (16C50) In-Reply-To: Date: Sun, 24 Feb 2019 02:29:27 -0700 Cc: Brock Allen , oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <9E5DF94F-0B6D-4F9E-922C-654A73DC40B4@alkaline-solutions.com> References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> To: Dominick Baier Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 09:29:32 -0000 --Apple-Mail-DDA71A89-6564-4C89-9A1C-3868F3A7DAF6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Offhand, Google Apps on iOS. Also the Facebook SDK uses a similar pattern.=20= I believe third party apps which use Google for SSO are mandated to use it a= s well. Slack and Pok=C3=A9mon Go, for examples.=20 A few apps will also use it or a similar pattern (for SAML) once they have d= etermined it is an enterprise account. Some businesses are pushing hard for t= he others to change - a lot of EMM solutions and other authentication method= s (like mutual TLS) don=E2=80=99t work properly with embedded browser views.= =20 -DW > On Feb 24, 2019, at 1:26 AM, Dominick Baier wr= ote: >=20 > The Uber app uses it for their OAuth flow to PayPal e.g. >=20 > =E2=80=94=E2=80=94=E2=80=94 > Dominick >=20 >> On 23. February 2019 at 18:05:33, Brock Allen (brockallen@gmail.com) wrot= e: >>=20 >> I often have push back from customers (mainly the marketing department/UX= folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They a= sk for examples of any other popular or well known apps that follow this pra= ctice. Does anyone on this list have examples? >>=20 >> TIA >>=20 >> -Brock >>=20 >> _______________________________________________=20 >> OAuth mailing list=20 >> OAuth@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-DDA71A89-6564-4C89-9A1C-3868F3A7DAF6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Offhand, Google Apps on iOS. Also the Facebook SDK uses a similar pat= tern. 

I believe third= party apps which use Google for SSO are mandated to use it as well. Slack a= nd Pok=C3=A9mon Go, for examples. 

A few apps will also use it or a similar pattern (for SAML) onc= e they have determined it is an enterprise account. Some businesses are push= ing hard for the others to change - a lot of EMM solutions and other authent= ication methods (like mutual TLS) don=E2=80=99t work properly with embedded b= rowser views. 

-DW

On Feb 24, 2019, a= t 1:26 AM, Dominick Baier <d= baier@leastprivilege.com> wrote:

The Uber app uses it for their OAuth flow to PayPal e.g.

———
Dominick

On 23. February 2019 at 18:05:33, Brock Allen (brockallen@gmail.com) wrote:

I often have push back from customers (mainly the marketing department/UX folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They ask for examples of any other popular or well known apps that follow this practice. Does anyone on this list have examples?

TIA

-Brock

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------C9E0C8C9A6850C9D7D3DA874-- From nobody Sun Feb 24 07:32:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895FB1200ED for ; Sun, 24 Feb 2019 07:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeOI9XrxOFaO for ; Sun, 24 Feb 2019 07:32:40 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E0C124B0C for ; Sun, 24 Feb 2019 07:32:39 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id r5so7200693wrg.9 for ; Sun, 24 Feb 2019 07:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:in-reply-to:references :user-agent; bh=6P7FiUNG/h4/iZZ54juQzI1dFTgVLF7qACxI3B+g3nA=; b=maldq6i9yUeIuTY4BLBISPCoqYp03Ks0Hv8qM4kQsKUaKNhK4C7zqHhfiDO9jToHgI XCA7t1EGwpjid5KAkFZrOF/I5IBfoCefpgSE9jCBxviwDCwZ2wDd454EyNogw1mwCmm1 I1RpSNgl5rviHexlZLBYXpMaVg7R09FJHKMFcRUKH2AQIBqf/Es6h5IUAPJolAuW9QVu B9fwmivQKFd9o9Z45GCd2msdbqRO1efoCVcVjA74a1xUQffyECADDy7wsn87NhYSFRBM Zg9yZ20ldHJW0EJhNLj4Sk70XlY1i9u/ttTDT9bpU40Pe86jA3kZemg4cQz1WoIMzBi9 rPCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :in-reply-to:references:user-agent; bh=6P7FiUNG/h4/iZZ54juQzI1dFTgVLF7qACxI3B+g3nA=; b=fzk48ZSRFFEgm6FznJDGks/0fGiKFqvEVVPQWF51QaomgotTKquuNHouzadtCQtTqp W9bQyFwdPuU5Ml65LcP0AwXb2pv92AoWIAnx23EMu/vxUdZCiph2OZw0kmKBKeYrfpmQ 1DWh6heWajngGeuMvVhiVy1kknMzw8yMxuf6VmmFcmNVEl7anmsZxs6VAstUGUNCc6X6 Ps5kVr6xwm73fZNq8SlMuPybRLH6nlOcSOAF5+NMe3hfcVBsslKgPGluLSMWyCm6RCSt TSNd/IzVW6Aqk3JQsHA+FBhc6BdcSb2rMLqqlL5lwtELQD068SQwC90xytX9UvDVzefH 3KbQ== X-Gm-Message-State: AHQUAuYHrpVP9QFBRZRMe2NqzgZNxJ2dOldwhurh94roIC8DNf0+Qwu2 gH4P1/6zRkGQqxePcDNC8gIsN36KdZA= X-Google-Smtp-Source: AHgI3IawWLZMVpoHwUfQPIEGx4uDquLUnPkGylDk6qvdAgeMFe4ZV76U66QLXJZ6ZGt1D/ABXV17qw== X-Received: by 2002:adf:edd1:: with SMTP id v17mr9668007wro.300.1551022357805; Sun, 24 Feb 2019 07:32:37 -0800 (PST) Received: from [192.168.179.133] ([62.28.200.34]) by smtp.gmail.com with ESMTPSA id p12sm4249972wrt.4.2019.02.24.07.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Feb 2019 07:32:36 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_17244688.531493915649" MIME-Version: 1.0 Date: Sun, 24 Feb 2019 15:32:34 +0000 Message-ID: From: "Brock Allen" To: "John Bradley" , "" In-Reply-To: <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> User-Agent: Mailbird/2.5.27.0 X-Mailbird-ID: c6f71d94-12f4-4f99-b373-c9f815325da1@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 15:32:42 -0000 ------=_NextPart_17244688.531493915649 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0Interestingly I was told that switching to AppAuth increased login c= onversions for them with YouTube. That was a while ago. I think you just said the magic words that marketing folks like to hear. Th= anks all. -Brock ------=_NextPart_17244688.531493915649 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;Interestingly I was told that switching to= AppAuth increased login conversions for them with YouTube. That was a wh= ile ago.

I think you just said the magic words th= at marketing folks like to hear. Thanks all.

-Brock
= =0A =0A =
------=_NextPart_17244688.531493915649-- From nobody Sun Feb 24 09:43:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87371295EC for ; Sun, 24 Feb 2019 09:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCAbxtuh2XnN for ; Sun, 24 Feb 2019 09:43:46 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB1412958B for ; Sun, 24 Feb 2019 09:43:45 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id x9so5683307iog.12 for ; Sun, 24 Feb 2019 09:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9eDqyC8teOca9lKPG7kLW9GUe8GstujE/HDVUyG8mlQ=; b=CByke5/WSgWdMo1RYkVQ8HfDFc7OcGrHnUCF4TcSM/UdWwiUg1fNbn1MIiCIX1S0vQ TT0hBOMpYJ1pTLAPtmQ87xl4RSTrs08uiwcg5i7xwtNhvkrkqzfM2eB57iVYzE+iK6TM d3teyp3dKjnr3IVUSKO1aghfOS4hSpcBxin0BXWfOyDtD5GlJczS5gN9o5etAVPqULvP FWWxZ4OHQn8l+5hm0UC6PN3qHgnxs3D7T0YAWGydgm6Kzqk4kBarRu/xkro+e/RV975A utB+h/kYktmWHuXpI2eND04/DnZDPB7TsRUoyNO/58N2ubZIRC/NVvVMpVotJmhq8iq0 QbOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9eDqyC8teOca9lKPG7kLW9GUe8GstujE/HDVUyG8mlQ=; b=s1GRS8cW3kffzUc4gblbnTJjg7cLmAFXaM/5gaOEcjBh23rf72p/m8xZuFsUvFUI0Y hvfnunSTELfmS4ZW4Xn8jTUMXZeSNCelpIZO5B1qAtzAxS/h02KPyypYiBzuyp5TOzRV KmxSGs8UwyJqpxPSQmSru6F1WKvz5ZBdkbQLNAztMupPksCbQEL252LV55NLvtcMiDuG uJ70ZtsGuRmEDwxns3VDUCKth86EocGFJTFoz5kgFgFTLUTe40WRXZKK5VAOsh+oRzK+ ImYf77MA7EQbe7cwH1IS+hIraEnHnwlpIUwpcQaq7ccxp6hJStQMp02e7YxhbC/HM0R9 wvGg== X-Gm-Message-State: AHQUAuanCIOpaIWinqedeZKshBvG9pnsDUkSCY84H3wzjJC/h96yyH6v DlUaVPVUaSP831VUd2AlWPzsoAi7zGLY3mwHz216hw== X-Google-Smtp-Source: AHgI3Ia5fUeCWAtTUNxD9XXTVzjQqIIyl32AlyYeD7i+pfTNNvfVTtCNLXPW+iRnN5ZZfPwNH76KyDrprZBqJX8d3NU= X-Received: by 2002:a6b:8fd7:: with SMTP id r206mr7631744iod.5.1551030224634; Sun, 24 Feb 2019 09:43:44 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: William Denniss Date: Sun, 24 Feb 2019 09:43:31 -0800 Message-ID: To: Brock Allen Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="00000000000093a08e0582a75d19" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 17:43:48 -0000 --00000000000093a08e0582a75d19 Content-Type: text/plain; charset="UTF-8" For apps signing-in third party (3P) users on iOS, Google Sign-in does require it (for 2.5 years & counting now), I'm also noticing it all over the place in other apps for 3P sign-in as it's really the only viable option for 3P sign-in - which is the argument we make in RFC 8252. First party (1P) sign-in is an interesting case, since for 1P there are more options available. Google apps do use the ASWebAuthenticationSession for 1P user sign-in, simply go "Add another account" in an app like Maps to try. I've noticed a few other apps doing this of late as well, such as Target which uses SFSVC for sign-in of their own 1P users, which I assume was implemented before ASWebAuthenticationSession existed. For 1P sign-in, there are several good reasons to go with ASWebAuthenticationSession, like syncing the signed-in session with Safari and using it if it already exists. On Sun, Feb 24, 2019 at 7:32 AM Brock Allen wrote: > > Interestingly I was told that switching to AppAuth increased login > conversions for them with YouTube. That was a while ago. > > I think you just said the magic words that marketing folks like to hear. > Thanks all. > > -Brock > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000093a08e0582a75d19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For apps signing-in= third party (3P) users on iOS, Google Sign-in does require it (for 2.5 years & counting now), I'm also noti= cing it all over the place in other apps for 3P sign-in as it's really = the only viable option for 3P sign-in - which is the argument we make in RF= C 8252.

First party (1P) sign-in is an = interesting case, since for 1P there are more options available. Google app= s do use the ASWebAuthenticationSession for 1P user sign-in, simply go &quo= t;Add another account" in an app like Maps to try. I've noticed a = few other apps doing this of late as well, such as Target which uses SFSVC = for sign-in of their own 1P users, which I assume was implemented before AS= WebAuthenticationSession existed.
=C2=A0
For 1P sig= n-in, there are several good reasons to go with ASWebAuthenticationSession,= like syncing the signed-in session with Safari and using it if it already = exists.


On Sun, Feb 24, 2019 at 7:32 AM Bro= ck Allen <brockallen@gmail.com> wrote:
=20 =20 =20 =20 =20 >=C2=A0Interestingly I was told that switching to AppAuth increased login co= nversions for them with YouTube. That was a while ago.

I think you just said the magic words that marketing folks like to = hear. Thanks all.

-Brock
=20
_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000093a08e0582a75d19-- From nobody Sun Feb 24 16:59:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7D12DD85 for ; Sun, 24 Feb 2019 16:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6DAA8_Z0x5H for ; Sun, 24 Feb 2019 16:59:38 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9A93F128CF3 for ; Sun, 24 Feb 2019 16:59:38 -0800 (PST) Received: from [IPv6:2601:282:202:b210:ad62:fd44:8359:5a36] (unknown [IPv6:2601:282:202:b210:ad62:fd44:8359:5a36]) by alkaline-solutions.com (Postfix) with ESMTPSA id F2E17315EC; Mon, 25 Feb 2019 00:59:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: David Waite In-Reply-To: Date: Sun, 24 Feb 2019 17:59:37 -0700 Cc: Brock Allen , oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> To: William Denniss X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 00:59:40 -0000 > On Feb 24, 2019, at 10:43 AM, William Denniss = wrote: >=20 > For 1P sign-in, there are several good reasons to go with = ASWebAuthenticationSession, like syncing the signed-in session with = Safari and using it if it already exists. With enterprise 3P, you=E2=80=99ll have to use some web agent for = authentication pretty much no matter what, and you=E2=80=99ll almost = certainly get pressure to use ASWebAuthenticationSession, and/or = potentially lose deals to competitors during product evaluations. It is = simply what is required for robust integration into a corporate = infrastructure. For 1P on iOS, it depends on the complexity of authentication for first = party. If you are just doing password and maybe SMS-based challenges, = there is decent enough native app integration for password sharing and = SMS keyboard for that to keep conversions high, even with having to = authenticate twice. However, if you want to authenticate the device (even pseudonymously = with session cookies) or do other factors, the authentication is simpler = with ASWebAuthenticationSession. Which means your life will be easier if = you have more complex authentication requirements anywhere on your = roadmap to just start off using ASWebAuthenticationSession. It is likely that future authentication technologies like WebAuthn will = not work with an embedded web view. The ability to arbitrarily inject = javascript means that apps can phish webauthn responses for domains via = embedded web views. -DW From nobody Mon Feb 25 02:48:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9E130ED7 for ; Mon, 25 Feb 2019 02:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAh5MWlZRp7S for ; Mon, 25 Feb 2019 02:48:04 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E0212F1AC for ; Mon, 25 Feb 2019 02:48:04 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id h10so6457225lfc.12 for ; Mon, 25 Feb 2019 02:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cIi68zM5eCxHKcu92f/OkMOB5nw9ZS65vD2BVzjDP5o=; b=PKzRE1PtRXAEtj1NJ3ZxMWamlxwcCUd3pDDZ2wg/lodnlzmgxUgraS2px1doA2XaUv s4/lI2trp9IcE27GGe83+P5s4Arn/p/PpaKCZWwB/uDyHD/yMgKlOCByFlPvKjgbSHm/ A5AMqwgRqCQw8szMVyOzCNAt1Y02FnFi/wzOAp1JX+rzbIUkq0dyJOzuokxIG1WYlD+W eD0JKY2YICvDii90oietQfF609cJklY5+Vjuupvg/30ABUsVSnpCynKMSksw/7qh2+tH fDZeID5W8yrzez6zUDHCi9+eVV3Y9Nw/eEfo337cqa9O9+709DNm5mg/zRCW8Bprixj3 vo/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cIi68zM5eCxHKcu92f/OkMOB5nw9ZS65vD2BVzjDP5o=; b=l5zzxNSB4+Hvz7ZDsAtx1mICY2lvCzU6yBlrgd8vwmBlzPRMDCFj/FWcAfVuvvqs0B +6q3rkwkUHbpMDn7IPztdxifXe4iJmVP6PWhBCzb+tkuG3MH2e4B2r8LneWW3HIZxMDN T84wCODApeZJUKTMsOZfCOLg4ShCj/mHRMiXKuVdWdptG1OMx1AyTA2VQDowScCRBEq0 hlc2QQTaCDUvfglyqmsgj8Gp6iEQm6HJIMuShR3roW73podVn3Tx21JxZifPkLLxMTDX hbxf7HLd/jNQ1bB4kfZtdWZLh3oc9iM4H3oybcNtHHdq6Cwysg5mxgRA7ESF4HV9hPTw ut0w== X-Gm-Message-State: AHQUAuY4b+oixAOvL09zaDHqrzlRcrE2BUnRP7rr5CxUzsjMt/cSTKlq eSGnR1Oj4qnVx8ywkYs28GzW0Y3ZmZ2e6MPpI0ivf7Qz4jY6wh6j X-Google-Smtp-Source: AHgI3IasFS3T+Bw/hMbbHzhmzZBKyuR4ZkGxEcE+7KOGsa2WgsSiwnnDdthwoybKy9USAVsjRdTG7ztyoSjcZd7mJ7I= X-Received: by 2002:a19:c1d4:: with SMTP id r203mr4892505lff.60.1551091682009; Mon, 25 Feb 2019 02:48:02 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 25 Feb 2019 10:47:51 +0000 Message-ID: To: David Waite Cc: William Denniss , oauth Content-Type: multipart/alternative; boundary="000000000000b87f130582b5ac39" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 10:48:07 -0000 --000000000000b87f130582b5ac39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ahh, as John knows this is a big pet peeve for me :) Although that's all true on mobile, on desktop things are more complicated. - Using a system browser on the desktop (Linux/Mac/Windows) means that you don't control the experience (there might be modal dialogs occluding the browser or any other Z order windows factors; the browser instance might have already other tabs open; the default browser of any particula= r machine can be different; users might need to take steps to get back to = the app; etc) - Use of loopback adapters is banned by many big enterprises on their machines - The big security advantages of the approach on mobile, where apps are all nicely sandboxed, is not as pronounced in an environment where the u= ser login session in the machine is the main security boundary (think keylog= ger attaching to the main windows events pump, or a debugger - all stuff not possible on mobile but viable on desktops) True, it would be fantastic if desktop OSes would offer system browser features comparable to what's available on iOS and Android - but today that doesn't appear to be the case. And the inability to leverage existing sessions when using embedded views on the desktop is a true pain. But judging from the behavior of the most popular desktop apps in market (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for Mac...) losing the ability to access cookies is less of a nuisance for users than all of the above. And considering that desktop machines usually have their own way of identifying devices, that is also not much of a factor for desktop apps. The best practice has been discussed for the last 4 years and still all of the big apps above remain on embedded: it is however telling that the mobile apps from the same vendors all embraced the system browser approach. Since the native best practices came out, I have been working with desktop developers dealing with this cognitive dissonance of the best practice saying something that is very hard to put in practice. I understand that it is well intentioned and it is easier to give one single advice for both mobile and desktop, but while the necessary features and experiences are lacking on the desktop I am not sure how much of a difference it is making in that use case. On Mon, Feb 25, 2019 at 12:59 AM David Waite wrote: > > > On Feb 24, 2019, at 10:43 AM, William Denniss 40google.com@dmarc.ietf.org> wrote: > > > > For 1P sign-in, there are several good reasons to go with > ASWebAuthenticationSession, like syncing the signed-in session with Safar= i > and using it if it already exists. > > With enterprise 3P, you=E2=80=99ll have to use some web agent for authent= ication > pretty much no matter what, and you=E2=80=99ll almost certainly get press= ure to use > ASWebAuthenticationSession, and/or potentially lose deals to competitors > during product evaluations. It is simply what is required for robust > integration into a corporate infrastructure. > > For 1P on iOS, it depends on the complexity of authentication for first > party. If you are just doing password and maybe SMS-based challenges, the= re > is decent enough native app integration for password sharing and SMS > keyboard for that to keep conversions high, even with having to > authenticate twice. > > However, if you want to authenticate the device (even pseudonymously with > session cookies) or do other factors, the authentication is simpler with > ASWebAuthenticationSession. Which means your life will be easier if you > have more complex authentication requirements anywhere on your roadmap to > just start off using ASWebAuthenticationSession. > > It is likely that future authentication technologies like WebAuthn will > not work with an embedded web view. The ability to arbitrarily inject > javascript means that apps can phish webauthn responses for domains via > embedded web views. > > -DW > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b87f130582b5ac39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ahh, as John knows this is a big pet peeve for me :)=C2=A0=

Although that's all true on mobile, on desktop things are= more complicated.=C2=A0
  • Using a system browser on the desktop = (Linux/Mac/Windows) means that you don't control the experience (there = might be modal dialogs occluding the browser or any other Z order windows f= actors; the browser instance might have already other tabs open; the defaul= t browser of any particular machine can be different; users might need to t= ake steps to get back to the app; etc)=C2=A0
  • Use of loopback adapte= rs is banned by many big enterprises on their machines
  • The big secu= rity advantages of the approach on mobile, where apps are all nicely sandbo= xed, is not as pronounced in an environment where the user login session in= the machine is the main security boundary (think keylogger attaching to th= e main windows events pump, or a debugger - all stuff not possible on mobil= e but viable on desktops)
True, it would be fantastic if desk= top OSes would offer system browser features comparable to what's avail= able on iOS and Android - but today that doesn't appear to be the case.= And the inability to leverage existing sessions when using embedded views = on the desktop is a true pain. But judging from the behavior of the most po= pular desktop apps in market (Office, Slack, Adobe Reader, Visual Studio, e= ven the Google Drive app for Mac...) losing the ability to access cookies i= s less of a nuisance for users than all of the above.=C2=A0And considering = that desktop machines usually have their own way of identifying devices, th= at is also not much of a factor for desktop apps.

= The best practice has been discussed for the last 4 years and still all of = the big apps above remain on embedded: it is however telling that the mobil= e apps from the same vendors all embraced the system browser approach.
Since the native best practices came out, I have been working with de= sktop developers dealing with this cognitive dissonance of the best practic= e saying something that is very hard to put in practice. I understand that = it is well intentioned and it is easier to give one single advice for both = mobile and desktop, but while the necessary features and experiences are la= cking on the desktop I am not sure how much of a difference it is making in= that use case.=C2=A0


=

= On Mon, Feb 25, 2019 at 12:59 AM David Waite <david@alkaline-solutions.com> wrote:
=

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmar= c.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthent= icationSession, like syncing the signed-in session with Safari and using it= if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentic= ation pretty much no matter what, and you=E2=80=99ll almost certainly get p= ressure to use ASWebAuthenticationSession, and/or potentially lose deals to= competitors during product evaluations. It is simply what is required for = robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first par= ty. If you are just doing password and maybe SMS-based challenges, there is= decent enough native app integration for password sharing and SMS keyboard= for that to keep conversions high, even with having to authenticate twice.=

However, if you want to authenticate the device (even pseudonymously with s= ession cookies) or do other factors, the authentication is simpler with ASW= ebAuthenticationSession. Which means your life will be easier if you have m= ore complex authentication requirements anywhere on your roadmap to just st= art off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not= work with an embedded web view. The ability to arbitrarily inject javascri= pt means that apps can phish webauthn responses for domains via embedded we= b views.

-DW

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b87f130582b5ac39-- From nobody Mon Feb 25 03:21:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8428126C01 for ; Mon, 25 Feb 2019 03:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atjWpdU3Q7fm for ; Mon, 25 Feb 2019 03:21:40 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CE2124C04 for ; Mon, 25 Feb 2019 03:21:39 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id y15so7688166wma.0 for ; Mon, 25 Feb 2019 03:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zLD+KDbCBMOGQJPTHpt4zbddKPWtxVzBz4AHRM0eBbA=; b=eQwWB1K7dUcO7bvYK+lfQ9PxSaVTVq663StH7b9enFHjzhk9LTxXZScMTo/zEg5Ken 84B7PovUc0oI+Qe8itzkkPcBbRnctx6bpJUEW35pTn3Y2ACW5ZVwQ0l195cvPh4z8O+G d9E1ujrTmbRpIGdJji6QUPTGKl78GXdkYLKTZ18KQSwCdneCBodmqlfg4fH4a3kiOXcR Mdfqf91gz3/cOu0GE+Jl1bud1NMTbbPK5KX+DDoRP+Jj1CezKfC1f1zoFl6/SIuH32Zl AP+zCvJnLbas9y2o663z1i+8nDOnQATHW4Xlzi5SO7xXBQSWALBzU8unt9btYN0zmTRY ZM3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zLD+KDbCBMOGQJPTHpt4zbddKPWtxVzBz4AHRM0eBbA=; b=XOGVAOZcEtaMYTpAYPgaNyk29XNxcHxBRmiV5GQRfECA/v1rarW/b4u1CVnbhSq86o gniXqUt/iUsZlU5kkfMUAa4P57CLIwqcaqTRK8XJ1hw9thes/slqFyi8dRlrvElAjJ2f euu3nP9TycO5yJFl4Y5p43kZKjKRTsAR3TwYapJXHQu3/z5mZoZBZqjL0DsaH+cZCLLt 3b3Jr7dHX+mgra3SQl+fRGNVUzxcS2TYVmRndOoU8V0OFLRWcoomy+gIt10iz/2W3YV4 s0EYJWoI66tVcKcId8H3fVKHphYXdIOpcUw92UQcKyKtsdOrCRZ0jsLD6IT9kbdQv5j/ ZPPg== X-Gm-Message-State: AHQUAubzR9XYvVZtjRXrHS0f+AI8G/cWhAeAhqc+kI3gzAY6PE+imbt9 V3BW3kXhZrygGBZCHqBcUKlMSsaeMjZ7YcGCqzF4s6JbUwGarg== X-Google-Smtp-Source: AHgI3IbBvAsrhGsbqgJd/IrFxQZkFukADz545rRBkBPIdmLHS0Y0kX+tGPWWRzBAU7GudfTFSTpaw8yoL4m7NRIEFkc= X-Received: by 2002:a1c:14e:: with SMTP id 75mr9717774wmb.48.1551093697632; Mon, 25 Feb 2019 03:21:37 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: John Bradley Date: Mon, 25 Feb 2019 08:21:25 -0300 Message-ID: To: Vittorio Bertocci Cc: David Waite , William Denniss , oauth Content-Type: multipart/alternative; boundary="000000000000dc73b20582b62496" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 11:21:43 -0000 --000000000000dc73b20582b62496 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Windows Web Authentication broker is a option. https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication.We= b I have encouraged Apple to provide a SSO service on OSX. The availability of WebAuthn in browsers may make the platforms rethink some things. John B. On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci wrote: > Ahh, as John knows this is a big pet peeve for me :) > > Although that's all true on mobile, on desktop things are more > complicated. > > - Using a system browser on the desktop (Linux/Mac/Windows) means that > you don't control the experience (there might be modal dialogs occludi= ng > the browser or any other Z order windows factors; the browser instance > might have already other tabs open; the default browser of any particu= lar > machine can be different; users might need to take steps to get back t= o the > app; etc) > - Use of loopback adapters is banned by many big enterprises on their > machines > - The big security advantages of the approach on mobile, where apps > are all nicely sandboxed, is not as pronounced in an environment where= the > user login session in the machine is the main security boundary (think > keylogger attaching to the main windows events pump, or a debugger - a= ll > stuff not possible on mobile but viable on desktops) > > True, it would be fantastic if desktop OSes would offer system browser > features comparable to what's available on iOS and Android - but today th= at > doesn't appear to be the case. And the inability to leverage existing > sessions when using embedded views on the desktop is a true pain. But > judging from the behavior of the most popular desktop apps in market > (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app fo= r > Mac...) losing the ability to access cookies is less of a nuisance for > users than all of the above. And considering that desktop machines usuall= y > have their own way of identifying devices, that is also not much of a > factor for desktop apps. > > The best practice has been discussed for the last 4 years and still all o= f > the big apps above remain on embedded: it is however telling that the > mobile apps from the same vendors all embraced the system browser approac= h. > Since the native best practices came out, I have been working with deskto= p > developers dealing with this cognitive dissonance of the best practice > saying something that is very hard to put in practice. I understand that = it > is well intentioned and it is easier to give one single advice for both > mobile and desktop, but while the necessary features and experiences are > lacking on the desktop I am not sure how much of a difference it is makin= g > in that use case. > > > > On Mon, Feb 25, 2019 at 12:59 AM David Waite > wrote: > >> >> > On Feb 24, 2019, at 10:43 AM, William Denniss > 40google.com@dmarc.ietf.org> wrote: >> > >> > For 1P sign-in, there are several good reasons to go with >> ASWebAuthenticationSession, like syncing the signed-in session with Safa= ri >> and using it if it already exists. >> >> With enterprise 3P, you=E2=80=99ll have to use some web agent for authen= tication >> pretty much no matter what, and you=E2=80=99ll almost certainly get pres= sure to use >> ASWebAuthenticationSession, and/or potentially lose deals to competitors >> during product evaluations. It is simply what is required for robust >> integration into a corporate infrastructure. >> >> For 1P on iOS, it depends on the complexity of authentication for first >> party. If you are just doing password and maybe SMS-based challenges, th= ere >> is decent enough native app integration for password sharing and SMS >> keyboard for that to keep conversions high, even with having to >> authenticate twice. >> >> However, if you want to authenticate the device (even pseudonymously wit= h >> session cookies) or do other factors, the authentication is simpler with >> ASWebAuthenticationSession. Which means your life will be easier if you >> have more complex authentication requirements anywhere on your roadmap t= o >> just start off using ASWebAuthenticationSession. >> >> It is likely that future authentication technologies like WebAuthn will >> not work with an embedded web view. The ability to arbitrarily inject >> javascript means that apps can phish webauthn responses for domains via >> embedded web views. >> >> -DW >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000dc73b20582b62496 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Windows Web Authentication broker is a option.=C2=A0

I have encouraged Apple to prov= ide a SSO service on OSX.=C2=A0

The availability of WebAuthn in browsers may make the platforms r= ethink some things.=C2=A0

John B.=C2=A0


On Mon, Feb 25, 2019, 7:48= AM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Ahh, as John knows this is a big pet peeve = for me :)=C2=A0

Although that's all true on mobile, on des= ktop things are more complicated.=C2=A0
  • Using a system browser = on the desktop (Linux/Mac/Windows) means that you don't control the exp= erience (there might be modal dialogs occluding the browser or any other Z = order windows factors; the browser instance might have already other tabs o= pen; the default browser of any particular machine can be different; users = might need to take steps to get back to the app; etc)=C2=A0
  • Use of = loopback adapters is banned by many big enterprises on their machines
    • <= li>The big security advantages of the approach on mobile, where apps are al= l nicely sandboxed, is not as pronounced in an environment where the user l= ogin session in the machine is the main security boundary (think keylogger = attaching to the main windows events pump, or a debugger - all stuff not po= ssible on mobile but viable on desktops)
True, it would be fa= ntastic if desktop OSes would offer system browser features comparable to w= hat's available on iOS and Android - but today that doesn't appear = to be the case. And the inability to leverage existing sessions when using = embedded views on the desktop is a true pain. But judging from the behavior= of the most popular desktop apps in market (Office, Slack, Adobe Reader, V= isual Studio, even the Google Drive app for Mac...) losing the ability to a= ccess cookies is less of a nuisance for users than all of the above.=C2=A0A= nd considering that desktop machines usually have their own way of identify= ing devices, that is also not much of a factor for desktop apps.
=
The best practice has been discussed for the last 4 years an= d still all of the big apps above remain on embedded: it is however telling= that the mobile apps from the same vendors all embraced the system browser= approach.
Since the native best practices came out, I have been = working with desktop developers dealing with this cognitive dissonance of t= he best practice saying something that is very hard to put in practice. I u= nderstand that it is well intentioned and it is easier to give one single a= dvice for both mobile and desktop, but while the necessary features and exp= eriences are lacking on the desktop I am not sure how much of a difference = it is making in that use case.=C2=A0



On Mon, Feb 25, 2019 at 12:59 AM David Waite <= david@alkaline-solutions.com> wrote:

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthent= icationSession, like syncing the signed-in session with Safari and using it= if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentic= ation pretty much no matter what, and you=E2=80=99ll almost certainly get p= ressure to use ASWebAuthenticationSession, and/or potentially lose deals to= competitors during product evaluations. It is simply what is required for = robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first par= ty. If you are just doing password and maybe SMS-based challenges, there is= decent enough native app integration for password sharing and SMS keyboard= for that to keep conversions high, even with having to authenticate twice.=

However, if you want to authenticate the device (even pseudonymously with s= ession cookies) or do other factors, the authentication is simpler with ASW= ebAuthenticationSession. Which means your life will be easier if you have m= ore complex authentication requirements anywhere on your roadmap to just st= art off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not= work with an embedded web view. The ability to arbitrarily inject javascri= pt means that apps can phish webauthn responses for domains via embedded we= b views.

-DW

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000dc73b20582b62496-- From nobody Mon Feb 25 03:38:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745B7130DC9 for ; Mon, 25 Feb 2019 03:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ISYP3u5VoQ2 for ; Mon, 25 Feb 2019 03:38:49 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D8E126C01 for ; Mon, 25 Feb 2019 03:38:49 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id m73so1038999lfa.2 for ; Mon, 25 Feb 2019 03:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ECPELGs6DIi+NYA9p7AOqSIHakp1RdDIf+CAWbF0P4=; b=q26NbvklsJKby7k6o8gK4V70vwulE4oIfKYvCtTdeL232jwXhBQFVaD4PyJbPSkqfd 73BXjfgPe9NEvsRqs2AF4tS3Nj7ld/G44TeyhTPUVK1zuOXMlM6yS56cNwRPaG48y3mU TnoemtIGs1p1sIlX+/IC0LYbbtqUSOwoUKZwHM8oS8KH+dkq5wrqdPG+FbbnMbCT/lu2 ERActjbKULI35rtll5GXGuCOR3qxmRiSC6dTV0eFWmfV+tmpw9o/du6k2lC19I+wgyQi O2R+4RfTYK7nmajOH1mJgqt/tuqKVw3l8oXdDKr4SyLeD6l0if7I/TNjtQAhKz1NxTWk 9m+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8ECPELGs6DIi+NYA9p7AOqSIHakp1RdDIf+CAWbF0P4=; b=OhqayscWzZ7aPJh/GRbvF0kUPdnB7nwXPYNeItWn25/Hq5ek8okYa9HR0Du4zRuolA s74XF6hdbhaY8uTi8EpdiE9GH8F+mK4jWjIkCkFa8J0H3bprwoWjJvwCtWoknJMn95ht z1zwCu38V0kEoqzNY4LO0fMq9pjSlZ0Yi9dPsW28w2sF3DyoUMOWmZ1I2ixVRdPX5KQk xdEFKWXYes84fN/NoFTon6ohAfXy8YMHsClzMPLc2a5iBBzMNcaghY6R1c9j/gVncUJR clArF1IYAqKn4VbxoR3LMA6ZEvnKGvHZOgyg2APdO7aY7UjSznojVGNkmAzA87aM9mor jBYA== X-Gm-Message-State: AHQUAuaMUTeeCt5+D1GpGKJUFT1WExuWarNoANnGG4RPJD0LmtQ2EgxX uJiB988Fy1BKiBMeGC+8SG2sd4gHi6fMyXKcG44B/w== X-Google-Smtp-Source: AHgI3IZN5atezvXgqmX8If5MZiOPXMsYtLFxMazz+hGFhzrQfW8CDGabTNatAAEv6GY6pAhBjtaEbUEwrwuburyXS24= X-Received: by 2002:ac2:52ad:: with SMTP id r13mr9639467lfm.50.1551094726838; Mon, 25 Feb 2019 03:38:46 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 25 Feb 2019 03:38:37 -0800 Message-ID: To: John Bradley Cc: David Waite , William Denniss , oauth Content-Type: multipart/alternative; boundary="0000000000003516a50582b662c1" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 11:38:54 -0000 --0000000000003516a50582b662c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable True, the WAB is perhaps the best approximation of a desktop system browser-like feature, but it doesn't solve Mac or Linux. Even within the Windows world, Win10 usage pulled ahead of Win7 only in January, and barely- and the WAB isn't available on Win7. In fact, you bring up an excellent point. I am wondering if the OS vendors are making any plans to make WebauthN available to desktop apps beyond 1st party applications. Regadless of what the future might look like, the problems I listed above are concrete blockers for the adption of that pattern on that desktop. I am wondering if those issues should be explicitly acknowledged in the best practices document, so that developers running into them realize they are now issues and not something they are doing wrong. On Mon, Feb 25, 2019 at 3:21 AM John Bradley wrote: > On Windows Web Authentication broker is a option. > > > https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication.= Web > > I have encouraged Apple to provide a SSO service on OSX. > > The availability of WebAuthn in browsers may make the platforms rethink > some things. > > John B. > > > On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> Ahh, as John knows this is a big pet peeve for me :) >> >> Although that's all true on mobile, on desktop things are more >> complicated. >> >> - Using a system browser on the desktop (Linux/Mac/Windows) means >> that you don't control the experience (there might be modal dialogs >> occluding the browser or any other Z order windows factors; the brows= er >> instance might have already other tabs open; the default browser of a= ny >> particular machine can be different; users might need to take steps t= o get >> back to the app; etc) >> - Use of loopback adapters is banned by many big enterprises on their >> machines >> - The big security advantages of the approach on mobile, where apps >> are all nicely sandboxed, is not as pronounced in an environment wher= e the >> user login session in the machine is the main security boundary (thin= k >> keylogger attaching to the main windows events pump, or a debugger - = all >> stuff not possible on mobile but viable on desktops) >> >> True, it would be fantastic if desktop OSes would offer system browser >> features comparable to what's available on iOS and Android - but today t= hat >> doesn't appear to be the case. And the inability to leverage existing >> sessions when using embedded views on the desktop is a true pain. But >> judging from the behavior of the most popular desktop apps in market >> (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app f= or >> Mac...) losing the ability to access cookies is less of a nuisance for >> users than all of the above. And considering that desktop machines usual= ly >> have their own way of identifying devices, that is also not much of a >> factor for desktop apps. >> >> The best practice has been discussed for the last 4 years and still all >> of the big apps above remain on embedded: it is however telling that the >> mobile apps from the same vendors all embraced the system browser approa= ch. >> Since the native best practices came out, I have been working with >> desktop developers dealing with this cognitive dissonance of the best >> practice saying something that is very hard to put in practice. I >> understand that it is well intentioned and it is easier to give one sing= le >> advice for both mobile and desktop, but while the necessary features and >> experiences are lacking on the desktop I am not sure how much of a >> difference it is making in that use case. >> >> >> >> On Mon, Feb 25, 2019 at 12:59 AM David Waite < >> david@alkaline-solutions.com> wrote: >> >>> >>> > On Feb 24, 2019, at 10:43 AM, William Denniss >> 40google.com@dmarc.ietf.org> wrote: >>> > >>> > For 1P sign-in, there are several good reasons to go with >>> ASWebAuthenticationSession, like syncing the signed-in session with Saf= ari >>> and using it if it already exists. >>> >>> With enterprise 3P, you=E2=80=99ll have to use some web agent for authe= ntication >>> pretty much no matter what, and you=E2=80=99ll almost certainly get pre= ssure to use >>> ASWebAuthenticationSession, and/or potentially lose deals to competitor= s >>> during product evaluations. It is simply what is required for robust >>> integration into a corporate infrastructure. >>> >>> For 1P on iOS, it depends on the complexity of authentication for first >>> party. If you are just doing password and maybe SMS-based challenges, t= here >>> is decent enough native app integration for password sharing and SMS >>> keyboard for that to keep conversions high, even with having to >>> authenticate twice. >>> >>> However, if you want to authenticate the device (even pseudonymously >>> with session cookies) or do other factors, the authentication is simple= r >>> with ASWebAuthenticationSession. Which means your life will be easier i= f >>> you have more complex authentication requirements anywhere on your road= map >>> to just start off using ASWebAuthenticationSession. >>> >>> It is likely that future authentication technologies like WebAuthn will >>> not work with an embedded web view. The ability to arbitrarily inject >>> javascript means that apps can phish webauthn responses for domains via >>> embedded web views. >>> >>> -DW >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000003516a50582b662c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
True, the WAB is perhaps the best approximation of a deskt= op system browser-like feature, but it doesn't solve Mac or Linux. Even= within the Windows world, Win10 usage pulled ahead of Win7 only in January= , and barely- and the WAB isn't available on Win7.
In fact, you bri= ng up an excellent point. I am wondering if the OS vendors are making any p= lans to make WebauthN available to desktop apps beyond 1st party applicatio= ns.

Regadless of what the future might look like, = the problems I listed above are concrete blockers for the adption of that p= attern on that desktop. I am wondering if those issues should be explicitly= acknowledged in the best practices document, so that developers running in= to them realize they are now issues and not something they are doing wrong.=

On Mon, Feb 25, 2019 at 3:21 AM John Bradley <ve7jtb@ve7jtb.com> wrote:
On Windows Web Authenti= cation broker is a option.=C2=A0


I have encouraged Apple to provide a SSO service on OS= X.=C2=A0

The availabilit= y of WebAuthn in browsers may make the platforms rethink some things.=C2=A0=

John B.=C2=A0


On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci <= ;Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Ahh, as John knows this is a bi= g pet peeve for me :)=C2=A0

Although that's all true on mo= bile, on desktop things are more complicated.=C2=A0
  • Using a sys= tem browser on the desktop (Linux/Mac/Windows) means that you don't con= trol the experience (there might be modal dialogs occluding the browser or = any other Z order windows factors; the browser instance might have already = other tabs open; the default browser of any particular machine can be diffe= rent; users might need to take steps to get back to the app; etc)=C2=A0
  • Use of loopback adapters is banned by many big enterprises on their ma= chines
  • The big security advantages of the approach on mobile, where= apps are all nicely sandboxed, is not as pronounced in an environment wher= e the user login session in the machine is the main security boundary (thin= k keylogger attaching to the main windows events pump, or a debugger - all = stuff not possible on mobile but viable on desktops)
True, it= would be fantastic if desktop OSes would offer system browser features com= parable to what's available on iOS and Android - but today that doesn&#= 39;t appear to be the case. And the inability to leverage existing sessions= when using embedded views on the desktop is a true pain. But judging from = the behavior of the most popular desktop apps in market (Office, Slack, Ado= be Reader, Visual Studio, even the Google Drive app for Mac...) losing the = ability to access cookies is less of a nuisance for users than all of the a= bove.=C2=A0And considering that desktop machines usually have their own way= of identifying devices, that is also not much of a factor for desktop apps= .

The best practice has been discussed for the las= t 4 years and still all of the big apps above remain on embedded: it is how= ever telling that the mobile apps from the same vendors all embraced the sy= stem browser approach.
Since the native best practices came out, = I have been working with desktop developers dealing with this cognitive dis= sonance of the best practice saying something that is very hard to put in p= ractice. I understand that it is well intentioned and it is easier to give = one single advice for both mobile and desktop, but while the necessary feat= ures and experiences are lacking on the desktop I am not sure how much of a= difference it is making in that use case.=C2=A0

=


On Mon, Feb 25, 2019 at 12:59 AM David Waite <= ;david@alkaline-solutions.com> wrote:

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthent= icationSession, like syncing the signed-in session with Safari and using it= if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentic= ation pretty much no matter what, and you=E2=80=99ll almost certainly get p= ressure to use ASWebAuthenticationSession, and/or potentially lose deals to= competitors during product evaluations. It is simply what is required for = robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first par= ty. If you are just doing password and maybe SMS-based challenges, there is= decent enough native app integration for password sharing and SMS keyboard= for that to keep conversions high, even with having to authenticate twice.=

However, if you want to authenticate the device (even pseudonymously with s= ession cookies) or do other factors, the authentication is simpler with ASW= ebAuthenticationSession. Which means your life will be easier if you have m= ore complex authentication requirements anywhere on your roadmap to just st= art off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not= work with an embedded web view. The ability to arbitrarily inject javascri= pt means that apps can phish webauthn responses for domains via embedded we= b views.

-DW

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003516a50582b662c1-- From nobody Mon Feb 25 03:40:29 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8A130EE7 for ; Mon, 25 Feb 2019 03:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTRb5Tchyu_U for ; Mon, 25 Feb 2019 03:40:25 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEA6130DC9 for ; Mon, 25 Feb 2019 03:40:25 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id i5so5009642qkd.13 for ; Mon, 25 Feb 2019 03:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=DvR9fS8f0j+UZ7m8qPAZaoZVo1PRuJDATGszuKQa04M=; b=g8yEo3NF7PrT6ffnJOmOkcYfvGi0NBJfUVNB8jbs9bspS9FeRPU8FY9DROBSyFRf0G jY4WkUKozweHEvEzTRBXaXKXmR/jTdbgVbT0DlFl/Pa/8PK7cCxLAjk8KvO39PAo6ybS m89bPHN0oH6f08qLZ3uVK5yFIg05p91Thz0w8GB28P03vFvr45k42bjIMkRV+3X4JuZO ByhmMPeoygQKp/dVZl+zb5EmKyGYpLpr3HZo9+/9eH4rESxR87y5701paWtS3OQTqf4A h17bjq/Hyi1YvssRr74OMKlhzOKPzbsG7DPeQxdNczo9vrIiXDq52yVE3j2c+2EtjLfX o6Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=DvR9fS8f0j+UZ7m8qPAZaoZVo1PRuJDATGszuKQa04M=; b=A0ghPmPSqgEA9M6PeLIFPh74/FpEEtWV6rdc8C2U9HrB+Wnm9Yk1MEG8XHLvh6NKlZ gIidEWhDHg7HF23wLa4Fs8nPDBWBvKTEaQJZ1Kh/00NZCmGj9b+wdEAwyn/wpc8D6o+2 D3w736fl+3IhFN0JL2ksAhQI5JGN5trLIRq3Ej0DnzOL5KHDbfFHbOvta/k9v0DxGxDF KMDePv4yR4wsZaCprxZqfXhpo2LERWJU67uiwyWmwaeUBhKKE07ycd10wxfmcHio03gA dSAi7ASKAPYkL5EyTJFYW6YuOMwFf+j32mHt1XnoreoCjZ+r/ZWR9lufj5oI234T25aT rOng== X-Gm-Message-State: AHQUAuZeGG4oJHNWSSX0TEk4W+tsNYJZHwzLjlOPhFxc6iKsUMv7MApN FUVeNzIbRem2BjRp03BKxkx2fwoMnCow/ASbHdGZfmg57A== X-Google-Smtp-Source: AHgI3IZ3TKg+xKQRf/NzMOhZBkL//kJHffnPMx2DQk5iNhASTYA+DlnAuuVIJVREMEjAVmeRHotLhZ/IqCaa0ytXmsE= X-Received: by 2002:a37:a407:: with SMTP id n7mr12880695qke.46.1551094823957; Mon, 25 Feb 2019 03:40:23 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Feb 2019 03:40:22 -0800 From: Dominick Baier In-Reply-To: References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> MIME-Version: 1.0 Date: Mon, 25 Feb 2019 03:40:22 -0800 Message-ID: To: Vittorio Bertocci , David Waite Cc: William Denniss , oauth Content-Type: multipart/alternative; boundary="000000000000fecd0e0582b66711" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 11:40:28 -0000 --000000000000fecd0e0582b66711 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A good example of a desktop application using browser authentication is Github for Desktop. They use custom URLs/callbacks for both OSX and Windows. Works very well. =E2=80=94=E2=80=94=E2=80=94 Dominick On 25. February 2019 at 11:48:20, Vittorio Bertocci ( vittorio=3D40auth0.com@dmarc.ietf.org) wrote: Ahh, as John knows this is a big pet peeve for me :) Although that's all true on mobile, on desktop things are more complicated. - Using a system browser on the desktop (Linux/Mac/Windows) means that you don't control the experience (there might be modal dialogs occluding the browser or any other Z order windows factors; the browser instance might have already other tabs open; the default browser of any particula= r machine can be different; users might need to take steps to get back to = the app; etc) - Use of loopback adapters is banned by many big enterprises on their machines - The big security advantages of the approach on mobile, where apps are all nicely sandboxed, is not as pronounced in an environment where the u= ser login session in the machine is the main security boundary (think keylog= ger attaching to the main windows events pump, or a debugger - all stuff not possible on mobile but viable on desktops) True, it would be fantastic if desktop OSes would offer system browser features comparable to what's available on iOS and Android - but today that doesn't appear to be the case. And the inability to leverage existing sessions when using embedded views on the desktop is a true pain. But judging from the behavior of the most popular desktop apps in market (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for Mac...) losing the ability to access cookies is less of a nuisance for users than all of the above. And considering that desktop machines usually have their own way of identifying devices, that is also not much of a factor for desktop apps. The best practice has been discussed for the last 4 years and still all of the big apps above remain on embedded: it is however telling that the mobile apps from the same vendors all embraced the system browser approach. Since the native best practices came out, I have been working with desktop developers dealing with this cognitive dissonance of the best practice saying something that is very hard to put in practice. I understand that it is well intentioned and it is easier to give one single advice for both mobile and desktop, but while the necessary features and experiences are lacking on the desktop I am not sure how much of a difference it is making in that use case. On Mon, Feb 25, 2019 at 12:59 AM David Waite wrote: > > > On Feb 24, 2019, at 10:43 AM, William Denniss 40google.com@dmarc.ietf.org> wrote: > > > > For 1P sign-in, there are several good reasons to go with > ASWebAuthenticationSession, like syncing the signed-in session with Safar= i > and using it if it already exists. > > With enterprise 3P, you=E2=80=99ll have to use some web agent for authent= ication > pretty much no matter what, and you=E2=80=99ll almost certainly get press= ure to use > ASWebAuthenticationSession, and/or potentially lose deals to competitors > during product evaluations. It is simply what is required for robust > integration into a corporate infrastructure. > > For 1P on iOS, it depends on the complexity of authentication for first > party. If you are just doing password and maybe SMS-based challenges, the= re > is decent enough native app integration for password sharing and SMS > keyboard for that to keep conversions high, even with having to > authenticate twice. > > However, if you want to authenticate the device (even pseudonymously with > session cookies) or do other factors, the authentication is simpler with > ASWebAuthenticationSession. Which means your life will be easier if you > have more complex authentication requirements anywhere on your roadmap to > just start off using ASWebAuthenticationSession. > > It is likely that future authentication technologies like WebAuthn will > not work with an embedded web view. The ability to arbitrarily inject > javascript means that apps can phish webauthn responses for domains via > embedded web views. > > -DW > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --000000000000fecd0e0582b66711 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
A go= od example of a desktop application using browser authentication is Github = for Desktop.

They u= se custom URLs/callbacks for both OSX and Windows. Works very well.
<= br>
=E2=80=94=E2=80=94=E2=80=94
Dominick=

On 25. February 2019 at 11:48:20, = Vittorio Bertocci (vittorio=3D40auth0.com@dmarc.ietf.org) wrote:

Ahh, as John knows this is a big pet peeve for me :)=C2=A0

Although that's all true on mobile, on desktop things are more complicated.=C2=A0
  • Using a system browser on the desktop (Linux/Mac/Windows) means that you don't control the experience (there might be modal dialogs occluding the browser or any other Z order windows factors; the browser instance might have already other tabs open; the default browser of any particular machine can be different; users might need to take steps to get back to the app; etc)=C2=A0
  • Use of loopback adapters is banned by many big enterprises on their machines
  • The big security advantages of the approach on mobile, where apps are all nicely sandboxed, is not as pronounced in an environment where the user login session in the machine is the main security boundary (think keylogger attaching to the main windows events pump, or a debugger - all stuff not possible on mobile but viable on desktops)
True, it would be fantastic if desktop OSes would offer system browser features comparable to what's available on iOS and Android - but today that doesn't appear to be the case. And the inability to leverage existing sessions when using embedded views on the desktop is a true pain. But judging from the behavior of the most popular desktop apps in market (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for Mac...) losing the ability to access cookies is less of a nuisance for users than all of the above.=C2=A0And considering that desktop machines usually have their own way of identifying devices, that is also not much of a factor for desktop apps.

The best practice has been discussed for the last 4 years and still all of the big apps above remain on embedded: it is however telling that the mobile apps from the same vendors all embraced the system browser approach.
Since the native best practices came out, I have been working with desktop developers dealing with this cognitive dissonance of the best practice saying something that is very hard to put in practice. I understand that it is well intentioned and it is easier to give one single advice for both mobile and desktop, but while the necessary features and experiences are lacking on the desktop I am not sure how much of a difference it is making in that use case.=C2=A0



On Mon, Feb 25, 2019 at 12:59 AM David Waite <david@alkal= ine-solutions.com> wrote:

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthenticationSession, like syncing the signed-in session with Safari and using it if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentication pretty much no matter what, and you=E2=80=99ll almost certainly get pressure to use ASWebAuthenticationSession, and/or potentially lose deals to competitors during product evaluations. It is simply what is required for robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first party. If you are just doing password and maybe SMS-based challenges, there is decent enough native app integration for password sharing and SMS keyboard for that to keep conversions high, even with having to authenticate twice.

However, if you want to authenticate the device (even pseudonymously with session cookies) or do other factors, the authentication is simpler with ASWebAuthenticationSession. Which means your life will be easier if you have more complex authentication requirements anywhere on your roadmap to just start off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not work with an embedded web view. The ability to arbitrarily inject javascript means that apps can phish webauthn responses for domains via embedded web views.

-DW

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--000000000000fecd0e0582b66711-- From nobody Mon Feb 25 03:40:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA40130F2D for ; Mon, 25 Feb 2019 03:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqO5AbdUtA9R for ; Mon, 25 Feb 2019 03:40:52 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9D7130F0F for ; Mon, 25 Feb 2019 03:40:51 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id v16so7067015ljg.13 for ; Mon, 25 Feb 2019 03:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sPEubQ9vPXDwds0KcKIPZt4xlwWrvNApQuKVPVTbZ9c=; b=dSjoXcNlgaezWXXgH+tqwhQ8gyU1rN0B8RjVRNCkOCXxHVbZrrg94CjSZc+s3+Y1c2 mblQWJJa89xr/zLG3v8ZZFgLzJm68LYXHtM2/D+Gtpw5dUUjRFORagUKde+K05C2dUGO OkFvJbbah2HlOONrO0CvQJ85wBO9hvACt3q7nJawwQjhmG18Y/o4Pg90nXcSI2xvOaeN FisR0m0l6w8S5fqI4XPr93l75Cv5gKU/P9CEoLFAOJxHa7eQUnYHB9Qr0ExV4z85jKcV lYdycbAa0aY47pnvYH3GdVjA4l8xAuteDXIFpAGwraKQgoRkmne4tk7MQ+SvyTZc+Lbm ygxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPEubQ9vPXDwds0KcKIPZt4xlwWrvNApQuKVPVTbZ9c=; b=Rtsjf8/fNocJPDyamtS7cVhnk3UzOmWQOm/3LpfO0tz4nKIWp87V2tEHHrNcSroxMq vv//i2tZvGRw/8pSs4YiYLXWBF8oVEAhGkwmCuubnGZno+9Aqn4ZTUnpPVoA4OZK6q8c KRrD/s0C8aaEmZsN0S5uJcs0h8VX3f3X6fI0Pp000hsGOzHvkFXsflF5yWYrvURSzMOf Pd1wJMMeMWGOlLyKJ9PckOyzax0NploEaTHOtZw2IVzVzDgeXZgA6qrZyc3ziMTd3EsY Cu4i6fgJVQ2dQNpJoQ9XTs88LNQVpXOmIG2v7pgvPyul1VN0Qcl6nwYMp5TuIvZ5ERJx aSQw== X-Gm-Message-State: AHQUAuaFgFw/ebeds/H8caQ8FUGdxSkU3FjWPNHgMkUo+zO8vQINMDC3 W2pEbPdaNITqpBHSzSC1Ayuf5BRAjXeN4UhIXSMYwg== X-Google-Smtp-Source: AHgI3IYTIRkD2uEBDlgxcSi6I87QFC3C2IrQEL1JbXwkNVTw6pkia7D+H8DWYYaflXSf88dR3F5sYfmyrPVMqN00Puw= X-Received: by 2002:a2e:2165:: with SMTP id h98mr9754225ljh.117.1551094849072; Mon, 25 Feb 2019 03:40:49 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 25 Feb 2019 03:40:39 -0800 Message-ID: To: John Bradley Cc: David Waite , William Denniss , oauth Content-Type: multipart/alternative; boundary="0000000000007e0b5f0582b669ea" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 11:40:56 -0000 --0000000000007e0b5f0582b669ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wish I could edit emails. Fixing some meaning changing typos. True, the WAB is perhaps the best approximation of a desktop system browser-like feature, but it doesn't solve Mac or Linux. Even within the Windows world, Win10 usage pulled ahead of Win7 only in January, and barely- and the WAB isn't available on Win7. In fact, you bring up an excellent point. I am wondering if the OS vendors are making any plans to make WebauthN available to desktop apps beyond 1st party applications. Regardless of what the future might look like, the problems I listed above are concrete blockers for the adoption of that pattern on desktop. I am wondering if those issues should be explicitly acknowledged in the best practices document, so that developers running into them realize they are known issues and not something they are doing wrong. On Mon, Feb 25, 2019 at 3:38 AM Vittorio Bertocci wrote: > True, the WAB is perhaps the best approximation of a desktop system > browser-like feature, but it doesn't solve Mac or Linux. Even within the > Windows world, Win10 usage pulled ahead of Win7 only in January, and > barely- and the WAB isn't available on Win7. > In fact, you bring up an excellent point. I am wondering if the OS vendor= s > are making any plans to make WebauthN available to desktop apps beyond 1s= t > party applications. > > Regadless of what the future might look like, the problems I listed above > are concrete blockers for the adption of that pattern on that desktop. I = am > wondering if those issues should be explicitly acknowledged in the best > practices document, so that developers running into them realize they are > now issues and not something they are doing wrong. > > On Mon, Feb 25, 2019 at 3:21 AM John Bradley wrote: > >> On Windows Web Authentication broker is a option. >> >> >> https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication= .Web >> >> I have encouraged Apple to provide a SSO service on OSX. >> >> The availability of WebAuthn in browsers may make the platforms rethink >> some things. >> >> John B. >> >> >> On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci > 40auth0.com@dmarc.ietf.org> wrote: >> >>> Ahh, as John knows this is a big pet peeve for me :) >>> >>> Although that's all true on mobile, on desktop things are more >>> complicated. >>> >>> - Using a system browser on the desktop (Linux/Mac/Windows) means >>> that you don't control the experience (there might be modal dialogs >>> occluding the browser or any other Z order windows factors; the brow= ser >>> instance might have already other tabs open; the default browser of = any >>> particular machine can be different; users might need to take steps = to get >>> back to the app; etc) >>> - Use of loopback adapters is banned by many big enterprises on >>> their machines >>> - The big security advantages of the approach on mobile, where apps >>> are all nicely sandboxed, is not as pronounced in an environment whe= re the >>> user login session in the machine is the main security boundary (thi= nk >>> keylogger attaching to the main windows events pump, or a debugger -= all >>> stuff not possible on mobile but viable on desktops) >>> >>> True, it would be fantastic if desktop OSes would offer system browser >>> features comparable to what's available on iOS and Android - but today = that >>> doesn't appear to be the case. And the inability to leverage existing >>> sessions when using embedded views on the desktop is a true pain. But >>> judging from the behavior of the most popular desktop apps in market >>> (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app = for >>> Mac...) losing the ability to access cookies is less of a nuisance for >>> users than all of the above. And considering that desktop machines usua= lly >>> have their own way of identifying devices, that is also not much of a >>> factor for desktop apps. >>> >>> The best practice has been discussed for the last 4 years and still all >>> of the big apps above remain on embedded: it is however telling that th= e >>> mobile apps from the same vendors all embraced the system browser appro= ach. >>> Since the native best practices came out, I have been working with >>> desktop developers dealing with this cognitive dissonance of the best >>> practice saying something that is very hard to put in practice. I >>> understand that it is well intentioned and it is easier to give one sin= gle >>> advice for both mobile and desktop, but while the necessary features an= d >>> experiences are lacking on the desktop I am not sure how much of a >>> difference it is making in that use case. >>> >>> >>> >>> On Mon, Feb 25, 2019 at 12:59 AM David Waite < >>> david@alkaline-solutions.com> wrote: >>> >>>> >>>> > On Feb 24, 2019, at 10:43 AM, William Denniss >>> 40google.com@dmarc.ietf.org> wrote: >>>> > >>>> > For 1P sign-in, there are several good reasons to go with >>>> ASWebAuthenticationSession, like syncing the signed-in session with Sa= fari >>>> and using it if it already exists. >>>> >>>> With enterprise 3P, you=E2=80=99ll have to use some web agent for >>>> authentication pretty much no matter what, and you=E2=80=99ll almost c= ertainly get >>>> pressure to use ASWebAuthenticationSession, and/or potentially lose de= als >>>> to competitors during product evaluations. It is simply what is requir= ed >>>> for robust integration into a corporate infrastructure. >>>> >>>> For 1P on iOS, it depends on the complexity of authentication for firs= t >>>> party. If you are just doing password and maybe SMS-based challenges, = there >>>> is decent enough native app integration for password sharing and SMS >>>> keyboard for that to keep conversions high, even with having to >>>> authenticate twice. >>>> >>>> However, if you want to authenticate the device (even pseudonymously >>>> with session cookies) or do other factors, the authentication is simpl= er >>>> with ASWebAuthenticationSession. Which means your life will be easier = if >>>> you have more complex authentication requirements anywhere on your roa= dmap >>>> to just start off using ASWebAuthenticationSession. >>>> >>>> It is likely that future authentication technologies like WebAuthn wil= l >>>> not work with an embedded web view. The ability to arbitrarily inject >>>> javascript means that apps can phish webauthn responses for domains vi= a >>>> embedded web views. >>>> >>>> -DW >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> --0000000000007e0b5f0582b669ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wish I could edit emails. Fixing some meaning changing t= ypos.

True, the WAB is perhaps the best approximation of= a desktop system browser-like feature, but it doesn't solve Mac or Lin= ux. Even within the Windows world, Win10 usage pulled ahead of Win7 only in= January, and barely- and the WAB isn't available on Win7.
In fact,= you bring up an excellent point. I am wondering if the OS vendors are maki= ng any plans to make WebauthN available to desktop apps beyond 1st party ap= plications.

Regardless of what the future might lo= ok like, the problems I listed above are concrete blockers for the adoption= of that pattern on desktop. I am wondering if those issues should be expli= citly acknowledged in the best practices document, so that developers runni= ng into them realize they are known issues and not something they are doing= wrong.

On Mon, Feb 25, 2019 at 3:38 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:
True= , the WAB is perhaps the best approximation of a desktop system browser-lik= e feature, but it doesn't solve Mac or Linux. Even within the Windows w= orld, Win10 usage pulled ahead of Win7 only in January, and barely- and the= WAB isn't available on Win7.
In fact, you bring up an excellent po= int. I am wondering if the OS vendors are making any plans to make WebauthN= available to desktop apps beyond 1st party applications.

Regadless of what the future might look like, the problems I listed= above are concrete blockers for the adption of that pattern on that deskto= p. I am wondering if those issues should be explicitly acknowledged in the = best practices document, so that developers running into them realize they = are now issues and not something they are doing wrong.

On Mon, Feb 25,= 2019 at 3:21 AM John Bradley <ve7jtb@ve7jtb.com> wrote:
On Windows Web Authentic= ation broker is a option.=C2=A0


I have encouraged Apple to provide a SSO service on OSX= .=C2=A0

The availability= of WebAuthn in browsers may make the platforms rethink some things.=C2=A0<= /div>

John B.=C2=A0


On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci <= Vittorio=3D= 40auth0.com@dmarc.ietf.org> wrote:
Ahh, as John knows this is a big= pet peeve for me :)=C2=A0

Although that's all true on mob= ile, on desktop things are more complicated.=C2=A0
  • Using a syst= em browser on the desktop (Linux/Mac/Windows) means that you don't cont= rol the experience (there might be modal dialogs occluding the browser or a= ny other Z order windows factors; the browser instance might have already o= ther tabs open; the default browser of any particular machine can be differ= ent; users might need to take steps to get back to the app; etc)=C2=A0
    • =
  • Use of loopback adapters is banned by many big enterprises on their mac= hines
  • The big security advantages of the approach on mobile, where = apps are all nicely sandboxed, is not as pronounced in an environment where= the user login session in the machine is the main security boundary (think= keylogger attaching to the main windows events pump, or a debugger - all s= tuff not possible on mobile but viable on desktops)
True, it = would be fantastic if desktop OSes would offer system browser features comp= arable to what's available on iOS and Android - but today that doesn= 9;t appear to be the case. And the inability to leverage existing sessions = when using embedded views on the desktop is a true pain. But judging from t= he behavior of the most popular desktop apps in market (Office, Slack, Adob= e Reader, Visual Studio, even the Google Drive app for Mac...) losing the a= bility to access cookies is less of a nuisance for users than all of the ab= ove.=C2=A0And considering that desktop machines usually have their own way = of identifying devices, that is also not much of a factor for desktop apps.=

The best practice has been discussed for the last= 4 years and still all of the big apps above remain on embedded: it is howe= ver telling that the mobile apps from the same vendors all embraced the sys= tem browser approach.
Since the native best practices came out, I= have been working with desktop developers dealing with this cognitive diss= onance of the best practice saying something that is very hard to put in pr= actice. I understand that it is well intentioned and it is easier to give o= ne single advice for both mobile and desktop, but while the necessary featu= res and experiences are lacking on the desktop I am not sure how much of a = difference it is making in that use case.=C2=A0

<= div>

On Mon, Feb 25, 2019 at 12:59 AM David Waite <= david@alkaline-solutions.com> wrote:

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthent= icationSession, like syncing the signed-in session with Safari and using it= if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentic= ation pretty much no matter what, and you=E2=80=99ll almost certainly get p= ressure to use ASWebAuthenticationSession, and/or potentially lose deals to= competitors during product evaluations. It is simply what is required for = robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first par= ty. If you are just doing password and maybe SMS-based challenges, there is= decent enough native app integration for password sharing and SMS keyboard= for that to keep conversions high, even with having to authenticate twice.=

However, if you want to authenticate the device (even pseudonymously with s= ession cookies) or do other factors, the authentication is simpler with ASW= ebAuthenticationSession. Which means your life will be easier if you have m= ore complex authentication requirements anywhere on your roadmap to just st= art off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not= work with an embedded web view. The ability to arbitrarily inject javascri= pt means that apps can phish webauthn responses for domains via embedded we= b views.

-DW

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000007e0b5f0582b669ea-- From nobody Mon Feb 25 03:56:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3AB130DE7 for ; Mon, 25 Feb 2019 03:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukSFM22TEJ2F for ; Mon, 25 Feb 2019 03:56:22 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BAC1200B3 for ; Mon, 25 Feb 2019 03:56:21 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id d14so7106154ljl.9 for ; Mon, 25 Feb 2019 03:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k22aYvbU4wWwac2LUykTtOg1PvBk6IW11Er2AzVExSw=; b=IxG6abCDrzeMLiJt78QRRzteJAoThQhjqfAejUNvaiFhmiCkznZSgFFOQV5NqUBLtC uKPJvz5bhMhC7HvoYO3pmJScqKzJsoG8vVicTi3Cta/56KhLA9E3cStvAtjTj1oXT8V+ vT37fh5kZyqhMcYdOcLSfTDA6jyDqgGfQiD4xNHdVbPPCKd2qrlrDonI0DsNis+ZLh7q GjNADqukGzZvAc3Afyb2/PWuXgrA/Vr8SJA/Ufd0m+whvA/meTaVz7mtIkE/bOnaAXDx 0h2HQhW5LyNGsmleShWUKb4lCtRqSkzxginJtvm72W1vZiwBHknSScH4EBa5zf/cBOPI UC+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k22aYvbU4wWwac2LUykTtOg1PvBk6IW11Er2AzVExSw=; b=BSzb16uPO/r4vVSBhU6hlNueBZB1wtcN3z//UTn/mXm2QqROyvq7OYCBiXYOlrb8RY Y65QLJRM8ok3WsTrBs8AqYQ6/3yR6VoU3gg+z5QqBY29ZcgCmsD1bRRJ9H4AKCb4fwfr q0yxHmohWxqj8jV17e4ik10skSN2mOHx11uANzm8T64mqqS1bX7BB7NfK1j5Dqo1CFNa 6PgB03FvfY20AB4wBwttxRXdqc2PHYq+7KKiuo97hWHBJwefVJ6Lxa5RZ8hUlvuPWYZ6 /OQVHxF4aX5/JMC2CfPhI4LTSX+8s+DJM/hpdpQPaI7Zc1N8O6hO4Dcw2RNLkf04n943 ypUA== X-Gm-Message-State: AHQUAua4VQyFFIqcE0E0FiAjE7y2A7Uj0w67MVa2Y+v96Jwkpcfb+Eq6 fLvmGRfb9vViuxjOu912jVRHUKV7qXLEYG09s1CpvA== X-Google-Smtp-Source: AHgI3IbeyU80pLjYf+jVSdYp9nt4oNKCeFbuE/4ZZTTrKNkPaOZe+1IHAomBC6t2cutrhmCrte7mOqrtsuq3+2Oh81U= X-Received: by 2002:a2e:131a:: with SMTP id 26-v6mr9301766ljt.107.1551095778761; Mon, 25 Feb 2019 03:56:18 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 25 Feb 2019 03:56:09 -0800 Message-ID: To: Dominick Baier Cc: David Waite , William Denniss , oauth Content-Type: multipart/related; boundary="000000000000e894ca0582b6a070" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 11:56:26 -0000 --000000000000e894ca0582b6a070 Content-Type: multipart/alternative; boundary="000000000000e894c70582b6a06f" --000000000000e894c70582b6a06f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The callbacks do avoid the loopback, which is great, but the usability remains harder than mobile and the embedded case: the auth tab appears among others, the modal windows remain a possibility, etc - the level of sophistication of the target audience of the github app can definitely (hopefully?) navigate those challenges, but for consumer grade apps they can be blockers. When decision makers are presented with concrete support costs from customer calls vs possible security issues, it's often hard to make a case for the latter. [image: image.png] On Mon, Feb 25, 2019 at 3:40 AM Dominick Baier wrote: > A good example of a desktop application using browser authentication is > Github for Desktop. > > They use custom URLs/callbacks for both OSX and Windows. Works very well. > > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 25. February 2019 at 11:48:20, Vittorio Bertocci ( > vittorio=3D40auth0.com@dmarc.ietf.org) wrote: > > Ahh, as John knows this is a big pet peeve for me :) > > Although that's all true on mobile, on desktop things are more > complicated. > > - Using a system browser on the desktop (Linux/Mac/Windows) means that > you don't control the experience (there might be modal dialogs occludi= ng > the browser or any other Z order windows factors; the browser instance > might have already other tabs open; the default browser of any particu= lar > machine can be different; users might need to take steps to get back t= o the > app; etc) > - Use of loopback adapters is banned by many big enterprises on their > machines > - The big security advantages of the approach on mobile, where apps > are all nicely sandboxed, is not as pronounced in an environment where= the > user login session in the machine is the main security boundary (think > keylogger attaching to the main windows events pump, or a debugger - a= ll > stuff not possible on mobile but viable on desktops) > > True, it would be fantastic if desktop OSes would offer system browser > features comparable to what's available on iOS and Android - but today th= at > doesn't appear to be the case. And the inability to leverage existing > sessions when using embedded views on the desktop is a true pain. But > judging from the behavior of the most popular desktop apps in market > (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app fo= r > Mac...) losing the ability to access cookies is less of a nuisance for > users than all of the above. And considering that desktop machines usuall= y > have their own way of identifying devices, that is also not much of a > factor for desktop apps. > > The best practice has been discussed for the last 4 years and still all o= f > the big apps above remain on embedded: it is however telling that the > mobile apps from the same vendors all embraced the system browser approac= h. > Since the native best practices came out, I have been working with deskto= p > developers dealing with this cognitive dissonance of the best practice > saying something that is very hard to put in practice. I understand that = it > is well intentioned and it is easier to give one single advice for both > mobile and desktop, but while the necessary features and experiences are > lacking on the desktop I am not sure how much of a difference it is makin= g > in that use case. > > > > On Mon, Feb 25, 2019 at 12:59 AM David Waite > wrote: > >> >> > On Feb 24, 2019, at 10:43 AM, William Denniss > 40google.com@dmarc.ietf.org> wrote: >> > >> > For 1P sign-in, there are several good reasons to go with >> ASWebAuthenticationSession, like syncing the signed-in session with Safa= ri >> and using it if it already exists. >> >> With enterprise 3P, you=E2=80=99ll have to use some web agent for authen= tication >> pretty much no matter what, and you=E2=80=99ll almost certainly get pres= sure to use >> ASWebAuthenticationSession, and/or potentially lose deals to competitors >> during product evaluations. It is simply what is required for robust >> integration into a corporate infrastructure. >> >> For 1P on iOS, it depends on the complexity of authentication for first >> party. If you are just doing password and maybe SMS-based challenges, th= ere >> is decent enough native app integration for password sharing and SMS >> keyboard for that to keep conversions high, even with having to >> authenticate twice. >> >> However, if you want to authenticate the device (even pseudonymously wit= h >> session cookies) or do other factors, the authentication is simpler with >> ASWebAuthenticationSession. Which means your life will be easier if you >> have more complex authentication requirements anywhere on your roadmap t= o >> just start off using ASWebAuthenticationSession. >> >> It is likely that future authentication technologies like WebAuthn will >> not work with an embedded web view. The ability to arbitrarily inject >> javascript means that apps can phish webauthn responses for domains via >> embedded web views. >> >> -DW >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000e894c70582b6a06f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The callbacks do avoid the loopback, which is great, but t= he usability remains harder than mobile and the embedded case: the auth tab= appears among others, the modal windows remain a possibility, etc - the le= vel of sophistication of the target audience of the github app can definite= ly (hopefully?) navigate those challenges, but for consumer grade apps they= can be blockers. When decision makers are presented with concrete support = costs from customer calls vs possible security issues, it's often hard = to make a case for the latter.

3D"image.png"

On= Mon, Feb 25, 2019 at 3:40 AM Dominick Baier <dbaier@leastprivilege.com> wrote:
A good example of a desktop application usi= ng browser authentication is Github for Desktop.

They use custom URLs/callbacks for both OSX a= nd Windows. Works very well.

=E2=80=94=E2=80=94=E2=80=94
Dominick
=

On 25. February 201= 9 at 11:48:20, Vittorio Bertocci (vittorio=3D40auth0.com@dmarc.ietf.org= ) wrote:

Ahh, as John knows this is a big pet peeve for me :)=C2=A0

Although that's all true on mobile, on desktop things are more complicated.=C2=A0
  • Using a system browser on the desktop (Linux/Mac/Windows) means that you don't control the experience (there might be modal dialogs occluding the browser or any other Z order windows factors; the browser instance might have already other tabs open; the default browser of any particular machine can be different; users might need to take steps to get back to the app; etc)=C2=A0
  • Use of loopback adapters is banned by many big enterprises on their machines
  • The big security advantages of the approach on mobile, where apps are all nicely sandboxed, is not as pronounced in an environment where the user login session in the machine is the main security boundary (think keylogger attaching to the main windows events pump, or a debugger - all stuff not possible on mobile but viable on desktops)
True, it would be fantastic if desktop OSes would offer system browser features comparable to what's available on iOS and Android - but today that doesn't appear to be the case. And the inability to leverage existing sessions when using embedded views on the desktop is a true pain. But judging from the behavior of the most popular desktop apps in market (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for Mac...) losing the ability to access cookies is less of a nuisance for users than all of the above.=C2=A0And considering that desktop machines usually have their own way of identifying devices, that is also not much of a factor for desktop apps.

The best practice has been discussed for the last 4 years and still all of the big apps above remain on embedded: it is however telling that the mobile apps from the same vendors all embraced the system browser approach.
Since the native best practices came out, I have been working with desktop developers dealing with this cognitive dissonance of the best practice saying something that is very hard to put in practice. I understand that it is well intentioned and it is easier to give one single advice for both mobile and desktop, but while the necessary features and experiences are lacking on the desktop I am not sure how much of a difference it is making in that use case.=C2=A0



On Mon, Feb 25, 2019 at 12:59 AM David Waite <david@alkaline-solutions.com> wrote:

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthenticationSession, like syncing the signed-in session with Safari and using it if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentication pretty much no matter what, and you=E2=80=99ll almost certainly get pressure to use ASWebAuthenticationSession, and/or potentially lose deals to competitors during product evaluations. It is simply what is required for robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first party. If you are just doing password and maybe SMS-based challenges, there is decent enough native app integration for password sharing and SMS keyboard for that to keep conversions high, even with having to authenticate twice.

However, if you want to authenticate the device (even pseudonymously with session cookies) or do other factors, the authentication is simpler with ASWebAuthenticationSession. Which means your life will be easier if you have more complex authentication requirements anywhere on your roadmap to just start off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not work with an embedded web view. The ability to arbitrarily inject javascript means that apps can phish webauthn responses for domains via embedded web views.

-DW

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e894c70582b6a06f-- --000000000000e894ca0582b6a070 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jska56lu0 iVBORw0KGgoAAAANSUhEUgAABCUAAAHGCAYAAABD4DEZAAAgAElEQVR4Aey9CXyU1bk//p0lM9kh JGxhByWsYRcFRVGsKApqxVrBVsFfW/xV0faq/f3aev/X2turvb9bl15te10rKAq1QquCLBEFXNjD GtnCkghCCCRkmcks/8/3vHMmkyGTzCQzySR5Dp/h3c55zjnf97xv3ud7nuc5psNHi71gMpkAr7Gr juW/piEgODYNt+BSgmMwIk07FhybhltwKcExGJGmHQuOTcMtuJTgGIxI044Fx6bhFlxKcAxG5KJj uy0BPbtnwkSsJMUMAa/Xi+JTJXA6a2JWRySCTTDBy1vu8YL/qGuZuAXghaF38QzMPCN6WCTYSt72 h4B6DFS3PHw85GXZ7FssODYbQhmP0YFQcBQco4hAdETJ+1FwjA4C0ZEi41FwjA4CDUqxWi3o3q2L EBINohSdiyR9enTtAqvFEh2BzZSiiAhO+JrIR2gti7qWsa9IKh6Sp5CJ4WaiLcXbOgK1pIQi6Dzq wWnrnWrV9guO0YFfcBQco4NAdKTIeBQco4NAdKTIeBQco4NAdKTo8SgTWxfhSUKiR7cusJhrP7cv yiQnooqAxWJWmBN7SYKAINB2EKj7lvSZ4Gkur+10I85aKjhG54YIjlHFUb4XmwmnjMdmAugrLjgK jtFBIDpSZDwKjtFB4CIpiYk29OqRhQSr9aJrciK2CCQkWBX2iXZbbCsS6YKAIBA1BOqSEkosvZ28 PjMicedoOtKCY9OxCywpOAai0fR9TmVp80B5rpuDo7wfm45ebUl5rmuxaM6e4Ngc9GrLCo61WDRj zwR4fP7yzZDS5ovSKiKzSyf07JYJs1hItNr9JPaM45GZkS73odXuglQsCISPQGj6Vs0eePw+cBIC M3xQ6+QUHOvA0eQDwbHJ0NUpKDjWgaPJB4Jjk6GrU1BwrANHkw8ExyZDV6eg4FgHjqYc+ClvI6af EcyvgxAVZrMJaakp6JyeCu5Lig8E0tNSkJqShHPnL6D8QiU8ErshPm6MtEIQCELA5F99I+jCxYde g6CgEQXftcJSXAxRWGcEx7BgajST4NgoRGFlEBzDgqnRTIJjoxCFlUFwDAumRjMJjo1CFFYGwTEs mBrJxBURzCR8fD6EytqskTLxfpkBChm7gFYRdBVISU5EclJivDdb2gegsqoaFZXVqKlxwe3xwOVy Cy6CgCAQBwiYvPxrIUkQEAQEAUFAEBAEBAFBQBAQBAQBQUAQEAQEgRZGoJ6YEi3cAqlOEBAEBAFB QBAQBAQBQUAQEAQEAUFAEBAEOiQCQkp0yNsunRYEBAFBQBAQBAQBQUAQEAQEAUFAEBAEWh8BISVa /x5ICwQBQUAQEAQEAUFAEBAEBAFBQBAQBASBDomAkBId8rZLpwUBQUAQEAQEAUFAEBAEBAFBQBAQ BASB1kdASInWvwfSAkFAEBAEBAFBQBAQBAQBQUAQEAQEAUGgQyIgpESHvO3SaUFAEBAEBAFBQBAQ BAQBQUAQEAQEAUGg9REQUqL174G0QBAQBAQBQUAQEAQEAUFAEBAEBAFBQBDokAhYO2SvpdNhI+Dx eOFyu+DxeODxeuH1eI2t1xu2DMkoCAgCgoAgIAiYTCaYTSaYzMbWbDbDarWqc4KOICAICAKCgCAg CHRcBExer2iXHff2199zEhE1rhrUuEhGCPlQP0pyVhAQBAQBQSAaCJCcSLBakZAgBEU08BQZgoAg IAgIAoJAW0NASIm2dsdi2F6Xy41qp1NZRcSwGhEtCAgCgoAgIAjUi4DFbIbdZoPVaqn3upwUBAQB QUAQEAQEgfaHgJAS7e+eRtwjt9uDKodDyIiIkZMCgoAgIAgIArFAgOREot0Gi0XIiVjgKzIFAUFA EBAEBIF4QkBIiXi6Gy3cFsaJqHI44Xa7W7jmGFRnMgEeD+hsQr9lSYKAICAItCcE6Gmp3mxmM9CB vC5JSihygv2WJAgIAoKAICAICALtEgEhJdrlbW28Uw5nDRxOZ+MZJYcgIAgIAoKAINDKCNClw25L aOVWSPWCgCAgCAgCgoAgEAsEhJSIBapxLrOq2qGCWMZ5M8NvHmcNxToifLwkpyAgCLRtBDroO4/B MJMS7W373knrBQFBQBAQBAQBQeAiBISUuAiS9nuC5r8VVdUSO6L93mLpmSAgCAgC7RoBrtSRkpQo bnrt+i5L5wQBQUAQEAQ6GgJCSnSQO+72eFBZVQ1ZAbaD3HDppiAgCAgC7RQBxg0iMUGCQpIgIAgI AoKAICAItH0E5C9627+HYfWALhtCSIQFlWQSBAQBQUAQiGME+LesstoRxy2UpgkCgoAgIAgIAoJA JAgIKREJWm00b2W1uGy00VsnzRYEBAFBQBCoBwG1epQQE/UgI6cEAUFAEBAEBIG2h4CQEm3vnkXU Yq6y4XK1gyU/I+q1ZBYEBAFBQBBo7wjUuFzg3zhJgoAgIAgIAoKAINC2EbC27eZL6xtCwOPxyrKf DQEk1wQBQUAQEATaNAJc2pqrcpjNpjbZD2eNB16vC1a4YDF5AI8bMPs+zTwuwGyB22sGc5hMVtgS 2t5cktfjMQKThrFKFl1z9OIyjB0STmpKmXDktlSeHSWH8cHRrfji1H58U1mKk5WlMMGE7smd0TM5 A1f0GIKb+o7H6MwBLdUkqaeVEHC73di9ezfKy8sxfvx4JCYmtlJL4qha/UL4/K/AJ88Dx3cBFgvQ fxxw/S+A3BmAxwPEWYyhr776Cv/1X/+FDz74ABUVFbBYLOoXKbJdu3bFvHnzMH/+fPTt21cV5zsv 3PdjpPVFI/+mTZuaJEYCXTYJtrZRiIEtXW6xkmgbd0taKQgIAoJA20Tg6NFjoPrYt5/xwdTSvbBa LEhOalsf79WOGljMXiR4qgB7J5yqAL4pA6ocQEmVgWBmEpBkB3qmA91TADjOo8acBLfHhER7QkvD HNv6vB5DvqntkS5NBWbZ4U347bZ3caTsVFgiBqb3wK/G3YnbB1wRVv54zxSsWPGYblla2eIxg9nq Y/YnuEy89zGS9pGIoCJ77tw5VYyEBImJ7t27RyKmfeXVhMSyx4BPfg+42D2L0UcTCVwTcMcLwNT/ zcEBhElkxhqkzZs3Y926dXj55Zdx9OhRZGRkgOSCzWbzj2GOa45nnfQxn4GEhAQ17jkmzp8/j2HD huEHP/gBbrnlFiWLZUhgkeiIxySkRDzelVZsE102GEtCkiAgCAgCgoAgEEsE3lz8tiIl5s75fiyr aVA2SQmSE/Ge3G4PqqsdSLF7AGsK/rEX2HYC2F7kxaGzJpRVAS7fd6rVBKQnAYO6eDGmlwljewO3 DAPgqkCFw4zERDssljaixJN0cDvhdbv8yoNJzWyaQEsKr7sGZmsCYElUs6BOpxs1bjdMMMMLzgoa d1Z/w/NjnjCZTSYk2qywWMKzqoiH8XGw7BvMz3sBO0uONKk5o7MG4JVrHsKg9B5NKh9PhahYURmj IsYUSELwHgee53G8KmHNxZSK644dO+ByKa3bL47YDBo0CCNHjux4qw1p64f8fwIv3wK4EgBPDcBX Hh93eu6p958H+L87gD6j/O8WP4CttHPXXXeBxMSRI0cwZcoUjBkzBsnJyer+1tTUqHGsxzfvMZMm JTgG7Ha+2y04deoU8vLyUFhYiNzcXDz44IOKnNDkhi7XSt0MWW3USYmDhw7j+PET6N27Fy69ZFDI itvLhRNFxdi+Yyf27N2Ps6WlOHfuPDlZpKenI6NzZwwaOAC5I0cgZ/AlDb4U//b3FfjubTNbHZby iso6DFysG3ThQjn27i3A7t178e2Z08r0rKKiEikpyUhLS0P3bt0wbNhQDB8+BKkpqbFujsgXBAQB QUAQaAEEKisq8H9//W/qg/mpf/s1klM4pd/yie4bqcnJLV9xBDU6nTXwempgT0zGmoPAW1uAz495 Ue4AUu0mJFqpZFPV1gq2Fx6vCdUu4ILDizQ7cEVfE+4eD0y7BHBUV8JkToDNFsdWEx43vI5yeMq/ BRzl8Ho9MNE9hbOEioxwwQQPLAl2mFKz4EnujrIqM058W4bKyipYLCQczOp7Rk+E8hueH/Quj1eR EqnJNnTNSEJaig0J1vgmaVaf2IH7P3kB552VEYyci7N2tqfglWsexHW9Rl18MY7P8L5pEoL7JCEu XLigZoNpIUCFjEQFE5Uyq9WKzp07o1OnTkhNTfVbUrCclhXH3W20aVRQt2/fjuPHjzeYt0uXLrjs ssuQ0krv1wYbF6uLmpT44y1AwYeA2wRkDQLu+iNQXQ689ROgohSwuoBJPwW+/4LP/a31yWmO1erq akVIPPnkkxg7dqzSi/S4JdnGcc4xHJh4rMc183J8vP/++/jZz36mztNS4vXXXwfHA5OWwecknlJT SYmQvTh+okiZ/hcePYaq6mrkjhgeT/2NWltIRrzx5ls4cPBQvTLPnCkBf7y+8uM1yMjojB/NvxdD h+RclH/J0r9h5ao1rU5KMPBX8EC/qLFROlFWXo6VK1dj46bP662zvPwC+Csu/kaRPnzIrrh8Imbc 9B2kpqZFqRUiRhAQBAQBQaA1ENiw8XOlKPAja+PnX+D6ade1RjPAGErOmhrYEuJTQa+udsJm8cKc mIzfrgWWbPOiymVCss2E7mmA22MQECQh9HeqnkFLtHqRYjOhxg18egTYfNyLu8aa8MvrkuGpcYCy ExNtrYJ7Q5Uq0qG6HJ6Sw3CfKoC3sgQmfjwnJMPMWBmOSriqK2FLTIC1cza8VhvOujrh8LcefH34 DM6XliHBZoPdZlX4sC6ST4qyMQEOpxsutwed0+wY2LszBvROQ1bn5Li1miAh8b3Vv4dHu6o0BF4j 1845KnDn6mfwzrTHMK132yAmtLKlSQeSEVTGORuslbH6un3y5ElFZNCNoU+fPoqcoAySFlpmfeXi /Vxpaaly1yAOjaWzZ89i7dq1asadGHSIREsqvgxPHzbMxyweYNZvgWHXG90/vhNY86RBVnyzzzgX J+5flZWVys2CZAR/tJLgrylpwYIF4P0/dOiQIqY0IUFZ2nKIZF68ERNN6WtIUqJLRmd8e/qMknnq 1LfIBzBy+DD1YmhKRfFWhiaUb7+zFGvWfRJR00pLz+Hp/3wWU66chHvmfl8F2KKAN996B2sjlBVR xWFm5vPLwF8tkbZs3YYl7yyDM4L61Ifrps+xectW3HXnHRg/fmyMm3oGa15fil3lQPqI2Zg/NSvG 9Yn4ZiFQtBIP3/kLbMx+CK8smodce6TS8vFM7g+wGMCcRTvwWG6k5ZuZP//3GDVX1Y438x9FS1ff zNbHd/HT6/HKkr0oQza+8+AstE+aPL5vQXDrqBCs/2yD//SGDZ9j2nXXttp3QrWDQS/pi+tvUlzs kCyxWwGn1Y4HlwJ5h7ywWUxISzTICKfLVAez4PaTqKDXg8nkRVqiCcz/+mYvjp414YXZdthNzvgk ZBios/ocPOdOwHP+BLwM4Mj7Y7XD5fHA47igZjZN5q7wmu0470jAoZMXsPdoJY4Xn0NVRSUSbAmw JyQoUkIpoGYTzBYTEixmOGvccLk8uFBRA3uCFRnpNnRKTfR/qMfFzfc1Yv+5E5j/yQtRISR0v9we D+Z98jxW3/wkcjr30qfjcqvJA34DUpE6fPiw+rGxvMZEEk6bsOtjXtM/khMkMAYMGID+/fv7CQkt WwlpA/+xvVQwd+3a5XdPCafZnDVnzAniQHeA9qCENtpvvgxtiUbsCI6TEzuBcXcYxU7tAzwm45rN p/AzT/ALtNFKop+B7hU9e/ZUMSQY5JKEBLc8z/vmcJBMrvbrT5qADmwJxwnzM64ELSROnz6tLCQY Y0JbUdByhq4e7WUshCQlRgwfhq3bd+D8+TKFEYkJst50YagPvEAg432/rKwcf3j+v3Gk8Ki/qbyh Y8eMwqiRI9Cndy9kZWXCZDLjbOlZFBYew8bPv8Teffv9+T/dsAlFxd/g5w//FO8sfQ/rP9vov9aa O25G7m6BtHrNOvzjnx/WqemSQYMwdOhg9ccis0sXpKengViXnCWGhdi7rwCHDh1WZUhk/HXRWyg9 V9pqM2t1Gi8HPgSKsOqVFdhbacGgG36EmYMbAiaSvA3Jqb12ZssK5JUDKHgeKwvmIVe0+lpwOtSe A9vefRXrTwEZ4+7CvZMyOlTv20pnd+zMV5Zwur2l584hf9dujModqU+1+Nbjia/gX1TCXDVueBMT 8dN3SUhAWUfwu9lYrZuKWOMwMY/Xa1JlrBa6Upuw7iCUzD/eYYO7ulrF1ODHatwkTw08laUqQCfo tmFLNFw3YFKxJRhTwpKUDkuXAajJGIyzVRk4euo8Tp85D4vJi07pSeo7jN+c/FjlN6jHywVJTEiw EjeLwoHBJS5U1qCiyqUsJ/yB8OIECEa/ICFR1kyXjfq6Q5mU/dmtv1MrdtSXp7XPadJAW0jk5+fj 22+/rUNGME/gj20O1DW4z+t08SguLlaExlVXXaUCAnLM6zpau6+N1U9ldMuWLYpYaCxvqOvHjh1T OEyYMEG5toTK1+bP042HcYIumQKc2gbUWIGP/h04uR+oKgMKPgZMdsDiAIZO83W3rjtEa2JAQoFE EscmkyYP+Ddh9erVWLVqFQ4ePKiIKRJ1HMe8xqTHPp8ZBr2kOwjzkMigTOZl8Myrr74aM2bMUEE0 Wa6tPAeqk/X8F5KUYOfHjRmN7TvzQesAJlpO8IOjLRMTvMHP/fGlOoTE8GFDcN8P70FWpuGjE4hT r6Rs9MrOxuRJlysS4p2lf0P+rj0qy6HDR/Dzx3+Jqqr4CSjJAJexTmvW5tUhJGhSd+fs2+uNPdKl Swb4Y1wSmvXSDebdpe8ptpvt/Mc/P1IfHdOumxrrZov8cBD4Oh8FdHVNvgRjGiQkAESSN5y6AWSN n4mpaZuUpcT0iz2kwpQi2do8Ame3I18FpO+G3HFCSMTr/fzss4uX/frss42tSkowOCK/X1o76Q9R KiHJyUl4ag2w/jAJCWMij9+e4ZARgf3Q+bWrNWVR5u/XAb+aloiqqir/EoL6ozawfIvv82PcXQNl 5mHmPbED1kSYGD8CFlhsdlhSM2HKHAhvel8kmSxIS6lCn26JSLTbkJSUoFb6Y3wvejxQuXe6PKh2 ulBV7UJFVQ1cFjMsPiKGLjwa9xbvawMVLj6wHnvOHmsgR/Mu7T57FG8d+BRzLr26eYJiUFrfDypb VKR27typZnz1+NRkA6vmahOMHaGXwaQCxllhjmvmo5sDzdj5fDOAIK/feOON/nse7woZiRgGP2S7 m5vKysrwySefYMSIESoQpsazuXLjqrwmWK//ObDlLaDmW8BrBnYvA5TubjMIic45wOT7jKar90z8 9IJuFZpo4Pin1QOJiL/+9a9YuXKlGtMkHGhJUZ+1A8tyvPM6SQ3KIzHHH8fR3r17lczvfve7yM7O Vs+JftbiB4XwWxKSlKAIAjF29Chs27HzImJi5Ijh6gUTflXxkfOtJUtBMkGnGTfegNnfvVUfNrjt ld0TP1v4U/zzw1VY9t77Km88ERJsEAdsLNO+fQV1CAnOiN0z9+6wA22RnHj05w/jzUVvYWf+LtVU WlyQ+Bk6NE61UMcp5G/ajPzD5eg98/u4pmv9CJ8/+gW++PIICuxj8NCsIfVniuuzDmzbUQjSWhlD x6Bhr8VI8kbQ6V7T8ezG6SELlB1ZiVWLVmFR9n1YPl/MKEIC1cYvHN+6H6X8GzQwF2MjduFp451v I83/5uRJHDxkxGLq06e3ajWDY3994CDOnD6DrK6t4yrnqnEBttaPr0AlocpRo5TrT48C7+4AEixG kL9ILYwD8+t9vaXMd3eYMOVS4Ko+NqWwJ8XLcqFkUbSSQHKCE4ZWO0zp2bCmdYM5JQMmezq89nQ1 G9gpzYvcSzPgcaXCamWQQ4uKFcIgEiQl6C7OOBKnSipw6Ph5nCtzKJIi0WYyYk2YuI0jSxEVLt2L 321bFvOn+nfbl+LuS6fEpbUEJwN5X0gk0AQ9kIigAsWA8nTH4JKJwfeP11mG1gG6LMGkfvLNN9/g iy++wBVXXKGIieCyMQc9zArYh/3796ufJmnCLNpgNuKqSZ5x48YpU/8GC7S1i4Z5GNClN/C/lgJ/ /A7grDFW4fDWAAlOIHscMH8JkJhmxJ/QzG0r91XfZ45J3n8mWoiTSHrjjTewfPlydb8Yb4KBXJmf 1zmumXQZHnOfup22miD5wJgVJDdodUOyjnnuv/9+FQg1Xp8D1bFG/muQlGBZdq4+YmInTTRHjrjo BdJIfa16mUEt1+at97fh5pum447bZ/mPw925+aYb8PWBA36LiXDLxTofZwk8/FKJUeID8/qbi/2s NFcimT/vhxHXxkjhLPfHF/+Mr78+oOS9sWgx/u2JXyomMGKBsS5Qth+bdx9HGdLQ0AJcJ7Zux17O 7sa3a2dotCKZnY4kb+gaI75S+O4v8NRSBozwseIRS5AC8Y/AAWw/UAUgCTmjLo3/5nbQFq5fXxtL 4srJk9Qs9pIlfDiBdevX4847vtsqyPBvIP8WMiBiaybVBrjV6hivfQFU1njVChsuroxJBTucxpkA rnSpv81ZRH9z042BC3UkWExqZY7XvjBhSj8LzKiBx2Nt9f7r7pnMDEaofC9gsibB0jkbpsxBsHTq AVNi51rSggZ6SSYkJzUeDC7JbsW3Z6vh9ZaD8cHIdhCXeFwW9KtvD6CookTDEbPtiQslYF0TuzVm 4hizJlwkWFsukISgPz1JCU1IcEtFikEbL730UjVLrBW5QEHUQWiNS8KCVhOcadYyqLBR2WeMiR49 evjP83q8JPabcSBo4RGrRHcWzpzTnSMrq3XI4LD7ptnUsAsonwSg+2DA7SMczW6g/2Rg6kPA6FsB qy2uCInArnFMa4KBFj8fffSRctugS8Zjjz2Gm266yb+iCkkHPXb1s6DHOmXwHJ8H/Vu/fj2ee+45 7Nu3D8uWLcPs2bP9sgLbEK/77Edgf9nHRkkJdoYFSUzQlePsWc5fQa1I0daICbpe6ESXjaYu3cng mNqFQ8uLh21NjK0kVn28BlWVxjJWaWmp+OEP54bs9kMP/4v/2vPP/qd/P3Dn3h/Owe/+4z+VT3Jl RSU+Xr0Wt9x8U2AW2W9BBL7deTDs2elI8rZgF6Sq9oDAvr04pMx1hmCCMQHfHnrVrvpAC8EtW7eq PtHUmgGL6e//3nvvg8tefvXVFtw685ZWm7nj30J7Ky+TWeP2qACUKwsS8eUxY/UMrrBhNZuQbjes jxtTnahvVzButZcxJAwig/q90wUkJRiGB5TJlTlYx8oCE6YPcMLpscHWyqQMB4eJCghnCb1uZeZg Ts2EpVsOTBl9YLImGqYPTXgy7HYL7Am0pDDD5HTDywmZOHXd+OfRzU3oYdOKsK54ISW0UkX/d5IH R48eVUqVPq8JiaFDh6rzPNYKSnDveY16SK9evZS1BJU7nSiP1gIkLlgXTeB5LpQsXa4ltuzzjh07 Ym7BzL5w5vzTTz/FkCFDQEzjof/1YhwpYcT3B60H9q8FTFWAKQHw1AB3Pg/08wXKbwrRUW/joneS +OuxrqWSoCooKFCWDQxUeuutt2LUqKavnEMCipYSBw4cqBOjhOSGtrjQdcfTltiwfbT+4GQ3E49V zI1wG8oXwhgSEzt2XkxM5I5Ua0WHK6s18nFZz12796qq+dKaf98PmvTQfrRqtQps2Rp9aKxOvrhj lfih+cknn/rF3zLjJqSmpPqPm7LD8pTz1pJ3VXHKv+E714ftCtKUOqVMKASKsP0wI0yGMzsdSd5Q 9cl5QaA+BBzYtqtYXegxYgwujvJTXxk5Fy0EGP+gvKwcXOqZP85KlpVdQHlZGcou8JyxzwDY+u/N xMvG+1ehmnjZBHy2YZMiJh7/P79Geloa0tLTVNDj9NQ0pKanoZM+x21aGjp37qRM96PVB8rRbYum zIhl0d/Alo4vjwIXHEDXVKCs2oQZQ4FnZwGVTh/REMRMKKsCVuYFzlYZbh+vbzGsK0hIkKSY1B+4 bwLwwkYgv9iEzslAaRVUXdNz0uGliTPixI2BOHi8asUNc3IGTKndYEowrCG8rhpU1XhQVe1GeZUL zhqP794FfdCbuEiHF7YEM6wWM0rLHSivcKrvTgb89C0S6rtFsbMWjXgMANhy+mBTijWpTEvWFU4D qXzwRxKBK0ZoJY1bumwMHjxYnQsmEViGSZ/XxzxH8uHEiRNKoeFzzmu0FKBrB60peKzrCaeNscpD ooTm9S2Z2G/OmpeUlIBBQOMuVZcDBXnAqJmRN61gnc9kzAV06g30GKJW7lHuYZESHZHX3qQSgeOW AqiEc8wyPkRmZmadv3vh/M2iPMrgLykpSblzkJjgPhV6HYuF1+ORlOD41NYRJNGY9GokPOYvLEsJ fTfMJlO9xASJChIWvB6viSuJ6DRh3Fh0yYg8eFo8ExLsWyxfxHv27IW2xOjaNQsTJ07QcDZrSzmr 167D6dNnlHzWM2ZM05nDcBpz/tAX+PjzfJwo9QUFtSSh68AJuGn68DpK0Ld5i7B4NxV1ncqxa8lL MCJh0E1jKh65HVj6Qh5O6CzcFuXhDy/k+c6kYeRdczFNxaHY78/be9oCzB4KnP16PdZ+VRDUllxc PWks+qQHCg3Yd53Bns82YvPXp1Dq1H2wITmjOyZMuxlj/TEvKrFn+dv4+JgTGaNux71TugcICdrV QSszwpidDifvmS1Y+tJiLF23EQUlTsCWiZzJc7DwsTmY3Ksg9LKdZ1ZgwbVPYBPmBCypWbvMp7/V i3+AUVx5U6VJeHLdi5gVwmrxzObFeObZV5G3qwRO2JCZMxnT5z2EhTcOYNi1uslff0Myz2D5gml4 YiMw6Tdr8FKoipXkM8hf/hpefWUF8go5lmzIHDkV8xb8BDOvHIBQt7huo4KPynFkwwq89OoKbMkv AOEF0tB//CRMnfsTLLi2nn45ipG/cjFeXbGRx/EAACAASURBVLQRWwoKoUa1uidTMXv2HNwQqi3B S5yWFWDlS3/CSyvywO6k9Z+KmQvqYnkmfyleenYxVm0x6jHy/AQ/uTGn8f5qtyBLf4wdfdHdCQai nmMHvtn3BTZsPYhvSp0qPgozWWyd0XVgDq6c2MBzpaSV4eCmT/HFvmKcrtTPVhJ6XDoZN1x/KVz6 nZA2DHPuvRrd6mlBWz616fMv8ff3V0TUhSlXXenPf+WVkxQpwROcreFqHPw1lG67dSamXjOloSwR X4vl38JwG2PxOnG6KgHbi4HkBGPpT34jdfINa5sF4CoaIZMX6JkGLJwCnK8GXv4K6JQIzLsMWHiV ETCTpAQTrQRoOcG6TlcBGWa+FBJCim6pC7SeAZcFpZluQhKQkKTi0+luO2o8KD5dhePflOHb0ipU VrmVO4bJbILbrXw+jMkj36clLS+U0qnGFwkMr4o7oX1a/IROS3UwjHq+4eojLZRasq7GuhT4DJaW GhhowoBbulxQcdLEQuC1QNmBcnReLrV4/PhxNRZYjudJTJCUYH7+eL41U31BC1uqPa1Zd7191JYM 3x4CPvhtZKQErSRcNUDBp0AN/dVMwKBJgD3ZsMKqt8L4OanHI1tE0oBuG1zGk8SBTno/nDEbOLb1 2KdM/r3VFkTxSkiwXWw/A3QyLgZdrkimMBEDkmkRkRIsqIkJBimk9QETXTp2tfIyYKohDfy3e49h JcEsubmRr3Af74QE+xXLeBL5u3f70R09alSjL/xQLht+Ib4dPlSUt3rNWnWG9cSOlHDjm7xFWFKH aODXTRVOH/gUb5w8g7vuvRo9gxsZk+NawkCJ54uXyx+ptnyJZQcKMGb293FNcBCLkxvw+tJdys1C l7O4+SHnROWZ4zh0BrWkxNl8bD5mmEaV7tyMgik3o/5QorVBKxufnW48b9FHj+B7j+cZii8bmdYf /VGIgrzn8UDeCsxZ9GhMEL1YqAP5T38P9ywuBGxpSLMZgYZKCvKw+PE8bMz/K959PPdiYuJiQU07 48jHs3Pvx2sFvAdp6N8/DYWF5SjZtQq/f2AV/jT1P/DOc9MjC0FStBK/fvgJrFAy2SwbMvunobyw BIVbVuE1+2TMDSIlyvJfxQPznscuYygYBFG2EwWFJSjIW4an8pbhmZEP4c1X52FIAzyAo2glHr7z F8grtyGNYMKJ8sJALHNw5JX7cc9zuwzyJzMNKCkPytMw3jrAZfKluSHGagO3ouwAVixdg0MGAa8y WmwWuJ1uuJ3ncHL/l1i2Px+DbrgTMwfX47desR/vLcrDUY2Tz6TQ7a7Cyf1r8EZRMa7r10D97eAS yYHMzC547fU31UdOYJc4o0G3PUYK5zYtNQ3du3cDSWqdevbogZm3zFAkc/kFWlpcUKaqtKzQH146 Lz9Q7rv3HrWalz4XrS0/fFo7Wc1AcSlwuASwWzl7a7g9MxaE3m+wmb4lQ+mFMbYXMDobmH8ZMGuE 0bPyan6P6XgTJtitRl3F54Guma3de11/wGoYlgR4YILZ7VKuPvzb76hxqaCVR4rK8e3ZSkVE0BrC ZjNM8FVgTE64MHiGsocwtpROdxaDtlCXVIUaV117PGxPtSAp0ZJ1NYYt769eupCxILQyxS2VM87w 6nOUFbivZVOGPk9FhjOpnGmlIqOv6bKMqcBrrJNKWmun4cOHqyUbt27d6jdRj3Wb+E6l6wYtUOIq qSi1FuDYNqBoC1BaDGRkGy/ChsgjPtC8/s1e4Oxhw3UDNcCQ63zda/33fCQ4c1zqH90WSCQwcdxy nIdDJvDvsE4k4ViGcvj3lWOfKe5IKd+3FNtGa0wGte3du7fqN59r9p3PNN2zrKvX6hld3c2mbU+f KVGrWgwaOKBpAmJcShMorKZ/v8i/LG+84XrwF8+JNzZW6dtT3/pFDx0a3RfesKE5flIisB5/hVHa cRxdjb+Xu9Dvmttx08juSKRcVxn2rHoPHx+uAsr3Yu2WMZg73pi/7jZ1Lh7hSqWn1+OVJXtVoMta q4faRs1+0FhpY897L+HjIm1B0fDqGxVbl+PjUkvdtgA4f2g9/rFmL047z2H78o/Q+8c34hJ/VUVY 9YFBSNi7T8Rts8aip1YiHaUo3LURB/UUFMt0ycWEvnt8lhITQit5kcxON5LXkf97PKAICRtGznsR Ty8Yj166jWUFWP7M43hi3iOofa36O9fATi4ey9+BxwDkPz0a99BCYs5fsfPxhlffOPLSI5hflIsn 330Ts4akGfIdR7DyN4/g8RWFKFz8BJbe+T7mxuSVVYxFv74febY5ePmjn2CCH4Ry7F/+ezz+6xUo zPsFHnhlAJbPr58qugiQohVYMOsJbKLhycj78OIzgXIBR9EWLF50pk4x3o975i5GIWzImfkrPPnY TAzxm2c4UJS/DL9f8Hvk7Xoe9zychfdfmhmCJMnHc48tRdrCd/DZndrioRz7330c9zy1CYWLf4Hn sqYi77kCjP/VO3g6IE/+Kw9g/nO7ULj491gx903MDhkIVge47Ixh40JmqtM//0HFfix9Ow8nSCjY MjFy2nRcMyjdz7pXn9yPtWvy8HVpFQ6teg9r0udiWh3C7xTWLPUREheVd+CbXaux4pO9WFvLzfqr bm87XPL7oZ8uwJ/+8nKd5a6vnHwFbp11S6PdDV7emX+Xlq/4J9YFBJlOSkrET350PwYM6N+ovKZk iCVBH3Z7PC5UOgwrhy5JXrg9NGU3vrEDt6Hk8c85SQf++Jf93gkGIcE4EzynlHLfn3wvj+HF2SqT qlNZJ4QS3ILn2Tz1XcJJa9VW7phg8q2QwW/yymo3LlS5wNgY6Wk29MxKQUZ6osKKGPBemkxeRUko PCxmXKh0ouRcFUrOO5Rbh9fMPPRLrg2c1oLdbLCqJKsdVa4AprPB3M27aLe0vjKue8D7TmWJClIw IcnVBqiIBSaSDIFJf89yy2tcYYA/rXDRZF2bgPM6lR3WR6sJXSZQXmvsczY4IyNDBbo8c6bu3+Zo t4eucJdddplaySHaspsvz3dvD3wKJHmBw5uAcXcYlg6+1SbqrUOTGXT5sHqAGjPgtgKX+lxTuBxP HCc9hnUTOT75Y+L4Dx7zPN/Y2OX4pgySG1xilko9yQjKCn6mdL3xsGXb+Lx26dIFtHRiYswV/phI sJBMi9odJZDHjh1XwuPxv5KAyLcZnTvFYxOb3abgB6DZAgMEcKZLJ/pCNZYY6FL/GsvbJbPWczyw nsbKRXrdUe5A12l34nZNSFCANR3DZ8zCeJ83z+nDhWj+CtKNt6y01IHBM+fWbQuAToOuxtzZY6Ca 4yzEhk21uOP0QZxQs8BpGDw1gJBgdfYM9B9/M6bV4YuSMXzWfDzy4IIGXTcimZ1uOG8BFv+KCjDQ f87LeOXhAEKCbUzPwayn3sHLs7PQEp9omzYDv3rpyVpCQuE0ANOfehoLs3lQiBWba5cH5pnopTys KlqIdxcvDCAkKD0NQ2Y9iTefvUERM4XPvYp1Abc4dP3lWPfcUwYhMflJvH+RXMDeazzmPT4dtfPW de/Hm08FEhKsyY5euXPw7LtPYhKtSDY+hVc3O0I0YRdKcl/Es36ywdeXO5/Gb0jcoRiLn1sM25yX L8qTO/9JLFS8yy4s3Rga7+od+UaAy+7DMaH2lRCiPXVPH/xko4+QyMZ35t6JaQGEBHMm9hiCGXNv x0jFTZVj16f5dZ7zs5vWYZfyaUnDyFnB5e3oOfJm/Hj2sMbdT+o2q80ekSz42cMPoVOn2r+VJBUW vbXEUDLD7BlXRlj89jt1CAnKpOxYERJsWiz/FobZdbWqxNlKwMUYj5zxJbngs5IIRwZ1NObnltYV 6Ym1q3aoa1Tvfd/61PdZB+tinf5lOMOpKIZ5SCYoNoId0SlAkeBZjhHeL7vNgu6ZyRh2SRdcNrI7 rhjdExNGdFP7Y4Z0w4hLM5Gb0xW5g7sip38GunRKUiQESQuWN+65rz5dVxxs+6TUvpFj3ZzuSZ1j XUXY8tWY9933YFJC+77r55R5AxPP63N6y5gUep95A2eMmZ8zz1TYmALzBcptjX2SJ1OmTFEBDWOl NPbt2xfXXnttnBISSgMHSMwd2gTlU7lvdXi3Qr8rGORS3VoX0HWwsRKHcaPDk9MKuTgm+ePY51Yn PTa5DTwfeF2X1df1MfME7/McZWm5Wk48bTnuNRlD8oGECpfz1YTEwIEDwTFMq4+okRIEpG/fPvGE Q522mPTgVje1ziU5CAOBCxUV/lypKSn+/WjsBMoLrCcasuvIyBiO64bWY7aNDAzv65tJLy+tdY2o UzjKB93H4rp+IbynulyOKwYaJg+lJwJIErsdxlkHHAEm6s1rWSSz043k3b8RS8lI2O7Arx4OZaZv x4S592Fk8xodVunsBQsxq94J9xyMn27YahQcidVSbTbc8fAdCGWEkX7tPCxQxMgqbMwPRQQEdPPI SvxpJamcqfjN06GsGQLyczd/BV5q9H7QsmcmFqrGOLFs6SbUz5HkYN6d4+txdUnDyGvH+yqehHnz 67vvA5A7WeMdGKMlsL2l2Lyb1lgWDBqda1gxBV5ucH8/th82aK4eE6djeMjXU3dMm9TfeIZO7cFm f0fLsOewEfcgecjUIAuKgIp7XI4xDYRlCcjZLnbpmvHozx9Gzx61neaqGn95+TV/fKGGOsrgyC+/ +rpaiUPnoyzKpOwOmerqXop0aAiHIF2toaxxe83fZZMFJou1lknxtdi4bny0JySY0TnVjrQUG7js Z3qqHZ1S7cjsnITMzsnKgqJTqg2d0xKRZE9QK5kw0CWXf+V3v/HBHl9QDOpUxyQrpo3rm+YPKBXT esIRrhWqcPIG5tHltPJF3YLLadLSgEqLvh5YRu/ra3qrz7f2ln1g2+nzr4mTaLWJs8+Mp6HjCURL btTkaIW8aLfhglHtBQrWA26XsapGQxXxBVh5Hjj8BeA2GfEkaCVhtsR9PAnebyrfJOA0GaWJA70N 1XWOX+bR+RrapwxeDxzzgfuh6mip82wL+09LJibiQYKC4zUnJwdXXHGFWhaY5+mCZb3+OjXNFVH7 yEwHrsLBwt26dkW8um6wfYzwfcrngnC2tBS9klomckBEwDYzM+N9xMpslcQBo7EzkTjI6Bw9Rj6Q iAgkKJoJx0XFk3sNqBPIMjBDl64kJcqBynPgatKxHh09Buc0qHjl9O2ODw8XA6VncBqAovvSczAo Yzu2lDrx9YpFcFwxBdeN7otOIbiNwP6F2vfPTmcMwPBGZqcby1tUsAlq3YRZU5GrXTbqq7hXDuh4 4Q8YWl+eKJybmhvaLSJ7ABXpTUBhMWhUGf25rJm4tkEQcjCSr97FwK5iohaKvjCAKMpfhQLuTp+J SX73i4ZBOrJ/i2GR0tj9ADBkgq8x6/JRiKnq/tSVPh79QzSx1wDivAXIHo+cEED68XaWg3+aLhoe J7ZjL2OhWfogp461T91W1Ht0olg9I0A35Ay9SHLdIoMHoOeqQpzAOZw+SesdXj6OkyoOmw39h9bL Yvlk2NGb74lToYiVulW1h6P09DQ88vCD+PP/vIpDhw6rLjEY8X//95/xkx/PVx8Y9fWTH8p/+Z/X cPhIrWXMoEED8eP/NS9kmfrkNPVcXATd9rjRJRkqmKX6yPSaQMMBfmfT8oEpXNKBbguMIUGXDWV5 QTkBEyzGvhdWi0nVCY8vSGtTAYxaOR8lwUkhmuurDgfMGqrYEEZwCIeTgVGrcay4HC5aT3iM4KDJ SQlITkxAcpLF/3FPEoJ5qqpdqKiqQaLHoOv1R3zUmh8FQTP7T8R7hz+PgqTGRVyT3RJ0f+PtYA6O ea0caZcLXZIm50z6ful8+pwuS2WGKwDt37/fn1fLoGWETpRDywnmpyl7oDydp7W2VMa++OIL/0oc 7DtXX6DC2pxExY5LTJLkIGGzfPlyXH311UrBa47cqJfVLhhffwJY3ECNFThzEDi5H+g1otYcLLhi Wr3wnVG4Gag+A5htgNdZG09Ckx3B5eLkmPeF45LkRH3jvKExqvM3tSvNLd/UekOVY1+JA8csLUe4 z7gSfC/weeX45e/UqVORW0rUR0hkZWVixIhhodoTF+e7BQTjOnY8ft1MmgMWI1bHKqV3qtWEGCE1 mulsCWkAIwXWo89Fa2v12RlES15z5Fh9EWdDytBEg7M8YOY6A1fdNgPDlG9HOY5+/gFefekveOW9 9dhzMozZ9osq07PTQOMBLhvPW7J/i6ohOzvrYqXzorpb4EQj+mlsW2BHWiP168sFRxpXcv3Y5mSH 7UJQfkTRGMjJyW78fmTnYBIBCfjQC8ZHtzf4vP94QFbj5E5xSW0AVH9BoGDnQdD4p0kBLssNogO2 DHRttJFZyPAZRflcO4HTZ3zPWDKSa19zAa3r2LucwfjpAz/G6NG1MVxINhw/wQA69acTRcV1CAmW pQzKaokUy7+FYbffbEGy3Vgxw01CgoErPcaSnvxTHRzw0pjpN77Rg/cTE4A3twIr9hgkB2UxtoQm NUh2sA6uzsE648V9Q2HFRnLWTx0ERPlUVt0mtcynzWqBx+3ByTOV2LH/NFZvOoaVGwuR99VxbN1z CsdOloGkhU7OGjecTjeqHS7183pNsNusSLRbQMuJeErT+4xFGlceaYF0fe/RLVBL+FVQOaJyFkxK cEY0lMWAPk+CgUp3QUGBcs3gMRNlUskJtAzgMQPlBdcTfktjk5NLl7733nt+QoK1sK3sl46H0ZSa SXSQrNFYUQbPffzxx9i8eXOd802RH9Uy2kp9/zrePYDWUjScPORbOoikRb3JR17SdcOq1gTmF4Kx 8gbzNxSLol55LX+SFj6M+6DHJYkoKub8BZIVwS1riFTgNX1dbzmm4jWxjRyn2t2qrKxMtV+7cHz+ +efYs2ePIiTYh4jcNyg42EKChMSokSPiejlQdnTkiNoVN3bsjN4c7ZKlf8O99y/A2+8sa/UxYdYP fwxa0qN7rQnvvn2GshOtavbu2+8X1WHNev0IBO1YbHUVypS+uGHu/8K8mRMxOIsfOm6UFe3Fx0tf xYvv5SsrjyAJoQ/9s9NhLL8YQd7sLJ/WF7pmuRKAQHZWo5q0P7ex6oX/sH3sOPKx7TAVjiYEuIwq AskI4F6jKrmtC+MH1Lx7fwBtycYPjX59+4bsFoNJ6w8mlmFZymipFMu/heH2weUxIbsTMDATcLi8 MDNYoxkoOA2cqQBs1tpJQp/erkiGwH3q1zzm8qFHSoFffAD8bq1BbKTYa4kNxm5gHayLdbLu+Ei1 7fC6a9QKU2aaXrNT9PRLsCCrSzL6ZKejR9cUpCQnwOHy4Fy5A6Vl1SivcKLKUQOXi8HdAmNHALSg yOyciB5ZyejVPRW9uqWiU5odCVz2JI5SoiUBD41sPEBsc5s8ruslGNxJ+QQ2V1TUymtFhHFk+D6g 8sQtrQU4M8pEvYLn9TVNPvD6jh07lPKtlTqdh+W5z6TPMaBkoPKjLrbifyQHVq1aFZJ8oKVHMLHQ WHPZVxIagYRMcJn8/HysXh1mzIbgwrE45rNOF4wjXxpLepKEMLuBzUt8tdW+I+pUz/cEE4Ncuhj1 1w30GQVkNGTNWEdCqx5wuUsSTxs2bMA777yjSCMGaqUyzr+FJCb0GA5uaKjzzMdr+jq3fJ7039pg OfFyzOdSJy7ly9V4mLg0KmNJ9OnTRwW5ZKDWsN/eFLptx061/KcW7ickgqLo6uvxtB0TMMuzddsO nI5CJFy+UNauW6+6uWq1saRla/Y5lgNzxMhaSxgSU/qhaG5/KWf7zny/mJEja8kj/8kOuHP2tG/2 PDmtHpcTKzr1G4sZ378Xj/zodnxnSKYiLhxFG7Hkg1pz6cZgO77vWNiz02HltRtxA7bsbyTKtMM3 s91YA9v19TMoZrwHBgXNbjxwrC3L+NiMJAZGRGWKC+jMAmRnRrgyitGH5vxfve8A6EmBJgS4VPXa bIYNlLM8jHgwZ1CqHi0LfMM1YMalHN/SV6qB5HA1xSKpAYFt6BI/JLSrXXbPHrDZas2Pqx0O8KcT r+lYFCxTcaE2JpHOE8ttLP8Whttuj8mGrknAmGygqsaY4U1OMJbt/D8fAjuLAYebhIXxoyFA8K/a ZxxQUmG4bvD7/uWvgAXLgA1HDBcOtofuDKyDdbFO1h0XiQ02W+D1uOF1VsGknp/aWT0Gt+zTMw0j c7Iwdnh3jB3aDWOGdsXYYd0wflh3jBvRDSMHZ6F3j1QkJVr9H+CMOdGnZypGDM7CuOHdMXpIFoYM 7IxMFfwyhJLTioAszL0FA9NjG1viZ6NmtWIP66+ayheVbxIGgYnEA4Pc8fuPeXjMH5VtkhG7du3C 7t27lWk3CQnm44/PNXURBslj4jkmnmdEf5qCtyT5qSoP8Z9uW4jL6jQVU84ca3/7hvLS7J06B/vY ZpJWRo9uMVww+JfaUwPc8Dtg3GzAyXWN61FD9cz/2eNAUT5A9yxaSwy+xuh63Linhb4T9957r1qe 9cCBA3jsscfwm9/8Ro1bLqlN9x3e+0BlPbSk0Ffi4e9c6NbVXmE72V8GfWU6ePCgih+Rnp6u3Dj6 9esHkjgkMbWReG3pevY0IVFaagQDYxa6Q9D6QLOa9RSLq1Nds9jeYdi1e6/yaXntjUV49GcLm8Uw LXrrXf8LYsTwWqW9tTrO5bC4hG8s0ohhw5FA/x+XC1xe9Ysvv8IVl09sdlWUc+a0ocRSPuvpCOk0 TZ9D+q+XYs8xg5SwNxAHQ+Fk747h19+Jnilv442t5+A4vAcFGBB6+U8/uI0ErfTn4054ebNzfHEa 8rZg/+O5CLUoqiM/DyvqyI+jA1saDDuPEjh5C+qLkeAoQL7P8jB0y7eg4AiQGyIOA8q2YKWSkYNr h9RXSV3JA3LoXLEMWLoSmx8ejwlhGFcMyJ0EG5bBGUaZ/ZuNpaFtk3MbiW5Rt13NP9JuQU0JcOmr vXcvdEUhTqIYe3Y4kDu6AXC+PgLjczYTvXv7ynfpjgzsQhnKceJAKdC17gd0bR+LsPdYrR9z7fmO sXcoID5Ev/61S3ky1sQbby5WSzbOnft9XHrJIAUIPzSKv1F0E74+eBBjRo9qMaDU38IWqy1ERZzp c5ZhYr90vLPTcLfgShR0L+AiNNuKDAuIEKXVaX6b01qCZAXJCxoBpNiAr44Du04ZlhbJNi9cbhNS 7cBErnbuLAPMqQ2JbeFrjBlB/xIHvI4yoLocSEwDzFalQKYlm5CSaEVGuh01NW6/mweL0OohJYkz i3UVF7pp9AhYOpTHqUlxQsTUg67NbMXL1/wUN3/4G1TGgNjMzeyPGX11wOF6GtAKp6iIUJGm/kBl hEqHJhOoXJN8INHZu3dvRS4wH2eWOZvMsppcCCQk2A36nVPBYaL+wXK9evVCVlaWssBgOV22Fbrt r5KzvlxpgDPlgfEv/BkCdkjGECsqq/UpmrQM4a+xxLKjR4/GmDFjGsvaQtd9BOTX6w1SwekBUrsB Nzzut5aqtyEkM2hZd3ADgCojngSD6Qy51pc9/ojH4H7cd9994KoSdFXatm0bvvzyS1x55ZXKlYNu jCSXOHaZeN8CSaz6xoCWz2v6OstQBrf6nM4Xj1s+t+w7n/GdO3cqKwk95nmN74W6b/p6esEO00Ii mJDgWuZthZDQ3Zr93dv0LvbuK8Cy95b7jyPd+WjVany52fChZ9nZ3701UhFRz2+NoXksZ76uuWaK v83/+OdHuFBxwX/clB3OnlGOTpQfOPumz7fHrWP/F9gWYvKwYt+n2KUC7yVhUEjioi4qXfp297l5 uOGqe6neI3/QyjBmp8PNmzV5JozVIf+E55arkJf11H0EK55d1iJLgtZTeeOn0vtjgoqPWYBX19Xv plS0cjHpgUZSAZ5ZtFEFdbw4owP5L/0JigYYeQcmhSIuAgraJ8zEHBpLOJfhqWfzQ8gNKMBgkhNm Gyt8NFamaAWee4n3qz8WzK5vhY26cqN6pN2Cki/BmEgDXOqG2HMx1rdazckvV2JPiOcKOIU1mwrV imT2gWMx1s9dXIrherWbXZ+GLF+x4wvsjdqqN7rxbWdbeMRYT5wt7t+vLyqrqvD2kqV47oUXce7c eZSeO4cX/viSOscP6H79a907Cgtry7ZEj2P5tzDc9lvNJji8NkzPASb2NaHCSRcOI7aE1QJU1wDn qxr+lVUDpVWGpQXr1QEy6fpR4zKIDpIclM06WBfrZN1xkdhfixUmEjRuJzyVpfCcPwFPRQm8NVX+ CPq09EhPTkBGmh2d1S9RrbTB1TeCCQn2y2I2IzUpAV3S7eiSnhjXhIS+D2OzBuGv1z4CqzZL1xea uU0wW/HHq37cTCnRL66VJ8Z6oFJOkpJkAS0DSEhQATly5Ai2b9+uyAr63pOU0ObtgS3SCheXBWW5 wMRro0aNUkQF69L1BuZprf0BAwbgtttuQ/cA9+dQbaGSyr6RnNCJ+hcVuHAICc7Az5gxA2PHjo0j BdX3HiraZSzpafYCvX2xibj6RmNp3xqDvKDrlz0T6Ocj3uqzrmhMVgtf53i/+eabsWDBAtx0001q nxZDvM+8x7QK0OQZj6mUa5KBx7z3mnAI3Gc+nZdjnZZE1MUDSY0W7mpE1bEv2mLi2LFjKojtvn37 8PXXX6v3QIOkBDseipDQL4mIWtPKmfv26Y3rrvWZ/wD44KNVTSImVq/JwztL3/P35popV6JfHCyH ynsSS6Jo2nXXIjnFWFKTL8o33ljkxyB45/ln/xP6F3xNH7/6+l/VC5fHScnJoPy4TF27+4ILluPo jqKQSn9XHUHvZAHy/csN1t8ji6UE6xe9izWHygLkOfDNluV4Y02xsUJB38m4Ws/mUszZfKxYuQ2F Z2vNpJV0xyls3nTEUFS7D4AxT8krldiz/BX84YWX8PqnpwIaEsnsdAR506di3jzOoDqx6dcP4NfL CwKCdAKOoi14ds738Ez6JCOoYkCLC6Zp/AAAIABJREFUwt3NHqLCMQJ5qwKWdAy3dDj5BmDSbCOC efFzj+M3G4x7YZQsx/7lT+CB3xSjf6Ouu9nI2vi/ceevVmB/4FhwFGPj0z/A/MX03eiP+x4PWt7T kY9nZ1+GUZMfwcrAOIL2XCx8Zg6IbuHi+3EP5Z6pOw7KjmzEq0+vVKuJGO3NwZzgMoFtgQNF+Yvx 8J1PYJMT6D/nScwJZd4SDnRNyKMDXGYMHWOsMNMEGSySc80U9OZEqbMYH1/0XAHVJ/fjg0XvYRe/ Z23ZuPqaukxQzmXDjGec5Zf8E/mBgWNdZTiY9y7e+Owc0tNCzcaGetbYulP4ZNFL+MMLr+C9fUGs RsV+vPdnXnsbnxhGBU1EIPbFDh/x+RsxqFq1A//+u2fw+RdfXlQxz/32359RefTFQwFl9blYbamw xsP3CRVtDwzXhfsuB5ITTKhxc0bL6Dkn/0lONPZLsNS6brCstmzmdzl/lEnZrINuEqyTdcdH4iem ry1eD7wVJfCc2g/3yb3wlh4zSIoaJ7y+GUO2O/DXUB+Yj4SF7itxifcP82m9R2HZdx5HVlL0Iur+ y+hbkdul1nKpIcxa8pr+HqUeQUWMiggj7pN44Hcqf1SoaCXAgJBUxOpTrnhPmefw4cN+QoLnKJ+y hwwZoiwSSHzwmDLi4fnXWJMsoFJK64XG2kWFTZMQ7E8wSaFlBm+J66233hoW+RFcNqbH+mVXdd5g VPleSvUtW9sQscAJVlcNcOAzIw6F1QsMuAxI7lz7Aoxpw6MjvEuXLrjnnnvw5ptvYuHChWqscpzT eoIEWiApwTHNH8dwYz/KYF4mytByotPq2Eth/2ghwR9xIEHD9wNjTIR032Chrdt34Pz52q9YumzQ QqKxByv2XWp6DXd/7w5w1ubQYcP3/p8frsSRwkLc98N7kJXZ8JqIfLG+u+zvWL3WMHVmKzhjNOf7 dza9QVEuabVa4KSJVAxSUlIifjDnbvz5f15RD0TB1wfxyqtv4J65d0dk4cD1699c9BYOHDykWsnx dO89c0D58ZmGYMzAjThx2Imy/Svwwn4L7BY3HD2m4pHba7W4bqMuQcbu7Sh1F2PtGy9hrcUGi9uO YXfNxbSg5cN7XjYFlq152PXhYrU0Jt/B/tUAOMudNQa3zbq07rKh7lKcPrAXfz/gUwSUfKea+VW4 2frgOzNya8uczcdmn7l56c7NKJhys+HWEcnsdCR5YUfuwy/i6SPfw+N5hVjx6+9hxa8BW2Z/pJUX osQJ2HLuwyvPTsXKCZuwCdnICqXjhRgIWVNn4wbbJqwqXoz7r1yMtP45sBVnYuHKFzGrcS+IEFLr nu4161EsXHo/nisoxLIHbsIy2JDZPw3lhSVwoj9mPvskxi/9AZ4IZQyixE3Fr56x4bl5T+B7K54A 0vqjPwpR6J/koZwX8XDQsqFn1r2G1wroIpCHp1bmY/r82hUP7LmP4sVny/HAwytQsMInt07bAEx+ EjMDuqPLPPJYQBlbJnKynSjwN8aGnDl/wIuP59YNqhogJya7/gCX3ZA7LpTLRJg1pwzB7FnnsGj5 dpx2ltQ+VzYL3AFR+xUhMXsWhqcEye16Je6adg5vrDkOR+VxrF36KhglKPC5zBh1O25wr8aS3U7A ag/C6pjftaP08H58O6U7uukqTu/HIWX55MTRrfk4O/Ty2jgxxwpwVHmEnMPeHcdwzfRa6wJdPB62 /Nt3ImC1jb/9/X1/s/j+nuqzosv75FP1t+F8WRn+/n6tk9aJ4yeUYsJZ0Fgn/g2Mh8SPxkSbVc1y TumXhDtHA3/dYlLLevJbnXq4/maPpL2amOA3Pb9La9wmfH88MKUfUFXlVOaxrDs+vtO84D+yJ1wh A84KuM8dh8ntBGqqYcn0wpyQCCRE+IegHsAMLOOFjKmngb5TXLbzs1n/gQWfvohPineHzhjGlRv7 jsOjo24PI2frZOEYpMJEpYPEApVn+pMzngQJCSrhTFSyGACP+amcMD8TFXOW0wqYOulTxFiGcSQm TpyoYjJoC4v4GPe6pcaWRAktGOjCsn79ekXM1M1R9ygcywiWILYTJkzA8OFx6vbMFxQfzOROUH5o NPUqPWGcqw0tU7fz+sXIJUPPHgZMCYDFVeu6oZcYrVsq7o6oQ/P+UOnmj4ljnudpFURLCo4LJm05 wH19Tl2o5z/K0PJYTq/kwrgk+jmJn/d/PR3wneI3BZ9VTSLyXUBsQlpK7Cv4ug4hwVUR2johQSw4 SBb+dAEG9KfzpZH27N2PX/zyX/Hin1/Gxk1f4NjxE/6XBkE6euw4/vHBR3j8l/9ah5C4ZNBAPP4v jzR7vWHdjmhsGZchlmnYsCG45eab/FXszN+F3/+/Z/0Eg/9CiB0SEczPcjpR3tChymZen4q77SUz ZuOmIZlIVt+7bjjcFiSnGVYj/sZ2uRxzb5uI3hm+j2K3E25LGrr4zcT9OYGUIbh9/mxcd6kh0yAk LLBnZGPktNn40fcvR8+A7Go3fQjGDOmGDIZiZ6J8WGBPzkS/cdMxb/7NdZWtLrmY0Nf4454xaoI/ zkQks9OR5DUalY3pz32I9198FDeM76/iMzhLCuHMHo8bHnsZHy1diFo9vD8yIyUS0qfimeX/jTlT DdnlhQVwZkdObhhtDfG/PRfzln6Ilx+7AeP7M8KEEyWFTmRPnYOn330Tv7m2UTMJJTgtdyHeXfky Hp0+EpkOg5CwZeZg6pwn8ea69+uVk3XtfbgvxwakTcWvptcSErqlva59Ess3vIOn5wW2rQSg3Nm/ xIuPTb0oDAbLvLsuoIyzRBESqi0ss3wt3n188kXldJ2x2p7dukcFuLQMzA1wpWhGbT0ux9wfz8Et 4/qgq/Gg+ggJPlfdMOyKmZj341kYG4J7Thl6M35011SM7NUZdv2IuY1ncvxNc3DvlO61iwond0an Ok3ti2H6WRs4pJaQYJ6uQzBIcS429BuXW0tI8FrfHPRTj2hnDBsdn4QEm1l49JhfgQjsdp/evfDY oz/DrbNuUT/u81xw4gfH0WPHgk/H5JgfbfGQ+MHFHz8gKyur8ei1wNUDgUqnQSZoUsE34RVWk5mX P12WsiiTslkH69L1hiUw1pnYWLXqhksFvDQlpsKUlAGTPQ0mW5KxPGAAj8BlQT0e+kkbP/2RHaqZ HFdasQ2VJx7P90zOwPvTf4kVN/4Kk3rUTmxE0tYJ3S7Fq1MfiuuV7zgW+c3NLUkDWklMmTIF2dnZ iojg+cDE+808nEnmj/vBY4BlSEhQxrRp0/xxJALrCpQZT/tsMy0auNpAcxNdAWbNmhW/hITqoI95 6DnCWOvRawWObQbOFBrEhI+UqoOF121c27oUsPgi/TJWXo5yDoZawqhOgfg84Lin/sifTiTZaD3B sUpyjgQVCQq6Jekf464UFxcrVwbuB/54nvl4rqioCJ999hm2bt2q6qCLkCb9g58rXX88bXUb9Ttc P+cmr94Lam3e+s/Ug8/TipAIWFIzKGubPHS7PXj7naVYs+6TiNtPZufmm6Zj1i0z6vV3jFhglAuU tUCk848/XgNamQSmSwYNwpAhl2LgwAHoktEF6elpKCsrR8nZsygsLFRxPBgULTARx+98Z1rgqXa8 vx9LX8jDCQC9py3A7KGt0FVHPt7+y0acRDdc/aPvNqwMRpI3kq4UrcD8G5/AFtyAP2x4GtdGz5I1 klZI3lZFoAirXlmBvZVJGHbbvbgh0E2pVdvVcOX5772EtUWAZeB0PDSjrgtIwyXb9tXVa9bWif/D YFU3z7gRV105SX1gBfaOnxQbNmzCin9+WCeqPMnn66fF3kUvPTXYDCawda2z76ypQYLJC6fVhgeX AnmHvLBZTGpZULeHZrtGrImGWkf9nkt/MoaE08Xgl15MHWTCC7MBm8uJGq8JthawRGmojRddc5TD 9c0eeE7ug9flgCk5A+Yu/WBO6wETg11aE2GipYQvzgLHjv5YvUhWOz5RVHEWH5/Yhg3f7ENx5Vmc rCzFkbJAl8u6nefyn3QDybDHU0DTum3UR7ynVDw4M6oVEJJnX331FehLzsR73th9pxz+mIYNG6Ys BDg7zO9x/qiQ6VlXlSmO/2M/9u7dCy4bGqi0htvknJwcXH755WrmPdwyrZLPeGkBRzYDz1wGcFUg kxMYeTvwk78ZTQpeSYPvgpNfA89MBKovACaPmnTBv+YbJGardKR5lfJ+c3xzvC5ZsgR//OMfFZlA 1yNa+pBQINFGIqO+lVj0s8GxQtKdY52xWbhkLkkJWiDNnj1brfLB5XfjIW3apNZzi7gpIacUONtB iwFudTTtiKXHcQH6Is69+3uYctVkvLl4Sdgz/UOH5OCeOXeBS6LFa7LbbHA4YxslnkRC54wMvLv0 b/7IwgcPHQJ/4SSa5905+7u4bMK4cLJLnighoGen0Wt4w4QEQ1j4ZrLDyRtJ88ry86BCxOaMxwAh JCKBrv3k/TofBQyvkDYAY9oIIcFVaAp9cR+69grPWqa93LDDAUEuR4/OxR2336ZI5/r6xw+oq66a jNxRI/He35dj+/adKhvdJGOd+LcvHhPJAoejBgleB/4y247frjVhyTYvyqtNSLbVkhMeujiopQ6N XuiJZDPJCAtjUphQXg0kWb24d4IJv7yOK+w54PSYYbfH3jUmYmxNZsCeClN6TxXw0pzeA+aMvjAl 1v/i1x/fEdfTxgv0SumC+3KmqZ/uSudXv69362zpskELiSRLfI71Oo31EQ4kC6hMkZjgPk3OqVRT mWIUfs78krDQpEN9Mjg2aGnAoJZ0g2C8BX5H8jxltxVCgn1jm+lyQWX0k08+UauQBPe5vmOSwVdd dZVataC+63F3ji8wEhMDJgA53wEOfgx47MCu94A35gF3/CeQEmS6eHAj8PoPgOpzgCkRsFQD0xYa hAQtK3wuD3HX1wYaxLFNwoFkHOOLcOzSRYfL3pKYY9wREg3MR1KC44M//Txwn0nLoSyWp+XFoEGD 8POf/xyTJk1SchpoRpu4FJKUoGsCf+09MfjlL3/xLygqLsa27TtBV46zpaUqmjiJCy7p0y0rS1mL XDFxAnrXY5oabxjZbQngzIwe0LFqHwmFITmD8eFHq1TAs3Dq48PFpURvnnEDUlONxRdj1T6RG4xA ETbv47K+Fgwa0ZjJaCR5g+tp4LhsI577tRGTZeTsyS28/GQD7ZJLLYiAA9t2GKtgZAzOrevq0IKt iKwqFwpXbsQhZYnZDTlD6/PJikxiW8p96OAhZHTujLvvvgs5gy8Jq+md0tNVrKZJV1yBt95agoMH wiOswxJeTyb+beHfvnhNJA0YT8lbXYlfXpeMif1MeGsL8PkxL85WAql2ExKtdL3mbLA2a/eCREW1 y4QLDi/S7MCUASbcPd6EaZcw4GglTOaE+CQkeCMsNpg79QTosqFiRyTBZAtye4zXGxZn7eL4fnDE DPx/4++Oa5eN+mBj26lIMZGYoAJG9wyasl933XUoKSlRxASXCKVSRmWLiaQDFTnO/jJ+RGZmplLM WJYKOuVSFmVzv60lLmNKd44tW7Zgz549DTaf/b/66qtVMMAGM8brxbueB/5jvGH9YLYDm18D9q4C RswAug8GXE7g0EZgz0cA34GakOg9GZg0r9ZvLV7710C7OD5p5cAtdUrecx7/7W9/U+4bmrALV4fS VfG54PNzww03KIKP50lc8Floi88D2x/SfUN3WrZtEwFnjQvVjrrR+WPZkwsXyrF3bwF2796L02dO o6y8HBUVlUhJSUZaWhq6d+uGYcOGYvjwIUhNiX+Tw9hgFQfuG7HpmF9q/isPYGXWPMyePBIDsgIU N8cZHNm8Ak89/jy2MNhj/4fwzop5aIwa8QuWHUEglgic/gJvrylH78tyMbZ3d6T4h64LFScPYkPe Ruw9Y3woZ4y7C/dOamZgzlj2Jcqyz5w+g01ffIUbp1+vFICmiKcyvurjNbj88svQNSuzKSIaLZPI KN4JIedZGi3fUhnoOlpd7UCK3QNYU/CPvcC2E8D2Ii8OnTWhrApw+VyxrSYgPQkY1MWLMb1MGNsb uGUYIwNWoMJhRmJi/UtmtlRfmlwPg9WpZDL8x5ssqP0WDLSU6JWSiZemLMCUnnEa0DDM20Cli8oY fzrQHQNZknjgTytvVKyYaP2gz5Gs4I/B/ShHkxG83lYVsEDYuDzqhg0b/ISMvsa+jR49Wv2IR5tM 2o0j/0Pg5dsBtwPw2gGPAyCPrPkk3naXL6CTzQ1kDgMWrgY6ZxukRBskngLvF8etHqtcZYUWE3wO uOoErYciTRz7tLJIT0/3yw2sI1J50czfVPcNISWieRfiTFZ5xcVBguKsiR2sOR2AlHh6NO5Z3PBt tY18CK+8NA+59VvwNlxYrgoCsUDg9Hq8smRvnSVsL67Ghq7jpuOuSb1CL1t1cSE50wII8GM9NTmp BWqKXhXVjhpYzF4keKoAeyecqgC+KQOqHEBJlVFPZhKQZAd6pgPdGSrDcR415iS4PSYkxqO7RvTg 6fCSSEpwedt7c67Dr8d9D51t8RcrpSk3iUoTf5qc4JbPL33qSToEKlV6n4QFZ5MDzdc1GaGVvKa0 Jd7KUEmlOweDHzJR4aR1BN1V2nzSrheHvwSWPmgEvCQJ4TH5Y8rA44L648oVNybcDXz3/wGpme2C kND3j+OdYzfaKd4sJJpKSsT/tEK071wHkpdot6GquuWsJToQtNLVEAjkLvg7XhywDMtXbsGW/AK1 DCizcqWH3AmTMHPubEzPzQ5aTjGEMDktCLQUAl0vx03TgG27inH0zDk4agNmw2LrjK4Dc3DFxFz0 T5c/mS11SyKpJzFOY0k01AdNKjhdVnidTmQluNA9ywMw8JvZN874kW62wO01w+G0wmRJg81qVpOL DcmOu2u0jPAFKVTTom11xrcFgZ3WezR+e9lc5HS+eDWbFmxG1KsiiaB/2hKCCpWOC0EiIjAxL/Px p/Nwvz2REbq/tCpmzAEGL+RM+uTJk5UFib7eprdqySAPMHAi8PONwFeLgM1vA8d3ABdKAHMC0H0Q kHMNcPkPgUFXGN3VVhZtuvO1jSchwfHOcc79wOVf6ZLU1MRnoj0ksZRoD3exgT6QlKhxuRrIIZcE AUFAEBAEBIG2iQCXwU5K9PvbtM1OSKsFAUFAEBAEBIEOjkD7oFY6+E1sqPv8WLPGwFSooTrlmiAg CAgCgoAgEGsEONMkhESsURb5goAgIAgIAoJA7BEQUiL2GLd6DclJicr0rdUbIg0QBAQBQUAQEASi gADNVVOSmm7uGoUmiAhBQBAQBAQBQUAQiBICQkpECch4F8OPt/bogxfvuEv7BAFBQBAQBKKLAP+W CSERXUxFmiAgCAgCgoAg0JoISEyJ1kS/hetmYJWKqmoVZKWFq5bqBAFBQBAQBASBZiPAFQlo/Sck e7OhFAGCgCAgCAgCgkDcICCkRNzcipZrSLsLftnOovO23EiQmgQBQaBNItBB33kS1LJNjlZptCAg CAgCgoAg0CgCQko0ClH7zOBw1sDhdLbPzkmvBAFBQBAQBNoVAlzi2paQ0K76JJ0RBAQBQUAQEAQE AQMBISU68EhwezyodjjhdrvbPgomE8C1fwEx6237d1N6IAgIAkEI0P3OxHNqvXe+6TpG4gobJCTo tiFJEBAEBAFBQBAQBNonAkJKtM/7GlGvSEoocsLjiaicZBYEBAFBQBAQBGKBAEkIRUbIktaxgFdk CgKCgCAgCAgCcYWAkBJxdTtatzE1LpciJzxCTrTujZDaBQFBQBDooAiQjLDbbLBaLR0UAem2ICAI CAKCgCDQOgi0ZhBpISVa557HVa00Cw5MPHa53Khxu9Q28JrsCwKCgCAgCAgC0USAASxJQlgtFnG/ iyawIksQEAQEAUFAEGgiAi1NUAgp0cQb1R6KBZMRwX3S1xl7gtYTxs+rtjwnSRAQBAQBQUAQCBcB WkGY1c8Es8kMs8UssSLCBU/yCQKCgCAgCAgCMUCgMfKhsevRapKQEtFCso3J0YRDYLODzwUfB+aV fUFAEBAEBAFBQBAQBAQBQUAQEAQEgbaLQDDpEHzMntV3Lto9tkZboMiLfwSCyYbA4/r2A8/Ff++k hYKAICAICAKCgCAgCAgCgoAgIAgIAqEQqI9o4Dmt9wVe57nA41Aym3NeSInmoNcGy+qBppseeMx9 fRwY7DJwX5eTrSAgCAgCgoAgIAgIAoKAICAICAKCQNtDgO6UOgXua/KBOqHeZ77gY102WlshJaKF ZBuUowkIbvU+CQjuV1RU4MyZM3A6neCSofq63rbB7kqTBQFBQBAQBAQBQUAQEAQEAUFAEOiQCGiS gVuLxQKbzYasrCykpKQoAoLkBHU9XudP77cEWBJToiVQjpM6AgkFvc+t3ichQQJCkxHdu3dHYmIi rFbhruLkFkozBAFBQBAQBAQBQUAQEAQEAUFAEGgWAi6XC9XV1Th16hTsdjsyMzMVUaGtJjQxwUq4 r1Pgvj4Xja2QEtFAsY3I0OQDm6v3tWsGyQjuX7hwAWVlZRg0aFAb6ZU0UxAQBAQBQUAQEAQEAUFA EBAEBAFBoCkIHDp0CGlpaepHUoJWFEyBBIWWGytSotaZRNck23aPgCYk9JZkRKCVRLdu3do9BtJB QUAQEAQEAUFAEBAEBAFBQBAQBDo6AtT9SkpKlMW81guJidYV9TaWOIldfizRjSPZwYOJx/xpMoKW EjTjqaysRFJSUhy1XJoiCAgCgoAgIAgIAoKAICAICAKCgCAQCwSo+1EHpC4YmOqzlKD+GAtrCbGU CES+A+4HkxMOh0NiSHTAcSBdFgQEAUFAEBAEBAFBQBAQBASBjocA4wdSB9Tu/Fo/bEkkhJRoSbTj rC5aSQRaS5Adq6mpibNWSnMEAUFAEBAEBAFBQBAQBAQBQUAQEARihQB1QOqCgcQEdcWWSuK+0VJI x0k9mvnilkmTEoFuHHHSVGmGICAICAKCgCAgCAgCgoAgIAgIAoJAjBEgGaEJCT1xzSq1zsj9WLht 6G6JpYRGooNu9aALHIgdFArptiAgCAgCgoAgIAgIAoKAICAICAIdDoHACWo9ad2SIAgp0ZJox1Fd gYON+/rHASlJEBAEBAFBQBAQBAQBQUAQEAQEAUGgYyCgJ6q1Tshe///s3Q1YFFeeL/4vqEAm0ZgX pjFhRoLJCOQ+QzMzkc5MIjhRwagRX7KC5i7g7Abc3SiZUcHx5eaqWfBlVnTurpjdEbj/KGTiC0aM GM2KmoyNM3tp8p8BMglKDLnCkIkGkiio1H1OVVd3dXc1dEPzonxJsLurT50651OnqqlfnzpHXTYQ AgxKDITyEN6GGpwQjW4gG94QJmHRKEABClCAAhSgAAUoQAEKDBuBwb4mZFBi2DS1niuqNsaeUzIF BShAAQpQgAIUoAAFKEABCtwJAoP95TSDEndCK+pDHdQuOqIhih/xmj8UoAAFKEABClCAAhSgAAUo MDwE1GtANTihvh6o2jMoMVDSQ3g7aqNTH4dwUVk0ClCAAhSgAAUoQAEKUIACFPCxgHotqD76OPtu s2NQolue4ffmYDTC4afMGlOAAhSgAAUoQAEKUIACFBgaAoN9DcigxNBoBywFBShAAQpQgAIUoAAF KEABClBg2AkwKDHsdjkrTAEKUIACFKAABShAAQpQgAIUGBoCDEoMjf3AUlCAAhSgAAUoQAEKUIAC FKAABYadAIMSw26Xs8IUoAAFKEABClCAAhSgAAUoQIGhIcCgxNDYDywFBShAAQpQgAIUoAAFKEAB ClBg2AkwKDHsdjkrTAEKUIACFKAABShAAQpQgAIUGBoCDEoMjf3AUlCAAhSgAAUoQAEKUIACFKAA BYadAIMSw26Xs8IUoAAFKEABClCAAhSgAAUoQIGhITByaBRjcEvRNHc6RoaF4d4Vq+D/4INAVxck qQtdkgTJ+ly8liQJXV1ieRekLklOI95XXivvS9ItJd3nn+PGvxag69Il+fVjJ6sGt5LcOgUoQAEK UIACFKAABShAAQpQYIgJDPughAhIABJuNl7EX1f9AmOW/iMCfvgjSGJHSfK/tl3m+NLxPVsiAF2W GnTuKYb0zdfaxf38/At88p/H8eZb5aiubcGlG8rmAu424LuPRuK5hLl4OjEK92tL8cH/QsKKo3Kg 5dG/3YoNUx/UvsvnFKAABShAAQpQgAIUoAAFKEABnwl0NNfg3aL/jTfP1+LjK8pF67APSoiAhPgR vSDw9df4ctsW3D3/edw1b54VXn1fTqUsU+MRoieFNZWSj4Sbb5XLv3JAw/rmlRs3ban640m75T/w y1WlsMj7dBTuNxjwqHVDX3zRgo9rWvAvNZW4FHICL0Xrl+Cj355E49Rk/Te5lAIUoAAFKEABClCA AhSgAAUo0GuBZpxd+wu88n4LOkUeo+7GowblK/NhH5SQ4wbaLhAiNrH/TXT+6Y+45+WfA3fdpQQs 1OCF/KhEG2z/SoD0zTV0/uu/4Vb9hw676ZNrHWi+3olJDkt99+LyW7/Aku01+GrUBCxetxKLf/oo Rjtl3/HFx6h+8z/widNy9eUjwcG40HICJ/4wH0/drS7lIwUoQAEKUIACFKAABShAAQpQoK8CzXj7 H9KRW3cDAYYfY/X6LDwbZe/Dz4EunQISCreEG3W1+PKXq3Hzk0b59g55uUgr/pd/rd0gJKDr00/R sWETuur/rLwPoKOrC39s/xot1+U4UF/3ou76HZZ8rBABiftmYefB3cjUCUiIFQPvfxSxL+bib4y6 2QA/iMFTuImTb51Bu5skXEwBClCAAhSgAAUoQAEKUIACFPBW4JN9q5WARORSvF66wSEgIfJiUEIo iPiCBIzOXGoLQIjAw63WVrSt+SWuV1TIvSWUZNbE8noSbp48iY7/uRHSX/8K5WYOCe03bqL+qcn4 5laXnLW3O82z9LV4c0M5LiEFw9d+AAAgAElEQVQSq/8tCzH3eLaWXqqLiMH0H48EPv4t/nBJLwWX UYACFKAABShAAQpQgAIUoAAFvBT44hQKiz4FRsXjn7fMxzid1f1X5x3HR1+5vvPXt17C01OmYqdF vNeM6tdykDFrhrzs6enPw916ck5ffYyTeb9Aupp+ygws/rsclNX2X68B1xp4uMTa4UFEJQInT8a9 /5wL/weDHVa+9vpefPPav6Pr66/lbhJyWOLrb9C5pxA3Sn+rBB6s+fzfgCB8PP95dD3+uBzg8AMg fn390/HeQRReAULmL8WzIX3N/W78t5nTEIxvcPL92r5mxvUpQAEKUIACFKAABShAAQpQgAJotxzH uzeAR9P+FrFuvkj3f+/4ViyZ9xLebnYj9kUNCpLTseKtFox7KgGLZ8fjqXu+gtv1mo/gF/My8T+P 1yIgagoWz56FOdH346tLf8DZj79ws5HBXGzv+SCm9hzx3e9izKuvYtQPf6j0mrAGG2689x6+ycvD rU8uoeuTS7i+ZStuvv87a88KCbekLvw55CH8JSUFft9WghpyQMJPBCWsmfiwmh+ffx+duBtzfhrl m1y/NxVzHgJufCDqxB8KUIACFKAABShAAQpQgAIUoEDfBD4+/wcAd+MZ43fdZjTy9b+PxJJ/r0Nu 3nE8nZ/gMkhi1f/agnt+moeyf4q2v/fzryDuC3FdrxNVr+3A+Rt3Y/H2w8jUjGGwAs346JKb0Ijb 4vX/Gw5DSnRZAxR33YV7spbj2oGDuH7okK0QXZdEMGKLfKtH1zffyMvF+t/cvIUL0UbcMJnUASfg 1y/9I9SiNOOTj8VUG48ipM+9JNQ8H0Zcsgm7Nr2rLuAjBShAAQpQgAIUoAAFKEABClCglwLNuCwP DxCJ8e5jEvAfv2glXvoOgJpSvKsznsClkGT8szYgIRfnHuiv9wX+Kve4iMTj6pyUtuKH4LHvDr2g hK14os+D1GX9lSB1SQicm4Rvrc6B37e+Ze0RAUhffwNJBCTkaIYEUd0PZ87CzSeflLOS+0T4+UGS e0gAflL/3L6hlHsCxtkHLdVUpQY7p0xVbrWxPk7+6TRM/pcaTRrXpwE/SsDUINflXEIBClCAAhSg AAUoQAEKUIACFOidQAju7yYU4A98F7HPTQDwKT6+5Drmw6TEn+AB3S3rrReCx6LuA/AHFOQdwUdD 8W4Nl7pYe0eIYSrloIT6qAQo/Cd+D9/auhn+3/2OMiCmHLwQt2tIuPCt0Wj+21T4fec71mlDtZlL /dpXQtlSM77QGQ8EGIUQgwGP2n7vRoC2aG6fP4roqY7jabhNyjcoQAEKUIACFKAABShAAQpQgAI9 Cri7blVWlGffCAhQLlkvf+EaRRj/Xd2v4uW19dZ7LC0Xv4gehUvv78CS+TMw5x+24G2LuwEreix9 /yewxySUGTa6RDBCQpf47VJ6TOCuuxC0/n9g5NSp8nvf3LqFD78XgS8XpUAKCJTL6OenDGdpe1RL bu0xob70zeP9eEC+beNT/NV1lwGIwt+U7kWh+pv/d9DcSdNtEe7//k+7fZ9vUoACFKAABShAAQpQ gAIUoAAFehbo6bpVycFpSlDPvk933bhmvXseRVL+MbxdvAYvPRGCzrp3kPvyC3jm7/5Nd5YP17wG b4kY6FIORthu4xBTenZB6upCZ2cHPnvShJa5SbiQOAMd8XHWgso3bGgKrb62Bin6YZBLIACPGiMB tODYeZ17bjSl8frp6O97vQpXoAAFKEABClCAAhSgAAUoQAEKOAp4dt0qByWaP/4Yosv/Yzq9Ijq/ cr2lQ91Qd+uN/u4U/M2WQhw7/jq2TbkPnQ0HkZl3Cu3qykPgUfSI8Lv3XvgbDPAPC5ODD11dXbZp P8VoEOK/a9c70Nb+Fe6//36EzZqJHy1cgO89OgEPPzQODz00Tr5VIjj4QTzwwH0YO/ZejB59D+66 6y4E3H8fRgYG9sttHA88NQtPAagtKkW17i0cQwCYRaAABShAAQpQgAIUoAAFKECBYSvgyXWrP756 H8cqbgCjfoJYndklj/3n79GhR9jDerZVAkIQu34VngfQ+X4NfPy9vm0z3j+x3rcRMAoIGIX3m/+C h0JF7wMxpoQkByZ+//v/QkLifEyM+BGmJ8zDm2+WQdye4e/vh65bN7Fh42ZMm56EGTMXYMeOAtzo vIUR/iMwYsQI+I/wx8hRgfAfFQg//xHeF6+nNe5PwJL59wFfv4MVq47gck/p+T4FKEABClCAAhSg AAUoQAEKUMBJ4OsL/4Kb7f+/01Ifvbx/Cl6Y3f11q//bqzbh8A0gKu1vEaO5C0MtQuepfPyqwjmU cAn6613Cn843uwYxvvoK8pf53/kO3I9QoW5xYB6VuIMEv5Gj8Mcr7cgsf1cZU0KOVUior/8znl+Y Jvd8eO21HUhKmonVazZg777foutWF1IW/z3q6z/Cr7ZtxPJlmXj72Als+9VO+IuAhL8//P1HwC8g ALdGjMCIUSP7pVKP/dOvsTpyFDrrduCF5PV4u1ZvgIlOXK4dSsGgfqFgphSgAAUoQAEKUIACFKAA BSjQC4GuG2345tPiXqzpySoBePznmuvWv8tHdbPj3Rgjc+tu4J7o5Xhlkf7Eoc//49/ik39Zghmv ReOZp76De776FGffq8GlG9BZ7wrezf4FMkfdB6PxCTweEoDO5hq8a/kUX+A+PP/zBIzzpNwDkkbC zZs3sKfuI+SaqxFkDRzcuHED7e3t2FWwB/fdNxav/3+vYdTIEUhMeAZff/01fvWrf8Xoe+7Bn2rr ce6943gkfLwczDAYgvFPL63CkiX/HeL5CP8ufPhlG1b85+/wmyc9HWbS24qH4Nl/242AtauR+/7v kPuPv0PuqLvxqG2+la9wqeVrKLt8FB4NudvbDTA9BShAAQpQgAIUoAAFKEABCtzhAl2del9w+6rS IXh2y6/RufYl/KqmHMtSyoFR9+HR+5VeESOfzy5AeuKjGO1ue4/Oxq/+dwhez9uCvUdq8BVG4X5D NJ5PW6qz3ncw4+XpuLzv97D8/h1YAATcbcCkp36Gv3kxBTHyjBHuNjRwy9XbM957731sqbLg5z95 AqOCgpB76n188cUXuPvub8Fc9XskTP8pRo4Ut16IkSUkzHx2OvYU7sWR8uOImPgYwic8otzqAQnP zpiKESP88cEHf0RCwjPybR5+I5TbNsStHPL4FdYZOnxb0+9i6qa9iL10Cu8WleOwpRYft7QomxA7 ekIkYp+bj8Sf/Ajj7xd3pagDcfq2FMyNAhSgAAUoQAEKUIACFKAABSigK2CdEOOZj0/h2GulOFZ7 CR+33JCTjlyW+KjuOg4LQ57AC/lv4gWHhXov7sdjz61C7nN67w2tZeLSPDIyAg2XGnFjZx5+Y6mV x5MQvSNGjhyJixcv4WfpYcoglfJEGn4ICxsvV+LPf/4Y4eFh8nPxlsgrKCgI3/52MD777P9ihL8/ vmj/Cu03b8pp2m91obm5WQ5UhIT0T2RGDCyatH4Kktww6wYjvv9POH40Ax0dHfKvm1W5mAIUoAAF KEABClCAAhSgAAUo0GeB0Y+KCTGm4G80OfXPYAeaDQzNp/LAEXIQQVysS69sxj07fw2//3wP9z/w ENra2iBm4XjgwWAE3jUakqTMyHHffcqIGF9/cw33jh2Lu741Bn5+/kqvCD9/jBlzLz5uuISfPJ3o UO1l5yxY9tBD8jLd4IBDar6gAAUoQAEKUIACFKAABShAAQoMD4FhGpTQ7Fz5dgYlSKEulYMQ8gs/ eRYOiMCF+JX7RCip/MWtGLZ1/cQdHhDLHnroIRx565AcqKitrcOq7NV4/fXX8cADIqAhd7lQN8NH ClCAAhSgAAUoQAEKUIACFKDAsBZgUMK6+0VYQvmRcPfdd8vTera3y3OG2Ja3tymvxZgTbQ7vKUnE snEhBkyfPlXuQXHPaGWkjilT4jBu3EPyMmtmfKAABYakgAUbwp9HIYD0Ax9hfcyQLOQAFYoWAwTN zVCAAhSgAAUoQIFhLeA/rGuvqby9D4OfHJAQ40d88sknDik++eRT+XXExO+hsVH7HnD9+nV53Ijv fe8x+zq2SIc9d/ubfEaB21GgA9VbnsPE8B9g7i6L6/S/t2OVWGYKUIACFKAABShAAQoMcwH/AGWo gsFgYE8J+TYMETRwDBxMiY/DsYp3sGHDOnlWDfHu0bePIzT0Ycx+7ln8/d//kxyYeCQ8XF61ouIE bt26hfj4OGteyi0dg7FT7+RttjWcwZF9B3HEXIXqus+t050G4MFII0ymWViwaCbiJoy5kwl8Uje7 Yx1q6y6g3ZprwIORmDAhHKZZ87B4eiwmBAc6bq/1BHYV1Mnulq3lqF1qRO86E9i/hZ+85XcoXhDs uB03r1r3L8GkVWeByXk4XzQfnq3lJrP+XFy9CY/M72au59HhiAwNR0zcZJhmPY3pUaFwku7P0jHv 4SLQ1oDTR4qwd99JnLaeL0eHR8IUl4qlmfMRM2QPoOGyg1hPClCAAhSgwNAQ8B81Bt/6TuqgFcZt UOKB536Ns7fBLBq9k1ODEOJRcopHKO+99NJSvL63BAuTU5Hx9+nyFKH//h9F2LljK+bMnonc8F9h 7vxFeOV/rJEHxlz9y/VYuHCBfEEnxzf8gJ/85Ce4ebPTetuGyJc/vRXoaDiANcvW40Bdp04Wnfi8 7jzKxW/heoyOXYHXdmbAxD+4XazaqkuwZu0mlOs6Ap2f16FO/FYdReG6AGQe+BOytVGH4GlYmhmJ 0wVNiFk7D1EuW+ACjwTaL6CuTvyexL4CAKOjsWjdBmQviAJDah4JMlEPAm2ns/FU+kFbwFFN3n6h Dicu5ODE3mJklryJ7BiGw1QbPlKAAhSgAAWGq8Dd4T/HyNGRg1Z9t0GJQSvRAG3YHiJQghBKRwkJ ouOEiFI89tijOHToDfzyl+ux6IV0jBs3Dtu2/jPS0v67XMLDZb/FipWr8WLGP+Kee+5BSvJC5OZu UmbigJ/mP6eYxwDV707aTNM72UjNPIgLcqUC8ODkFGSnz0JMVDjkL/LbmlBbXYMj+7ZiX1U72qu2 IeXpE1h1cC+WRvEPbqUttKF61xIkb61RepcEPIjJC5ZhwaxoxESFKhfCHa1oaKhDbflR7DlyEhfa O3VuzwhEzKq38OEqdy2sA03mcuzddxDvRK7Eu0uN7hIOk+WTsKl8F2aHaqvbhqbaz9DQcALvHDiK dyyfo7O9BvtWzcGRE3l4e/d8OCTXrno7PW9rwJEjRTiyrx2zi/Ixm0HCAd17Ha2taA+IxPx1G5A1 OxKhYwKBjjY0VZdgRcY2VLXXoSAlGzHn8zGdkbAB3TfcGAUoQAEKUIACjgLDMijhJyIPfiPghxE2 jV/8YhXEr/YnMfE5iF+9n8iob+Po0Qq9t7jMhwId1ZvsAYnwedi6cw0WRDn9BT0mCqbQKJhmpyC7 tgQrUtbjRHsNtsxbiuCTe7DgjrjC6wtqB6o3Po95hSKsE4DI+Ruwbd18ODMCYxATPAExpllYvKkN tftfhdnrzbbBXJCDgjPA0L23wutK9WGFQAQGj8EYhyY7BlGmUESZYjF78Vp0NFUhf9kSFFg60X4i B8+kBeK9olm3P19DCZatKwXwNKb3QZCr9lIgeB5Kzs+CSdv2Ascg1JSB0oNjMHfaelg6j+KIeQOm MyrRS2SuRgEKUIACFKCALwQ40KUvFJlH/wh0nMGGlGKlh0R4Kg4e3ewakHDa8pioFLx2NA+TAwB0 nsXKtQfQ6pRmuL1sPbIUydaAxOSNb+HQVr2AhLPKGEQt2Iwl2ls3nJPwtU8EAkNjkX3wOLbKjRbo PJONDe+0+SRvZjJ8BYLjnAISWooJk7DA2kOzra1D+w6fU4ACFKAABShAgQEXYFBiwMm5QU8Fave8 in3yEBLhWLVzLTy+9Tl0Pn69cyZEXAJn1iPfPIz/6O44g/yVZ+VbNgIW7cJriydwQEVPG+CApgvF gt17kP6w2GgnyguOomlAt8+NDS+BDrRZ415jxG0d/KEABShAAQpQgAKDKMCgxCDic9PdCViwf4d1 FIlFa7DEyxEVx0x/EVnWC7x95VVOYyOImR8ewyPhj2FDtbUMrVXYs2wxnolWlj8S8SSezdiEI7We fWMtuuDvXbsUz056XM73kfAf4JmULOw53QB3OYiZJEQZHklTe3O0wrwnC8lTf+CYh7n3fT2a9u+0 BnaexqvLJ/skIFG90Wq00WLfgWK2Cdn0x1gpbt0QP4XPW5c5WVvf9vmDrQyboO5W3W3Y0i3Bfk9o +9g2dMugtzAwFksyo5V3LCU43aCXSCwT43aUYE3Gc3giwrovohOQvKwIpxvctTZrXmI2hr3r8OLM JzHRegw8Ep0gt/X9HrZ1e6masD9Nbe8J2FAtgn+t2J9mLZNt9pGzWBlrXebQ3u05yc86mlC9fxNe nJmA76tlsx5Hm/dbuu/x1HoAqfI69n3aVluODTpGfTicrMX04lhvO4GXrPvoqY3up9Bt2LtAOVYi 1uG0bgy1DbVHtuKlFLvNxEnP4cWNB1DtSRt2pj5dgvzPxN1cyVgcp72/wykhX1KAAhSgAAUoQIEB EGBQYgCQuYleCNRW4R3rRBsLpsX24mI6Cqbpcl8JYH8VarspghhI85nYF7Cx/DwuqHNjdn6OuhPF WDbrSTy7xf3FhLhArN2zGE9MfgFr951E3efq7CDtuFB1FBvTE/FEWgkadC807IXqaD2DNVN/jJRN R1FlK4Q1j0XxSN3fm+/Nm3D6QI2ykVkpmM6BBu3gHj7rqW3M3VXrFPDyMGM3yULjUhArv1eHd2p1 rjY7arEn5Uk8vWg99p2og725XUBV+atIm/YkUvc26Japo3ornp2UiLR1pThhm04XgJgJ5EQxVh5Q goBuiua0WIxT8jOsPCPaezjS972J9R53ZXLKSoQyTm/Cs9FTMG9VMU5opqgFlGOgYNXzmBS9FHt7 OpDkrDtQu2sBnpj1Mgp1jFJif4AXj/TmeOrFsT5mGl619tr6rHAT9usFmlrLsWGjOE4DsGj3WsQ5 d1xoOoEVM5/EzOWvobzKPn2vmCnnRGEO5sUmYM1pnbbiyqwsaTqAFzNK0YkATN66DCbn7blbj8sp QAEKUIACFKBAPwkwKNFPsMy2bwKtDVUQX+SJQfJMvZxBI9SoXN6hsw4Nbv5m7zixFamZ5Qicn4ej VX/ExQsfyb/1Z17HqtjRclf6uoLFePGIfga1e57H3E3n0Y5wzN/4Js7WKetfrPsdTha+CGOAGCNg PVK3OPfW0Ph01GHPyp9h/5gXUXTid6iXy/BHnC/Pw/xwka4TZ1ZlYa+311FtdTBbOzNMnmbs36km Y9Za7X6HrZOtdUt/0+YpXNffZuNTeNI2LFufd9s2NHvY86ehE2zTrJrrlCPAvnIt9sx7Hhur2oHw edh04JS1rXyE+qoKFGVGI0C0lXU/w2bnW5baTmBFymsQM8GGO7d1yykc3bECkx+0b6n7ZyIg8Zx1 4NRwzC/4DdbbRlMMxoIi6zFwQJ3r+mlsrbIuE227aL7DIJ6tR5bgqfRiuWxiOl/7MfARlONoBeRD sf0k1s5cip7ic7WFSzF36wXErHwdZy3qMW09niJFoLIdJ5b/DJvlnh3d11T7bm+P9THT12CbPF5I DTZsLHfq8dGB0zuyIWI74vaq9c4RCbHfZv6DPBVygFF7fvgI9WfexCb5BHEB+9Kze3QRdeloKEHq 1Byc6QyAGF/mNU6Jot3FfE4BClCAAhSgwCAJMCgxSPDcbPcCbW2fWxOEI7SX3/AHh8pX9AAuoFU/ poB9BUUI3XIcb4vBH+X5RZXNisEHl5a8ZR18sBNntuyGyzVM7W68tKkOneKb4gNvYdtiI0LVbx0D gzEhbiUOHVwBUYrPCre6v2ioKkYh8vDuwZWImxBs7RUSiOCo+dhWlAflGr8Gu450199Dx7P1c6hf zE7oLaJOtr5edGbVjx1u81BuA9F097d15X8Mk1ad9fXm3ebXp7bhNtee3ngQUWoszal3Te2ul7FR jioog74ujgm19SAKDJ6AuFX7cWil3NpQuOWgw5gUradLUC46NTy8Ar92butjQhE1OwPFHk7f2rRf M3Dqlt9g2/Q+TG/TdgIbrGOehKe/jvdKMjTHAAD5OMpA6fk3kS6q1nkWa7accHtLFHAWhQWfYfGB cyhdGqtMgymTW4+ng3uVfHABBTucAwTd7Js+HevBmL11szz4rhjENF9zf4bovbJGDJwTkIzX1jnf XtWGd9Zm4UA7EDDZ+fwABIYasXjr69g5SwRazmJNQTeBTxGQqN2N5JnrcaYzHPN3HEcxx5fpZofz LQpQgAIUoAAFBlKAQYmB1Oa2PBZou1DncdqeE36GVqcLPNs6xrV41e2coaFYsGktjCLxZyVwjAl0 wLxvpzwzyMPpm5Htrut61DwslaMKNdjrdpCAh7Fq1XzoXtqFTsPiWUppP6u64PQtq60W+k/aGuCR om2MBZ1AgHbcCP2t3LlLe902+kISCFukQZtNRxX2ymOsPIz0rSvdDvoateBFJYjlPCaFu/av3YYH z5uOLMWzq8TAqQGYvOU4it0eOx5kBqDpyG5rsCQV21bFuu/NE2hE9rpkefDazvISvOMmyCi2GrBo g/vjUeSzSckHZ47Cs7sefHCsB8/Cq5uelns97dtYZL2drBZ7VhbjM7e3bRzFLjmS9DRe3erm/IBg zE5PUVz2lcO5g4xtL4geF/O2wSJ6SIhA0mzds40tOZ9QgAIUoAAFKECBgRRgUGIgtbktzwUCreNB eL5GNyknIcpNb4vJi6bqBwPU3ELVqfM6UdugvX/CgnfkqUECMH2WUfc6UskiGBMmKM/qLqi9P9TM rY8BM2FyO5DnGEyItc7dpztSgFNeDi8DlRlIHJYNvRexGw+jxvJfHv0e3ThpwCrQ+7bRlyK2olXt 3qLNpvqEMmBpwFTMdhcAE+mDJ0Bpbo63LAVHxUIe9/WznVizy9JNTwPtRh2fd1RvQuryk2gXAQnR 9b+PAQmgCeZyZcyThxfNcxtoUUsRaJqGBfKLszhd7W5AzwAsnt/9GDSBMfZ8avWs1Q3aHn1zrIcu 2KDc2nRhGzbvb0LT/m3YcgEImJWPbOfbNkTAxlwO+e6ryTMR5+b8JRcxNBIm+Ym7HmEdMG/JkoM/ D6fv8cF+s8HwCQUoQAEKUIACFPCJwEif5MJMKOBjgdBw0YdddNX/HK3i+qMXA8S3NqkD9wUiUL2t wqmcEyZ099e+SDxG9CCH6HJQVSeCCtZvGFubrLdGdKJw/mModMpX92VDE1oR63A/vZzOFK7mqrva mECPb/Z3XD80XL5YEZNhtHaHGLMSNZZlDutWb/kh0vY5LOq3F4GBwRgzxrMdHOxuR/ZD6XrdNvpS lo7P0WQdSiI20r7fbW25sxjzwos92kJDk+hOYG3fUWn4dfpBeRwIMQ5GdEE0Zi1Pw9Lp0xBlu+fI fbZt5t1I3lGMCwiAceWbPppa9nPUVinbjIuyRu7cFwEIjETMZGDfGaCtzV3Xj1hE9dQJIHCMLYjo YORu2z471kOxYN0G7J22HmfWPodnIe7LmIlfb5qme3prrTuvlOhMDiaF57grnWb5echjo7rUvwHV p5UBeKfP6j5go8mMTylAAQpQgAIUoMCACbCnxIBRc0PeCNjHgzgBs0ffZrrm3mSxXvE8HIseYw+u q9/+S4JDrd+aA+9UqQEavWoFykEBERiw/boJ4uitzWU+FKg9g/1ydg8jrsera2+2G4iYdcdxfp8Y 0DIAaK9B+aaXMXPyf8P3UzbhSA+zWhzZsRMW+bo2FotnR9ku6r0pQXdpA8d41+DOuAwC2l3uQ+i9 CSlYn/kg0NmO9k4gdtMKTPcsHteHSojjuw+rc1UKUIACFKAABSjQzwLsKdHPwMy+lwIxk7EIxdiH Tuw9UIXsGG+/4auF2TqnaMD0WNuMBr0sjbxaZLiYjcP5R8wssAcLeupw4bzagLyOhGkWUFgOdO49 APMqI6f/6yd3/bbh7cY6cPpACeRr/4dTEKd3S8/kPJx3mr3Cm60EmzJQfD4DbQ1nsH/HTuSX16C9 qhjLpp3F6QL3g1Yu3r0X2Pg8Ci+cxcqZSxF4dBd8OSxBh9zzwfPAxORI+WYUb6qumzY02JurdR8c 620nsGeP/TauqoISVM92P0aIXGgxi806eWQb3Tr0vDAUoWLmmzrALO5XifGgV0rPmTIFBShAAQpQ gAIU8JkAe0r4jJIZ+VQgMBazFynjSnTu24r9XvaWaBX3a8vd4B9G1nz3f9ArF0PdlLyjDtXi/gcA MaGaftFjgq23XJyFZ/eld7ONfntrDOIWWQf16yzFriPaMTH6baNDIGPrLT9uStLjPreu12M6d23D zXZ7WixmYtggj1MCGDNnOgTSxgRbL8LP1NlmVOkpv+7eHzNhMpbs3I8PLG9ilZi3FhdwYNlu9wMl jjFi/VHrDBjtJ7EsLRvv9Lk5jcYE63Ap1U2eZHYBtdZj0X0w4XN0uBtuQgVpqINZfh7p0a0r8Nmx 3oojy5SxHYwbf2MdX+I1rNhh0R0tZky4Fae2wWEmFbUanj8GIm6TMiXr24sZkPDcjSkpQAEKUIAC FBgoAQYlBkqa2/FSIBCm5Rts02GuzdjkOiWnuxybDmDFWmXqyIBZa7BY7xtn67r7T+hfEKhZt50+ aO1OPxUm7QCD1vvbRbq95d1PxafmNRiPgaZleFWZUxRnVv0MG1zmNR2MUvXTNgODlcEcYYHDmKQO m+tA9YmDDkvcveh123CXYXfLmw7gxRQxZgOA8BV4dbEmACZmxowyWo+FEhxxO8VCdxtw894YI5bu 3AB5FtLOgzjd3ayzgUasF1PUyjGMg8hI2wRzTwEAN5tVFk9AzCwl2FJXcNI6I4X7FTpOl2Ov/PZM xGmPRYdV6rDf3H2Ao3IvO1IAACAASURBVPadImVWmodnetZpwEfHetP+bKw402ndv5Pl8SVEuPRC QTbydY7LCVGTlIFqq0pwuvsqOQjwBQUoQAEKUIACFLjdBBiUuN322HAqb/B8vLrlaeUP8wvFSJ63 qccp/FrNWzF3ag7E3/4IT0XpVv1B5FTGzn3rsVnngkB+v60K+RuPyt3pAxalOd37HYzp86fKyeQ8 ur06a8KRPSe8m85TLWCfH4OxYJP1QhIXUDj/OazYX9vj7AvuhhH0pDi2TvgdbbrfAHuSR6/STDAi Tu5c8xny953R3bbojbDG2huhp230vm30lLP2/TbU7s/Gs2qbDXgaW4syHHpJyKmDp2HBNPGsE/vW bu0+GNBUjj3dzZmp3bzD8wkI7eluhtD5KD6pBiaKkTKvu2ChOvuL+94LUQteUoItn23DSxur3LfL Dgs2byyVj8XwzDTEdVNOy8b12O/uIr6pBJu3KuOrOPdGcaBweOGDY73pANasFVOphiNza5qyfyek 4NWV4XIvlYKVO12DrjHzkCXHbGqwYe2BbntLtFXvxt5qh0LzBQUoQAEKUIACFLhtBBiUuG121fAs aOiCXXh7oxKY6KwrRlrsDzB32VbsP12LprY2tLW1obXBgtP7t+KleT/ApEWvKQPyjZ6KnUVre5xm 0GgcrVyo77WgSb0S72hDk5ht4OkXUChuAREj5K9yHdNizOw12Kp8bYzCRfFI3nUGDa1qJkBHWxOq 929CcvQULDvTp6+U+7bzrReS0+QhMS7gwKo5eGLSEqzZWw5zdQNadRxTPJpORK9YwZgQa73VYF8R 9tZa6916ptcDluptRXdZYCwWL1e23blvKZK3VGn2aSsajmzC3JQShE5+Wnd154V9aRv2vDrQ0aq0 U9FW5d+mWpjN5di7dimeif4hZq46iDo5iDYPu0/ugf5Mm2Mwe50mGPD0Yuw63QB7c+tAW5MF+zcu xvcnv4zTTs2tetcCvLSnHLVNjoGijiYLdq1dD3lIWGMKTJ707g+dj9dKUiEup3GhGPNmuglMTDBi ugxRh12FJ6z7og21py32AJ0m8Hih8AU8lbIbpxta7QGljlY0nN6N5EliPAsl0LhteXdT8EbCGFWF lVMXYLPWp6PVGvxZD/kOEJ3eKGg9gRUzH8cj0Yuxp9Z+HIsq9O1Yb8L+tUqg9OH0DcjS9PKIWrIZ 6aLJXtC7jSMKS3Yqzp1ncvDMzGzsrW6CfeKRDrQ2nMGeZc/hifnbur2tp/WdbDwb8Ri+n1IEp6rZ myqfUYACFKAABShAgUES4ECXgwTPzXoqEIgJi/fgvQm78VLGNlS1t8NS/pr8q59DACLnb8C2dfMR 1c23qeq6MavysaTwOSxb9zwOrFOXah5HT8XWo/lOvSTU90OxYPebaE15Hlss7aja+jNM3aq+p30M gHFypO60f9pU/fpcXEiejcT+jTlYc6AOnZ+fxb51Z9HdrJ+jjclYv8h6X7sXhYtasAKTd7yMM51n sXHWD7HRum76gY/kKUq9yMrrpFFL8pFZvhgFdZ2wFLyApwscswhf9Btsm3UGk84ot/c4vuv4qm9t Q83rPNbO+iHWqi/1HgMexOTl+di2VGe6WG16sQ8Pfo7kedtgaT+PLemJ2KJ9X30eEI0458b/eQ3K C19G+SY1kdNj+Dzs3plim63F6V2Xl4Exa/H2AeDZ+cW4IHoxpQTjUEkGomzdZMSV/GQsyQxHecEF fLbvH/C02tjEYJ1x9nFe5MBjRxbmrjuJ9qptSJu2zWV7YsHo2DUo3p3WQ6DxQSzeugGmZYtRkJ4I p90v5xsQ+SKKRVmdttJ6ugQH5OjQeWw8UIclUfYyiqmAe3usN+zNwkoRCQlIxqvOwc1AI7I3JWNv eqlyG8e0t5CtCVoI5+KCdqRmHsSFuoNYO/+gflsKnweT4x0/mtq14vQ+a+Cr6lXsr03DejHwJX8o QAEKUIACFKDAEBFgT4khsiNYjO4FxKwBpTX/hZP78pA5axIcZjsIeBCRkVOxaON2HD3zf/D2Vs8C EvIWA0Mxe3clju5IxbTIB5VbRRCAByOnIn3Lmzhfs8vNN9fW8gZGYenB/4Oz+zZg0bRIiNkWlR+R xyTMyszDwao/4dAS30+jqG7J48cxUViw9S18cOYwdm5MxrRIbXmBgAcjERk7E+my4x/xwcGNWDBB e5Xp4ZaCZ6H45G+QPi0cynwlAXjQOBMxAzFDibjIO1qJkrUzEWubLUXZ/rrCU3h702QEe1olbdvQ 5uVp23DLJdpGJGJnvYit+ypwvuYcinsKSFjzCozKwKGaUyiR95/aXsUF74PyvssUbbZ+P5Y4RAeA qPTXsTVzJmJtbdxpnZObMd3tRa1+ReQLZuvtVZ2WbZibUQLHmUUDEbPqTRzcOBNG9cAYHY5psROc phQVgcdd+KDqTdcyjg5XnA78Dh+UpCHGg0Ajxui1gdEIj52JdYUV+P3RlTDp5BMcl4L5kQHA6ElY N18nGNebY712N15cVyOwMWvnSsTptL3AuJX49SxlsFG92zhCp2/Gu5bD2Cn2n60diihNOCKnJWNT YQVqxP5ze3wFI27RPMhVi12DBc7RGP3dy6UUoAAFKEABClBgwAT8JEmSBmxr3NCgCai7WTyK366u Lty6dQs3btxAR0eH7beurg4zZ84ctHIOzIYt2BD+PMQdCuLbe35rODDq3AoF+k2g9QBSY3NwBj6Y trPfCsmMKUABClCAAhSgwNAUOHr0KCIjIxEYGGj7HTVqFEaMGAF/f3/4+fnJv6L04rmvf9hTwtei zI8CFKAABShAAQpQgAIUoAAFKEABjwQYlPCIiYkoQAEKUIACFKAABShAAQpQgAIU8LXAyGNHj/k6 T+Y3BAXU2zdE0dTbN7S3cIjbOMTvpU8vDYPbN4bgDmKRKEABClCAAhSgAAUoQAEKDILAH37/B/yl +S8Qt2yov+qtG+rtG2qx+uP2jZEzZs5Q8+fjHSygBiXEoxqUcDemxB3MwKpRgAIUoAAFKEABClCA AhSggEbgR0/8iGNKaDz4lAIUoAAFKEABClCAAhSgAAUoQIFhIsAxJYbJjmY1KUABClCAAhSgAAUo QAEKUIACQ01g5FArEMtDgf4XMGL9hY+wvv83xC1QgAIDIRA8H8UX5g/ElrgNClCAAhSgAAUoQAEf C7CnhI9BmR0FKEABClCAAhSgAAUoQAEKUIACngkwKOGZE1NRgAIUoAAFKEABClCAAhSgAAUo4GMB BiV8DMrsKEABClCAAhSgAAUoQAEKUIACFPBMgEEJz5yYigIUoAAFKEABClCAAhSgAAUoQAEfCzAo 4WNQZkcBClCAAhSgAAUoQAEKUIACFKCAZwIMSnjmxFQUoAAFKEABClCAAhSgAAUoQAEK+FiAQQkf gzI7ClCAAhSgAAUoQAEKUIACFKAABTwTYFDCMyemogAFKEABClCAAhSgAAUoQAEKUMDHAgxK+BiU 2VGAAhSgAAUoQAEKUIACFKAABSjgmQCDEp45MRUFKEABClCAAhSgAAUoQAEKUIACPhZgUMLHoMyO AhSgAAUoQAEKUIACFKAABShAAc8EGJTwzImpKEABClCAAhSgAAUoQAEKUIACFPCxAIMSPgZldhSg AAUoQAEKUIACFKAABShAAQp4JsCghGdOTEUBClCAAhSgAAUoQAEKUIACFKCAjwUYlPAxKLOjAAUo QAEKUIACFKAABShAAQpQwDMBBiU8c2IqClCAAhSgAAUoQAEKUIACFKAABXwswKCEj0GZHQUoQAEK UIACFKAABShAAQpQgAKeCTAo4ZkTU1GAAhSgAAUoQAEKUIACFKAABSjgYwEGJXwMyuwoQAEKUIAC FKAABShAAQpQgAIU8EyAQQnPnJiKAhSgAAUoQAEKUIACFKAABShAAR8LMCjhY1BmRwEKUIACFKAA BShAAQpQgAIUoIBnAgxKeObEVBSgAAUoQAEKUIACFKAABShAAQr4WIBBCR+DMjsKUIACFKAABShA AQpQgAIUoAAFPBNgUMIzJ6aiAAUoQAEKUIACFKAABShAAQpQwMcCDEr4GJTZUYACFKAABShAAQpQ gAIUoAAFKOCZAIMSnjkxFQUoQAEKUIACFKAABShAAQpQgAI+FmBQwsegzI4CFKAABShAAQpQgAIU oAAFKEABzwQYlPDMiakoQAEKUIACFKAABShAAQpQgAIU8LEAgxI+BmV2FKAABShAAQpQgAIUoAAF KEABCngmwKCEZ05MRQEKUIACFKAABShAAQpQgAIUoICPBRiU8DEos6MABShAAQpQgAIUoAAFKEAB ClDAMwEGJTxzYioKUIACFKAABShAAQpQgAIUoAAFfCww0sf5MTsK+FzgT3/6E44dO4a//OUvPs37 29/+NmbMmIHHH3/cp/kyMwpQgAIUoAAFKEABClCAAhTwTIA9JTxzYqpBFDh06JDPAxKiOiLIUVZW Nog146YpQAEKUIACFKAABShAAQoMbwEGJYb3/r8tat/W1tZv5fzyyy/7Le/+zLi5NAl+fn7IM/fn Vpj37SRgzvODn18SSptvp1KzrP0vcB31ZXlIjgiRzxkhaWXovomYkefnB7+k0h7S9a3kw7e9Doxv 3/YO1x5cgWaUJvF8Prj7gFunAAUGWoC3bwy0OLfXJ4EtW7b0aX115VWrVqlPh8zj1bI03De3GIje jmpLFoxDpmQsCAUocLsKNJamIT7lDWDiQizfHobrjb2ryXVLPhITX0Zj4iGYi5IQ0rtsBm+t5jKk meaiImw7KiqyYAwavKJwywMhcB2W/EQkvtyIxENmFCXddi12IJC4DQpQgAJDRoA9JYbMrmBBhrdA I8oKihWCmjxUsAfE8G4OOrW/3mxGaV4y0sq6/55bZ9U7YtHV+jIUZCYin8eG5/vzeiXyU95AS3Qu KupLkZ+Vh4L82zCg4HmNh0RKttUhsRt8WIirqC8rQGZiPnj68SErs6IABSigEWBQQoPBpxQYNIHG SpQeB+IyMjAHLcgvq8T1QSsMNzwUBa5W5iFl9Ru4OkwbRn3ZXCzdfZzHhTeNs96MUpE+Ob7PPa+C jFmobJbQeDv2khAGIUkoapTQXNn/vSTYVr1ppP2VNgjGrEo0S40+6CVRj7K5S7H7+DA9+fbXLmK+ FKAABTQCDEpoMPiUAoMlYCnLx3FEIykzC0lxQMvmIlRcHazScLsUoMAdIXAdaLkjKsJKUIACFKAA BShwJwswKHEn713W7TYRMKMirwaITkO8MQLxaQkAilFWyajEbbIDWUwKUIACFKAABShAAQpQoJcC DEr0Eo6rUcBXAtcry5DfAsRlJcldrMMS0zBHhCUKyuDxmHSNRUgUI+ZnVsA1lHEVFZliJG8j8i2u pW4sind972o9KgoykRQfgRCRr58fwkxpyCur1+R/FWVp4r2QbmYBaURRokiThjJNwcQ913lp8YgI UfL2CzMhKbMIFi97xzabSx3zCRFBnTyUmvXHXXAY8f9qPcry0mAKU8oQEpGIzILKbmccUMptQphb E9XXcYT95kpxP7LVMiQCiZkFMGs81LX0HtWZVsalHJbfPpwyTt4fYp8kuZtq46pZHn9B9RX7Lr9S 30TO1MlC7I+0vDLUuymjXJ8ku0NIRDzS8vTtPDfTqz2g7DM/PLlaeX/1k9Y2I88+07s2qJoqs9c0 o7IgE4nW2Sl6qrsohXd1UvJPMoVZ91sIIuLTkNfd/tCjuNqoHJO2fMQxmYTMggo0Ou8nc56yLTua rc30esae5lIkiXbvlIGDpVM7Us8ZXh3WjaVIls8LJuSZtWv21dHxmLQRO9RLjB2QhzTVWD0OtMWw rej6pPu26ppeLLlq1pwb/MJgSstHd03Du7anv015qUfneO36nvp7mk7J29tzuFqiq40VKMhMsp2/ /azn/opG+85yaJvqivLjdajbVc//Yn1xXna0t7YZvyehnH5W40nrud/PL89lfAmv9431eIl3PvfY q+BQ6h5feLVPHY8Hx7KHICIxEwWOGLbN9/Vz1JYRn1CAAhTQCkj8GRYCXV1dkvi9deuWdPPmTamz s1O6du2a1NbWJrW2tkpNTU1SQ0ODVF5ePuQ8Vq5cKam/viqcmp94HNyfK9KxDEhAglR4US3JFelQ qlgWp1mmvqc8Xi6ZIwGQcs+pyy9KhXFineXSqWvqMuvjtVPScoj3IMXZN2J987JUMgcSDLmSLSvp nJQrpzdIExMypOzt26Xt2RlSwnglj9jcakndxLVT2ZIBkAz2gjhu/GKhlCDezz5lW+diyUJ5HYxP kDKyt0vbty+XUuMmSgbMkUouO67u/tVF6VhGrFwnGCZKCRnZ0vbt26XsjARpokGU0yDF5Z6zbVPN 51yueG+OVHLukJQ6HtL42FRpuVq/iQYlv9hc6ZxaQXVF6ZpUvT3BWu5YKXW5Uu6F1nXGpx6SHItu NZxTIp0T9TVMlBY6rYPx2a77yrY9+5Mr5wqVui2MlssXvVCpq6hv4bkrtoT2upVICw0GaeLC5fJ6 yxcKW8Vk4SHHUoqVr1VvlxJks/FSbKrTOuNTJcdVrknnchV3w8SFNrs5seMlQNuG5Jy9NLNVxeHJ xWPCeruUkaC0v4QM5bVYduyiJPWmDdqOn2PnpNw4g2SYqGmLcl3EMbFQKrEdk2qRvGwH185JubGK vbo/sjPmSLHiWHJ3zKib0jza95GmzYrjRi2r2E/asl48Jpttz0hQ2nRChvLaaqbJWuepve06tJbL JdIc0Y6cyu1gGQtpvPWcIY7F8dZ2N8flvCNJtvaq3ciVU1K27BUr5WratuQTx57qdUxp2+p5SXPO M8wplLS8Omjyop7aqrKevRxuzw2GhU7HnVjTy7bnrpDycmsZ0PM5Xk7uqb+n6eRMe3cOd3CA5pyV Giu3tzmaDxFb27R/uMlbVpdjvHou3y7ZzpMO9helY+LzYXuG/DkmPqcz5Ndi2TFNm+jFvrmofAaJ z2Xb59DyVPncYJiTLS0Xn8tefSZ6uU/Vz3nxGXUoVRqvsbR/jkKK9ennqMzPfyhAgSEqIK4BxbWg uCYU14biGlFcK4prRnHtKK4h1evJ/qgC+iNT5jn0BNRGxKCEsm+GTFDiyiEpVfzhnuD4R++VYxnK Bej2at3GpP5Rpb0+qN4uLloNmkCFsqpy0TZeGi8uhOaUOF48XzkmZYjtL7cHDSSpWtq1vESqs1/v WstQJ+2SLwwzpGPqe9dOSdnigtagf4GtlilbjZSoAZLoXMmlZpfrpItqvrq1ti+s3q5cGMdmHNL8 YWh9/0q1tD1BBBgMUoatoMp7yoVQtBQbGydlOFzFifevSKeylXyjndzF/pCDLwtLnLZ3xXqR7rwt 6x+IBoNkEEEOh3pdkY4tVwIgrkEiex2dn6n7XPtHtzaNUjeDZDA4XdCJmp3KlqLFfo7e7ugu9r+8 /1wvwK+cy5ViRUAp45hkK/7FQilO5OMShJGkK3V1Dm3LezNtbVyfK/XTBuKsabxtg5IkqZaiHSRs r7bXT87ymlRXaA2cpR5yeM/bOl0sjJOP41THyI7c1urqtFfjrvW1LbHtowRpe7VtT9jevngoQ95P iHXatyLFuVwlKKE9UdjWdPfEftHsUMIeghIGw3hpoXMUp26X9WLONVjqEpSwXdDGStmnHOvpE0fN RZhuvQwGabzL8a2e8yAtV89h7tg0y922VTlN9+eGU9nW4GOfz0GaArk89eIcL0mSp/6ephPF6e05 /PIh5dg0JGyXXA6Hy8ekkmP2vase587N//KhXGn7KXs6lefKseXyed75/C+pbccl8Kqs6e15QXzG brcG35zbuiRdlA6pAXevghLe7VNbnaJjpdi4DMegpqiWLUAYLTk1RWtA0fvPUdWZjxSgwNAUYFBi aO6XO65UDEo47tKhEpS4WKh8k+lyodnDhZbuH1vV2+ULT+c/qM7lGuSgxyE5aKEJKIjv3k4tly9a PP2DW/2jU/tHnkvgwUZdLW2PdroQVi9stBe6tvQePlEDKc4X2NrVrT00nIM96sVCtM63P/Lquu7W ehhcL6zkddTAkkOd1G+ttD1gNAVUL+4XOvew0KRxeqruc5e2Yk1nq5vzX5Dy+2pPGsfeKOq+09// ao8dTZuxXuQ6tzGnoopLDmXfe2Xmmot2iVo/bdtT31frYQt+qW+o5XBqK6qlS5DOtt5FqVAOwGn3 n/d1Usrs+ke9bTMePFHqBin1kOOFun3Va9KpbCUI51L/gQxKOAQ21dJdk04tV3qK5DpFIRUba3u8 VicVLhR1iJUyRPcXpx9fONouwpwDs+o5yU1bVc+RBucKOJVR+7K7tmorB9y0C/Xc4FBO79uetjze PNc7x3vq72k6qbfncNv52c252Kmi6nGud85wSqq8VIPmDvbiLfV87twbTLzn/b4RQQzRQ8LteVSU Q+695ni+1i2zBwv19qm9TtFSrmvXQDlXWy80TU9H8Ybavr37HPWgoExCAQoMqsBgByU4poT2XhY+ p8CACjSiUswDilSkJYY4bjnIhMQ0A9BShAqH+6odkzm8MpqQbABqyiyasSjMqMxvQVxyPJLi0xCN 3ajQDNxgMYsJAzOQaAxyyEp+cbUe5soyFOXnIystHvHxETCln3ZJZ0zKQgJaUFRhdpyu0VKJohog wTpWhryiuO83FsDuV5BTatGMT+GSrdsF1y0V2A37GBy6CcMSkSYG5jheAYvLUAoGJCeaoFNjICge SWkAWsxoVNdrtKCsBjBkJSNeb6WxRsTHiTpZUO9cmOhEGMOcFwIIi4BJLK5v7HYMC501e1gUjbR4 o06aMETIGwTsO6kRFqViSNavGIxKxWBRKxZhRIZoY3k58pgIbm997ouZTul7WuRVG9RktjAtHk5H nvXdMMQrDQgW9R71XtQpwpgBA2qQl5OHyma3WpoSOT+17iMsR1riWOc3ra+DEJ+UBYM4Bs3qjnKT tB8XJyUadY6pIISZxIHYgsZm54EvrIW53ojStHikvxGE1EOlKEh0PWD67uhBxZMSoXcaDAozyWP8 tDQ29+p85XbL8sDGOu+q5waHQ7UP5yCdTdgWeXiO99Tf03S9PodbzChqAaJz0vTPxbaKefLkOpot lagoLUB+jhg/KR6miCnY4cmq2jS9OC/UV8qfYMhK0jtXAwiKgEk9X2u35clzD/epLStDMhJNeh9s 4uMwCcrHod7nlJefo7YN8gkFKEABfQEGJfRduJQC/S9gKUO+iEmgGHPvsw/eJwYw9PO7C1M2i8n8 WrC5SG/wSr3imRCfZQBOl8E2zqPFjNKWOKTFhwHWoEWpWR3t0gJzaQuQmgiTw/VOIyqy4hFyXySe nDIX6XkFsDSORYQpE2kLo103bA0AtGwugz1+ch2VpXmoQSoyk7QXGUZkFhUidXwVdqfE4L6QCCTn ldrL65q7y5Krzcrwn8Yw/ctJZYUQhMl/1DXjqsu1oAndripbnEazGpRoboYIxbSsftI2WKCyj9R9 9gh0YjVKMcJC3Fz0AvJmaq7bYwQuNe3NgjCEuGORN3jYHmxBM5qVimkGb1PrpDw+4lyxsYnIK81G HI5j9ZRxuCtMDA6qM9BiX8x6VW0lCOVZG7RvwOgWC7YLbNvFdC/qNDYxD6XZccDx1Zgy7i6EicHj Khq9uLi17qM4I8L0rxuUyoSFyUGuluarPm5PdquenoWNdTiJ2JKrxW52PRABNKIoMxkpb7RgTkkl ihzOFbYs0HdHe15un4WNVY5J5wT2CvjWtqdzw2HNhWAv2p5zNRxfe3eO99Tf03S9PYc3N5rlKW7F LFV9+bluKUBS2F0YFzMFM1KWIr+yHlfDjEjOyoCY+8qrH6/3TTMa5dihsfvPIa8KIRJ7t09t2ZvC 3H5GiTTKx2GzTvDcy89R2wb5hAIUoIC+wEj9xVxKAQr0t4Clsgg1MGBiXITbPwqa60/jw+IyVOYn IUn/b36HYhpNyQB2oNJyFcmJYyFvIzrN+m29EeLtllIzLDkmGK3f8MzJMWn+GL8OS14yZuxoRELu MeRnJiJCs93m0kpsfqPGYZtACBLTUoHDO1Ba+QrixTe6182oEF9ppSYhXrO+WDEoIg1FjUl4paIU efl52L06BW+szkLC9gqUZel92+q0OevLoCD1akH/fWXpWNvFZXepXN8z2K9KrW9GL8xGmsndFb9I 5H4/uuY/hJZEL0R2msltG5Rrpqn22HjxrX8WzKVFyH8lH7uXzsDupbHIOOb6LffAmXnXBr3Rd25m 3tVpLOLFrCRZZpQW5eOV/N1YOmM3lsZm4FhpAXQ6BegXbawnbV0cXEG9bO/6m+3/pWEwxgfBcrwK 5qIyWJKydHsriEsjnzj2f4X6dQvetT13RenNOd5Tf0/TKWXr7Tncs/Xc1L+5DGmJS3E4LAOFpa8g 2RSiOWbMuP7ybsjfFbhZ3d1i7/dNkDhcffTTm33qxaZdPw49XLnXK3qYP5NRgAJ3kgCDEnfS3mRd bh+B65UozRP3BGSjoCLPbVdUS74RMS8Xo6DsFSSlaXsc6Fc1yJSE5diBHRUW5CeGyd3zo9Pi5alG xVW2MTED2FEGS2MWwurNOI0EFDpcaNejIr8KiN6OvJxEOH8f1WztpeC89bGJacg2FGNzmRl5iYlA ZSk2txiQnZaoCXho1xqrfGucmIn85gq8kjQDm19ORFZEPQrcdlNX1g8aq1whm+sbAZM7k2Y0mkX6 ELh+gXsV1116T6hlU9cT05ValwUFQfQPaTYmIyvLTXdbdfXb6jEIQUrFkJyVZW0jnlYgBKbkHJQm 56DAUoTMxHTsnpEMY50ZmaLRDIKZ920QaJYbgv6VQaPcgAyw9cjpS51CTEjOKUVyTgEsRZlITN+N GclG1JkzXY4xxz1g3UeHzWi8nuy+t0Rjozw9YXSIfl0c8xxar4xpRagIuorEl19GYtpYVBalIcJd NXrtOLTq7HVpCCpxIwAAIABJREFU+tL2XDbWu3O8nI2n/j2k6+053LP1XCrssEBMBfpGC5BRJKZ+ dYqYX72qufXRYTX3L3qxb5RgRD0a3X6Euf2AclOOPuzTq9301mtWzisQU4O7bNnLz1GX9bmAAhSg gKMAb99w9OArCgyIwFX5oh0wpCXCze2ccjnEvfJiuILjRZWe/bEUZISIO0D0hqivRNFpxzEGxhrj MQenUWZuhKViNxCXDHFnh+2nuR5mcdeIbtdisY5zLwnrmmIsBnHryO5SVF69isrS3eLGXzdjFdi2 Jj8JCklEXn62fKvKbtvgBY5ptK/GmhKRCuB0fhnUG1G078vPmytRelgM1+F8a4p49zRKK5VbQFzW a6xAkVgvIRFG9a+wCCMSxfAepZXut+eS0e2wIAJGpWKodAvZcz3GGtOQly/GDahChTqAx2CY9aIN lpY5jYOiVlcEDfNbxAEKkxqZ80mdxsKYlgeFS2+8E7UA6qMR8WkicrQDRRVuxmTAdZgrS9ECx2Nd zWHoPwbBmFWGstxYtLyRjvi0Ug/Odd46Dn2Fbkvok7Zn3UJvz/EOBfTUXz9db8/hyudXD+d+h3K6 vmisf0NeqHe7kRjrosx1le6XeL1vQmBMFJ/qh1Hk9nOoUvkc6n7L9nf7sk9Pl8JtMSqKoHwcGnWC El5+jtpLy2cUoAAFdAUYlNBl4UIK9KeA9aIdBmQlxWu6jupsMyweaeIm19P5KPPownEsTImp4goa RfkVOG1Ihkn75X5IPJLnAIfNBagoBaKTjNDGJBASAZNB/L3k/IfKVZjzkpFjEW/q/5gScxCNYlSU laGi2M1AlI1m3QH/rl9VLrgSurnH37bVsYnIyo0Fal5GZmaZ6wXMVQvy07JwGLHIzdLvqXE8JxP5 FqeLvKtm5CWn4zgMWJ6TbHcJikdyjnV7ORU699ZeRX1pFgo82j+2Wnj9JEQZJANmS72P7m0PQnxy DmJRg5czc1ChjqGhKdnV+lJkaSp21WKGM5tIruw/AyJCrN889oNZWJgIfACVooeMmx+P2qBm3ZYd Ocgqc85PDLyYjB0tQEJepr0Xk9d1ugqLWW8w1+uQm7shAiqXpkguT43Jr2ChASjOTHZts+JO8rIs ZK2ugWHhK0jWHusuOQ3lBUEw5VTgVLYITKTAlKwNTPjGcSBr70lb9ao8Xre9bnL3+hzvqb+n6cRA Bb08h4ck4ZXuzv3NFSjSO5FpOMIiFsqvXAKSjaVISxMDP+v9hEE5/VSKsYkdf3qxb8TYMvI4zG4/ h3LQzUet4/bFK6/3qTaL48jJzHc5r1815yE5/ThgWI6cZIe/Emwre/U5aluLTyhAAQroC/D2DX0X LqVA/wk0lqGgGHJPgsQeR9gOQ6KYBeD4YeSVViLT2EMQQ/y9Z0rEHBRj9+4aGHKzlFkebLUJgSkp DkjfjM2IxnaXmRqMSM5fiPyUN5BiikBRUhISx16VAw3Hx2ah5BUzUpaK7050foxJyEp4Genp6aKr AQodumBY0zdXYsqTT2J87BwkxotbJJpRX1GGsuMfArG5eMXNHz+OWwuCMacUh+rjMXf3XDxSNhEJ opwRIWi0lKKsuAqfYLw8kn+O3nD6mINd+SYUxUSgICEJSYkRQH0FysqO48MWA+Jyy5DnNBuFMasU JWYTUjbPwLgi+/aa6ytRWXEYVZ8YkFud71hMX78ympBtADZvToaxMRmZYdfRaHoF+Ulql45ebNCY hdISM0wpmzFjXBEmWj1CmutRWVmBw1WfwJBbDbVm1+vzEBNjxsS4RCTKAa1GWErLUCzSLSxBpsbN 12YhpiQk4DCOp8cj0ZyMxKBGIK0UDnfUeNIGNUzZJVlozHwEYXmpSEo2IqzRgtKyYlR9AoxPPYQC p1umvKvTddTnxSDGPBFxiYlIEtOw2PI3YGGJJuChKZPL05AkFJXlojlpNV6OuQ/5sdayNtcrx+WH LTDE5aKsKEnn20yX3IbwAjEeQSlKGk1IEYEJAOZSERz0keMA1tyjtuplebxre91l7u053lN/T9OJ svX2HO66nnpsNZoLUPrGhzCVXJZnjHAnEJKYhdzYN7B685OIqFSOJcifG40wleQjLSUFm11WFp+b CcDh40iPT4Q5ORHK6Ue57c3rfROSjPxDFbDMLcbLLp9DFoRk5eMVcwrcfdS6FA/e7lNNDnN2Id9U hJiIAuvnqPg4VD6TWwxxyC1zd3up95+jmq3yKQUoQAFXgUGdEJUbHzCBrq4uSfzeunVLunnzptTZ 2Sldu3ZNamtrk1pbW6WmpiapoaFBEnPUDrWflStXSuqvr8qm5iceB/rnYmFC93OUOxfoyiEpFZBg yJZOXVPe7H7+9YtSYQIkwCBlqyto86zeLkXL+enNuS4SXpPqDuVKqbHj5XJifKyUmntIqrsmSd1v 1/4+Ug9JV7TbVJ9fqZZKclOlODVvGKSJcanS8sJT0mU1jcePV6SLx3ZJGXNipfGiPoBkmBgnpS4v lE65yUyZX12Z+/1KXYm0PGGiZJDXHS/FzsmQdrlbUS7TFcUlTl1H2d6cjF3SsYvOtbXOa+8y371a ue7mvVfTuD5ek8ts3y/Zx+zb1dbNdU373PK551zfvVJ3SMpNjZMmGhRHGCZKccLj2EWH/Xjt8ilp V8YcKW6iQWkbUNy2H6pzSGffgjdm9rXcPbtybru00Lptw8QEqbDONaXaRt22QcneTmWLy6ek7alq G1LaY67b+ojteVqna9LlU6J9alzHx0pzMrZLh+rs+821Bm6WXD6nHDse20tipyv7SW+nu9mMJLlp u5dLpDniWHHKS/V2WmzLXX1/TonjQem+vV6UShYq7Wt86iHpouQrR+/qpamAUm+3x7ItpcMT923V TTlsa3d3bvC07dkyc/PEm3O8p/6eptMWyftzuLK263rjY+dIGbuOSdpTsdr2XNrmlXPSrowE6/nO IE1MyJB2nRPHZHf75op0bvtCzTqFkuPpx/t9o5x3NeceUQ75M+iyVDJHnIuVzyqtmPvn3uxTkYu2 rlekupLlUoJ6bpHPU7v66XPUfQ34DgUoMLgC4hpQXAuKa0JxbSiuEcW1orhmFNeO4hpSvZ7sj5L6 iUxdQxVccqcJqLtZPIrfrq4u3Lp1Czdu3EBHR4ftt66uDjNnzhxS1V+1apWtPFu2bLE978uT/siz L+W5U9ZtLk3CuBQzsk81uvQ2GAp1NOf54cnVc1ByuQzJfehgMBTqwjLoC3jSBpU0h8X1NXJ67K2k vx0upQAFKHD7CpiR5/ckVs8pweWyZK96WfFz9Pbd6yw5BboTOHr0KCIjIxEYGGj7HTVqFEaMGAF/ f3/4+SnTxYs8xHNf//D2DV+LMr9+FdAGE/p1Q8y8FwKNqBCjRBpykaTpxt+LjLgKBXopwDbYSziu RgEKUIACFKAABQZNgANdDho9N+ypwL333utpUq/T9WfeXhfmdl/BUob842KojESncSxu94qx/LeN ANvgbbOrWFAKUIACFKAABSigCjAooUrwccgKJCUlwWBwP+tDbwsu8hR588cXAo0ozctDjSEDeWm3 7RQAvoBgHoMmwDY4aPTcMAUoQAEKUIACFOiDAG/f6AMeVx0Ygccffxzilz9DT6C5LBM5lUG4XlGK Nz4EFpbkINE6K+TQKy1LdCcKsA3eiXuVdaIABShAAQpQYDgJsKfEcNrbrCsFfC5wFcU7dqAS8cg9 ZkapR1N6+rwQzHBYC7ANDuvdz8pTgAIUoAAFKHDbC3D2jdt+F3pWgdt59g3PashUFKAABShAAQpQ gAIUoAAFKOCtwGDPvsGeEt7uMaanAAUoQAEKUIACFKAABShAAQpQwCcCDEr4hJGZUIACFKAABShA AQpQgAIUoAAFKOCtAIMS3ooxPQUoQAEKUIACFKAABShAAQpQgAI+EWBQwieMzIQCFKAABShAAQpQ gAIUoAAFKEABbwUYlPBWjOkpQAEKUIACFKAABShAAQpQgAIU8IkAgxI+YWQmFKAABShAAQpQgAIU oAAFKEABCngrwKCEt2JMTwEKUIACFKAABShAAQpQgAIUoIBPBBiU8AkjM6EABShAAQpQgAIUoAAF KEABClDAWwEGJbwVY3oKUIACFKAABShAAQpQgAIUoAAFfCLAoIRPGJkJBShAAQpQgAIUoAAFKEAB ClCAAt4KMCjhrRjTU4ACFKAABShAAQpQgAIUoAAFKOATAQYlfMLITChAAQpQgAIUoAAFKEABClCA AhTwVoBBCW/FmJ4CFKAABShAAQpQgAIUoAAFKEABnwgwKOETRmZCAQpQgAIUoAAFKEABClCAAhSg gLcCDEp4K8b0FKAABShAAQpQgAIUoAAFKEABCvhEgEEJnzAyEwpQgAIUoAAFKEABClCAAhSgAAW8 FWBQwlsxpqcABShAAQpQgAIUoAAFKEABClDAJwIMSviEkZlQgAIUoAAFKEABClCAAhSgAAUo4K0A gxLeijE9BShAAQpQgAIUoAAFKEABClCAAj4RYFDCJ4zMhAIUoAAFKEABClCAAhSgAAUoQAFvBRiU 8FaM6SlAAQpQgAIUoAAFKEABClCAAhTwiQCDEj5hZCYUoAAFKEABClCAAhSgAAUoQAEKeCvAoIS3 YkxPAQpQgAIUoAAFKEABClCAAhSggE8EGJTwCSMzoQAFKEABClCAAhSgAAUoQAEKUMBbAQYlvBVj egpQgAIUoAAFKEABClCAAhSgAAV8IsCghE8YmQkFKEABClCAAhSgAAUoQAEKUIAC3gowKOGtGNNT gAIUoAAFKEABClCAAhSgAAUo4BMBBiV8wshMKEABClCAAhSgAAUoQAEKUIACFPBWgEEJb8WYngIU oAAFKEABClCAAhSgAAUoQAGfCDAo4RNGZkIBClCAAhSgAAUoQAEKUIACFKCAtwIMSngrxvQUoAAF KEABClCAAhSgAAUoQAEK+ESAQQmfMDITClCAAhSgAAUoQAEKUIACFKAABbwVYFDCWzGmpwAFKEAB ClCAAhSgAAUoQAEKUMAnAgxK+ISRmVCAAhSgAAUoQAEKUIACFKAABSjgrQCDEt6KMT0FKEABClCA AhSgAAUoQAEKUIACPhFgUMInjMyEAhSgAAUoQAEKUIACFKAABShAAW8FGJTwVozpKUABClCAAhSg AAUoQAEKUIACFPCJAIMSPmFkJhSgAAUoQAEKUIACFKAABShAAQp4K8CghLdiTE8BClCAAhSgAAUo QAEKUIACFKCATwQYlPAJIzOhAAUoQAEKUIACFKAABShAAQpQwFsBBiW8FWN6ClCAAhSgAAUoQAEK UIACFKAABXwiMNInuTATClCAAhSgAAUoQAEKUIACFOhW4MrXEpq+kNB+XcJX1yV03uw2Od+8wwRG jQBG3+WH0UF+CL3fD/fd7XeH1bB31WFQonduXIsCFKAABShAAQpQgAIUoIBHAre6gD83d6Ghpcuj 9Ex0ZwrcuAV88ZUk/176KxD+bX9MHOcP/2Eem2BQ4s5s76wVBShAAQpQwCZw69Yt1NfXo729HV9+ +SU6Ojps7/EJBShAAQoAgYGBuPfee+XfiRMnwt/fd3e5SwB+99EtfPmNeKb8XL4q4U9Nt+SL079+ 1YXrN9R3+HgnCgSNAh64xx/33+OHx0NHYNxYP0gS5CCVCFL8+HsjMJzjEgxK3ImtnnWiAAUoQAEK WAU+/fRTfPDBB4iMjERwcLD8B7f445s/FKAABShgFxDB2qtXr+Krr77C22+/jZiYGDz88MP2BH14 9ufLXbaAxM0u4Nyfb+K/Lt6CPUTRh8y56m0hIIJOn13pwmdXgD9+egs/DB+Bn3xvpNxD4v+1dzcw cV75vcd/wICHLKwNCXhxuiCZrUmCG2hNUrvFUlDrbskmSGF78ZUtGVWJtFbjSs5t7Lu5qit1vd3k 7mYbq3WqeG+syta1b211ncpOO61cCUuhNdpAbVoTF3ahNWpwAlmTBHY9hgGuzsw8Mw/D4IcBHubt O9JknrdznnM+5wzx85/znMfc0vPj27PaUrF6gbC0QLEVkqCEDYNFBBBAAAEEMkng1q1b+uijj/S1 r30tk6pFXRBAAIFVFzDB2o0bNwbf1dXVunr1qgKBgKqqqlZ0LjM64scfhW7Z+GRiTpeuTevTn4XC Eea/2fzr+Ipg0zSxFYh6f2hG/zk2p+Y6jx4qzgne2rNxfY7WP5CdPSJ7wzFp2pEpNgIIIIAAAksR MCMkTEDiV3/1V5dyOMcggAACCNgEduzYoZGREX344Ye2rYkv/ucn0Tkkbo7MRAISJqfsvPxM3DCT Ulhtbj4/mZiV6RPW69ZPrZCFtSV7PglKZE9bU1MEEEAAgSwRMHNImFs2CEhkSYNTTQQQcEXABCau Xbum2dloYCHRE/3MH0ox8umcuoeiF6CJ5sPxmSdgQhCmT5gRNOZlnsaSrS+CEtna8tQbAQQQQCBj Bfr7+/XII49kbP2oGAIIILBWAuZv6cDAwLJP99nd0IXmB/8VDkiY2Q15IWAEwl3h+q1Q3yAoQbdA AAEEEEAAgYwR+Pzzz1VcXJwx9aEiCCCAQLIEzN9SMwHmcl/mUaDmNfZ5+Ao0xxrAv9wcSZcpAlZX uBOeY2QqkCk1S7wejJRI3IwUCCCAAAIIpLSAeeynebQdLwQQQACBlQmYv6Um0LvS152fLf8WkJWe m/SpLTA+yegZghKp3UcpHQIIIIAAAgkLmEfb8djPhNlIgAACCCwQ8Hq98vvDE0Ms2Lv0Ddn8K/jS lbLzyJ9PEZQgKJGdfZ9aI4AAAggggAACCCCAAAIIIJB0AYISSW8CCoAAAggggAACCCCAAAIIIIBA dgoQlMjOdqfWCCCAAAIIIIAAAggggAACCCRdgKBE0puAAiCAAAIIIIAAAggggAACCCCQnQIEJbKz 3ak1AggggAACCCCAAAIIIIAAAkkXICiR9CagAAgggAACCCCAAAIIIIAAAghkpwBBiexsd2qNAAII IIAAAggggAACCCCAQNIFCEokvQkoAAIIIIAAAggggAACCCCAAALZKUBQIjvbnVojgAACCCCAAAII IIAAAgggkHQBghJJbwIKgAACCCCAAAIIIIAAAggggEB2ChCUyM52p9YIIIAAAggggAACCCCAAAII JF2AoETSm4ACIIAAAggggAACCCCAAAIIIJCdAgQlsrPdqTUCCCCAAAIIIIAAAggggAACSRfwJL0E FAABBBBAAAEEEEBgUYHp/nN69WSPJlWh5pdfUlP5ooem2I4bOnX4tPpMqcqa9fKhJqVN0Z0kb5zS 4dPBmqms+WUdSp9GcaoZ+xHIcAGPvv8/1qnea6o5q3/4zl19N8NrnA7VIyiRDq1EGRFAAAEEEEhz genRG+q8fEXdgyMamwyEauPxqqisUvVNLWquL1d+mtdxScWfntCt3g5dfu+6RsYmZVHIWJSUq6pm u55qqlNVcVSjv8sEJMzrtrr7RtVUnsCl/WiHvve6T2Mmee0+fbd96+LFtF1o1+77ru536OKZrNIe e7ljszRW3hJt2lqv7Y2N2loetYo9lHUEELiPQLlHB5s8euLhXJV6c1QQOXROU/45ffRhQMfOTas3 sp0FBNwRICjhjiu5IoAAAggggIARmB7Reyff1qWh0GX1PJSAX5O3B9R59nV1XqxV24F2NZTOOyKj Vu5cP6eT53s0Fo7JzKucsRgbVp95j3vnBQ9qGhtV1t+pMVWqoTYmIDE9qsGuLnV0d6t417e0+z4x h3nnS+cVYzV5WwNd5u2Tp2yb2p7frfqU7zvTmrjVp+7OTnWN1+r5Axk0ciSd+1NWlj1Xz3x9nV6s ybUFIuwQOSrw5qjy4TxVi6CEXYZldwQISrjjSq4IIIAAAgggoFF1HD8m322LwqOiyhrV19WpsnBc Q319utE/HBotMNmn86+9oYm0uj3Bqpfz52jHG3o9CiF5yrSloUH1m0tk/jE2Mdyr3r5+DY8vjFjk V7fo0Hda4p5ktPOUTviC4yBUG/eIDNhYuV17GjdHKzIxrN7ePvUPj8toBcZ6dPa1EY2nfN/p14U3 z4ZvZ8nY1oq2E0spKpCng8+v07Mbc2zlm9OdT2Y1/NM5jc9IX1ifqy99IUdf4krRZsSimwJ0NTd1 yRsBBBBAAIGsFZhW/5nj0YCEd4vaDpqRENGh9vUNTWqdvqPuU8d0fsAfvD3Bd/KiNr/SoqoMcrt7 45SORwISRaptO6A9DaXzb1epr9fOFmn6znWd74oaZRDD8qtSvEX19fYhIPWqN1gTg+o4c0q+oXDf OX5Old/arerln4mUCGS8wG/tLrAFJOb0Uf+U/uiHAQ1mfM2pYCoL8PSNVG4dyoYAAggggEC6Coz4 dKHXXCyaV6WeO/TCvIBEeIeUX6qGFw7oqbLwlvFOXb4+Hdmd9gvTN3T+fJ9CEl7V7juk9tiAhK2S +aX12vt0jW0Li4sKFFerab+t7/h7dPG9iUUPZwcCWS9QuU7t1dbl35yG//We9hKQyPpukQoAjJRI hVagDAgggAACCGSYwK3u6xoP16mksVU7iu9XwXI93bJNXSd7ghfvA53dmqjfoVCShU9wKBzs0Lnz lzUQvNXBI2/ZZjW17lZTdfyTTAy+pwsXO9R/ezI43F+eIlXUNKmldafmJ4k9V6M81y/prK87fFuF RyVbdqltd1NMusXrNtF1WX3h2Ix32161by1c/OBF9ox2fE+vW7dohCegtG+zkvWdPqzDwZUyNb98 aPWe0mGfdDLeZJlO+60CmttUTNtd6NDQmF8BObedLekii+V6urlWV8JPwrjde0MTO62+E04yfUfX L53V5esjGvObGz7MeTepftcePVsfM2LFTINy54Y6L13We/23IxOReorKtGlri9pba8L9cpHimDpe Pa6j7wyHDqho1ssvlclnPYXESjbm0+uHfaG1WNPpO7rR6dOV7n6NBJ1Mkb0q21Sj7c0t2jm/00qK 7bdNSvQ7YhUr9nNJ353pfp05elKhGGScvjdxVcePvqOgSNlTevnQ09GnsCTYNrHlYz0xgd/akasv WUk+Duib785Ya0v63Phovn7vSY/qN+aoyBO9/WPKP6vr/zqlV/7Rnl/sUy78+tFvFqj98TxVekNp Tbp/6rinb1+bjXv+6l8u0O894dFjG3JUYF21BuZ05+OAvn1qat4EnBsfLdDBnR7VPxSdsNMq17F/ nNHHcc/AxlQRsEJlqVIeyoEAAggggAACaS9wR0OD1sSWJarbvsm5RjU10WH3w0MaiZvirkY63tDR E75wQMIcFJB/bEC+E6/qjY7RmFR31X/uVR09cUl9VkAimGRSt/su6cSrb2hBkkgO5lzH9drZLts8 DwGND/h04ntn1L+kwRwTutFrTahRpIbt2TwCItR2r5q2sy6079t2kYZwXthaF51PI7bvjF7VW0df 09mu4XBAItgB5B8bVtfZ1/TqmRu6azvD6NW3dPS10/L1RQMSwRSTYxoeHJl3rC1ZdHG0Q29bAQlv rfbtT3Ayy3B5T/t6NRxxMt3cr7HhXl06cVTfiilz9ORmKdHvyPzU0bUEvjv5NWrbW6fgExY1Jt/F bpvTtG5c8IUCEirTU+22gESCbRMtG0vLE8hT00br0m9OHwxOJXihXqDXnitQ48O58wISpiwF3lw9 +eQ6/eUzeYsW7QvPePU/n/REAhJWuqZmr77/RGyyHLXuLdQPmvNDQQYrIGEO8+So9MHc6P8vJD3x 21794Ll8PWkLSFj5P/mkV8f3erQx9hSsp5SAvYlTqmAUBgEEEEAAAQTSVWBMI9a1uDapMuaBEfFr tUmVZVJfcM7GUY3ckWpin6Yw0aULPmlz4z61NFWpWBO61XFR5zuHZH53v+07r6sNByKjMkY73tLJ ntB4jZK6PXq+rV7l+dOaGPTp7ROduh24Ld+pDtUeinPhOHZFZ30lqmt7Uc01pcqf6NeFt8+rz8Ra /L36u64W1eyMPzIjWr9RDUfiJFXavIoTZZQ3HtCRhoBGO47rRGeojlvajmh3MO7hkTde0fpO63Bo KEW0iGu1FG67yiW2XWLF2qSyEik0NCegSLzI/IJ//B0Fp5zwblZz+141Vhcrf3pU3aeOB+cxmew9 r/N1NWrfmi9NX9fFd0xfkmTmQNm/V3WbCpWvad251avLV+zhizglvHtDp477FOz6ngo1H2hXaGBM jdqOHFFA/Tp39LwGTNKSRn3DevqGJ3Q5r2D6cHnlUdm2VrXtqpGZhmXiVocuXuiUeYjNZO9pndx8 RAfiDT9K8DsSpxbBTYl+d/JrWtVa26+zZljQwEVdHGzQbjO5xy2fLoWHCpU0tulp629Bom2zWEHZ noBAnkqLrMPn9PE1azmRTzNKYUb/8C8BdVyb0eD6XLU2rVP7Y7kqUo4qt+SrVTO6sCDLXDU+Pqc7 H07rhz+a0UfePH19Z74eC5YnR/WPF2jj+9EgyRNf9+rFqmgA5aNbAV36lxl9JOlLVR59tdJ2gie8 +sNfyVMwK/+sOt67p//z/qyKfqlAB3fl6zGvVFpVoMNPBPQH79vSsZhSAlZrp1ShKAwCCCCAAAII pLPAdOg2iWVXIWAGQCx8+f2qbHtF+1u2alNxsYqLN2lry34diExIMazO7nAUwFxgWpNLbmnTwb0m IGGyzFdxdYteeLYilP/Ye+q6tfBUkle1ew5qb0OVSs25NjWovX176B++ZkrO/v7oxW+85MFtd+UP 37oR9xBz28Phwzq84P29+4zgCOeUX6jioEH096V8rzExb3MhnWIvv1/lzx1aWtsto+iFUYZI6hHf hfAtBSVqfH5/8PaeUBcoV8MLe7UtGAvwq6+rN9SW4+ORW45UvV0NwYCEyS5fpVUN2t2+M3rbQeQs 1sKoOt46Hb5Vp0LNB1+y3T6Tr8Jgu3ij7eKx2qpYxYWh1hq5fClyq09F80Ed2t2gqtLQcebWkf2H 2rQlfLqRvQy6AAAgAElEQVRh39/Fn5gwke+IVfTYz2V9dwpV39YSLp9fPb6rmtCErl7qDJmWNGpP SzQql3DbxJaR9WUJFNhSTX1mW1nS4qx+6Lur/3bynt42AQmT5rNZXfgbv97/NJyBN0d19oCBLd/J W1M6cGpKf3VzRleuTen33w3ojrX/wVw9ay2vL9ALNdYl6pyuX76rvWfC6W7O6K/+/p5+9wf3woGP XP3hE+GAhGbV+Td39e33Z4MjQAb/bUq/f9k6R44eeyzl/ipaNeYzeFMdDAgggAACCCCAQEoJlKjY /PId+/Ju086GhXMylO9sVOWV0D3rY8GhCeXSUF/oF2lJtQ0Nik1VXFOjkku3Na5JDQ7dkapihmV4 a9VYH5Oqaouq1BV6pOP4RPBiy/rhN7aoKbke+2jN2EIOdQZvc4jdvCrr3m3aFeeX/bhtl/AJJzS6 YH7LO+ofDM9qUlKn7dHr4XDuNaqplnr6JA30a0gNqinfpEqvNGYCSX0X9NZFqbV5aziYdb9C3dWN UyfDT5oxk5nutwUk7pfOvs9WXu82Pd0Up2cVNmjntosa6PFL/iH1j0rVsYcl8h2xn96+vNzvTmGD dj/XFZpPY9inC+cGNBicSKJEjXvsT9Sx1XWpbWMvH8tJEgjo3Ws5qvulfH11S56qH8xRaVFobonI fA/KUZG5TyI8pUq0oLP64F8C828XGZrRsN+jUhMcNLdkWAfvzNNXwstTH07rD96fs/bE+fSoekN4 86ez+ouhmEP+bUbDu0LnKHgwT89oWu/GHMJqagjEiSunRsEoBQIIIIAAAgikq0D5vFsxxszghdiL pwVVG9Fw8NYNM3S+WCXxftQqLle8WIXMr9BWfqNjCo6VGInOStF39rAOn7UOWPgZiDcso7g8mufC JEvc4uBQUquWPSWR++8nei/qUvD+kCVmn+hhCx6tGZOBp1dnu2K2rdZqAm3n2FViyzQxGgokmO0l ZeGuNqJh6xai8St6/fCV2FS2deuWjxq1tNWp/3SvJjWpoc7Ter1T8pRtU+vep9WwKdLLbGmliY6T Oh0eElP21IFlTWYq2cq7mJWpXrkpg4majCvu92qxtHG+I4s5j67gu1O8o13P9RzVO8N+9QUjPuZO lT2yDZLQvLouuW3mkbOyLIFZ3fErGHiTcrTRzOOQyO0M6z16dW+BntwQneAyVIw5TSk6ueRiRRu/ udie+dtb10fz/+inkZux5h9krT2RGw1mbPDo7P+6/6WtfaSIlQWfqSFgjY1JjdJQCgQQQAABBBDI AIFyVZqfnIOvMV3vX/Az9sI69vdHh6NX1miREcAL08VuKSmOH7iIPW5N1h0c8stVU1+v+vC7pjJm ZMaalDGFTrLMtpu43hX5Ybaktt45/nWfKhdu3as/OnJQbdsrVRS+vgmM9ej8saN69Vx/JIBkz6Kw ulrhm4E01t8XCorZD0i15WU6L60aHhUXW9/9UApvcZb366XBrcFRM/rYmn9YOfrKlvtfwM8vUK4O 77YCEmZuiID+n8+vb779M/3Gd36ujk/mH80aAokKJNIbE82b4xFAAAEEEEAgSwWqG2rl7Qk94vP2 5Qu63tCu2LshojSj+ruLoWODczlsr43eex89SAosMtHgrSFZ00J4i0uCactLzO/AoaEXteHHaNqz WqvlxBzWqlQJnqfQa7v9Jc5kH3cn4l6szzvLYsfEabt56ZxW7nbr3CVrSESlnmqynvRSHp38sqxZ L8ebzHSxvIs3qaH1gBpap3VnsFPnT/mCk2WO95zRxYZvhSZwtKX1VDZrb+UdvW7mMLnt07E3pIMv xZk81ZZm4aKtvBOji94aNBG5T6VClVZV7Zkl8B2xJ7Mvr+S7c/f6eZ0PTmzpVUVFoW7fHtdt3xl1 1Nrn2LDVNdG2sReU5QQF5nRqeEZffSj0hIyiqgJ9/4kZh9sjwqdYn6+6h8IjGD6d0bdP3bM9jtP2 uM4ESxTv8EG/uV0jdK6iL5hL1Th/c6yEA3Oa3KXQXD+fTOs3fjBl7eEzzQQYKZFmDUZxEUAAAQQQ SAuB6ha1WLPy+ft09tg5xR0wMX1H3W8f1xXr1o2KJjWbJyHEe433xpmU8q6uX+mW9QNgda2Z8l9S 9ebIr9d9XfZHFMbL2MVt1S1qrQ3/cnw/BxeLsOKsi0ujo08G+9Ufk+FgV9Q/Zld0dbJbXQueo7pI 20VT3XdpeuQ9vfVq+GkWkiqa2yJPXjH3C1VvDruPdcXpN/fNOrwzX6XVTdrfWhte92s4+jiVeRmU N+3XvnA7B277dPzU/EeNzjs47kq5aqzy+nt0+b3IFIDRo+92q8PMJ2FeJdULn05jtifyHQnltPC/ y/3u3O3WmbN9oaeXbGnR/v3NCpHclu9Mh20EyWq0zcJis8VZ4OO/D+hH1h9L5ai+yavv/2Ze3Mdl bny0QN9/fp1aTbZbciKT/JpV8xSMyGtzgR615nWIbFz+Qu/AbGQCzNKqfB3efJ+8PpvRsFWfh/L0 x/c79j7ZsCv5AoyUSH4bUAIEEEAAAQQyUKBQDXv3qe/V8BMJxnt08mivyrY0qKF+s0o0rqG+Pt3o H9ak9UOYt1b79t/vF+ZxdZ74nu627dXT1cXS9B31+86Gf5mVVNas5q1hyuLt2lV7WaeDjyg8r++9 NaLWliZVlxWrUHc1MTGqwd4rujy6XYdCz9F0qQ3MUwme1/Bbb6rT/KAfdiiqrFF9XZ0qzRQBE8Pq 7b2u/si/rpdelEJvdGj8YNdVjVRtlffWdQ2X71T9YpMGLD378JGbVbtF6jXPsvT36Mzbm/R8a71K 8yd06/I5nbUulO+br189J19XoG1P6BGr92u72HwmBnT9utVJpMD4kK53d2tgLLqtZNvz2h8zOWRN U5PKenwaU7jftLZpV0158OkkujuhsZHr6vL1q6ztBe00VqPv6ZQvoG27tqsm/OSN6bsj6u0OPmfA THaiykWfb1uore0H1PzG68EJL/19p/VWx8t6aV6ZCuU1cRITVxjrVudgnXaVT6j7RkBNO6pV/XSz KntCE7YOXzqmN8Za1PpUzCNBgzZe1bU2K95ACTPXxJK/I6bKHcd1zDcsFW3TnkO7Q48wXdZ35666 z1gBoko9t7tBhYVmotBO9b0zHBxBcqajNuKRcNvE9gnWlykQ0Cvv5uovfydfleYq0JOr+ie9Ovv4 rIZ/OqtB80SOdTmq3piryqIcyT+jfzJnMoGCXeGnXGzI0x/+tkdvX51VwWMevbDDoy8tszRxk/3b lDqezNPXN+YEy/fV3ylU9WBAlz6YDQafv1Sdr69umtOl4BM4AvqroXw9+bj5nT1Xjb9TqD//IKAf Dszo5oBU+Wiu6mo8+vXN0s0/9eu7cU/IxlQQICiRCq1AGRBAAAEEEMhEgcKtan/lRV1864Q6b5sL yIDGBrrkG1g4m6KnbLva97eqJnqNvVCkbJu2F/eq6+wx9cTu9VSoud0e0MjX1ra92nbspHrGpcmh Tp0+1hmbSqrdtnDbam8prFLLgYMqOfm2Lg2Zn/UCmhzuU+ewefRDnJenREu9Db946zZVvjMcnFPB P/COjh19x0Rn1PzyzjgZL3dTvup3Nco3EHq8o3/gkt587VI4M69qm7dr1NcVvllmkXNYbXf+Tduw 7/CxC9ouJo/hLp1dbAZOT5m2tT2v1vrShbf8lDep/bl+HX9nSP7AmHrOv7mw3xiryOkCGu3z6XSf L7LFvuCtbVNLeCCOfXt0uVxN+/dpOByIu+07rlNlr9gmvqxWQ61XPcEgzpi6Trym4Dehdp+adkgq 3qHnXxzTWyc6dTvg1+2u83pzwVfFq83PHdDemkVGE1nOS/qO3JDPNxwaHD/Zo8vdu7R1p3kGQuLf nYmrJ3XeBK3MII7GZyMjVop3PKvGK2+qc9zEJWy3cSTcNlFlllYoMDSl3/1r6c+fyddjReG8vLmq fNi8F8n7s2n904ceVT5sbqvI0WO/sk5/+ivhY/0zuv5pnupXbbTEnP7ir6f05fYCPWkCI55cfaWm QC/V2Mrmn4ms9L47pUsb1+nZcBDjsccL9Njjkd3hhVktcZ7N2ISsr5EAt2+sETSnQQABBBBAICsF zAX5S3+sIy+2aXtlWWTywKCFp0hllXVq3vdN/fGhVtXEf7iBja1cjftf1p7tlSqxflbxFKmi9ll9 4xX7PevhJIU12v3KEX3j2TpVlnllJZE8Kiqq0JbGNh1stYZW2E7jxmL+Ju3c/0f6k5f3qbmuUmXW LIrBc3nkLSpTZW2j2l48oj/5zgtqcLQIFzJ4IdusLREQyVOySSX3C+4sp35VLTr44rOqrYg6ekq2 qPkbh9ReG/eZKDFnSbDtYlLbVz3ecL/Zc1BHvnNIu+MFJMIJynfs15Fv7lHjlop5fS+Sx77n1WiN KCnZrMbYtvF4VVRRG+yjR9q32ubWsJfItmwCcQeaw7cO+dV3+pjO9UfnQqnefVB7tlXIa3VGj1cV ZZGHIaqwqkUvvRKaaNPeR0x5K2qbte+bR7R/h1Vg23kji4k4b1Vzc2Xwe+Ep2qZdDdFyKJHvzmiH 3jajIczLu01t8x61UaXm1jqFbqSZfxtHQm0TqR8LqyIwNKXf/7O7+t//HNAHn85pKjroSNKcpvyz Gr41rTf/+p4uBE84p7dP3dMPB2ejI9s0p8lPAnrj//r18bz0q1DCzwJ65c/8euNfzWND5z8S1JTt g6FAaARH8FQzOnbyro7+KKDhSfMkENsrMKfJT2fU+c9TOmXbzGLqCeTMzc3Nb+nUKyMlWgUBq5nN p3nPzs5qZmZG09PTunfvXuR98+ZNfe1rX1uFM5IFAggggECyBC5evKiWlpZknX6Vz3tDpw6fVnBM AZPirbIt2WWGAN8Rt9txJX9T370WumJ/w3fP7WKSfxoLvNS8Llj6Z37ZiliubWX+9m//Vo8++qjW rVsXeefn5ysvL0+5ubnKyckJvk2pzPJqvxgpsdqi5IcAAggggAACCCCAAAIIIIAAAksSICixJCYO QgABBBBAAAEEEEAAAQQQQACB1RYgKLHaouSHAAIIIIAAAggggAACCCCAAAJLEiAosSQmDkIAAQQQ QAABBBBAAAEEEEAAgdUWICix2qLkhwACCCCAAAIIIIAAAggggAACSxJIzvSeSyoaByGAAAIIIIAA AlvV/t3vwoAAAosK8B1ZlIYdCCCQFgKMlEiLZqKQCCCAAAIIIIAAAggggAACCGSeAEGJzGtTaoQA AggggAACCCCAAAIIIIBAWggQlEiLZqKQCCCAAAIIIIAAAggggAACCGSeAEGJzGtTaoQAAggggAAC CCCAAAIIIIBAWggQlEiLZqKQCCCAAAIIIIAAAggggAACCGSeAEGJzGtTaoQAAggggAACCCCAAAII IIBAWggQlEiLZqKQCCCAAAIIIIAAAggggAACCGSeAEGJzGtTaoQAAggggAACCCCAAAIIIIBAWggQ lEiLZqKQCCCAAAIIIIAAAggggAACCGSeAEGJzGtTaoQAAgggkOUC69at071797JcgeojgAACKxfw +/0yf1NX+nqgIGelWZA+QwXoGxJBiQzt3FQLAQQQQCB7BdavX69PP/00ewGoOQIIILBKAp999pk2 bNiw4tzKvkhQYsWIGZoBfYOgRIZ2baqFAAIIIJDNAiYoMTk5mc0E1B0BBBBYFQHzt/SLX/zisvNa lx9Kal14zs0tOysSZpiA1ResvmH1lQyr5pKqw0iJJTFxEAIIIIAAAukjUFNTo3//939PnwJTUgQQ QCBFBT744AM98sgjyy7dFwtDIyR+6ct5ys2RchgwsWzLjEuYI3nyJNM3zGt9uK9kXD2XUCGCEktA 4hAEEEAAAQTSSSA3N1f19fW6evVqOhWbsiKAAAIpJWD+hm7btk05K4gkWEGJDQ/k6Nd+0ZNS9aMw yRUw8alf3+KR6RvmtT78mdxSJefsBCWS485ZEUAAAQQQcFXg4Ycf1qZNm9TV1eXqecgcAQQQyEQB E5D48pe/HPw7upL6VT2YExwhYfJo2Jynsi/mygzbN3dxcCfHSmTTM63V5qYPmL7wy1WhURJ5uVLl g9l7aU64Lj37M6VGAAEEEEDAUaCqqkoej0fvvvuuzC0dZq4J816NmeQdT84BCCCAQBoJmKdsmEkt JyYmdPPmzeAICRPYXenrgXU5qqnI1c2R2eCtG/99R76u/jignqEZghIrxU3D9GZMhHmbANWOLZ7I 7TxbKnJVWJCGFVqlIhOUWCVIskEAAQQQQCAVBcyIiYqKCvX39+s//uM/gk/l4HGhqdhSlAkBBJIp YIK1JmhrnrTxzDPPrOiWjdh6bC7P1cinc/rs53Py5Eo7azz6ysY89f3XjO5Mzumnk7PyT8emYj2T BLz50oNFuSotylHtL+SpYkPolg1Tx5Iv5GhzWfaOkjAGBCUyqbdTFwQQQAABBOIImDkmHn300Th7 2IQAAggg4LaAmZLi134xTz/+aFY/+Xg2eDpzUVqxgUsxt+1TOX/TL0zAyoykWcG0JalcxSWXjW/C kqk4EAEEEEAAAQQQQAABBBBIXMDMGfDIplyVr8/Rh3fmNOGf06RfmgpYswwknicp0k+gwCMVeXNU 7M3RL5TmBEdJpF8tVr/EBCVW35QcEUAAAQQQQAABBBBAAIEFAqVfyJF580IAgahAdt+8EnVgCQEE EEAAAQQQQAABBBBAAAEE1liAoMQag3M6BBBAAAEEEEAAAQQQQAABBBAICRCUoCcggAACCCCAAAII IIAAAggggEBSBAhKJIWdkyKAAAIIIIAAAggggAACCCCAAEEJ+gACCCCAAAIIIIAAAggggAACCCRF gKBEUtg5KQIIIIAAAggggAACCCCAAAIIEJSgDyCAAAIIIIAAAggggAACCCCAQFIECEokhZ2TIoAA AggggAACCCCAAAIIIIAAQQn6AAIIIIAAAggggAACCCCAAAIIJEWAoERS2DkpAggggAACCCCAAAII IIAAAggQlKAPIIAAAggggAACCCCAAAIIIIBAUgQISiSFnZMigAACCCCAAAIIIIAAAggggABBCfoA AggggAACCCCAAAIIIIAAAggkRYCgRFLYOSkCCCCAAAIIIIAAAggggAACCBCUoA8ggAACCCCAAAII IIAAAggggEBSBAhKJIWdkyKAAAIIIIAAAggggAACCCCAAEEJ+gACCCCAAAIIIIAAAggggAACCCRF gKBEUtg5KQIIIIAAAggggAACCCCAAAIIEJSgDyCAAAIIIIAAAggggAACCCCAQFIECEokhZ2TIoAA AggggAACCCCAAAIIIIAAQQn6AAIIIIAAAggggAACCCCAAAIIJEWAoERS2DkpAggggAACCCCAAAII IIAAAggQlKAPIIAAAggggAACCCCAAAIIIIBAUgQISiSFPXVPmpOTk7qFo2QIIIAAAggggAACCCCA AAKrKpDsa0CCEqvanGSGAAIIIIAAAggggAACCCCAAAJLFSAosVSpDD7OioyZT4/Ho+np6QyuLVVD AAEEEEAAAQQQQAABBBAwAubaz1wD2q8J11qGoMRai6fY+UznM+/c3FBXWLdunT7//PMUKyXFQQAB BBBAAAEEEEAAAQQQWG0Bc+1nrgHNy1wTWteHq32e++VHUOJ+Olm2z3TADRs26Cc/+UmW1ZzqIoAA AggggAACCCCAAALZJ2Cu/cw1oLkWTNaLoESy5FPkvNYoCRMVM+8HHnhA9+7dU2dnpz7++OPgcooU lWIggAACCCCAAAIIIIAAAgisUMBc75lrPXPNNzU1FbwGtK4HrdESKzxFQsk9CR3NwRkjYAUjZmZm IkN0rG0PPfSQfv7zn+vatWuanJwMdlRznP01NzdnX2UZAQQQQAABBBBAAAEEEEAgxQRiR0Dk5eWp oKBARUVFMtd95kdpKxBhjrWOt7atRXUISqyFcgqfw4qImc5p3mbdTHTi9XpVXl6u0tJSmYDE7Oxs 8G2qQkAihRuUoiGAAAIIIIAAAggggAACNgF7oMFc75nrPnPNZ4IT5tPaZl0PmvW1fBGUWEvtFDiX 1SGtoljRMCsokZ+fH9xlghDmZbYHAoFIUIKAhCXHJwIIIIAAAggggAACCCCQHgLmus8EG8zbBCKs wIS5/jNva5t1fWhqZS2bTzdfBCXc1E3xvE2HNEEGe+c06yYgYWZgNdtNQMJ8mm1WQMIKWKR49Sge AggggAACCCCAAAIIIJD1AuZ6zryswIQVgDDBCCs4YT6t60LruLWCIyixVtIpeh4r+mU6oOmcVuDB BCPMy3ROE4Sw3tZ+s8++nKLVo1gIIIAAAggggAACCCCAQFYKWCMcrE8r6GB9WiMkzHWgeZvt1vXh WoIRlFhL7SSey3QuexDB3jFji2X2WR3VzCdh0tlHStjziU3LOgIIIIAAAggggAACCCCAQOoIWNd+ 1nWe+bSPkLBGTpht1ogJc4yVzqpJ7Lq1faWfBCVWKpiG6U1nMoEF69MEIOyBBrPd6pD2oISpKrdu pGGDU2QEEEAAAQQQQAABBBDIagFzzWde1mgI63rP+jHaCkZYx1kBCOvTTTyCEm7qpkHeVmDCdEKz bN7WrRpmmzVCwh6MsC+nQRUpIgIIIIAAAggggAACCCCQtQJWoMEAWEEJ+6dZtt7mmLUIRNgbI2fO /hO5fQ/LGSlgb25r2Xxay1YQwtpmBSCs/dZnRuJQKQQQQAABBBBAAAEEEEAgAwWsQIP1aQUlzLp5 m3XzstatZYvCSmetr+YnQYnV1EyDvGKDCvZ1s2ytW8EIUyX7chpUkSIigAACCCCAAAIIIIAAAggs ImAFIMxua9kejDDbY4MQseuLZL2szQQllsWW3omswINVC/t6vGX7NisNnwgggAACCCCAAAIIIIAA AuknYAUYrE9Tg8WWY/e5UVuCEm6opkGe8QINsdti19OgWhQRAQQQQAABBBBAAAEEEEBgCQL2QIQ5 PHZ9sW1LyDqhQ5joMiGuzDnYdLjYoEO8Tpg5NaYmCCCAAAIIIIAAAggggAACloDT9Z/TfiuflX4y UmKlghmQPjY4kQFVogoIIIAAAggggAACCCCAAALLEFirYIRVNEZKWBJZ/GnvdAQosrgjUHUEEEAA AQQQQAABBBDISgH7NeFaAxCUWGvxFD9fMjtjitNQPAQQQAABBBBAAAEEEEAAgVUWCD2MdJUzJTsE EEAAAQQQQAABBBBAAAEEEEDASYCghJMQ+xFAAAEEEEAAAQQQQAABBBBAwBUBghKusJIpAggggAAC CCCAAAIIIIAAAgg4CRCUcBJiPwIIIIAAAggggAACCCCAAAIIuCJAUMIVVjJFAAEEEEAAAQQQQAAB BBBAAAEnAYISTkLsRwABBBBAAAEEEEAAAQQQQAABVwQISrjCSqYIIIAAAggggAACCCCAAAIIIOAk QFDCSYj9CCCAAAIIIIAAAggggAACCCDgigBBCVdYyRQBBBBAAAEEEEAAAQQQQAABBJwECEo4CbEf AQQQQAABBBBAAAEEEEAAAQRcESAo4QormSKAAAIIIIAAAggggAACCCCAgJMAQQknIfYjgAACCCCA AAIIIIAAAggggIArAgQlXGElUwQQQAABBBBAAAEEEEAAAQQQcBIgKOEkxH4EEEAAAQQQQAABBBBA AAEEEHBFgKCEK6xkigACCCCAAAIIIIAAAggggAACTgIEJZyE2I8AAggggAACCCCAAAIIIIAAAq4I EJRwhZVMEUAAAQQQQAABBBBAAAEEEEDASYCghJMQ+xFAAAEEEEAAAQQQQAABBBBAwBUBghKusJIp AggggAACCCCAAAIIIIAAAgg4CRCUcBJiPwIIIIAAAggggAACCCCAAAIIuCJAUMIVVjJFAAEEEEAA AQQQQAABBBBAAAEnAYISTkLsRwABBBBAAAEEEEAAAQQQQAABVwQISrjCSqYIIIAAAggggAACCCCA AAIIIOAkQFDCSYj9CCCAAAIIIIAAAggggAACCCDgigBBCVdYyRQBBBBAAAEEEEAAAQQQQAABBJwE CEo4CbEfAQQQQAABBBBAAAEEEEAAAQRcESAo4QormSKAAAIIIIAAAggggAACCCCAgJMAQQknIfYj gAACCCCAAAIIIIAAAggggIArAgQlXGElUwQQQAABBBBAAAEEEEAAAQQQcBIgKOEkxH4EEEAAAQQQ QAABBBBAAAEEEHBFgKCEK6xkigACCCCAAAIIIIAAAggggAACTgIEJZyE2I8AAggggAACCCCAAAII IIAAAq4IEJRwhZVMEUAAAQQQQAABBBBAAAEEEEDASYCghJMQ+xFAAAEEEEAAAQQQQAABBBBAwBUB ghKusJIpAggggAACCCCAAAIIIIAAAgg4CRCUcBJiPwIIIIAAAggggAACCCCAAAIIuCJAUMIVVjJF AAEEEEAAAQQQQAABBBBAAAEnAYISTkLsRwABBBBAAAEEEEAAAQQQQAABVwQISrjCSqYIIIAAAggg gAACCCCAAAIIIOAkQFDCSYj9CCCAAAIIIIAAAggggAACCCDgigBBCVdYyRQBBBBAAAEEEEAAAQQQ QAABBJwECEo4CbEfAQQQQAABBBBAAAEEEEAAAQRcESAo4QormSKAAAIIIIAAAggggAACCCCAgJMA QQknIfYjgAACCCCAAAIIIIAAAggggIArAgQlXGElUwQQQAABBBBAAAEEEEAAAQQQcBIgKOEkxH4E EEAAAQQQQAABBBBAAAEEEHBFgKCEK6xkigACCCCAAAIIIIAAAggggAACTgIEJZyE2I8AAggggAAC CCCAAAIIIIAAAq4IEJRwhZVMEUAAAQQQQAABBBBAAAEEEEDASYCghJMQ+xFAAAEEEEAAAQQQQAAB BBBAwBUBghKusJIpAggggAACCCCAAAIIIIAAAgg4CRCUcBJiPwIIIIAAAggggAACCCCAAAIIuCJA UF5dCpEAAAPgSURBVMIVVjJFAAEEEEAAAQQQQAABBBBAAAEnAYISTkLsRwABBBBAAAEEEEAAAQQQ QAABVwQISrjCSqYIIIAAAggggAACCCCAAAIIIOAkQFDCSYj9CCCAAAIIIIAAAggggAACCCDgigBB CVdYyRQBBBBAAAEEEEAAAQQQQAABBJwECEo4CbEfAQQQQAABBBBAAAEEEEAAAQRcESAo4QormSKA AAIIIIAAAggggAACCCCAgJMAQQknIfYjgAACCCCAAAIIIIAAAggggIArAgQlXGElUwQQQAABBBBA AAEEEEAAAQQQcBIgKOEkxH4EEEAAAQQQQAABBBBAAAEEEHBFgKCEK6xkigACCCCAAAIIIIAAAggg gAACTgIEJZyE2I8AAggggAACCCCAAAIIIIAAAq4IEJRwhZVMEUAAAQQQQAABBBBAAAEEEEDASYCg hJMQ+xFAAAEEEEAAAQQQQAABBBBAwBUBghKusJIpAggggAACCCCAAAIIIIAAAgg4CRCUcBJiPwII IIAAAggggAACCCCAAAIIuCJAUMIVVjJFAAEEEEAAAQQQQAABBBBAAAEnAYISTkLsRwABBBBAAAEE EEAAAQQQQAABVwQISrjCSqYIIIAAAggggAACCCCAAAIIIOAkQFDCSYj9CCCAAAIIIIAAAggggAAC CCDgigBBCVdYyRQBBBBAAAEEEEAAAQQQQAABBJwECEo4CbEfAQQQQAABBBBAAAEEEEAAAQRcESAo 4QormSKAAAIIIIAAAggggAACCCCAgJMAQQknIfYjgAACCCCAAAIIIIAAAggggIArAgQlXGElUwQQ QAABBBBAAAEEEEAAAQQQcBIgKOEkxH4EEEAAAQQQQAABBBBAAAEEEHBFgKCEK6xkigACCCCAAAII IIAAAggggAACTgIEJZyE2I8AAggggAACCCCAAAIIIIAAAq4IEJRwhZVMEUAAAQQQQAABBBBAAAEE EEDASYCghJMQ+xFAAAEEEEAAAQQQQAABBBBAwBUBghKusJIpAggggAACCCCAAAIIIIAAAgg4CRCU cBJiPwIIIIAAAggggAACCCCAAAIIuCJAUMIVVjJFAAEEEEAAAQQQQAABBBBAAAEnAYISTkLsRwAB BBBAAAEEEEAAAQQQQAABVwQISrjCSqYIIIAAAggggAACCCCAAAIIIOAkQFDCSYj9CCCAAAIIIIAA AggggAACCCDgigBBCVdYyRQBBBBAAAEEEEAAAQQQQAABBJwECEo4CbEfAQQQQAABBBBAAAEEEEAA AQRcESAo4QormSKAAAIIIIAAAggggAACCCCAgJPA/wd5YbCmm0gjqQAAAABJRU5ErkJggg== --000000000000e894ca0582b6a070-- From nobody Mon Feb 25 05:29:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3CC130EFC for ; Mon, 25 Feb 2019 05:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIW5EYqQnuxX for ; Mon, 25 Feb 2019 05:29:08 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A869128CB7 for ; Mon, 25 Feb 2019 05:29:07 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id i16so9898698wrs.13 for ; Mon, 25 Feb 2019 05:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xwfq9k6t8XN09k0xi+PwMu7RefPgDtE4WlE9PT/9rNI=; b=fv2rWnLrzgkZabP0eTjYgvjCQp/AOHe5u094K8pQFwKigZMrTSmoQ21uupvTbiNFzH WXMJfcygpXraictnSXMvc7MJ1miScYzgSVMUpBJTJ34CSia3ooFwnG9b2ivYzVe77P9t NcRtBqWYQwjeYsvEEYMNX0mt0eq5vjZsfAAegfzTPLGcWaGTiAJAJCVdDhyS96+wMlWF v+RnUpZJXXWP+TWN7nMsJZ2cSbOyPVX3IDEd9YbmaFEIicUzQl8qnu6CUeR2LkvRy1Dt i1bBpXMqCT9XY6UKX0T+Xpq7MsqB2i1x9PT34gBkfme7Ki6mZxrIQfCNpbAVo2w9oWdV Un2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xwfq9k6t8XN09k0xi+PwMu7RefPgDtE4WlE9PT/9rNI=; b=fGVdST3uhE2Xr1ucVZsOr3r0qUiJp2OAooR6cIOSFJXDE4RVmCuP2XA0qeI+jtqg8u ifo9iYqgPrO07vQ7XKJQ73YJQf1tWW/Voly53xkNviwrFKUpfHkwfy09yhfVnDtXqj08 8OC42iQ+IWQtHS9xfy5s8xcX66Nkgv5q2XSc1PD3ra+n3kqSnVI5FDgcMmyiNLyiR44U 5uJs53DUALmIRu+bMYJ/qOa9BVINb9oRejpqFpgbQSOW9RpCsLMb0jiJKHqKLO8V7y4V VvIKsb32yQ/m3MfI3kb5aLXYlbcQM70MYFnNXPpcW6BEC9geQDvAW0Qw1nb47vMsueAm HLRQ== X-Gm-Message-State: AHQUAuaykexS4zrCIA9PRqECM/FJlnfb0Yw2jVY0f8T7mX2I15ZGKOG2 tZ084ewTc2TRA2bAWR68itAsIfmY/5RxutZsF9rDtA== X-Google-Smtp-Source: AHgI3IaLZPQNYqLiCTncwJrsaYn8fIlBPFYLI+vjhdsYaLAvz0VgAUOJgJpzfYySzZsd6J1kFLBRUi9Us4NY52pMju4= X-Received: by 2002:adf:e8c7:: with SMTP id k7mr12952757wrn.298.1551101345823; Mon, 25 Feb 2019 05:29:05 -0800 (PST) MIME-Version: 1.0 References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> In-Reply-To: From: John Bradley Date: Mon, 25 Feb 2019 10:28:53 -0300 Message-ID: To: Vittorio Bertocci Cc: David Waite , William Denniss , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000ba92340582b7ecde" Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 13:29:12 -0000 --000000000000ba92340582b7ecde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Win 10 2019H1 has a WebAuthn API for third party apps. Chrome and Fire Fox are now using it. Trusted browsers have some whitelisting involved. Other apps will be able to use the API eventually. There are some issues around the RPID for apps and websites that may make the authentication broker simpler. Android has a API but it requires whitelisting and really only talks to the platform authenticator at the moment. So for the moment AppAuth is the best option for WebAuthn. John B. On Mon, Feb 25, 2019, 8:38 AM Vittorio Bertocci wrote: > True, the WAB is perhaps the best approximation of a desktop system > browser-like feature, but it doesn't solve Mac or Linux. Even within the > Windows world, Win10 usage pulled ahead of Win7 only in January, and > barely- and the WAB isn't available on Win7. > In fact, you bring up an excellent point. I am wondering if the OS vendor= s > are making any plans to make WebauthN available to desktop apps beyond 1s= t > party applications. > > Regadless of what the future might look like, the problems I listed above > are concrete blockers for the adption of that pattern on that desktop. I = am > wondering if those issues should be explicitly acknowledged in the best > practices document, so that developers running into them realize they are > now issues and not something they are doing wrong. > > On Mon, Feb 25, 2019 at 3:21 AM John Bradley wrote: > >> On Windows Web Authentication broker is a option. >> >> >> https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication= .Web >> >> I have encouraged Apple to provide a SSO service on OSX. >> >> The availability of WebAuthn in browsers may make the platforms rethink >> some things. >> >> John B. >> >> >> On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci > 40auth0.com@dmarc.ietf.org> wrote: >> >>> Ahh, as John knows this is a big pet peeve for me :) >>> >>> Although that's all true on mobile, on desktop things are more >>> complicated. >>> >>> - Using a system browser on the desktop (Linux/Mac/Windows) means >>> that you don't control the experience (there might be modal dialogs >>> occluding the browser or any other Z order windows factors; the brow= ser >>> instance might have already other tabs open; the default browser of = any >>> particular machine can be different; users might need to take steps = to get >>> back to the app; etc) >>> - Use of loopback adapters is banned by many big enterprises on >>> their machines >>> - The big security advantages of the approach on mobile, where apps >>> are all nicely sandboxed, is not as pronounced in an environment whe= re the >>> user login session in the machine is the main security boundary (thi= nk >>> keylogger attaching to the main windows events pump, or a debugger -= all >>> stuff not possible on mobile but viable on desktops) >>> >>> True, it would be fantastic if desktop OSes would offer system browser >>> features comparable to what's available on iOS and Android - but today = that >>> doesn't appear to be the case. And the inability to leverage existing >>> sessions when using embedded views on the desktop is a true pain. But >>> judging from the behavior of the most popular desktop apps in market >>> (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app = for >>> Mac...) losing the ability to access cookies is less of a nuisance for >>> users than all of the above. And considering that desktop machines usua= lly >>> have their own way of identifying devices, that is also not much of a >>> factor for desktop apps. >>> >>> The best practice has been discussed for the last 4 years and still all >>> of the big apps above remain on embedded: it is however telling that th= e >>> mobile apps from the same vendors all embraced the system browser appro= ach. >>> Since the native best practices came out, I have been working with >>> desktop developers dealing with this cognitive dissonance of the best >>> practice saying something that is very hard to put in practice. I >>> understand that it is well intentioned and it is easier to give one sin= gle >>> advice for both mobile and desktop, but while the necessary features an= d >>> experiences are lacking on the desktop I am not sure how much of a >>> difference it is making in that use case. >>> >>> >>> >>> On Mon, Feb 25, 2019 at 12:59 AM David Waite < >>> david@alkaline-solutions.com> wrote: >>> >>>> >>>> > On Feb 24, 2019, at 10:43 AM, William Denniss >>> 40google.com@dmarc.ietf.org> wrote: >>>> > >>>> > For 1P sign-in, there are several good reasons to go with >>>> ASWebAuthenticationSession, like syncing the signed-in session with Sa= fari >>>> and using it if it already exists. >>>> >>>> With enterprise 3P, you=E2=80=99ll have to use some web agent for >>>> authentication pretty much no matter what, and you=E2=80=99ll almost c= ertainly get >>>> pressure to use ASWebAuthenticationSession, and/or potentially lose de= als >>>> to competitors during product evaluations. It is simply what is requir= ed >>>> for robust integration into a corporate infrastructure. >>>> >>>> For 1P on iOS, it depends on the complexity of authentication for firs= t >>>> party. If you are just doing password and maybe SMS-based challenges, = there >>>> is decent enough native app integration for password sharing and SMS >>>> keyboard for that to keep conversions high, even with having to >>>> authenticate twice. >>>> >>>> However, if you want to authenticate the device (even pseudonymously >>>> with session cookies) or do other factors, the authentication is simpl= er >>>> with ASWebAuthenticationSession. Which means your life will be easier = if >>>> you have more complex authentication requirements anywhere on your roa= dmap >>>> to just start off using ASWebAuthenticationSession. >>>> >>>> It is likely that future authentication technologies like WebAuthn wil= l >>>> not work with an embedded web view. The ability to arbitrarily inject >>>> javascript means that apps can phish webauthn responses for domains vi= a >>>> embedded web views. >>>> >>>> -DW >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> --000000000000ba92340582b7ecde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Win 10 2019H1 has a WebAuthn API for third party apps.=C2= =A0 =C2=A0Chrome and Fire Fox are now using it.=C2=A0 =C2=A0

Trusted browsers have some whitelisting invo= lved.=C2=A0 =C2=A0Other apps will be able to use the API eventually.=C2=A0 = There are some issues around the RPID for apps and websites that may make t= he authentication broker simpler.

Android has a API but it requires whitelisting and really only ta= lks to the platform authenticator at the moment.=C2=A0=C2=A0

So for the moment AppAuth is the best= option for WebAuthn.=C2=A0=C2=A0

John B.=C2=A0


On Mon, Feb 25, 20= 19, 8:38 AM Vittorio Bertocci <Vit= torio@auth0.com> wrote:
True, the WAB is perhaps the best approximation of a desktop s= ystem browser-like feature, but it doesn't solve Mac or Linux. Even wit= hin the Windows world, Win10 usage pulled ahead of Win7 only in January, an= d barely- and the WAB isn't available on Win7.
In fact, you bring u= p an excellent point. I am wondering if the OS vendors are making any plans= to make WebauthN available to desktop apps beyond 1st party applications.<= /div>

Regadless of what the future might look like, the = problems I listed above are concrete blockers for the adption of that patte= rn on that desktop. I am wondering if those issues should be explicitly ack= nowledged in the best practices document, so that developers running into t= hem realize they are now issues and not something they are doing wrong.

On Mon, Feb 25, 2019 at 3:21 AM John Bradley <ve7jtb@ve7jtb.com>= wrote:
On Windows Web Authentication broker is a option.=C2=A0


I have encouraged Apple to provide a SSO service on OSX.=C2=A0

The availability of WebAuthn in br= owsers may make the platforms rethink some things.=C2=A0

John B.=C2=A0

<= /div>

On Mon, Feb 25, 2019, 7:48 AM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Ahh, as John knows this is a bi= g pet peeve for me :)=C2=A0

Although that's all true on mo= bile, on desktop things are more complicated.=C2=A0
  • Using a sys= tem browser on the desktop (Linux/Mac/Windows) means that you don't con= trol the experience (there might be modal dialogs occluding the browser or = any other Z order windows factors; the browser instance might have already = other tabs open; the default browser of any particular machine can be diffe= rent; users might need to take steps to get back to the app; etc)=C2=A0
  • Use of loopback adapters is banned by many big enterprises on their ma= chines
  • The big security advantages of the approach on mobile, where= apps are all nicely sandboxed, is not as pronounced in an environment wher= e the user login session in the machine is the main security boundary (thin= k keylogger attaching to the main windows events pump, or a debugger - all = stuff not possible on mobile but viable on desktops)
True, it= would be fantastic if desktop OSes would offer system browser features com= parable to what's available on iOS and Android - but today that doesn&#= 39;t appear to be the case. And the inability to leverage existing sessions= when using embedded views on the desktop is a true pain. But judging from = the behavior of the most popular desktop apps in market (Office, Slack, Ado= be Reader, Visual Studio, even the Google Drive app for Mac...) losing the = ability to access cookies is less of a nuisance for users than all of the a= bove.=C2=A0And considering that desktop machines usually have their own way= of identifying devices, that is also not much of a factor for desktop apps= .

The best practice has been discussed for the las= t 4 years and still all of the big apps above remain on embedded: it is how= ever telling that the mobile apps from the same vendors all embraced the sy= stem browser approach.
Since the native best practices came out, = I have been working with desktop developers dealing with this cognitive dis= sonance of the best practice saying something that is very hard to put in p= ractice. I understand that it is well intentioned and it is easier to give = one single advice for both mobile and desktop, but while the necessary feat= ures and experiences are lacking on the desktop I am not sure how much of a= difference it is making in that use case.=C2=A0

=


On Mon, Feb 25, 2019 at 12:59 AM David Waite <= ;david@alkaline-solutions.com> wrote:
=

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
>
> For 1P sign-in, there are several good reasons to go with ASWebAuthent= icationSession, like syncing the signed-in session with Safari and using it= if it already exists.

With enterprise 3P, you=E2=80=99ll have to use some web agent for authentic= ation pretty much no matter what, and you=E2=80=99ll almost certainly get p= ressure to use ASWebAuthenticationSession, and/or potentially lose deals to= competitors during product evaluations. It is simply what is required for = robust integration into a corporate infrastructure.

For 1P on iOS, it depends on the complexity of authentication for first par= ty. If you are just doing password and maybe SMS-based challenges, there is= decent enough native app integration for password sharing and SMS keyboard= for that to keep conversions high, even with having to authenticate twice.=

However, if you want to authenticate the device (even pseudonymously with s= ession cookies) or do other factors, the authentication is simpler with ASW= ebAuthenticationSession. Which means your life will be easier if you have m= ore complex authentication requirements anywhere on your roadmap to just st= art off using ASWebAuthenticationSession.

It is likely that future authentication technologies like WebAuthn will not= work with an embedded web view. The ability to arbitrarily inject javascri= pt means that apps can phish webauthn responses for domains via embedded we= b views.

-DW

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--000000000000ba92340582b7ecde-- From nobody Mon Feb 25 13:14:55 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B3C13101C; Mon, 25 Feb 2019 13:14:53 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZBOQGho5FLO; Mon, 25 Feb 2019 13:14:50 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F68130FDA; Mon, 25 Feb 2019 13:14:47 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id l15so673970iti.4; Mon, 25 Feb 2019 13:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qa0HoGujxdmVPiGGy1Yt1oaz/9utxycj1tT4b3Shqrk=; b=mzLsMaLyZMqYogjS+h/veLbLVUuiQ6VHnhhbWXYOwdWzObXpc+654wvbNf/RNAShGE mrCa6peiJLiTpPwnHCJ16qm3Lu+EdL6Y/79auBN3TnosNyYshj90SZSrcYyHvClmZ1uW wQWuEAgM9Ep2nwt587HOVGAEmhjGfJ8DGAYDTp77fE60IdBdHXPB/gvMjND2KRg8Bwy/ RXla0FQsh5V6V98HlHZel3RKpLSpn3a2CvoP3Egxrcf+1aW7+kGhFIfjMIdW0nm0SNKJ KX0TEiPO+ECKP3o57um3YwzOEpZG3CW4F3WRG2pSI4uudvvvpFdqvMBIckLsjH5StMyu VFMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qa0HoGujxdmVPiGGy1Yt1oaz/9utxycj1tT4b3Shqrk=; b=rZJB+O0+jGCnL9wxLwkux6uMOXr2ToSB9W4qYgao4Fr+v18fA7F85SV687909ibjAJ QgwRPoHP4yEi/bc4xQ9IXrjIB4i1vcEwhRxPdE7h0uvBN7eoXnq0uWX1b3aOvXDdfaZU FRCYNGrtze+9gkzCVazdBlzPyfG11i7E7Jps2jAGyV3Mpnzm8Ckp3SNNXCWwFGosHI/3 nZY3JiQQ93ZflJCekF9wm965iUyV1ChIAswlFQ+UfH0UX2mtX1BpIIjHSc1tNF9T0sCo jLjHDH/hWyBlRSSvVClDKUjnLYQd6OWoXKrGHgJzpTLj69p9YKDqXrd4aIbri40AFVtR FVdg== X-Gm-Message-State: AHQUAuaVeIF8DHXKs/6c00x+mJtVa09km30ZP4osD7Rg3mxg8WK2B8jI ZTV2OZ4w2fr+Xq5fgsQlld/I6tHAZDARyYjaY4Q= X-Google-Smtp-Source: AHgI3IbgLxnL1ZM+G9CCf46jZQjzMsVcyRSb76qLHgAshNrCL8bzzDOBCtcPTgqt3ffBlIXW/G736WoTW7ylU0SqGdc= X-Received: by 2002:a02:c6a9:: with SMTP id o9mr11172099jan.70.1551129286891; Mon, 25 Feb 2019 13:14:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 25 Feb 2019 16:14:36 -0500 Message-ID: To: Brian Campbell Cc: draft-ietf-oauth-resource-indicators@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000002560180582be6e94" Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 21:14:53 -0000 --0000000000002560180582be6e94 Content-Type: text/plain; charset="UTF-8" Authors, Since the draft was updated recently, we would like to get a new statement from you around any IPR related to this specification. Are you aware of any IPR related to the following Resource Indicators document? https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 Regards, Rifaat On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell wrote: > I am not aware of any IPR related to this document. > > On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef > wrote: > >> Authors, >> >> As part of the write-up for the Resource Indicators document, we need an >> IPR disclosure from all of you. >> >> Are you aware of any IPR related to the following Resource Indicators >> document? >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ >> >> Regards, >> Rifaat >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --0000000000002560180582be6e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

Since the dra= ft was updated recently, we would like to get a new statement from you arou= nd any IPR related to this specification.

Are you awa= re of any IPR related to the following Resource Indicators document?= =C2=A0=C2=A0

Regards,
=C2=A0Rifaat


On Mon, Jan 7, 2019 at 8:01 AM Bri= an Campbell <bcampbell@pin= gidentity.com> wrote:
I am not aware of any IPR related to this doc= ument.

On Fri, Ja= n 4, 2019 at 8:43 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Authors,

= As part of the write-up for the= Resource Indicators document, we need an IPR disclosure from all of you.

Are you aware of any IPR= related to the following Resource Indicators document?
=C2=A0Rifaat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
--0000000000002560180582be6e94-- From nobody Mon Feb 25 13:16:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F9E130FDA for ; Mon, 25 Feb 2019 13:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT4pnwuBJgSS for ; Mon, 25 Feb 2019 13:16:13 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE92C130F66 for ; Mon, 25 Feb 2019 13:16:12 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id e24so717487itl.1 for ; Mon, 25 Feb 2019 13:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=of3jXu+q0BhyjnlFzFiKL4qQnGb9Z+FnCmdZE0FllZo=; b=XwEbbxXMV396B6hH6csLXg4fKk+eozQ6uq7h524AY1owIZv/wqD339HENu/MMwKUQO ZbwDAIDrQALp6QkSxfnwjrEcCPTWuKhx8d4wVnftyknCA6Arj9A9wkFm2rnKzTHxEIhw VUw1T9jEfcqb8S8BaczOsmU6EJTbA9tEpADNw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=of3jXu+q0BhyjnlFzFiKL4qQnGb9Z+FnCmdZE0FllZo=; b=JY5Z8Cre5yGVD/D391PVY6pZF/0eo4mHll4Gu85SoMrN6ymuM29nh7BaMQwMT+Q0C7 +we50Qy/IDh8Q8Bf61Tv2twXcr8o/gorwA3qrloN2zwUbYTc11g68tGOzCQsodHo8P5K o0l3ibmlnN2QYUAcwiQXvsBv3IGwONOI2I47wFTBsR8EvFxOKRAzksu6mZHaGG1RohnD J91OSOVKbDse+6Q9n0TSj+wi3EGowjC8Ki5be9Lk/pntlyAlpeWHh/4M8HtcSncDI6V+ kOiXGrQZYX1OOH/o/HrPhtHwfbP7As3P+o5I19NJzukCI/DDocE8mSfdtvjbagc9feq7 jc1w== X-Gm-Message-State: AHQUAuZN3J0GVkO3ww96lYV5gphY5LBJxgsAF/jW1joCK5PA6kM1FqsO YRRpjiTipO9cGRImO0mxa9VSwD8MCjJqfqmeZhEfowOeWMg1Gl0mwYY/TOik0NjivDh/E2uAG/L euH9cAMf1e8VH97E9lnE= X-Google-Smtp-Source: AHgI3Ib6H953KXRFwVj7m+8saUmiSt/7yIMuo4V1OlcUj99762Om1IIWzieQK2B6wQu/KXUJWU3/gbJmou6kaSCUU4s= X-Received: by 2002:a24:3091:: with SMTP id q139mr538129itq.174.1551129371969; Mon, 25 Feb 2019 13:16:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 25 Feb 2019 14:15:45 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: draft-ietf-oauth-resource-indicators@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000037a6dd0582be7386" Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 21:16:16 -0000 --00000000000037a6dd0582be7386 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR related to this document. On Mon, Feb 25, 2019 at 2:14 PM Rifaat Shekh-Yusef wrote: > Authors, > > Since the draft was updated recently, we would like to get a new statemen= t > from you around any IPR related to this specification. > > Are you aware of any IPR related to the following Resource Indicators > document? > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 > > Regards, > Rifaat > > > On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell > wrote: > >> I am not aware of any IPR related to this document. >> >> On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef >> wrote: >> >>> Authors, >>> >>> As part of the write-up for the Resource Indicators document, we need a= n >>> IPR disclosure from all of you. >>> >>> Are you aware of any IPR related to the following Resource Indicators >>> document? >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ >>> >>> Regards, >>> Rifaat >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000037a6dd0582be7386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR related to this document.

On= Mon, Feb 25, 2019 at 2:14 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
A= uthors,

Since the draft was updated recently, we would l= ike to get a new statement from you around any IPR related to this specific= ation.

Are you aware of any IPR related to the follow= ing Resource Indicators document?=C2=A0=C2=A0

Regards,
=C2=A0Rifaat


On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell <= bcampbell@p= ingidentity.com> wrote:
I am not aware of any IPR related to this d= ocument.

On Fri, = Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Authors,<= /div>

As part of the write-up for th= e Resource Indicators document, we need an IPR disclosure from all of you.<= /font>

Are you aware of any IP= R related to the following Resource Indicators document?
<= font face=3D"arial, helvetica, sans-serif">https:= //datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/=

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

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000037a6dd0582be7386-- From nobody Mon Feb 25 14:14:51 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D61612D827; Mon, 25 Feb 2019 14:14:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155113289000.10633.211919709867086012@ietfa.amsl.com> Date: Mon, 25 Feb 2019 14:14:50 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 22:14:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-13.txt Pages : 29 Date : 2019-02-25 Abstract: This document describes OAuth client authentication and certificate- bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 25 14:24:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9998131110 for ; Mon, 25 Feb 2019 14:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1VLFcHCGSDs for ; Mon, 25 Feb 2019 14:24:27 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A1C131147 for ; Mon, 25 Feb 2019 14:24:27 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id l15so997297iti.4 for ; Mon, 25 Feb 2019 14:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Xy4keeLYCtI3BFL2zWrqsbG47tpiu7ZhQqBTZdIyvqE=; b=F+D8M3qlXf2EUNIj9pfNIigdOu5CKoTxJ6RFT3yEGNLXenHSOJZR7F10D1L2zXkUAY dSuDgxme4uNtDHCLSAbKi3KbykrbnisUpWJXrq08I8B4e5Wvp2LaibxKJndLPT4YyapT 0eeHpaOEWMSd6pDyORjUwU1w1/EDpMN9ez4Wc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Xy4keeLYCtI3BFL2zWrqsbG47tpiu7ZhQqBTZdIyvqE=; b=sHL1AKnC7NkuW0TEYiHpKbQ9KpLynVmCVJJ5cO/0m3Chwfu+EBAV5LD1+cz1+/p5iD og9u7aqE10NIVkKnq5IzDar+gzARBX4XNgWlneDZiizdHQpVuhDLxoArXzVeNdxqwPo1 I+oEobcQV86FPN8GTkn82V2ffN9HDYUoxKva2PIPMSeusdl3ncgfh302uWvpXi1v5PxO sKWmasg+MKq7x5kclTLOcdkGMKJBRNMSH77YXpfyC/j+n48QntQ4gSm1Kgq2qkKjD5QI XTGx5YAkfrP0Zj+arbgF7ERZXLIovZWoJvh2ZPEsltx4E5+11JNpq2eYc3SAOBSmz9HB GqkQ== X-Gm-Message-State: AHQUAuYFybNaiyWGmSAG4Nl+4Fc9t228B8vRBltg/sBpCy+apsDz3RIY o6cridzCzI8ARzyjODnBWp7M8ovwXuZ+kId5h4xYCG8UrD+aZp4XNlqqXLF7HoLL2dYReu3iblp PjrFDXwrJYdSs75oV9bM= X-Google-Smtp-Source: AHgI3IaAG7NHc8M7dbvIlX/lgzTzlbHcPufeugQeWcO2ulfxKI17KNJJcuZWMTTOi+rQF2Rg3OHWKiDOTVtT8UQ/uCE= X-Received: by 2002:a02:3b2b:: with SMTP id c43mr11145625jaa.91.1551133466371; Mon, 25 Feb 2019 14:24:26 -0800 (PST) MIME-Version: 1.0 References: <155113289000.10633.211919709867086012@ietfa.amsl.com> In-Reply-To: <155113289000.10633.211919709867086012@ietfa.amsl.com> From: Brian Campbell Date: Mon, 25 Feb 2019 15:23:59 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000004340e60582bf67cc" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 22:24:37 -0000 --0000000000004340e60582bf67cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Draft -13 of "OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens" has been published. The changes are listed below and are largely aimed at addressing feedback from the AD review. Although they also include some things that the WG has discussed on this mailing list and at/around the meeting in Bangkok. draft-ietf-oauth-mtls-13 o Add an abstract protocol flow and diagram to serve as an overview of OAuth in general and baseline to describe the various ways in which the mechanisms defined herein are intended to be used. o A little bit less of that German influence. o Rework the TLS references a bit and, in the Terminology section, clean up the description of what messages are sent and verified in the handshake to do 'mutual TLS'. o Move the explanation about "cnf" introspection registration into the IANA Considerations. o Add CIBA as an informational reference and additional example of an OAuth extension that defines an endpoint that utilizes client authentication. o Shorten a few of the section titles. o Add new client metadata values to allow for the use of a SAN in the PKI MTLS client authentication method. o Add privacy considerations attempting to discuss the implications of the client cert being sent in the clear in TLS 1.2. o Changed the 'Certificate Bound Access Tokens Without Client Authentication' section to 'Public Clients and Certificate Bound Tokens' and moved it up to be a top level section while adding discussion of binding refresh tokens for public clients. o Reword/restructure the main PKI method section somewhat to (hopefully) improve readability. o Reword/restructure the Self-Signed method section a bit to (hopefully) make it more comprehensible. o Reword the AS and RS Implementation Considerations somewhat to (hopefully) improve readability. o Clarify that the protected protected resource obtains the client certificate used for mutual TLS from its TLS implementation layer. o Add Security Considerations section about the certificate thumbprint binding that includes the hash algorithm agility recommendation. o Add an "mtls_endpoint_aliases" AS metadata parameter that is a JSON object containing alternative authorization server endpoints, which a client intending to do mutual TLS will use in preference to the conventional endpoints. o Minor editorial updates. ---------- Forwarded message --------- From: Date: Mon, Feb 25, 2019 at 3:15 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-13.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-13.txt Pages : 29 Date : 2019-02-25 Abstract: This document describes OAuth client authentication and certificate- bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-13 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000004340e60582bf67cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Draft -13 of "= OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tok= ens" has been published. The changes are listed below and are largely = aimed at addressing feedback from the AD review. Although they also include= some things that the WG has discussed on this mailing list and at/around t= he meeting in Bangkok.

=C2=A0=C2=A0 draft-iet= f-oauth-mtls-13

=C2=A0=C2=A0 o=C2=A0 Add an abstract protocol flow a= nd diagram to serve as an overview
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of OAu= th in general and baseline to describe the various ways in
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 which the mechanisms defined herein are intended to be u= sed.
=C2=A0=C2=A0 o=C2=A0 A little bit less of that German influence.=C2=A0=C2=A0 o=C2=A0 Rework the TLS references a bit and, in the Terminolo= gy section,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clean up the description of w= hat messages are sent and verified in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the= handshake to do 'mutual TLS'.
=C2=A0=C2=A0 o=C2=A0 Move the exp= lanation about "cnf" introspection registration into
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 the IANA Considerations.
=C2=A0=C2=A0 o=C2=A0 Add = CIBA as an informational reference and additional example of
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 an OAuth extension that defines an endpoint that util= izes client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authentication.
=C2=A0=C2= =A0 o=C2=A0 Shorten a few of the section titles.
=C2=A0=C2=A0 o=C2=A0 Ad= d new client metadata values to allow for the use of a SAN in
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 the PKI MTLS client authentication method.
=C2=A0= =C2=A0 o=C2=A0 Add privacy considerations attempting to discuss the implica= tions
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the client cert being sent in th= e clear in TLS 1.2.
=C2=A0=C2=A0 o=C2=A0 Changed the 'Certificate Bo= und Access Tokens Without Client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authenti= cation' section to 'Public Clients and Certificate Bound
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Tokens' and moved it up to be a top level sect= ion while adding
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discussion of binding re= fresh tokens for public clients.
=C2=A0=C2=A0 o=C2=A0 Reword/restructure= the main PKI method section somewhat to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = (hopefully) improve readability.
=C2=A0=C2=A0 o=C2=A0 Reword/restructure= the Self-Signed method section a bit to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = (hopefully) make it more comprehensible.
=C2=A0=C2=A0 o=C2=A0 Reword the= AS and RS Implementation Considerations somewhat to
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (hopefully) improve readability.
=C2=A0=C2=A0 o=C2=A0 Clari= fy that the protected protected resource obtains the client
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 certificate used for mutual TLS from its TLS implementat= ion layer.
=C2=A0=C2=A0 o=C2=A0 Add Security Considerations section abou= t the certificate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thumbprint binding that= includes the hash algorithm agility
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reco= mmendation.
=C2=A0=C2=A0 o=C2=A0 Add an "mtls_endpoint_aliases"= ; AS metadata parameter that is a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 JSON ob= ject containing alternative authorization server endpoints,
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 which a client intending to do mutual TLS will use in pr= eference
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the conventional endpoints.=C2=A0=C2=A0 o=C2=A0 Minor editorial updates.



---------- Forwarded message ---------
From: <= ;internet-dra= fts@ietf.org>
Date: Mon, Feb 25, 2019 at 3:15 PM
Subjec= t: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-13.txt
To: <i-d-announce@ietf.org>
Cc: <oaut= h@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 WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access To= kens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 29
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-02-25

Abstract:
=C2=A0 =C2=A0This document describes OAuth client authentication and certif= icate-
=C2=A0 =C2=A0bound access tokens using mutual Transport Layer Security (TLS= )
=C2=A0 =C2=A0authentication with X.509 certificates.=C2=A0 OAuth clients ar= e provided a
=C2=A0 =C2=A0mechanism for authentication to the authorization server using= mutual
=C2=A0 =C2=A0TLS, based on either self-signed certificates or public key =C2=A0 =C2=A0infrastructure (PKI).=C2=A0 OAuth authorization servers are pr= ovided a
=C2=A0 =C2=A0mechanism for binding access tokens to a client's mutual T= LS
=C2=A0 =C2=A0certificate, and OAuth protected resources are provided a meth= od for
=C2=A0 =C2=A0ensuring that such an access token presented to it was issued = to the
=C2=A0 =C2=A0client presenting the token.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtl= s-13
https://datatracker.ietf.org/doc/html/= draft-ietf-oauth-mtls-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-mtls-13


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000004340e60582bf67cc-- From nobody Mon Feb 25 16:57:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A322D12E7C1 for ; Mon, 25 Feb 2019 16:57:20 -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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 162hkHPoNTgr for ; Mon, 25 Feb 2019 16:57:19 -0800 (PST) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0768912E036 for ; Mon, 25 Feb 2019 16:57:18 -0800 (PST) Received: from [IPv6:2601:282:202:b210:8868:dfd:fd8a:935c] (unknown [IPv6:2601:282:202:b210:8868:dfd:fd8a:935c]) by alkaline-solutions.com (Postfix) with ESMTPSA id 1E77931682; Tue, 26 Feb 2019 00:57:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: David Waite In-Reply-To: Date: Mon, 25 Feb 2019 17:57:17 -0700 Cc: Dominick Baier , William Denniss , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <11F45020-9D49-4BF7-882B-9A1F8C47B8E4@alkaline-solutions.com> References: <67bf27b0-e7d6-4710-ba6e-f46809d60d77@getmailbird.com> <5dda37c0-e3c5-5e64-347b-25d561072232@ve7jtb.com> To: Vittorio Bertocci X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [OAUTH-WG] popular apps that use appauth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 00:57:21 -0000 > On Feb 25, 2019, at 4:56 AM, Vittorio Bertocci = wrote: >=20 > The callbacks do avoid the loopback, which is great, but the usability = remains harder than mobile and the embedded case: the auth tab appears = among others, the modal windows remain a possibility, etc - the level of = sophistication of the target audience of the github app can definitely = (hopefully?) navigate those challenges, but for consumer grade apps they = can be blockers. When decision makers are presented with concrete = support costs from customer calls vs possible security issues, it's = often hard to make a case for the latter. True, but these were all a reality when AppAuth first came about as well = - the fall-back was custom URL schemes through the system browser, which = meant an application switch, a new tab, a possible modal prompt to get = the user back to the application, etc. It is a harder problem on desktop operating systems because it is more = challenging to decide if =E2=80=9Cexternal user-agent=E2=80=9D always = means =E2=80=9Csystem browser=E2=80=9D or =E2=80=9Cuser default web = browser=E2=80=9D, and if the latter that means a testing matrix to = understand the UX and limitations. Hypothetically, in some enterprises = external user-agent might even mean =E2=80=9Cthis security product we = bought=E2=80=9D. However, we will see more mandatory sandboxing and hard-to-obtain = entitlements necessary to talk to the resources we want for = authentication. If you are only doing 1P authentication you have a = longer runway than a company who wants to leverage third party or = enterprise-deployed authentication. And to optimize the UX, those = applications may have a period where they decide to include both AppAuth = and non-AppAuth flows. -DW= From nobody Mon Feb 25 23:41:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFA1130E25; Mon, 25 Feb 2019 23:41:20 -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=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME2INyffrDI4; Mon, 25 Feb 2019 23:41:17 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130053.outbound.protection.outlook.com [40.107.13.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DEA128B33; Mon, 25 Feb 2019 23:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wc9nG2LqbckoBlsYqoDyM13j4PSKg5NYjzkwms4SjZg=; b=NQ/HQGBPeTb6Hu3Erk9362b3qEHeYiquVRXzdXIu7pyfdEAXZ/9Bl5ThmEj++3NwF2cdw7LbxrJ6LRH21dohRJExLI0WqnQ9OK7d1WjRiisMdhpKRcghlvzWMvXhrwnEkdeFJF7WVS+39iXgrDpYH/UnxwqRLOvB4eMmyne/890= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Tue, 26 Feb 2019 07:41:13 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3ce6:d8fa:3271:6019%8]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 07:41:13 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef , Brian Campbell CC: "draft-ietf-oauth-resource-indicators@ietf.org" , oauth Thread-Topic: [OAUTH-WG] Resource Indicators - IPR Disclosure Thread-Index: AQHUpEQ1MHe1Hk90RUuBboc1XHW7AaWjyZYAgE2MGgCAAK8DcA== Date: Tue, 26 Feb 2019 07:41:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.223] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30bc39e8-f354-4abc-9913-08d69bbdc895 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 20:tnFfGjqxigzMwNWXVivwD0yck6hp+WHULU4Jr0dq4Sm+YIWJzoklglmDaEK7ZrMmH3Vdl3ydSxER4v2q8OBtREarj6V/DuJ4X6aD+BJXIKh7dsEJI4gXQXXpT3/CrlyAckoXW7ToNXmMKGz9zXIZBUTR8a1nWs50sAGP1UZ+yuY= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(366004)(40434004)(189003)(199004)(8676002)(81166006)(81156014)(446003)(229853002)(790700001)(6116002)(3846002)(186003)(486006)(7736002)(476003)(11346002)(106356001)(606006)(74316002)(26005)(105586002)(14454004)(25786009)(4326008)(5024004)(72206003)(256004)(14444005)(6246003)(9686003)(6306002)(236005)(52536013)(54906003)(102836004)(97736004)(478600001)(53546011)(8936002)(66066001)(71190400001)(71200400001)(966005)(33656002)(110136005)(54896002)(316002)(6436002)(86362001)(68736007)(76176011)(99286004)(6506007)(5660300002)(55016002)(2906002)(7696005)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uKMrTKOOeD21O1jiOEofb5JubD4JeQ9UOTm2vmVFQ8/YwhSvSc/NDCNWwcfw531tlYY801bP+0cd2+mOvoc3U4FZVKgmmDXJdS5ciovGAfkB+KlJ5LID8HIcPacx7pyqEDuVhSmIykoGbmMT2LXw6qKSZ2Pl2VYknFQKVkOsQaLQBD4P2SZQGvBIwVmoEwUAN0/oEHcqgriVCMo9C0aFI4ckzgWsffYCR00iXNOcUGu/0sDDITVZyhqbo9OBEE8koHwOjXy6Vtm2E5bgGuBkrRv1vxkom2BfCGmCeSByHwyQZIefgd6knUDxh349fjV7BwoNb171+oRNWZWDpTc//gtWwifL/lT/awJVTG3SH3IhDy9MGzJnJLAuEVhJZI2dPQKf9evNpksVEYH5jHa5nQqbV4gwGUxx8uIPye/O7AE= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112325190D4DB42B9B8BDA1FA7B0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30bc39e8-f354-4abc-9913-08d69bbdc895 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 07:41:13.4444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 07:41:20 -0000 --_000_VI1PR0801MB2112325190D4DB42B9B8BDA1FA7B0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNCkZy b206IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KU2VudDogTW9u dGFnLCAyNS4gRmVicnVhciAyMDE5IDIyOjE1DQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPg0KQ2M6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9yc0BpZXRmLm9yZzsgb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gUmVzb3VyY2UgSW5kaWNhdG9ycyAtIElQUiBEaXNjbG9zdXJlDQoNCkF1dGhvcnMsDQoN ClNpbmNlIHRoZSBkcmFmdCB3YXMgdXBkYXRlZCByZWNlbnRseSwgd2Ugd291bGQgbGlrZSB0byBn ZXQgYSBuZXcgc3RhdGVtZW50IGZyb20geW91IGFyb3VuZCBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhp cyBzcGVjaWZpY2F0aW9uLg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0 aGUgZm9sbG93aW5nIFJlc291cmNlIEluZGljYXRvcnMgZG9jdW1lbnQ/DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoN ClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gTW9uLCBKYW4gNywgMjAxOSBhdCA4OjAxIEFNIEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVs YXRlZCB0byB0aGlzIGRvY3VtZW50Lg0KDQpPbiBGcmksIEphbiA0LCAyMDE5IGF0IDg6NDMgQU0g UmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5p ZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KQXV0aG9ycywNCg0KQXMgcGFydCBvZiB0aGUgd3JpdGUt dXAgZm9yIHRoZSBSZXNvdXJjZSBJbmRpY2F0b3JzIGRvY3VtZW50LCB3ZSBuZWVkIGFuIElQUiBk aXNjbG9zdXJlIGZyb20gYWxsIG9mIHlvdS4NCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHJl bGF0ZWQgdG8gdGhlIGZvbGxvd2luZyBSZXNvdXJjZSBJbmRpY2F0b3JzIGRvY3VtZW50Pw0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLw0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJp YnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112325190D4DB42B9B8BDA1FA7B0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0g bm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50LiA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0LmlldGZAZ21haWwu Y29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbnRhZywgMjUuIEZlYnJ1YXIgMjAxOSAyMjox NTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzQGlldGYub3JnOyBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlc291cmNlIEluZGljYXRvcnMgLSBJUFIgRGlzY2xv c3VyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdXRob3Jz LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhl IGRyYWZ0IHdhcyB1cGRhdGVkIHJlY2VudGx5LCB3ZSB3b3VsZCBsaWtlIHRvIGdldCBhIG5ldyBz dGF0ZW1lbnQgZnJvbSB5b3UgYXJvdW5kIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIHNwZWNpZmlj YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5BcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGUgZm9s bG93aW5nIFJlc291cmNlIEluZGljYXRvcnMgZG9jdW1lbnQ/PC9zcGFuPiZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9u LCBKYW4gNywgMjAxOSBhdCA4OjAxIEFNIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVk IHRvIHRoaXMgZG9jdW1lbnQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gRnJpLCBKYW4gNCwgMjAxOSBhdCA4OjQzIEFNIFJpZmFhdCBTaGVraC1ZdXNl ZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPkF1dGhvcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+QXMgcGFydCBvZiB0aGUgd3JpdGUtdXAgZm9yIHRoZSBSZXNvdXJjZSBJ bmRpY2F0b3JzIGRvY3VtZW50LCB3ZSBuZWVkIGFuIElQUiBkaXNjbG9zdXJlIGZyb20gYWxsIG9m IHlvdS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5BcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGUgZm9sbG93aW5n IFJlc291cmNlIEluZGljYXRvcnMgZG9jdW1lbnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy8iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO1JpZmFhdDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBk ZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21w dXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0 aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Us DQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsg eW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB2112325190D4DB42B9B8BDA1FA7B0VI1PR0801MB2112_-- From nobody Tue Feb 26 04:06:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4F3130EB9 for ; Tue, 26 Feb 2019 04:06:52 -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=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om9gNDSPHKkC for ; Tue, 26 Feb 2019 04:06:49 -0800 (PST) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82E5130EA0 for ; Tue, 26 Feb 2019 04:06:48 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id o17so13680456wrw.3 for ; Tue, 26 Feb 2019 04:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ZrK/78qAeVlHiQuEXspDNNJ4ZQDTqqLC0LbTdmJh8Q=; b=i/Nnf3F8VBpwP38ki+M8G/PlyTa8+vl84hMlJ1QOw+niPRnU++mCvM2JFEKvQhrD7I Q+1Ca/tOunFK9sG1qPdnoe6imLI2vUKMdlFtoQX44+ozr4l8eCLZ8XA0V8bHY5Dh1U7Y PV9btFyRbrfdAw7m76lw3TZBff2VOWVl1/jio7rVvKeInJtmNUIxa5I1wpOCJWHy7kV7 pjPhgoH1YffwwcdTMuCzAlZV96WdGGKdCGxhoA9r5UXaBHTne69GKwNjGgF6XXPuJ+Cb dhibS2Yg7PLQn59QeIus4ZJAxZwNtQU+pjXv41kZzmPoiryA+QQr8fkmw6xY8AcesiRf qxlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ZrK/78qAeVlHiQuEXspDNNJ4ZQDTqqLC0LbTdmJh8Q=; b=ShXdI1WJXkTj3k20iuXquf1lnT8aFovMCUGBvbRU68wlCrVcpQywkFbrHcqAe2KZRt F/plZABWXt1EY4ysMr9BWg8E57hBXtROmL/lk9oCecyDA9De7DN2hjj4DPgf+BYly7oT +be+lbCYFoQn15NWpnlHxyzyp4Y+5FBXuSYamG9podoLDQNaPgY5A+lIvfAA22lTuPcX lXwYsYJfKGl4dspAkz8p9KeEqdmeo6gaxfmJIwUCulYo8k2l90J8bmZ9N0Ua3WPftHPX dw7R9AfcFEaTr1GSa7PvDwTVYFZk0KAsaPxxgn/uhJwVPU5kdk/48Y1bkpKkl6RTOmns ybJA== X-Gm-Message-State: AHQUAubzCXxWSR3VOYy39/wth4YNwt+eQS6xnP1LNR6zy55nxe3tT0JD xf+XDh7u9CWipXWaivXT1o7FEKvEzIUCn3IM9EhS8g== X-Google-Smtp-Source: AHgI3IbhehugHKARzIC81Hqslqu2fiVllrdld2iFIL1TOzRGBuTfkCGMEYvRmLuov+znDGwzZRSPEpyDFzo0k7A3Kdk= X-Received: by 2002:adf:9167:: with SMTP id j94mr17101325wrj.106.1551182806591; Tue, 26 Feb 2019 04:06:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Bradley Date: Tue, 26 Feb 2019 09:06:34 -0300 Message-ID: To: Hannes Tschofenig Cc: Rifaat Shekh-Yusef , Brian Campbell , "draft-ietf-oauth-resource-indicators@ietf.org" , oauth Content-Type: multipart/alternative; boundary="0000000000002b3ad20582cae48a" Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 12:06:52 -0000 --0000000000002b3ad20582cae48a Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR related to this document On Tue, Feb 26, 2019, 4:41 AM Hannes Tschofenig wrote: > I am not aware of any IPR related to this document. > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Montag, 25. Februar 2019 22:15 > *To:* Brian Campbell > *Cc:* draft-ietf-oauth-resource-indicators@ietf.org; oauth > > *Subject:* Re: [OAUTH-WG] Resource Indicators - IPR Disclosure > > > > Authors, > > > > Since the draft was updated recently, we would like to get a new statement > from you around any IPR related to this specification. > > > > Are you aware of any IPR related to the following Resource Indicators > document? > > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 > > > > Regards, > > Rifaat > > > > > > On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell > wrote: > > I am not aware of any IPR related to this document. > > > > On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef > wrote: > > Authors, > > > > As part of the write-up for the Resource Indicators document, we need an > IPR disclosure from all of you. > > > > Are you aware of any IPR related to the following Resource Indicators > document? > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ > > > > Regards, > > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > --0000000000002b3ad20582cae48a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR related to this document
On T= ue, Feb 26, 2019, 4:41 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

I am not aware of any IPR related to this document. =

=C2=A0

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Sent: Montag, 25. Februar 2019 22:15
To: Brian Campbell <bcampbell@pingidentity.com> Cc: draft-ietf-oauth-resource-indicators@= ietf.org; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure<= u>

=C2=A0

Authors,

=C2=A0

Since the draft was updated recently, we would like = to get a new statement from you around any IPR related to this specificatio= n.

=C2=A0

Are you aware of any IPR related to the following Resource= Indicators document?=C2=A0=C2=A0

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell <bcampbell@pingidentity.com> wrote:

I am not aware of any IPR related to this document. =

=C2=A0

On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef &l= t;rifaat.ietf@gmail.com> wrote:

Authors,

=C2=A0

As part of the write-up for the Resource Indicators document, we need = an IPR disclosure from all of you.

=C2=A0

Are you aware of any IPR related to the following Resource Indicators = document?

=C2=A0

Regards,

=C2=A0Rifaat

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


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--0000000000002b3ad20582cae48a-- From nobody Tue Feb 26 04:09:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749B130EC0 for ; Tue, 26 Feb 2019 04:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzB-N3awK8Mf for ; Tue, 26 Feb 2019 04:08:56 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76844130EA0 for ; Tue, 26 Feb 2019 04:08:56 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id q1so13685014wrp.7 for ; Tue, 26 Feb 2019 04:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=BX2rP5JI5Gps815wO6Ap+ur/1BNxCrD0bgUvbvx5gpg=; b=bu06dW3ALSITQnK6xC3u2TmHUu3PITW+JiMh6QBHjR5N97JkUmNI81g+j8K2/XDm/M dSCAPEhcZMvqSlLJaPV/GOdqH8J+vRt6mGdXLo70seH3OeUobFQaKSP7J39jVYPG6+ES N57wpXmH5jbJvrjY2sqI4+gtCyJPOYD6998Xk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=BX2rP5JI5Gps815wO6Ap+ur/1BNxCrD0bgUvbvx5gpg=; b=LxT5JhwbBrEmd+EQ8yo4zDvcDKSqgFvaYCuSLvrA+Uf3BD41grncSb1WhsaGnCUNXW c/w6T6ZcVHeuX5B+76qf93ma8qr3OEmJTjxSXZOkl9R+DHdznSOka/dgXJxankKOw6ms 8/CmsMe98i1zu3cNMOXmbArcJ1+klk0NkwwWqpAp9zlk5j8VXBpaXF3QPsL3XXB1+LDw CYCGWt9EnWzn1QIjeJXnDNLsRFgMv4aZA2vau1SV5mPYs8pPN6rw7BG0S0W37JWMHQdi Vy8w7U5DPX4tI2Pxp/Jjma6nwrAQmt2WW2uoLbaksHVL+VzBctqGrHoQvX73Y3VoEmZx OQQQ== X-Gm-Message-State: AHQUAuZ/X5byEO5JG4nrn7lk8vEFS26bQxBbvxpw0n0BbNOaZyLKgUkc foACxtJev+UNh60bE/p17KjgWXfqRVg= X-Google-Smtp-Source: AHgI3Ibw+Ch/EL0MYppXFs/9XtB9g88lRyamw3WRRr9NIKP4RK5I8L/b9UAgRjmvApRewRFeumev1A== X-Received: by 2002:adf:e3ce:: with SMTP id k14mr16185587wrm.179.1551182934807; Tue, 26 Feb 2019 04:08:54 -0800 (PST) Received: from guest2s-mbp.lan (173.132.93.209.dyn.plus.net. [209.93.132.173]) by smtp.gmail.com with ESMTPSA id o30sm13524552wro.57.2019.02.26.04.08.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 04:08:53 -0800 (PST) From: Neil Madden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 26 Feb 2019 12:08:51 +0000 References: To: "draft-ietf-oauth-resource-indicators@ietf.org" , oauth In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 12:09:00 -0000 I am not aware of any IPR related to this document. > On 26 Feb 2019, at 12:06, John Bradley wrote: >=20 > I am not aware of any IPR related to this document >=20 > On Tue, Feb 26, 2019, 4:41 AM Hannes Tschofenig = wrote: > I am not aware of any IPR related to this document. >=20 > =20 >=20 > From: Rifaat Shekh-Yusef =20 > Sent: Montag, 25. Februar 2019 22:15 > To: Brian Campbell > Cc: draft-ietf-oauth-resource-indicators@ietf.org; oauth = > Subject: Re: [OAUTH-WG] Resource Indicators - IPR Disclosure >=20 > =20 >=20 > Authors, >=20 > =20 >=20 > Since the draft was updated recently, we would like to get a new = statement from you around any IPR related to this specification. >=20 > =20 >=20 > Are you aware of any IPR related to the following Resource Indicators = document? =20 >=20 > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02 >=20 > =20 >=20 > Regards, >=20 > Rifaat >=20 > =20 >=20 > =20 >=20 > On Mon, Jan 7, 2019 at 8:01 AM Brian Campbell = wrote: >=20 > I am not aware of any IPR related to this document. >=20 > =20 >=20 > On Fri, Jan 4, 2019 at 8:43 AM Rifaat Shekh-Yusef = wrote: >=20 > Authors, >=20 > =20 >=20 > As part of the write-up for the Resource Indicators document, we need = an IPR disclosure from all of you. >=20 > =20 >=20 > Are you aware of any IPR related to the following Resource Indicators = document? >=20 > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ >=20 > =20 >=20 > Regards, >=20 > Rifaat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Feb 26 05:29:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C718C130E5D for ; Tue, 26 Feb 2019 05:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3pe4Pe7NSEV for ; Tue, 26 Feb 2019 05:29:19 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F851200B3 for ; Tue, 26 Feb 2019 05:29:18 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id p18so10451432ioh.5 for ; Tue, 26 Feb 2019 05:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ae+rKgTDMTy9/DQDHDZwJP0LaSILQ65ECBZwL+s/qYE=; b=h11o8AY6wQgxxAgV7XcSksWpy13nyDQOnYYi1T+Ed9pJAQnonxqOPZX3e7IPbCNO+R Zn+udsMqlsGY3ou+m2+cEoxlJy1/nFs2zHW8tF0C07m1DkdTfI4/BpJCaSorz0UBiq3e ivfvBmGQ2m/V5fUqqL44YIRtmBDsFKS8MkzX3yTfEvUhzz8NxMwhZ3rFJNMaX2JJY1oP Pn8SmbUJ0EFch9h26gc8W3+1gP9FTxNpkMLTSGr01HgyrwW0KZFyy8E5lHjAd0xZi03m 6QxMQG0opPzlGci4KtcNn0qea2HYBPdolswV6QXeJvQOus1/VoFmYLZEBoaflnnVc3K2 K6/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ae+rKgTDMTy9/DQDHDZwJP0LaSILQ65ECBZwL+s/qYE=; b=N8I4mhqc4YqNMEJGBAsLRI8UPL26BO8zLy2/fNatqZjICHwZ9TbIr2cxvkUPCZ28QR T2M4Xn+IowhAoprQV5E9/aZgnlx3Y27F1V5Ck2+oee9iD5hAqcR/Y+VKzSqCqKJeUUMB 4IaO1daoUf2voVJE+daKNHFqAlVUequCBO/M6Zi3FmUuXDZ2STVure8RTwd1a5lzecNv LYvedoozHMs/5KAYtlgXP0p9TNOBkIzRw1vzwgsZK1LuWgmmIHIs2UNoi1JJfGF2/5Xj GkOxzKlNuYtHWkRRPlpcrxboBEKxN9DGIhSYZV1B6l5bBPiYh/6xVVhB9HnYYC8/ksVS l3Iw== X-Gm-Message-State: AHQUAuZ2q85EZ/MfxhzSjEOh1H8xjupKQ3tGCfRoaizJYh2doxr/kj0g v2HN9+uGZuHbSpWnnO8E7MaQqO4Km3WZniv3FYKlYWi/9lk= X-Google-Smtp-Source: AHgI3IapTHKCxsGO3PVSa7Rg/LIaEiUma4DH8asQxud+124uHal1xisPI37rcXgj3AvMR15oQfkKzyGtyZFb6uwaJck= X-Received: by 2002:a6b:dd16:: with SMTP id f22mr12297557ioc.148.1551187757564; Tue, 26 Feb 2019 05:29:17 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 26 Feb 2019 08:29:06 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000004508f30582cc0bdf" Archived-At: Subject: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 13:29:21 -0000 --0000000000004508f30582cc0bdf Content-Type: text/plain; charset="UTF-8" All, The following is the updated shepherd write-up for the draft-ietf-oauth-resource-indicators-02 document. https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ Please, take a look and let me know if I missed anything. Regards, Rifaat --0000000000004508f30582cc0bdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

=
The following is the updated shepherd write-up for the draft-ietf-oaut= h-resource-indicators-02 document.

Please, take a look and let me know = if I missed anything.

Regards,
=C2=A0Rif= aat

--0000000000004508f30582cc0bdf-- From nobody Tue Feb 26 08:38:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C027131050 for ; Tue, 26 Feb 2019 08:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNQKaBu--gFr for ; Tue, 26 Feb 2019 08:38:37 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22D0130F28 for ; Tue, 26 Feb 2019 08:38:34 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id p17so10971612iol.7 for ; Tue, 26 Feb 2019 08:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k/yQaGuIHILyzw4oypLHQ36jU6yly8i7Q6R3ZN36dbo=; b=Bta8hOa7jbSLpUEGhfDu24F5eg/l1rYTg5RmVyskfSgrykG/LJ+86Vpu++WB0pD1JC xULWtH+IFvDfdfgm/RJG2usdjIOFelQ4C6gzKoDjYBZVdH/A1AMRLdmx8UyCZeu3o8FV Uhn1+H0Be/dC+XIfXoYqsGROrVJgwsy6g12Jc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k/yQaGuIHILyzw4oypLHQ36jU6yly8i7Q6R3ZN36dbo=; b=GjOJxweob1vjEVcfV9KDO5wxoNIMHk0gkylb/qndmJXwSb5JJz8HOU7Tt9fadl8zPP 0sZqZBrzVzZ6AN5reJgkPwFM38KX3eL9B9j5JjCxlwds9il6OTzJsXiWe8JPKsDqVdRa MkV9jxTzG9kz7dJXKACkvXK91TDbXRD5FYYPhrt7Fvayi8or/6EZFBcTqdlRW9wOofwo Cpb2JXQwV3I4SIVCrafcdxkTn/DGQuR/Hgi87qUxm/a87dXmKSHc94Ft9iN2UJZrba6n dsl312SglLP8Nk2Pm0ekx/R9GK7QO6sXJqB2G4lzO8Txw4q8Ws5qxZVY55A7Fl+5I034 LySQ== X-Gm-Message-State: AHQUAuZLmX950WL1MtFJi0Iii+XQpqD/iReHYS+W/Z5W1ZcuKpQ9LugY 94GTV3p45rRa/IpEVfPBCllpNrvUlKOxgOwwhPeRB154Cs4w8nqfyRiRQbVEvw4Ux7U0TjNVUfm AafVy+UrFKyQ77Q== X-Google-Smtp-Source: AHgI3IYT+C4HYP+gZToueZcpYZMCCs357XzH27C5vkQOhtEIaQTaQ4nBpqjMOyXe28IKQG8by8cTZLks+kUtEXbeLnQ= X-Received: by 2002:a5d:8190:: with SMTP id u16mr14027073ion.238.1551199113936; Tue, 26 Feb 2019 08:38:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Tue, 26 Feb 2019 09:38:07 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000299aef0582ceb05d" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 16:38:40 -0000 --000000000000299aef0582ceb05d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Rifaat, It looks okay to me. I went ahead and fixed the nits in the document source too: https://github.com/ietf-oauth-resource-indicators/i-d/commit/e967f667a02249= 53683833b704f5cc59ce48f96d On Tue, Feb 26, 2019 at 6:29 AM Rifaat Shekh-Yusef wrote: > All, > > The following is the updated shepherd write-up for the > draft-ietf-oauth-resource-indicators-02 document. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/she= pherdwriteup/ > > > Please, take a look and let me know if I missed anything. > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000299aef0582ceb05d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rifaat,

It looks okay to me.



<= /div>

On Tue, Feb 26, 2019 at 6:29 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= /div>
All,

The following i= s the updated shepherd write-up for the draft-ietf-oauth-resource-indicator= s-02 document.

Please, take a look and let me know i= f I missed anything.

Regards,
=C2=A0Rifa= at

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000299aef0582ceb05d-- From nobody Tue Feb 26 18:58:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E96130FC2 for ; Tue, 26 Feb 2019 18:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ClMbfIAgcT7 for ; Tue, 26 Feb 2019 18:58:27 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A75C12E7C1 for ; Tue, 26 Feb 2019 18:58:27 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id f88so13995012uaf.2 for ; Tue, 26 Feb 2019 18:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XbkH3f1tsaCdDlrC4J7PhBqupJxXCDRICJBqItfwdPY=; b=QLOkhOtt+6dgDPpqgeMcvstiU0GdcZkGejy0s+Ck7xhmm3b6dm1Q6aNJLCitPbeC/o pBAX/wVU9hfahDcGF+//LLgWDivIGNNdh+9aoWu4nu49lYjcxEitVwoCDocNAUWkuYM7 gOIea+xYQSj72Z3C19jA3gVWx0OFRedGNZLFa4INRZz2kyotDpZ9oSIEr7KEtNyB75tK ND3ufSUlghYUuqawFJIuTRydmv4M4ajfncrQUOqV38rPP7OWRAXmNoadQWv5izpL3aw0 +ucqF3PXi2o4jT2E8Zv3BBlfVY31jc6OjIv2RJdxs70ybstqzD012T127+QPi278M+Hw fZKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XbkH3f1tsaCdDlrC4J7PhBqupJxXCDRICJBqItfwdPY=; b=ES0sFrBoRDTPssv3a3k6vkO6fc0E735Vg+g0SPtiJtq4AIArLY3q+QqhqJScMvgUKY Nd6NA/OzefcX8vPyEVuiy/jzlwQ3Y8XqwTkkhVQPYMKcDNzab2HPRLYIVky2lFi07xPO rx4P5TBevYKINy9TetnCDKzaBJJ+wndtDp8GTIGqvj2zXbRKp+SzHAqPZbQK+ZQ3vr/R dbLPXubgOmiJc88VGKykq3E4E+q/PgytM0I2d85o6if4dvkCToJ6wkzQbk/LLhAZG9Mo WMR/p1LYN+ZFmr4pxkaD3Lbhj+LGpt9BY5NwTaya4UGGmRsz862dtB2xhJAV8NHGCr8N kyPw== X-Gm-Message-State: AHQUAuZ8UOC7Yt7/ir/8qFWoYrKXKtEHX9mICNVePVOMueqA6UhJnC1G 4hLFhD2d0ToV26BcVAd1HFJoq35b4UIwvgPNvkU= X-Google-Smtp-Source: APXvYqyegGogl7n8ETLxkiQSayd/Ig2oqJwqqbU+aWFWzLfdwftl6+QCJRJ9h3H5C0MG4cAtoaP+cgaE3RIsf5O6STU= X-Received: by 2002:ab0:7605:: with SMTP id o5mr779536uap.59.1551236306268; Tue, 26 Feb 2019 18:58:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sandeep Kaur Date: Wed, 27 Feb 2019 08:28:04 +0530 Message-ID: To: Brian Campbell Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000ff754c0582d75889" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 02:58:29 -0000 --000000000000ff754c0582d75889 Content-Type: text/plain; charset="UTF-8" Hi there I wants to unsubscribe OAUTH WG. Thanks!! Sandeep Kaur On Tue, Feb 26, 2019, 10:08 PM Brian Campbell wrote: > Thanks Rifaat, > > It looks okay to me. > > I went ahead and fixed the nits in the document source too: > https://github.com/ietf-oauth-resource-indicators/i-d/commit/e967f667a0224953683833b704f5cc59ce48f96d > > > > On Tue, Feb 26, 2019 at 6:29 AM Rifaat Shekh-Yusef > wrote: > >> All, >> >> The following is the updated shepherd write-up for the >> draft-ietf-oauth-resource-indicators-02 document. >> >> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/ >> >> >> Please, take a look and let me know if I missed anything. >> >> Regards, >> Rifaat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ff754c0582d75889 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there

I w= ants to unsubscribe OAUTH WG.

Thanks!!
Sandeep Kaur

On Tue, Feb 26, 201= 9, 10:08 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
T= hanks Rifaat,

It looks okay to me.
=




On Tue, Feb 26, 2019 at 6:29 AM Rifaat Shekh-Yusef <rifaat.ie= tf@gmail.com> wrote:
All,
The following is the updated shepherd write-up for the dra= ft-ietf-oauth-resource-indicators-02 document.
<= br>
Please, take a look and let me know if I missed anything.

Regards,
=C2=A0Rifaat

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ff754c0582d75889-- From nobody Tue Feb 26 19:16:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29312950A for ; Tue, 26 Feb 2019 19:16:26 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8rznjkxHAGA for ; Tue, 26 Feb 2019 19:16:23 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC851274D0 for ; Tue, 26 Feb 2019 19:16:23 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id k21so12331214ior.13 for ; Tue, 26 Feb 2019 19:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UpJ3u23oxsfh37PYmACZuffEtq01UpdS+2nRPAlCQVw=; b=HNDAyJFMa6Dh2KeqIHpgdfPwWUePr0U/XJggro9nhl/QEAfYNrmgKvt6IJcQWLe7Ze xzARgqRFc1A6uKrNaNQu3BmddDxu7QjTkWkFRbnVocCu5K6Thy1x0lMcwdMCvBasM+P4 qy583+F7WcLRNyKyxxV//f5cpW1sw1RPy6SLpZPLyykATcmruLPhPNthKS0YlvF4TedO /C2utTG17qrge5Zdyw80b8B0JV0n1TL0CHZ19rBmm67ty7JY0likjtG31H3+ejk7K6LJ ZbMGJGseJVr7dOw+s+JTN0VIq7uTLYy3GWYBjf+aqPhww6tF+SEyWseKpMh7iBjyGyVe ZfjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UpJ3u23oxsfh37PYmACZuffEtq01UpdS+2nRPAlCQVw=; b=mJbQJrcVSl9pv07+o73rV8tD7wuzVl30F780qn844kn5PmT1/x3ZCbZQ1PwwbbnC4g tJnaCIYeH8Vuf8x3eIfOfpkaYNt8NFKPuhQhAQG23jLrCUBOkN8LFHBKVvc+ifPwQbtJ Pa3WIm2agaJwHX4o8uFys0wqp0ykHpd70OTOw1NlUcOU16srheWpB0120F/Ib90E3Fgn e713Q32BDt483Ij8g/Y/X8aVvnZ/ml1MI0U+z5D6lV0F7vw8yYuSl/OvqsskOVpyX6ik 6+amRV1V3AJvLd2thHaotlDIJCnjNnu7v0YRolIamG5nkM8czzst6ZfURLpenG3vEZgt L8uA== X-Gm-Message-State: APjAAAXZu58ZeHGA4Hzjt5k3TODfUCnGMsPd9B0N0rpQcnG11sgZlF0T e8pWlAAla39BGSeF9MLa5jj44iNRsrkRrvegK1k= X-Google-Smtp-Source: APXvYqwCDd9xQOB6lq4wBIISeXq4IHguM3o36y3h5sNPthCAVxXZTA5MZX44BaBl5YkIpqDBucHm1+PnlPYs7VsN9nw= X-Received: by 2002:a6b:dd16:: with SMTP id f22mr829109ioc.148.1551237382708; Tue, 26 Feb 2019 19:16:22 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a4f:8d94:0:0:0:0:0 with HTTP; Tue, 26 Feb 2019 19:16:21 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Tue, 26 Feb 2019 22:16:21 -0500 Message-ID: To: Sandeep Kaur Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000028a30c0582d7994b" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 03:16:26 -0000 --00000000000028a30c0582d7994b Content-Type: text/plain; charset="UTF-8" Use the following link to unsubscribe: https://www.ietf.org/mailman/listinfo/oauth Regards, Rifaat On Tuesday, February 26, 2019, Sandeep Kaur wrote: > Hi there > > I wants to unsubscribe OAUTH WG. > > Thanks!! > Sandeep Kaur > > On Tue, Feb 26, 2019, 10:08 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Thanks Rifaat, >> >> It looks okay to me. >> >> I went ahead and fixed the nits in the document source too: >> https://github.com/ietf-oauth-resource-indicators/i-d/commit/ >> e967f667a0224953683833b704f5cc59ce48f96d >> >> >> >> On Tue, Feb 26, 2019 at 6:29 AM Rifaat Shekh-Yusef >> wrote: >> >>> All, >>> >>> The following is the updated shepherd write-up for the >>> draft-ietf-oauth-resource-indicators-02 document. >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource- >>> indicators/shepherdwriteup/ >>> >>> >>> Please, take a look and let me know if I missed anything. >>> >>> Regards, >>> Rifaat >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited.. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.*_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --00000000000028a30c0582d7994b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Use the following link to unsubscribe:
https://www.ietf.org/mailman/listinfo/oauth

Regards,
=C2=A0Rifaat


On = Tuesday, February 26, 2019, Sandeep Kaur <tsandy1313@gmail.com> wrote:
Hi there

I wants to unsubscribe OAUTH WG.

Thanks!!
Sandeep Kaur

On Tue, Feb 26= , 2019, 10:08 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.i= etf.org> wrote:
Thanks Rifaat,

It = looks okay to me.




On Tue, Feb 26, 201= 9 at 6:29 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:=
All,

The follow= ing is the updated shepherd write-up for the draft-ietf-oauth-resource-indicators-02 document.

Please, take a look and let me know if I missed anything.

<= /div>
Regards,
=C2=A0Rifaat

<= /div>
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th
--00000000000028a30c0582d7994b-- From nobody Tue Feb 26 23:46:24 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866F4130E6B for ; Tue, 26 Feb 2019 23:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3_K6EPSZFZH for ; Tue, 26 Feb 2019 23:46:19 -0800 (PST) Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42B5130DD3 for ; Tue, 26 Feb 2019 23:46:17 -0800 (PST) From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-resource-indicators-02 Thread-Index: AQHUznCDlavViZgLxU6Xzxv4pDGlCw== Date: Wed, 27 Feb 2019 07:46:14 +0000 Message-ID: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.5.136] Content-Type: multipart/alternative; boundary="_000_9A2A24308B1F426296E58F5165AAD4F9iwelcomecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 07:46:22 -0000 --_000_9A2A24308B1F426296E58F5165AAD4F9iwelcomecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgc29tZSBxdWVzdGlvbnMvdGhvdWdodHMgb24gdGhlIG5ldyBkcmFm dCBmb3IgcmVzb3VyY2UgaW5kaWNhdG9ycy4NCkkgZGlkbuKAmXQgZG8gYW4gaW4tZGVwdGggc3R1 ZHkgYnV0IHdvdWxkIGxpa2UgdG8gc2hhcmUgbXkgdGhvdWdodHMgd2l0aCB5b3UgYW55d2F5Lg0K DQoxLiBJbiB0aGlzIGRyYWZ0LCB0aGUgUmVzb3VyY2UgaXMgaWRlbnRpZmllZCBieSDigJhyZXNv dXJjZeKAmSBwYXJhbWV0ZXIuIEZvciBleGFtcGxlLCB3aGVuIHRoZSByZXNvdXJjZSBpcyBhbiBB UEksIEkgd291bGQgZXhwZWN0IHRoYXQgQVBJIHRvIHZhbGlkYXRlIHRoZSBhY2Nlc3NfdG9rZW4g YXQgdGhlIHJlc291cmNlIHNlcnZlci4gVGhlIHByb3RvY29sIGZvciB0aGlzIHdvdWxkIGJlIGJh c2VkIG9uIHRoZSBBUEnigJlzIGNsaWVudF9pZCwgc28gZnJvbSB0aGF0IGFuZ2xlIHVzaW5nIHRo ZSB0aGUgY2xpZW50X2lkIGNvdWxkIGJlIGEgZGlmZmVyZW50IHdheSB0byBpbmRpY2F0ZSB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4uDQoNCjIuIEkgYWxzbyB0aGlu ayB0aGF0IHRoZSDigJhyZXNvdXJjZeKAmSBwYXJhbWV0ZXIgd291bGQgYmUgY2xvc2VseSByZWxh dGVkIHRvIHRoZSDigJxhdWTigJ0gY2xhaW0gc3BlY2lmaWVkIGJ5IHRoZSBPcGVuSUQgQ29ubmVj dCBzcGVjaWZpY2F0aW9ucy4gSSB0aGluayBpdCBpcyBnZXR0aW5nIG1vcmUgYW5kIG1vcmUgY29t bW9uIHRvIHVzZSB0aGUgT0lEQy1wcm90b2NvbCDigJxvbiB0b3Agb2YgT0F1dGjigJ0sIHNvIEni gJltIHdvbmRlcmluZyBob3cgdGhlIHJlc291cmNlIHBhcmFtZXRlciB3b3VsZCByZWxhdGUgdG8g dGhhdC4gVGhlIHZhbHVlcyBvZiB0aGUg4oCYYXVk4oCZIHBhcmFtZXRlciBhcmUgYWxzbyBjbGll bnRfaWTigJlzLg0KDQpUaGFua3MgaW4gYWR2YW5jZSBmb3IgcmVzcG9uZGluZyB0byBteSB2aWV3 cy4NCkNpYW8hDQoNCkphYXAgRnJhbmNrZQ0KDQoNCg0KT24gMjYgRmViIDIwMTksIGF0IDIxOjAw LCBvYXV0aC1yZXF1ZXN0QGlldGYub3JnPG1haWx0bzpvYXV0aC1yZXF1ZXN0QGlldGYub3JnPiB3 cm90ZToNCg0KICAgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNCg== --_000_9A2A24308B1F426296E58F5165AAD4F9iwelcomecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgaGF2ZSBzb21lIHF1ZXN0aW9ucy90aG91 Z2h0cyBvbiB0aGUgbmV3IGRyYWZ0IGZvciByZXNvdXJjZSBpbmRpY2F0b3JzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JIGRpZG7igJl0IGRvIGFuIGluLWRlcHRoIHN0dWR5IGJ1dCB3b3VsZCBsaWtl IHRvIHNoYXJlIG15IHRob3VnaHRzIHdpdGggeW91IGFueXdheS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEuIEluIHRoaXMgZHJhZnQs IHRoZSBSZXNvdXJjZSBpcyBpZGVudGlmaWVkIGJ5IOKAmHJlc291cmNl4oCZIHBhcmFtZXRlci4g Rm9yIGV4YW1wbGUsIHdoZW4gdGhlIHJlc291cmNlIGlzIGFuIEFQSSwgSSB3b3VsZCBleHBlY3Qg dGhhdCBBUEkgdG8gdmFsaWRhdGUgdGhlIGFjY2Vzc190b2tlbiBhdCB0aGUgcmVzb3VyY2Ugc2Vy dmVyLiBUaGUgcHJvdG9jb2wgZm9yIHRoaXMgd291bGQgYmUgYmFzZWQgb24gdGhlIEFQSeKAmXMg Y2xpZW50X2lkLA0KIHNvIGZyb20gdGhhdCBhbmdsZSB1c2luZyB0aGUgdGhlIGNsaWVudF9pZCBj b3VsZCBiZSBhIGRpZmZlcmVudCB3YXkgdG8gaW5kaWNhdGUgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGUgYWNjZXNzIHRva2VuLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Mi4gSSBhbHNvIHRoaW5rIHRoYXQgdGhlIOKAmHJlc291 cmNl4oCZIHBhcmFtZXRlciB3b3VsZCBiZSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhlIOKAnGF1ZOKA nSBjbGFpbSBzcGVjaWZpZWQgYnkgdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRpb25zLiBJ IHRoaW5rIGl0IGlzIGdldHRpbmcgbW9yZSBhbmQgbW9yZSBjb21tb24gdG8gdXNlIHRoZSBPSURD LXByb3RvY29sIOKAnG9uIHRvcCBvZiBPQXV0aOKAnSwgc28gSeKAmW0gd29uZGVyaW5nIGhvdw0K IHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgd291bGQgcmVsYXRlIHRvIHRoYXQuIFRoZSB2YWx1ZXMg b2YgdGhlIOKAmGF1ZOKAmSBwYXJhbWV0ZXIgYXJlIGFsc28gY2xpZW50X2lk4oCZcy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5r cyBpbiBhZHZhbmNlIGZvciByZXNwb25kaW5nIHRvIG15IHZpZXdzLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5DaWFvITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SmFhcCBGcmFuY2tlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAy NiBGZWIgMjAxOSwgYXQgMjE6MDAsIDxhIGhyZWY9Im1haWx0bzpvYXV0aC1yZXF1ZXN0QGlldGYu b3JnIiBjbGFzcz0iIj4NCm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmc8L2E+IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3Bs YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ZHJhZnQt aWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9A2A24308B1F426296E58F5165AAD4F9iwelcomecom_--
Ah yes, that makes sense. Thanks for= clarifying. And it is indeed a good reminder that even a seemingly innocuo= us change that should be backwards compatible can break things unexpectedly= .





On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> = wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that = all the properties in the JSON object returned from our userinfo endpoint w= ere scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that = even a seemingly innocuous change that should be backwards compatible can f= orce more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = Brian Campbell <bcampbell@pin= gidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what c= ould have gone wrong with or how token_endpoint_auth_methods broke somethin= g with the user info endpoint. If you have the time and/or it'd be info= rmative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbell@pin= gidentity.com> wrote:

It may well be due to my own intellectual shortcomin= gs but these issues/questions/confusion-points are not resonating for me as= being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being he= ard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:<= /u>

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless o= nly the implicit grant type is supported.=E2=80=9D So what does the mTLS-on= ly AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to i= nconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier= is incompatible with RFC8414, since some of its contents are only valid fo= r the non-mTLS endpoints, and others are only valid for the mTLS endpoints.= Hence this question.
  4. This introduces a new metadata property that could impact how other specs s= hould extend AS metadata. That needs to be addressed.

    5. =C2=A0

    I could go on for client points but you already get = the point. Though I=E2=80=99ll share that #3 is real and once forced me to = roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98= =83

    =C2=A0

    I don=E2=80=99t necessarily think an AS metadata pro= perty is wrong per se, but understand that you=E2=80=99re bolting a layer o= f flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discussed h= ere sufficiently deals with the fallout from that. In my view this is a com= plex enough issue and it=E2=80=99s for a nuanced enough use case (as far as= I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization S= erver Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the d= oor.

    =C2=A0

    --=C2=A0

    Annabelle Richard Backman

    AWS Identity

    =C2=A0

    =C2=A0

    From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
    Date: Monday, February 4, 2019 at 5:28 AM
    To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
    Cc: oauth <oa= uth@ietf.org>
    Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser = clients using the token endpoint

    =C2=A0

    Those points of confusion strike me as somewhat hypo= thetical or hyperbolic. But your general point is taken and your position o= f being anti additional metadata on this issue is noted.

    =C2=A0

    All of which leaves me a bit uncertain about how to = proceed. There seem to be a range of opinions on this point and gauging con= sensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

    =C2=A0

    And I'd really like to post an update to this dr= aft about a month or two ago.

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

    Confusion from the AS=E2=80=99s perspective:<= u>

    1. If I only support mTLS, do I need to include both token_endpoint_uri and mt= ls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty stri= ng?
    2. What if I only support mTLS for the token endpoint, but not revocation or u= ser info?
    3. How do I specify authentication methods for the mTLS token endpoint? Does t= oken_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
    4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled de= vice_authorization_endpoint under mtls_endpoints?

    =C2=A0

    Confusion from the client=E2=80=99s perspective:<= /u>

    1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2= =80=99 browsers and the AS expects to use that to authenticate me.
    2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoi= nt_uri.
    3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter= a JSON object as a parameter value.
    4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do= I do?
    5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its nam= e, right?

    =C2=A0

    Yes, you can write normative text that answers most = of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-sli= ghtly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for = confusion and failure that do not exist now, and forces them on everyone wh= o supports mTLS. In contrast, the 307 redirect is only required when an AS = wants to support both, and is unambiguous in its behavior and meaning.

    =C2=A0

    --=C2=A0

    Annabelle Richard Backman

    AWS Identity

    =C2=A0

    =C2=A0

    From: Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
    Date: Friday, February 1, 2019 at 3:17 PM
    To: "Richard Backman, Annabelle" <richanna@amazon.com>
    Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
    Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clie= nts using the token endpoint

    =C2=A0

    It doesn't seem like that confusing or large of = a change to me - if the client is doing MTLS and the given endpoint is pres= ent in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deplo= yment options. I personally think getting a 307 approach deployed and worki= ng would be more complicated and error prone.=C2=A0

    =C2=A0

    It is a minority use case at the moment but there ar= e forces in play, like the push for increased security in general and to ha= ve javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS c= lients and javascript/spa clients at the same time.

    =C2=A0

    I've personally wavered back and forth in this t= hread on whether or not to add the new metadata (or something like it). Wit= h my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like= the rough consensus of the group here is in favor of it.

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Anna= belle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

    This strikes me as a very prominent and confusing ch= ange to support what seems to be a minority use case. I=E2=80=99m getting a= headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that= versus using `token_endpoint.` Why is the 307 status code insufficient to = cover the case where a single AS supports both mTLS and non-mTLS?=

    =C2=A0

    --=C2=A0

    Annabelle Richard Backman

    AWS Identity

    =C2=A0

    =C2=A0

    From: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.= org>
    Date: Friday, February 1, 2019 at 1:31 PM
    To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
    Cc: oauth <oa= uth@ietf.org>
    Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token = endpoint

    =C2=A0

    Yes, that would work.=C2=A0

    =C2=A0

    On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <g= ffletch=3D40a= ol.com@dmarc.ietf.org> wrote:

    What if the AS wants to ONLY support MTLS connections. Does = it not specify the optional "mtls_endpoints" and just use the nor= mal metadata values?

    On 1/15/19 8:48 AM, Brian Campbell wrote:<= /u>

    It would definitely be optional, apologies if that w= asn't made clear. It'd be something to the effect of optional for t= he AS to include and clients doing MTLS would use it when present in AS metadata.

    =C2=A0

    On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.tonge@mome= ntumft.co.uk> wrote:

    I'm in favour of the `mtls_endpoints` metadata parameter - = although it should be optional.


    CONFIDENTIALITY NOTICE: This email may co= ntain confidential and privileged material for the sole use of the intended= recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. 

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org=

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

    =C2=A0


    CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


    CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


    CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 I= f you have received this communication in error, please notify the sender i= mmediately by e-mail and delete the message and any file attachments from y= our computer. Thank you.


CONFIDENTIALITY= NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If= you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ffca2c058154a2b7-- From nobody Sat Feb 9 02:09:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85D1311A8 for ; Sat, 9 Feb 2019 02:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u62otLpR5DLj for ; Sat, 9 Feb 2019 02:09:27 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D70130F2F for ; Sat, 9 Feb 2019 02:09:27 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id o125so3663501qkf.3 for ; Sat, 09 Feb 2019 02:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=JreeG75R8iV7VPfEn3QIdXerD1OBbaQFuPg/DhcV8OY=; b=mxFFM/rOQ4FsLEcxoo/1VSz00YUpEWeq7TnoneA+a4lBNioJsdCrLz0HyI6t7OV3Gd QmUGT9gr5KLmUnQVBB10hy4dChMG/rESFp8dqLJsRAeDeUTVki6clw6Lvr58cVheMQJE FxFCKDmr4ddJYKosHxVvMi3O6zF8qsbeAb+PZiE9eFl3kRKxdOaFHrvsT5TDI+Y9NNfq YT478afyjwaF4OLH1Nt+Vcs7QiC825Zn7N+UHVywg/UikNiYEce6ihjwnzFOfNXqyV9L gNY14fwIqDKi0OIHgvzM9TofEXXg0wOpo2buxrPJm+yvfYgKfyfwEIBSZljnab07mb5A LqmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=JreeG75R8iV7VPfEn3QIdXerD1OBbaQFuPg/DhcV8OY=; b=QPCP/y+0rBWGCwrpq2K0TGUYYBML9Sth3f/rxoDeDQ7JZQ3UBXey53NgUHDv15KZDT qFL4+m0O7HC2xpCfAr5vYUC1JHk77v8Eh1ZaYE8CUE053JXSnxavzLQaT7lEIHhTWzFS SF/mfKuX4U5aa3MGy6qgZLqnxKMqixF6bYFzQB81WMzMg78fwRuvqDBouDKWdQSx2LBy X8iIOeTS30H1XIhzi5EklMpY4K9xpw7PFZGLO4cNIYiA3NFVgGwleRo7E1IsPvYBamPw gbT2ikI0bRn7LU24oUJAhkEU42FeqmZ5/Oi6xejd+4W+fej4cnlUbo8PxJzTrc4nneYv 1AUw== X-Gm-Message-State: AHQUAubvj6osIqf0Mi5RjE6ZT568wO/ZMUS2AeInW10+t3DunPeUAflv K/UCBOGU2olwYPqGOTMStGqtBShPWZ5LpNJQz6tkjpI= X-Google-Smtp-Source: AHgI3IbH8jYjrBMxMJ3drqNqcc3Aswx0Kf08YN7bP9G27577a2pD5wT2JM4gjJVxH9VOIShDL+laDU/UrL47halo3UY= X-Received: by 2002:ae9:f113:: with SMTP id k19mr13744686qkg.72.1549706965345; Sat, 09 Feb 2019 02:09:25 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 9 Feb 2019 02:09:24 -0800 From: Dominick Baier In-Reply-To: References: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <54A2B8BD-2794-45B6-969B-E6155A1B7EBE@amazon.com> <18CD2B6D-5FA9-45B1-9334-EB785F40A6A9@amazon.com> MIME-Version: 1.0 Date: Sat, 9 Feb 2019 02:09:24 -0800 Message-ID: To: oauth , Brian Campbell Content-Type: multipart/alternative; boundary="0000000000002d019d05817345c2" Archived-At: Subject: [OAUTH-WG] MTLS token endoint & discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 10:09:31 -0000 --0000000000002d019d05817345c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We are currently implementing MTLS in IdentityServer. Our approach will be that we=E2=80=99ll offer a separate token endpoint tha= t supports client certs. Are you planning on adding an official endpoint name for discovery? Right now we are using =E2=80=9Cmtls_token_endpoint=E2=80=9D= . Thanks =E2=80=94=E2=80=94=E2=80=94 Dominick On 7. February 2019 at 22:36:55, Brian Campbell ( bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly.. On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: > The case I=E2=80=99m referencing didn=E2=80=99t specifically involve AS m= etadata. We had > clients in the wild that assumed that all the properties in the JSON obje= ct > returned from our userinfo endpoint were scalar strings. This broke when = we > introduced a new property whose value was a JSON object. It was a good > reminder that even a seemingly innocuous change that should be backwards > compatible can force more work on clients than we expect. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Wednesday, February 6, 2019 at 11:30 AM > *To:* "Richard Backman, Annabelle" > *Cc:* "Richard Backman, Annabelle" , oauth < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > And I'm honestly really struggling to see what could have gone wrong with > or how token_endpoint_auth_methods broke something with the user info > endpoint. If you have the time and/or it'd be informative to this here > little discussion, please explain that one a bit more. > > > > On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell > wrote: > > "far" should have said "fair" in the previous message > > > > > > > > > > > > On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell > wrote: > > It may well be due to my own intellectual shortcomings but these > issues/questions/confusion-points are not resonating for me as being > problematic. > > > > The more general stance of "this isn't needed or worth it in this > document" (I think that's far?) is being heard though. > > > > > > > > On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > (TL;DR: punt AS metadata to a separate draft) > > AS points #1-3 are all questions I would have as an implementer: > > 1. Section 2 of RFC8414 > says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit gran= t type is > supported.=E2=80=9D So what does the mTLS-only AS put here? > 2. The claims for these other endpoints are OPTIONAL, potentially > leading to inconsistency depending on how #1 gets decided. > 3. The example usage of the token_endpoint_auth_methods property given > earlier is incompatible with RFC8414, since some of its contents are o= nly > valid for the non-mTLS endpoints, and others are only valid for the mT= LS > endpoints. Hence this question. > 4. This introduces a new metadata property that could impact how other > specs should extend AS metadata. That needs to be addressed. > > > > I could go on for client points but you already get the point. Though I= =E2=80=99ll > share that #3 is real and once forced me to roll back an update to the > Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83 > > > > I don=E2=80=99t necessarily think an AS metadata property is wrong per se= , but > understand that you=E2=80=99re bolting a layer of flexibility onto a stan= dard that > wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata = proposal as it=E2=80=99s > been discussed here sufficiently deals with the fallout from that. In my > view this is a complex enough issue and it=E2=80=99s for a nuanced enough= use case > (as far as I can tell from discussion? Please correct me if I=E2=80=99m w= rong) that > we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Serve= r Metadata > Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Monday, February 4, 2019 at 5:28 AM > *To:* "Richard Backman, Annabelle" > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser > clients using the token endpoint > > > > Those points of confusion strike me as somewhat hypothetical or > hyperbolic. But your general point is taken and your position of being an= ti > additional metadata on this issue is noted. > > > > All of which leaves me a bit uncertain about how to proceed. There seem t= o > be a range of opinions on this point and gauging consensus is proving > elusive for me. That's confounded by my own opinion on it being somewhat > fluid. > > > > And I'd really like to post an update to this draft about a month or two > ago. > > > > > > > > > > > > > > On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > Confusion from the AS=E2=80=99s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_ur= i? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-en= abled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client=E2=80=99s perspective: > > 1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t kn= ow anything > about mTLS, but the IT admins installed client certs in their users=E2= =80=99 > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn=E2=80=99t expect to e= ncounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints,= what do > I do? > 5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they = told me to use HTTPS, so > I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right? > > > > Yes, you can write normative text that answers most of these. But you=E2= =80=99ll > have to clearly cover a lot of similar-but-slightly-different scenarios a= nd > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exi= st > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* Brian Campbell > *Date:* Friday, February 1, 2019 at 3:17 PM > *To:* "Richard Backman, Annabelle" > *Cc:* George Fletcher , oauth > *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints= `, > then it uses that one. Otherwise it uses the regular endpoint. It gives = an > AS a lot of flexibility in deployment options. I personally think getting= a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, lik= e > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not t= o > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I=E2=80=99m getting a headache just thin= king about > the text needed to clarify when the AS should provide `mtls_endpoints` an= d > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From:* OAuth on behalf of Brian Campbell > > *Date:* Friday, February 1, 2019 at 1:31 PM > *To:* George Fletcher <40aol.com@dmarc....ietf.org>> > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specif= y > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear. It'= d > be something to the effect of optional for the AS to include and clients > doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf..org/mailman/listinfo/oauth > > > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > * CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > * CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000002d019d05817345c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
We a= re currently implementing MTLS in IdentityServer.

Our approach will be that we=E2=80=99ll offe= r a separate token endpoint that supports client certs. Are you planning on= adding an official endpoint name for discovery? Right now we are using =E2= =80=9Cmtls_token_endpoint=E2=80=9D.

Thanks
=E2=80=94=E2= =80=94=E2=80=94
Dominick

On 7. = February 2019 at 22:36:55, Brian Campbell (bcampbell=3D40pingidentity.com@dmarc.ietf.= org) wrote:

Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good reminder that even a seemingly innocuous change that should be backwards compatible can break things unexpectedly..





On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

The case I=E2=80=99m referencing didn=E2=80=99t spec= ifically involve AS metadata. We had clients in the wild that assumed that all the properties in the JSON object returned from our userinfo endpoint were scalar strings. This broke when we introduced a new property whose value was a JSON object. It was a good reminder that even a seemingly innocuous change that should be backwards compatible can force more work on clients than we expect.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bcampbell@pin= gidentity.com>
Date: Wednesday, February 6, 2019 at 11:30 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <= oauth@ietf.org><= br> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

And I'm honestly really struggling to see what could have gone wrong with or how token_endpoint_auth_methods broke something with the user info endpoint. If you have the time and/or it'd be informative to this here little discussion, please explain that one a bit more.

=C2=A0

On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

"far" should have said "fair" in= the previous message

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampbe= ll@pingidentity.com> wrote:

It may well be due to my own intellectual shortcomings but these issues/questions/confusion-points are not resonating for me as being problematic.

=C2=A0

The more general stance of "this isn't need= ed or worth it in this document" (I think that's far?) is being heard though.

=C2=A0

=C2=A0

=C2=A0

On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

(TL;DR: punt AS metadata to a separate draft)

AS points #1-3 are all questions I would have as an implementer:

  1. Section 2 of RFC8414 says token_endpoint =E2=80=9Cis REQUIRED unless only the implicit grant type is supported.=E2=80=9D So what does the mTLS-only AS put here?
  2. The claims for these other endpoints are OPTIONAL, potentially leading to inconsistency depending on how #1 gets decided.
  3. The example usage of the token_endpoint_auth_methods property given earlier is incompatible with RFC8414, since some of its contents are only valid for the non-mTLS endpoints, and others are only valid for the mTLS endpoints. Hence this question.
  4. This introduces a new metadata property that could impact how other specs should extend AS metadata. That needs to be addressed.

=C2=A0

I could go on for client points but you already get the point. Though I=E2=80=99ll share that #3 is real and once forced me to roll back an update to the Login with Amazon userinfo endpoint=E2=80=A6good times. =F0=9F=98=83

=C2=A0

I don=E2=80=99t necessarily think an AS metadata property is wrong per se, but understand that you=E2=80=99re bolting a layer of flexibility onto a standard that wasn=E2=80=99t designed for that, and I don=E2=80=99t think the metadata proposal as it=E2=80=99s been discus= sed here sufficiently deals with the fallout from that. In my view this is a complex enough issue and it=E2=80=99s for a nuanced enough use case (as far as I can tell from discussion? Please correct me if I=E2=80=99m wrong) that we should punt it to a separate draft (e.g., =E2=80=9CAuthorization Server Metadata Extensions for mTLS Hybrids=E2=80=9D) and get mTLS out the door.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Monday, February 4, 2019 at 5:28 AM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

=C2=A0

Those points of confusion strike me as somewhat hypothetical or hyperbolic. But your general point is taken and your position of being anti additional metadata on this issue is noted.

=C2=A0

All of which leaves me a bit uncertain about how to proceed. There seem to be a range of opinions on this point and gauging consensus is proving elusive for me. That's confounded by my own opinion on it being somewhat fluid.

=C2=A0

And I'd really like to post an update to this draft about a month or two ago.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

Confusion from the AS=E2=80=99s perspective:

  1. If I only support mTLS, do I need to include both token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty string?
  2. What if I only support mTLS for the token endpoint, but not revocation or user info?
  3. How do I specify authentication methods for the mTLS token endpoint? Does token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
  4. I=E2=80=99m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled device_authorization_endpoint under mtls_endpoints?

=C2=A0

Confusion from the client=E2=80=99s perspective:

  1. As far as I know, I=E2=80=99m a public client, and don=E2=80=99t know anyth= ing about mTLS, but the IT admins installed client certs in their users=E2=80=99 browsers and the AS expects to use that to authenticate me.
  2. My AS metadata parser crashed because the mTLS-only AS omitted token_endpoint_uri.
  3. My AS metadata parser crashed because it didn=E2=80=99t expect to encounter a JSON object as a parameter value.
  4. The mTLS-only AS didn=E2=80=99t provide a value for mtls_endpoints, what do I do?
  5. I don=E2=80=99t know what that =E2=80=9Cm=E2=80=9D means, but they told me = to use HTTPS, so I should use the one with =E2=80=9Ctls=E2=80=9D in its name, right?

=C2=A0

Yes, you can write normative text that answers most of these. But you=E2=80=99ll have to clearly cover a lot of similar-but-slightly-different scenarios and be very explicit. And implementers will still get it wrong. The metadata change introduces opportunities for confusion and failure that do not exist now, and forces them on everyone who supports mTLS. In contrast, the 307 redirect is only required when an AS wants to support both, and is unambiguous in its behavior and meaning.

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> Brian Campbell <bc= ampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 3:17 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: George Fletcher <gffletch@aol.com>, oauth <oauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

It doesn't seem like that confusing or large of a change to me - if the client is doing MTLS and the given endpoint is present in `mtls_endpoints`, then it uses that one.=C2=A0 Otherwise it uses the regular endpoint. It gives an AS a lot of flexibility in deployment options. I personally think getting a 307 approach deployed and working would be more complicated and error prone.=C2=A0

=C2=A0

It is a minority use case at the moment but there are forces in play, like the push for increased security in general and to have javascript clients use the code flow, that suggest it won't be terribly unusual to see an AS that wants to support MTLS clients and javascript/spa clients at the same time.

=C2=A0

I've personally wavered back and forth in this thread on whether or not to add the new metadata (or something like it). With my reasoning each way kinda explained somewhere back in the 40 or so messages that make up this thread.=C2=A0 But it seems like the rough consensus of the group here is in favor of it.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

This strikes me as a very prominent and confusing change to support what seems to be a minority use case. I=E2=80=99m getting a headache just thinking about the text needed to clarify when the AS should provide `mtls_endpoints` and when the client should use that versus using `token_endpoint.` Why is the 307 status code insufficient to cover the case where a single AS supports both mTLS and non-mTLS?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From:<= /span> OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>
Date: Friday, February 1, 2019 at 1:31 PM
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

=C2=A0

Yes, that would work.=C2=A0

=C2=A0

On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

What if the AS wants to ONLY support MTLS connections. Does it not specify the optional "mtls_endpoints" an= d just use the normal metadata values?

On 1/15/19 8:48 AM, Brian Campbell wrote:

It would definitely be optional, apologies if that wasn't made clear. It'd be something to the effect of optional for the AS to include and clients doing MTLS would use it when present in AS metadata.

=C2=A0

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.t= onge@momentumft.co.uk> wrote:

I'm in favour of the `mtls_endpoints` metadata parameter - although it should be optional.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
3D"Ping= =
Brian Campbell
Distingui= shed Engineer
<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com
w: +1 720.317.2061 =
c: +1 303.918.9415
= = = =
Connect with us: 3D"Glassdoor 3D"LinkedIn = 3D"twitter 3D"facebook <= a href=3D"https://www.youtube.com/user/PingIdentityTV" style=3D"text-decora= tion:none;margin-right:16px" title=3D"Ping on Youtube" target=3D"_blank"> 3D"Google+ = 3D"Blog