From nobody Sat Feb 1 10:20:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60DF120853 for ; Sat, 1 Feb 2020 10:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.122, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irfHjqy5XTVR for ; Sat, 1 Feb 2020 10:20:41 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 62EAA12012A for ; Sat, 1 Feb 2020 10:20:41 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id s144so11197339wme.1 for ; Sat, 01 Feb 2020 10:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=xigiCnHCx/4exfa7wQt8zwG6JxxvTrwUFjBxo589GzA=; b=dWrRQNKFYcaqgk0Mz4NfeI+mgyRe/vqXaBRaBODQTiS4Crx4cn3+oM4bXf5oecH+a7 ZyxsIiQ7/y2n2Hs5HlsLF9KndpzOLz2UOp3Jx2VDCA+tACCAvmRyvVJJP0pJS82K8tCQ w3tgXqGXxH/5GgO143AjuXtb6Q41DNwfPYveEl9WhhXDomCAJVgGwME3hXydB05tqvx5 bu6+c2rKNMZ01D1/1/I9nFa6aakwatpaEcDzZ5OxJwzYx+JUY9Hit7+OoxN6qb2+pwEl GBa1EjQunalXGbXeLcsWGvoa6fagMKV+OBuUVlX9rabe5svgjtHiqEUY/bwoKHnAfmJ7 09kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=xigiCnHCx/4exfa7wQt8zwG6JxxvTrwUFjBxo589GzA=; b=crZvY5WAHGBILJ0q+AimXidYDydPjZ43EBlGfGG+Aj4PEUUziaf7S6uTaIVIfsUxGF wwtUxssU4kJg7EXroGLyMdFSbEmCzB3USu1WL9wRQBKRKQanJzvvvM3k1Kc8ww0T4INN dtHMQvj1+ILQ5vOSOVja7aqYaRtJdp23hI3S7wxD0AHQVdsVgQ8rr2yFngOJrjEmjWpL 3tn7Qbn+bgmVWDRpzHrBRjt7w1TJCq68QFMS7OhP8v+4YCWTE0LIm/9PV4h/Kp4Og37z 35FT4lI7TeMb3xs7vSIor/ke6SmIBkZuajKewFu9nPap7WaTAQYWsRxP/KqVTyCpWfoi lcFQ== X-Gm-Message-State: APjAAAXEhd5BaYBk4rjiy/E2pKPtG3AAMCNF09MPp224LC5fKoNH8KaU HEjxyjD/uLRXWqswqB2BhCc= X-Google-Smtp-Source: APXvYqzsPqWVxbY0CDs4WH09Gi8RBqv/GKkiivIhBJCGWQjU5ooVFPaTWRDVJu4rpNzq0zekJFtsDQ== X-Received: by 2002:a05:600c:2c06:: with SMTP id q6mr20009177wmg.154.1580581239997; Sat, 01 Feb 2020 10:20:39 -0800 (PST) Received: from [10.0.0.141] (bzq-109-65-61-207.red.bezeqint.net. [109.65.61.207]) by smtp.gmail.com with ESMTPSA id x14sm15612654wmj.42.2020.02.01.10.20.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Feb 2020 10:20:39 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Sat, 01 Feb 2020 20:20:38 +0200 From: Yaron Sheffer To: Dick Hardt , Message-ID: Thread-Topic: [Txauth] use case document? References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3663433239_430383412" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 18:20:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3663433239_430383412 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I support such a document in principle. I agree that having a list of use c= ases would help to scope the protocol document(s). =20 However I think now is not the right time, because a use case document is o= nly useful in defining scope once it is more or less stable and enjoys rough= consensus. We can only demonstrate consensus once we move past the BoF stag= e and into a WG. So I believe it only makes sense to produce the use case do= c when we have a chartered WG. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Txauth on behalf of Dick Hardt Date: Saturday, February 1, 2020 at 00:38 To: Subject: [Txauth] use case document? =20 As I reflect on my conversations with Justin, a set of use cases would help= guide us. We could then refer to a use case as why a feature is present and= see how different features support (or don't support) different use cases. =20 We can also use the document to decide which use cases are in scope, or out= of scope. =20 I'll put up my hand to edit. Who is interested in contributing? =20 /Dick =E1=90=A7 -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3663433239_430383412 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I support such a do= cument in principle. I agree that having a list of use cases would help to s= cope the protocol document(s).

 <= /o:p>

However I think now is not the right time, becau= se a use case document is only useful in defining scope once it is more or l= ess stable and enjoys rough consensus. We can only demonstrate consensus onc= e we move past the BoF stage and into a WG. So I believe it only makes sense= to produce the use case doc when we have a chartered WG.

 

Thanks,

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

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt= <dick.hardt@gmail.com>
Date: Saturday, February 1, 2020 at = 00:38
To: <txauth@ietf.org>
Subject: [Txauth] use = case document?

 = ;

As I reflect on my conversations wi= th Justin, a set of use cases would help guide us. We could then refer to a = use case as why a feature is present and see how different features support = (or don't support) different use cases.

 

We can also use the doc= ument to decide which use cases are in scope, or out of scope.

 

= I'll put up my hand to edit. Who is interested in contributing?

 

/Dick

=E1=90=A7

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman= /listinfo/txauth

--B_3663433239_430383412-- From nobody Sat Feb 1 13:49:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5699912004A for ; Sat, 1 Feb 2020 13:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 4CVpm7ntm5yH for ; Sat, 1 Feb 2020 13:49:21 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9C0851200F9 for ; Sat, 1 Feb 2020 13:49:21 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 011LnGvj019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Feb 2020 16:49:17 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Sat, 1 Feb 2020 16:49:16 -0500 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <18D187E5-1D6A-40C0-8F34-E6F911DF7E67@mit.edu> References: To: Ryo Kato X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on key validations by RS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 21:49:24 -0000 Hi Ryo, You are absolutely right that the =E2=80=9CJWSD=E2=80=9D method from the = spec only works with POST and PUT methods, since it only protects the = body. This is a known major limitation of this method, in addition to it = not protecting headers or adding replay protection. I only put this = method in as a stop-gap demonstration of the concept of a general key = presentation mechanism, and it does manage to work OK for the tx = endpoint (since there=E2=80=99s always a body there). I think it=E2=80=99s= debatable whether the specifics of this method are generally useful. Regardless, for presentation to the RS, I think that HTTP Signing and = MTLS are much more useful general-purpose key binding mechanisms. Even = DPoP, which has its own limitations, is usable across different method = types and could be used here. I think it=E2=80=99s important for TxAuth that the token presentation = mechanism and the client key proofing mechanism used during the = transaction are separable. It makes the most sense for the client to be = able to use the same thing in both places, but I don=E2=80=99t think = that should be a hard equivalence since that puts requirements on the RS = that might not apply. =E2=80=94 Justin > On Jan 31, 2020, at 3:13 PM, Ryo Kato wrote: >=20 > Hi, >=20 > I'm reading the draft 04, and I have some questions now. >=20 > The draft says: > ``` > The Resource Server (RS) accepts tokens from the RC and validates them > ``` > and also > ``` > Any keys presented by the RC to the AS or RS MUST be validated as part = of > the transaction in which they are presented. > ``` >=20 > Therefore, I understand that the *RS* MUST validate the proof of > possession of > RC's keys when accepting tokens from the RC. > (And I understand this procedure is for so called "sender-constrained > token") >=20 > However, I think it is a bit ambiguous about the way for *RS* to > validate that keys. >=20 > Assuming the `proof` parameter is `jwsd`, i.e. Detached JWS. >=20 > The current draft 04 says: >=20 > ``` > the RC takes the serialized body of the request and signs it > ``` >=20 > Yes, RC's transaction (continuation) requests to AS are always HTTP = POST > requests, > and their body is always a non-empty JSON object. >=20 > Whereas, RC's requests to *RS* are not always POST, so they can be = plain > GET requests. > Since GET request body is missing in general, the input for JWS will = be > missing too. >=20 > In this case, what should we take for JWS instead of request body? >=20 > - Ryo >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Feb 1 14:16:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0A412004A for ; Sat, 1 Feb 2020 14:16:35 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWDnUSiNq-02 for ; Sat, 1 Feb 2020 14:16:34 -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 AF505120025 for ; Sat, 1 Feb 2020 14:16:33 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id z26so7163841lfg.13 for ; Sat, 01 Feb 2020 14:16:33 -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=thBLFtguj5m6z4WPBBTGV3dMpWn2x79j74W5GMqrcj0=; b=c8i7jm9nrhjI5Rn/Z19ta6+G2PbgfCik5SF4MmxL9i9NX4cVgbyCgMlgzoFNSgwuuj 8ID+RzIb2SGZGTAJE/O1tYLu768DAT4vr53FmEMJO0QemjRXcy4GbHIOSuiyVJzNX9Pj KUhPcU04fLmqeGSpLjXO8JENs1XHOjFA6SYD5EZKojaJb5kRoH9FEnd6woR/uPoy8Gj5 Tu2rNWY1i+czTe9jG5ldAmY6ctw9VEzk8ceSk9y3ZAUj0oV0xkXOFW95wDOjKP3K9Cyw 7CSTfEAW5wS0FxyithHXaeX5fWtdiQDHpbu+fjs1kkyCUexefGg+UeKu970l2B/etJnM gKAg== 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=thBLFtguj5m6z4WPBBTGV3dMpWn2x79j74W5GMqrcj0=; b=K4ntmzNvx3NXrsH+6D8olkFgS5DPJ+faQIzg2PPCjw3IDp9RVfsSKIs6QySXfCIY9o VpL2PgrP1l9s9vlXZTNijhuNpQI8y6gw74zLUlcSpG81IRcGy/w7fxJ37JfN3lZyxI+W XkjeGCsjemSUBdpuOHIYFUwbknAYNqnYvZfWnYVnoIOqxLR36CHA5UmK06MAXEudD3Fh vxdNt9TrPipOILDLw2MPBxW0oly8e2cy5OfL+djUNZz5Rlt06alB5pvIFXprMCIgkjJD 1PkpTqiCOq1KgSNWj89ayo4Pt8x2UAvIHWOBL6kwfBJuFs6+ZWXYbxidGpdrFReWMepQ cPMw== X-Gm-Message-State: APjAAAV5wyFZ5FiI2DX3HnTvU6bMjT/yLZxxJi/6fDpHb44sTgOFSrj2 IZ3LFVBMDNlprenfLcpCvXVzlfHquCLv/YOO6rc= X-Google-Smtp-Source: APXvYqzuO8ij1E4BRwFjEpZhzmwklbjEiRzi47UH0hEuU0OTm2TfUK4KeyYMYvjhS3CBwGCf+sToi4occyr3zrE5gxE= X-Received: by 2002:a05:6512:78:: with SMTP id i24mr8599950lfo.10.1580595391725; Sat, 01 Feb 2020 14:16:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 1 Feb 2020 14:16:05 -0800 Message-ID: To: Yaron Sheffer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000db8570059d8b0a10" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 22:16:36 -0000 --000000000000db8570059d8b0a10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was thinking a rough draft of a use case document would assist in teasing out what is in scope and not for the WG. I've been adding use cases to the XAuth ID to tease out what would be in and out of scope. It would also provide clarity on why this WG is different from the OAuth WG. On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer wrote= : > I support such a document in principle. I agree that having a list of use > cases would help to scope the protocol document(s). > > > > However I think now is not the right time, because a use case document is > only useful in defining scope once it is more or less stable and enjoys > rough consensus. We can only demonstrate consensus once we move past the > BoF stage and into a WG. So I believe it only makes sense to produce the > use case doc when we have a chartered WG. > > > > Thanks, > > Yaron > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Saturday, February 1, 2020 at 00:38 > *To: * > *Subject: *[Txauth] use case document? > > > > As I reflect on my conversations with Justin, a set of use cases would > help guide us. We could then refer to a use case as why a feature is > present and see how different features support (or don't support) differe= nt > use cases. > > > > We can also use the document to decide which use cases are in scope, or > out of scope. > > > > I'll put up my hand to edit. Who is interested in contributing? > > > > /Dick > > [image: Image removed by sender.]=E1=90=A7 > > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000db8570059d8b0a10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was thinking a rough draft of a use case document would = assist in teasing out what is in scope and not for the WG.

I've been adding use cases to the XAuth ID to tease out what would b= e in and out of scope.

It would also provide clari= ty on why this WG is different from the OAuth WG.=C2=A0=C2=A0
On Sat, = Feb 1, 2020 at 10:20 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I support such a docume= nt in principle. I agree that having a list of use cases would help to scop= e the protocol document(s).

= =C2=A0

However I think now is not the righ= t time, because a use case document is only useful in defining scope once i= t is more or less stable and enjoys rough consensus. We can only demonstrat= e consensus once we move past the BoF stage and into a WG. So I believe it = only makes sense to produce the use case doc when we have a chartered WG.

=C2=A0

Thanks,

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

=C2=A0

<= span style=3D"font-size:12pt;color:black">From: Txauth <txauth-bounces@ietf.org> on behalf of Dick H= ardt <dick.har= dt@gmail.com>
Date: Saturday, February 1, 2020 at 00:38To: <txauth= @ietf.org>
Subject: [Txauth] use case document?<= /u>

=C2=A0

As I reflect on my conversations with Justin= , a set of use cases would help guide us. We could then refer to a use case= as why a feature is present and see how different features support (or don= 't support) different use cases.

=C2=A0

We can als= o use the document to decide which use cases are in scope, or out of scope.=

=C2=A0

I'll put up my hand to edit. Who is intere= sted in contributing?

=C2=A0

/Dick<= u>

3D"Image=E1=90=A7<= /p>

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/m= ailman/listinfo/txauth

--000000000000db8570059d8b0a10-- From nobody Sat Feb 1 14:23:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DBF12004A for ; Sat, 1 Feb 2020 14:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.122, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfSujoq8QUDw for ; Sat, 1 Feb 2020 14:23:28 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 52A1C120025 for ; Sat, 1 Feb 2020 14:23:28 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id y17so13013528wrh.5 for ; Sat, 01 Feb 2020 14:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=Vt7okXLpCCv4vlw7LqIhgQo0jXzsbwQTgjLtbioyhOc=; b=CG7Iuo3fsvQCPvWFpceIgY4eElRBXat6PCyFk5CmlQBFh8y6ppGB91AhuTg8IrVpPQ 74vyTeYrU6vIQz/RA4TdJZSzNZwcwxjffUGZMG3sJBi3xMcilg4S7nOZvbE07DbKYF8w 2B7xmhel5DXbDdifvyI/hqcHZNFvng7VPcmHSi3xHhT8I8fe71s8ytkfYZjfd7ozA+aw 7DoAHXBe3lGtpdsxEUHbbUO1ldJabePT8UyjDN1yvASXoYbfYAEmqEbqBzRAarE7QHH1 M/cYMMb7R+Gy81ormiGcSasGdsD1lwaqIGufKn87zSm+IpkJRhU6Wx+/Koej9aD4gyKJ V3TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=Vt7okXLpCCv4vlw7LqIhgQo0jXzsbwQTgjLtbioyhOc=; b=Fd7hw6M1S6XWDIfW1N1zIGD04TMdjBg/BasKPwKb3e76zXPDkelTZJmUltBuZUFJnU IZj1nHebP6qltuM+Bc1KpCdKVK6+90mi8GsNNcvZpydMKoKoymnWiab2hVm81+gIoMFB mfArXhsBAQV3sBpcYk589zs4k7cV7KpHmUDadOWaQm6HcyLSM+hiFXSIsFlH6fBdBDyT XxaWqxoG8+Rdg98N1ltOZwCrDqPcpTxkfnKMf0/Z3YIK8LX3UQH9NVQp5LpVEPBAo6RO 6YK07Y8CnYHPV1CU5hgH079oerI5jrtLugc/dbtkTvFpK2uT5zpdB1HfY6M/tDJsSB+b tPSw== X-Gm-Message-State: APjAAAVe+vFaFrJpZMiv27GkfUcMtZLGQJ7tYeBf7IZcM+ZnXfpUWCis d6nh+36QH5tR/kpwsvsNRg4= X-Google-Smtp-Source: APXvYqwIhb8nMjt+fizJEo8Z+pFLtunsXjLZc7/x0d6KfKZVFVh8xYFSvUN+LZqof7fdaO1pJdRsOw== X-Received: by 2002:a5d:494f:: with SMTP id r15mr6384697wrs.143.1580595806956; Sat, 01 Feb 2020 14:23:26 -0800 (PST) Received: from [10.0.0.141] (bzq-109-65-61-207.red.bezeqint.net. [109.65.61.207]) by smtp.gmail.com with ESMTPSA id p11sm6132686wrn.40.2020.02.01.14.23.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Feb 2020 14:23:26 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Sun, 02 Feb 2020 00:23:25 +0200 From: Yaron Sheffer To: Dick Hardt CC: Message-ID: Thread-Topic: [Txauth] use case document? References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3663447806_1889458004" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 22:23:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3663447806_1889458004 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, and in particular what=E2=80=99= s *not* in scope, before you have a WG. I am worried about scope creep which= is likely to happen once this is a WG and more people are involved. IMO the= best way to avoid it is by only having this discussion once everybody is on= board. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Dick Hardt Date: Sunday, February 2, 2020 at 00:16 To: Yaron Sheffer Cc: Subject: Re: [Txauth] use case document? =20 I was thinking a rough draft of a use case document would assist in teasing= out what is in scope and not for the WG. =20 I've been adding use cases to the XAuth ID to tease out what would be in an= d out of scope. =20 It would also provide clarity on why this WG is different from the OAuth WG= . =20 =20 On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer wrote= : I support such a document in principle. I agree that having a list of use c= ases would help to scope the protocol document(s). =20 However I think now is not the right time, because a use case document is o= nly useful in defining scope once it is more or less stable and enjoys rough= consensus. We can only demonstrate consensus once we move past the BoF stag= e and into a WG. So I believe it only makes sense to produce the use case do= c when we have a chartered WG. =20 Thanks, Yaron =20 From: Txauth on behalf of Dick Hardt Date: Saturday, February 1, 2020 at 00:38 To: Subject: [Txauth] use case document? =20 As I reflect on my conversations with Justin, a set of use cases would help= guide us. We could then refer to a use case as why a feature is present and= see how different features support (or don't support) different use cases. =20 We can also use the document to decide which use cases are in scope, or out= of scope. =20 I'll put up my hand to edit. Who is interested in contributing? =20 /Dick Error! Filename not specified.=E1=90=A7 -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3663447806_1889458004 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, = and in particular what=E2=80=99s *not* in scope, before you have a WG. I am= worried about scope creep which is likely to happen once this is a WG and m= ore people are involved. IMO the best way to avoid it is by only having this= discussion once everybody is on board.

 

Thanks,

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

 

From: Dick= Hardt <dick.hardt@gmail.com>
Date: Sunday, February 2, 2020= at 00:16
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc= : <txauth@ietf.org>
Subject: Re: [Txauth] use case docum= ent?

 

I was thinking a rough draft of a use case do= cument would assist in teasing out what is in scope and not for the WG.=

 

I've been adding use cases to the XAuth ID to tease out what would = be in and out of scope.

&nb= sp;

It would also provide clarity on = why this WG is different from the OAuth WG.  

=

 

O= n Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I support such a docum= ent in principle. I agree that having a list of use cases would help to scop= e the protocol document(s).

 

However I= think now is not the right time, because a use case document is only useful= in defining scope once it is more or less stable and enjoys rough consensus= . We can only demonstrate consensus once we move past the BoF stage and into= a WG. So I believe it only makes sense to produce the use case doc when we = have a chartered WG.

 

Thanks,

           &n= bsp;    Yaron

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.c= om>
Date: Saturday, February 1, 2020 at 00:38
To: <txauth@ietf.org>= ;
Subject: [Txauth] use case document?

=

 

As I reflect on my conversations wi= th Justin, a set of use cases would help guide us. We could then refer to a = use case as why a feature is present and see how different features support = (or don't support) different use cases.

 

We can also use the document to decide which use cases ar= e in scope, or out of scope.

 

I'll put up my hand to edit. Who is interested in contributing?=

 

/Dick

Error! Filename not specified.=E1=90=A7

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =

--B_3663447806_1889458004-- From nobody Sat Feb 1 14:24:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77312007C for ; Sat, 1 Feb 2020 14:24:44 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haiXvR9SItrK for ; Sat, 1 Feb 2020 14:24:43 -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 C9A94120025 for ; Sat, 1 Feb 2020 14:24:42 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id x14so10763341ljd.13 for ; Sat, 01 Feb 2020 14:24:42 -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=OiP6y2de1qZYeQfEBoDeMlspCAmyP1uyFO58a4fGJBc=; b=jOIc7tfTqhS+GFRDFriDtw5N8SLjIjMRsZGcFC4ay/0LuFxAdhhzKiLtJpXXHXiP8s jGHYwziBTALqkDyrqnBH5vCcVb3ftECS6J/+hEb6f6NGyQuyr1suQ4JAHZ9F3T9TtbGC Hf7+i6GZ7hUteCXm7bMQ1xf9ICazdcYXg0c+tnwA9nW0oRLwWjRh3ZGzQXZAr9KRaVje z0sIy4ZFYpZebIBC5gPDfwK9WnjO3jt32e6m5WORinB2CVvMRHFSQu0vr+aHd+CHBDZh ojwBZaaCFmF28u5vev4VGjPtqX03S4lYAlpucCvzfL+rPoPNRkP0GSl+7e2qCImOdiQj 5Ycg== 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=OiP6y2de1qZYeQfEBoDeMlspCAmyP1uyFO58a4fGJBc=; b=MsXa+y6ytlQqzkDljeVCJwkFocGJdL01ccUL0gE8vhATLdk5hmI9d5YWu4Hx44O5fK SK/TNToPbysEEO4BlLT672fOzxNBfcnYDZ7HRlCaet7LCRyD3zq8OBt+iw0446tPbUno dWdPX63UqHEhq1k+QQ+7rcY+xLwg3Sms//TnKXA+8NbNfy//kFx7ptQW23QJV/xdQaPw ldf4cc/JVQGFq7VN64V+kLc4V+LL2GRqZVEglLgf444+KHFjJsYecpkMrpcLj70czwVV STtqEBCE7xweI0T7/vaRZIJxYvSLrazlB+zkrjVWKUSQ39GKX4NL1wtSS3HpvfkLyMfX M+aA== X-Gm-Message-State: APjAAAV1DAQoszMzvHbN768znEyYiN6k3nk/8hJsmQCL3jZX7aLBtR0Z 4Bnj/2iHEfaRmMiCaJf8gy1hIfRw5Y6RDWagsRE= X-Google-Smtp-Source: APXvYqxDuwAsf5p5e0icXplkHNz51bEdaqalYvu+iqzlDBjDL2uVmP68bWQtm/yv1ZVijbSlsDmvLtNf6/lZvWgczTk= X-Received: by 2002:a2e:865a:: with SMTP id i26mr9839440ljj.236.1580595881011; Sat, 01 Feb 2020 14:24:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 1 Feb 2020 14:24:15 -0800 Message-ID: To: Yaron Sheffer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000056cee059d8b2833" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 22:24:45 -0000 --000000000000056cee059d8b2833 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Works for me. On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer wrote: > It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope,= and in particular what=E2=80=99s **not** > in scope, before you have a WG. I am worried about scope creep which is > likely to happen once this is a WG and more people are involved. IMO the > best way to avoid it is by only having this discussion once everybody is = on > board. > > > > Thanks, > > Yaron > > > > *From: *Dick Hardt > *Date: *Sunday, February 2, 2020 at 00:16 > *To: *Yaron Sheffer > *Cc: * > *Subject: *Re: [Txauth] use case document? > > > > I was thinking a rough draft of a use case document would assist in > teasing out what is in scope and not for the WG. > > > > I've been adding use cases to the XAuth ID to tease out what would be in > and out of scope. > > > > It would also provide clarity on why this WG is different from the OAuth > WG. > > > > On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer > wrote: > > I support such a document in principle. I agree that having a list of use > cases would help to scope the protocol document(s). > > > > However I think now is not the right time, because a use case document is > only useful in defining scope once it is more or less stable and enjoys > rough consensus. We can only demonstrate consensus once we move past the > BoF stage and into a WG. So I believe it only makes sense to produce the > use case doc when we have a chartered WG. > > > > Thanks, > > Yaron > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Saturday, February 1, 2020 at 00:38 > *To: * > *Subject: *[Txauth] use case document? > > > > As I reflect on my conversations with Justin, a set of use cases would > help guide us. We could then refer to a use case as why a feature is > present and see how different features support (or don't support) differe= nt > use cases. > > > > We can also use the document to decide which use cases are in scope, or > out of scope. > > > > I'll put up my hand to edit. Who is interested in contributing? > > > > /Dick > > *Error! Filename not specified.*=E1=90=A7 > > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000056cee059d8b2833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Works for me.

On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer = <yaronf.ietf@gmail.com> = wrote:

It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80= =99s in scope, and in particular what=E2=80=99s *not* in scope, befo= re you have a WG. I am worried about scope creep which is likely to happen = once this is a WG and more people are involved. IMO the best way to avoid i= t is by only having this discussion once everybody is on board.

=C2=A0

Thanks,

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

=C2=A0

From: Dick Hardt <dick.hardt@gmail.com>
Date: Sunday, Februa= ry 2, 2020 at 00:16
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:= <txauth@ietf.o= rg>
Subject: Re: [Txauth] use case document?=

=C2=A0

=

I was thinking a rough draft of a use case docu= ment would assist in teasing out what is in scope and not for the WG.

=C2=A0

=

I've been adding use cases to the XAuth ID to te= ase out what would be in and out of scope.

=C2=A0

It would also provide clarity on why this WG is different from the OAuth = WG.=C2=A0=C2=A0

= =C2=A0

On Sat, Feb 1, 2020 at 10= :20 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I support such a document= in principle. I agree that having a list of use cases would help to scope = the protocol document(s).

=C2=A0=

However I think now is not the right = time, because a use case document is only useful in defining scope once it = is more or less stable and enjoys rough consensus. We can only demonstrate = consensus once we move past the BoF stage and into a WG. So I believe it on= ly makes sense to produce the use case doc when we have a chartered WG.<= /u>

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ya= ron

=C2=A0

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hard= t <dick.hardt@= gmail.com>
Date: Saturday, February 1, 2020 at 00:38
To: <txauth@ie= tf.org>
Subject: [Txauth] use case document?=

=C2=A0

=

As I reflect on my conversations with Justin, a= set of use cases would help guide us. We could then refer to a use case as= why a feature is present and see how different features support (or don= 9;t support) different use cases.

=C2=A0

We can also u= se the document to decide which use cases are in scope, or out of scope.=

=C2=A0

I'll put up my hand to edit. Who is intereste= d in contributing?

=C2=A0

/Dick<= /u>

Error! Filename not specified.=E1= =90=A7

-- Txauth maili= ng list Txauth@ietf.or= g https://www.ietf.org/mailman/listinfo/txauth

--000000000000056cee059d8b2833-- From nobody Sat Feb 1 15:19:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30012004A for ; Sat, 1 Feb 2020 15:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 qgw4G47knx1W for ; Sat, 1 Feb 2020 15:19:28 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9DAF9120025 for ; Sat, 1 Feb 2020 15:19:27 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 011NJIZh007585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Feb 2020 18:19:19 -0500 From: Justin Richer Message-Id: <013B66C6-01E6-4A38-B160-0C999F2EF274@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_36EEAD85-DFAC-4C3E-9750-ED5F25F84F5D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 1 Feb 2020 18:19:18 -0500 In-Reply-To: Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer To: Dick Hardt References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth - a revision of TxAuth X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 23:19:35 -0000 --Apple-Mail=_36EEAD85-DFAC-4C3E-9750-ED5F25F84F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 31, 2020, at 5:28 PM, Dick Hardt wrote: >=20 > On Fri, Jan 31, 2020 at 3:22 AM Justin Richer > wrote: >> On Jan 30, 2020, at 11:13 PM, Dick Hardt > wrote: >> On Thu, Jan 30, 2020 at 1:05 AM Justin Richer > wrote: >> On Jan 30, 2020, at 12:25 AM, Dick Hardt > wrote: >>> On Wed, Jan 29, 2020 at 8:26 AM Justin Richer > wrote: >>> I think XAuth has an interesting take on the problem space that = TxAuth is looking to solve, but in my opinion it generally veers too = closely to OAuth2/OIDC/JWT in its solution approach. >>>=20 >>> Reusing aspects of OAuth2/OIDC/JWT that are working fine for = deployments will minimize the migration effort for them to take = advantage of the security features of this work such as not using the = redirect for passing parameters. I think XAuth supports the following = clause of the current draft charter: "the group will attempt to simplify = porting from OAuth 2.0 and OpenID Connect to the new protocol where = possible.=E2=80=9D >>=20 >> I understand the goals here, but I disagree that using the constructs = as directly as they have been here is the most appropriate approach. >>=20 >> Ok. I think we have reasonable clarity on the disagreement. >> =20 >>=20 >>>=20 >>> >>> =20 >>> 1. XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various = elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a key = abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D is = an identifier to a specific instantiation of a JSON object structure. = Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the = whole Transaction lets you do a lot of core things in a parallel and = reusable way. XAuth re-invents a few of these as separate items, listed = below, and I see this as a regression. >>>=20 >>> XAuth took the transaction handle and forked it into a completion = handle and a refresh handle so that it is clear what the Client is = wanting to happen. >>>=20 >>> It was not clear the value of the other handles that were listed in = XYZ.=20 >>=20 >> I think this may be that you misunderstood the purposes of the = handles, as you=E2=80=99ve reinvented nearly all of them with different = labels in XAuth. :) >>=20 >> I understand what a handle is, and what it represents. It appears = that the handles provide a reference to the display, resource, user, and = key objects. XYZ says the AS may issue those, but I could not find = determine when the AS sends them back to the RC. I understand the value = of the transaction handle XYZ, and built on that in XAuth, but XAuth = always sends the display, resource, user and key information by value, = not by reference, so your statement=20 >>=20 >> you=E2=80=99ve reinvented nearly all of them with different labels in = XAuth >>=20 >> is confusing. >=20 > I think what you=E2=80=99re missing is that the dynamically generated = handles are not the only handles in the system. >=20 > I did not understand that handles could be generated by the AS and = hand configured, and had missed the sentence in Section 2 for each = object that the RC can present a handle instead. >=20 > The Client ID in most deployments is a handle by this definition. The = AS generates it, and the Client presents it in future calls to represent = all the Client information. >=20 > My assumption is you did not want to call them identifiers, as you = want to use the term handle everywhere, and make dynamic handles and = static handles interchangeable. Correct? I wanted =E2=80=9Cstatic=E2=80=9D and =E2=80=9Cdynamic=E2=80=9D handles = to be the same kind of entity, with the only difference being how they = came into existence. What they represent and how they=E2=80=99re used is = the same.=20 As for the term, I didn=E2=80=99t want to use =E2=80=9Cidentifier=E2=80=9D= because that was already weighed down with the history of =E2=80=9Cclient= ID=E2=80=9D and there=E2=80=99s a certain specificity to it that I = didn=E2=80=99t like. I also rejected using =E2=80=9Cartifact=E2=80=9D, = =E2=80=9Cticket=E2=80=9D, and =E2=80=9Ctoken=E2=80=9D for similar = baggage, but =E2=80=9Chandle=E2=80=9D seemed to have the right kind of = connotation for =E2=80=9Cthis is a small simple thing that represents a = big complex thing=E2=80=9D. I=E2=80=99m more than happy to bike shed the = name of this construct, but I feel strongly on the nature of the element = itself. >=20 > It is unclear what value a dynamic display, resource, user, or key = handle has for a given transaction, as the information is all = represented by your transaction handle.=20 >=20 > Static handles, and reusing a dynamic handle in a subsequent request = allows a developer to pass by reference rather than value, but it is not = clear what real benefit that provides over just passing the value.=20 These handles are for use across transactions. It=E2=80=99s an = optimization for where you want to do it. I designed this as an = equivalent to a dynamic client registration, but instead of getting back = a single identifier representing the client (the client ID), you get = back identifiers (which I called handles as per the above) that = represent parts of the presented information. I split them out because each section of the request could vary = independently. One of the things I did when I first started implementing = XYZ was to refactor the request into specific sections that were = somewhat orthogonal and internally related. What=E2=80=99s in there is = what I=E2=80=99d come up with from OAuth 2, OIDC, and UMA: - The key that the client uses to identify itself and protect the = requests to the AS - The things the client needs to display to the user for UX purposes at = the AS - How the client is able to interact with the user (including any = information the AS needs to know in order to get the user back in a = secure way) - Information the client has about the user - Information about the resources the client is requesting =46rom XAuth I think we can also add: - Identity information about the user being requested by the client All of these can be established separately at different points of a = client=E2=80=99s lifecycle. A dynamic client is probably going to want = to call the same AS multiple times, possibly even for multiple users. = Therefore giving it a way to identify its key and its display = information makes sense to me. (I=E2=80=99ll note that I considered = collapsing these two into one, but that didn=E2=80=99t feel right for = reasons I can=E2=80=99t quite articulate yet =E2=80=94 so this is = something to debate during the WG). But the things that it asks for = (resources and identity), the details of interaction, and the = information the client might have about the current user are all things = that we already know are going to vary based on the circumstances of the = request.=20 So why not have all of those be passed by value? Currently in XYZ, = interaction is always passed by value because I=E2=80=99m not convinced = that it should have a shortcut, but I could be wrong there. The ability = to use OAuth2 style scope strings as well as rich objects is something = that I think is clearly desired, both in terms of a means of transition = from OAuth2 but also in terms of making things easier for developers. = The pattern of assigning a human-readable string to a set of API access = details is well established. The user handle, and in particular the = dynamic user handle issued by the AS, is a porting of UMA2=E2=80=99s = =E2=80=9Cpersisted claims token=E2=80=9D, which lets the client say = =E2=80=9CI=E2=80=99m pretty sure this is the same user as before, I=E2=80=99= m just making a new request on that same user=E2=80=99s behalf=E2=80=9D. = The AS can figure out if it needs to interact with the user or not = depending on how much it trusts the client and what is being asked for. = This is particularly useful for step-up authorizations over time.=20 The key handle is a little special in that it can help the AS determine = :how: the rest of the fields could vary, or even which fields could vary = at all, much in the way a client ID does. I called it a key handle = because fundamentally, it represents a way for the AS to reference a = public key in lieu of having the key itself passed by value. >=20 > The transaction handle is different as it represents all the context = the AS has for the transaction, which the Client does not have access = to. All the other handles seem like they are just shorter version, and = are more of an identifier. I agree that the transaction handle is different from the others in some = ways, since it represents an ongoing context. However, I realized that = it has much of the same properties as the rest of them =E2=80=94 in that = it=E2=80=99s a string that stands in for a larger object known by the = AS, it has a value assigned by the AS, and it=E2=80=99s a value = presented by the client. It=E2=80=99s possible that these concepts are = further apart from each other than I think they are, so it=E2=80=99s = something to consider. >=20 > =20 >> What is broken with Client ID? What identifier are you proposing in = XYZ? >=20 > I am proposing that the key information takes the place of the client = ID for all kinds of clients. As discussed below, the key handle is not a = key ID or a key hash =E2=80=94 but more on that in a bit. What=E2=80=99s = important is that it=E2=80=99s an identifier that the AS can look at and = ask itself, =E2=80=9CI=E2=80=99ve seen this ID, what authentication = method and policy should I use for its requests?=E2=80=9D This is the = first step in an OAuth 2 AS implementation, where the AS sees the client = ID and asks =E2=80=9Cwhat authentication method and policy should I use = for this request?=E2=80=9D This is why I see the key handle =E2=80=94 = and not a higher level construct like a client handle / client ID =E2=80=94= as the component that you would branch your decisions off of at the AS. = Once I=E2=80=99ve validated the key, whether by value or by reference, I = now know which client I=E2=80=99m talking to. I don=E2=80=99t need a = separate client identifier. >=20 > Got it. >=20 > So far the Client ID and the key handle look to me to be the same for = Registered Clients. What is the information referenced by a Client ID at = the AS, that would NOT be referenced by a key handle? I=E2=80=99m not sure there=E2=80=99s a clean answer to that question, = but here=E2=80=99s how things look: The redirect URL value (which is now able to vary within rules, as it = can in PAR), the specific display information that the client wants to = use in the context of this request (which might be locale-specific or = context specific), and even the details of a rich request. All of these = could be :limited: by either the key handle or client ID.=20 > =20 > I know that we don=E2=80=99t do it this way in OAuth 2, and I think = that=E2=80=99s a limiting decision that we=E2=80=99ve gotten incorrect. >=20 > Use cases that are limited by that decision would help understand why = you think it was incorrect.=20 It limits us to a model that =E2=80=9Call clients have a single = identifier, and the identifier is the key to all aspects of a client=E2=80= =99s policies.=20 Instead, I think we need to think in terms of =E2=80=9Cwhat can the = presenter of this key do?=E2=80=9D, especially if it=E2=80=99s a key = we=E2=80=99ve never seen before. This kind of thinking allows us to move = beyond a client identifier that the AS already knows into a world where = the AS can make a policy decision based on the authentication properties = of the request. It=E2=80=99s a shift in mental model that I=E2=80=99m = trying to get at here. > =20 >=20 > In the mental model of XYZ, the policy is then tied to whatever = software that key represents, and since keys aren=E2=80=99t shared = between clients, you get the property of a unique identification system = as well. For dynamic clients, they don=E2=80=99t have to send an ID at = all =E2=80=94 they send the key itself by value, since the ID won=E2=80=99= t reference anything that the AS knows about. > So we have an identifier for the clients that want a stable reference, = a method for passing values for clients that don=E2=80=99t have a stable = reference, and a clear way to upgrade from passing by value to passing = by reference for clients that want to do the equivalent of =E2=80=9CDynami= c Registration=E2=80=9D. There are a number of deployments where DynReg = is used :just: to give clients in the field a client ID because OAuth 2 = requires a client ID, and there=E2=80=99s a key that=E2=80=99s = recognized during the DynReg process. But if the server can recognize my = key, I ask: why not just start there when you do the request? You = can=E2=80=99t in OAuth 2 because of the redirect-first model and keys = don=E2=80=99t even show up there. You can in TxAuth because the model = allows the client to talk to the AS directly first, and present its = keys.=20 >=20 >=20 > So calling it a key handle lets you call it the same thing for both = Registered Clients and Dynamic Clients? The advantage to a Dynamic = Client is that it can present a reference instead of its public key = again on subsequent calls? Is there another advantage? >=20 > The AS could also compute a fingerprint of the Dynamic Client key and = use that as its ephemeral identifier for the Dynamic Client. If the AS chooses, it could do that, yes. But the AS might decide it = doesn=E2=80=99t need any kind of =E2=80=9Cidentifier=E2=80=9D for such = an ephemeral client.=20 > =20 > And it=E2=80=99s really important to know that handles do not need to = match or be derived from the information that they represent. >=20 > Yes. I understand what a handle is. =3D) > =20 >=20 > No, my proposal is that a public key is what the AS uses to recognize = a preregistered client, and that public key can be represented by a = handle. I would expect the handle to be stable over time, like a client = ID, but more specific.=20 >=20 > Which public key? XAuth describes how different instances of a = Registered Client can have their own private key, so the matching public = key is different for each Client instance. The Client can have a = certificate signed by a private key matching the public key registered = for the Client at the As.=20 So here we start to see where the OAuth2 model of what a =E2=80=9CClient=E2= =80=9D is breaks down: instances of a client vs. a client. There is no = =E2=80=9Cinstance of a client=E2=80=9D in XYZ, there=E2=80=99s just a = client. If it=E2=80=99s got its own key, it=E2=80=99s its own client, = even if they=E2=80=99re running the exact same software.=20 If you want to tie several pieces of software together, that should be = done at a different layer like we did with the =E2=80=9Csoftware ID=E2=80=9D= in DynReg, or by using information associated with the public keys as = you mention above. So I think ultimately we have the same kind of model = between XYZ and XAuth, but using different terms and underlying imagery.=20= > =20 >=20 > In OAuth 2, the client ID wraps together all of the different aspects = of the client and its associated policies. In XYZ, I sought to separate = those into different handles because, as we=E2=80=99ve found in OAuth 2, = different parts of the client system can vary over time. Our notion of = what a =E2=80=9Cclient=E2=80=9D is in OAuth 2 is also pretty vague. We = have developers all over the place sharing client IDs between different = web servers (production and development environments, for example), = different instances of software (mobile applications, SPAs, and = =E2=80=9Cpublic=E2=80=9D clients), and different pieces of software = altogether (micro-components that are tied together in a single = pseudo-app). >=20 > I don't think it is vague. The "client" is not a specific piece of = software. =46rom the User or RS's perspective, it is the "service" that = was provided the identity claims and/or authorization. They don't want = to have to re-authorize as they move between a mobile client, a desktop = client, or a web client for the same service. Are you sure they don=E2=80=99t want to re-authorize? I would be really = freaked out if I installed Twitter on my phone and it knew my account = information without me telling it. >=20 > What is clearly problematic is sharing the client secret across all of = these places. Implementations I have worked on have centralized the = client secret in one place, and then handed out the access token to the = software component for it to directly call the RS. >=20 > As I discussed above, certificates let a complex Client have each = component independently make calls to the AS. I think those are specific deployment considerations that need to be = discussed and considered.=20 > =20 > =20 > And we also have the explosion of Client IDs for apps using DynReg for = things like ephemeral instances that get used once and then stop = existing.=20 >=20 > As we have discussed, Client IDs for Dynamic Clients is problematic. = The only information an AS has about a Dynamic Client is what it has = done with the Client previously. Note that a mobile app can be a Dynamic = Client, and have a long lifetime. Right, and this is where some of the value of the handles comes in. It = lets a long-lived dynamic client identify itself and its values in = future transactions, without having an explicit, separate = =E2=80=9CRegistration=E2=80=9D step.=20 In other words, XYZ seeks to collapse the discovery, registration, and = authorization-start steps into a single call using a sensible mechanism.=20= > =20 >> The AS would return interaction responses that are the intersection = of: >>=20 >> - methods the client indicates it can do in the request >> - methods the AS knows it can support >> - methods allowed by the policy governing the request >>=20 >> I don=E2=80=99t understand the second part of this question, because = the AS still =E2=80=9Csupports the one the client wants to use=E2=80=9D = in the XYZ model. >>=20 >> I'm looking for a use case where the AS needs to select from a list, = rather than use the one mechanism that the Client wants to use. Why the = extra negotiation? >=20 > The AS isn=E2=80=99t selecting a single value from the list. It=E2=80=99= s responding to what the client wants to use, and it could respond to = all of them. If the client wants to use one mechanism, it sends only one = mechanism. XYZ enables all of the functions of XAuth=E2=80=99s = interaction methods, and then some. >=20 > I understand how it works, and that it is more powerful. It is also = more complex. What does practical value does this provide an = implementor? It allows developers of clients to support multiple interaction methods = simultaneously and not have to pick a single one before they know = what=E2=80=99s possible. It=E2=80=99s the client telling the AS =E2=80=9Ci= f you need to talk to the user, these are the ways that I can do it=E2=80=9D= . If there=E2=80=99s only one way, then the client developer sends only = one way.=20 It allows AS developers to choose the appropriate interaction method = based on the context of the request, including any internal policies = governing consent and information release. So from the other thread you = have a question about the AS knowing whether it has the consent to = release updated claims information to a client, and this lets the client = say with each login request =E2=80=9Cif you need to talk to the user, = these are the ways I can do it=E2=80=9D.=20 And again, having actually implemented both of these types, it=E2=80=99s = actually much LESS complicated to do it the way that XYZ does, on both = the client and AS side. > =20 >=20 >> =20 >>=20 >> As for a concrete example, look at how we handle the =E2=80=9Cqrcode=E2= =80=9D interaction case, based on OAuth 2=E2=80=99s device flow. In = this, you want to send a URI to the client that it can render as a QR = code as well as a code that the user can type into a page, in case they = can=E2=80=99t scan the QR code. OAuth 2 manages this by having a user = code as well as a pre-composed URL containing the code to be used for = rendering. XYZ used to have a mode for this similar to XAuth, but we = realized that we could describe this using two separate flags:=20 >>=20 >> - I can communicate a short code that the user can type in at a = static URL >> - I can get the user to go to an arbitrary URL >>=20 >> The second one is the same mechanism we can use for redirect-based = auth.=20 >>=20 >> I got that. I thought being more crisp in the interaction makes it = easier for implementors to understand.=20 >=20 > I don=E2=80=99t think it=E2=80=99s more crisp, I think it=E2=80=99s = more limiting, and it leads to more confusing code paths. Having = implemented both styles in XYZ in several languages, I vastly prefer the = current XYZ style.=20 >=20 > It is more crisp. And it is more limiting, and I think it leads to = simpler code paths. Again, I=E2=80=99ve implemented this, and the code paths are simpler for = XYZ. I know this because I have written the code paths. The XAuth style = is not more crisp, just more limiting.=20 >=20 > =20 >=20 > When you have the =E2=80=9Ctype=E2=80=9D field, you then have to = specify what different responses mean in the context of different types, = like what XAuth does in =C2=A74.2. In XYZ, the response fields have a = single meaning, and the client does what it can with them. I think = it=E2=80=99s presumptuous to assume =E2=80=9Cqrcode=E2=80=9D as a = scannable format, for instance. >=20 > A QR Code is a scannable format by definition. > =20 > Does the AS actually care how the client communicates the URL to the = user? Not really. >=20 > As I noted in XAuth, the AS does care. While a really long URL works = fine in a redirect or popup, it does not work in a QR code. The AS can = return a short URL for the QR code that redirects to the long URL. The = AS does not want to impose the redirect latency on the redirect or = popup. That=E2=80=99s not really true in either the specific or the abstract. = QR codes don=E2=80=99t have a lot of trouble scaling for rendering. And = if the AS has the capability of having enough information in the short = URL to redirect to a URL that it can actually use, wouldn=E2=80=99t it = just get the information directly at the short URL without a redirect? = Yes you could implement it as a redirect from short to long, but if = you=E2=80=99re worried about latency, then don=E2=80=99t do that. > =20 > Even if we were to optimize this for the client and have the AS return = an image instead of a URL, I think the AS should be able to return an = arbitrary image for the client to display to the user.=20 >=20 > In XAuth I asked if we wanted to allow the Client to over a webview = for the AS to load whatever it wants. Again, it=E2=80=99s all about getting the user in front of the AS with a = web page. I don=E2=80=99t agree that the AS cares much how the user gets = there. >=20 > Additionally, since we are designing all of this to be extensible, if = another use case comes up with a different interaction method, we can = just add a new type. And in XYZ, if there=E2=80=99s a new interaction method, you add a new = flag (or object) to the interaction object to signal that. If the AS = supports it, it can give whatever the appropriate response for that is = to the client. If the AS doesn=E2=80=99t, it can still pick another = type. I=E2=80=99ll note here that in XYZ, you=E2=80=99ve also got the ability = for the client to support a legacy interaction method while a new one = rolls out in parallel. With XAuth, you=E2=80=99ve got to make sure that = it=E2=80=99s supported at every possible AS the client can talk to = before the client makes that switch.=20 > =20 >=20 >>=20 >> =20 >>=20 >>>=20 >>> In the case where the AS interacts with an RO that is not the User, = there would be nothing the Client would need to do. Perhaps there is a = use case for something different? If so, please elaborate. >>> =20 >>>=20 >>> 4. XAuth allows OAuth-style scopes next to RAR-style data structures = (and next to OIDC claims structures). They are treated as completely = separate from each other. In OAuth 2, RAR is defined in the context of = scope (and resource and audience and other parameters), and this = combination is a matter of some debate still that needs to be solved. = However, it=E2=80=99s clear that they=E2=80=99re combined. In XYZ, the = only resource request defined is the object inside the resource request. = You can mimic =E2=80=9Cscope=E2=80=9D behavior by using a Resource = Handle, which again is defined as a single string that stands in for the = whole object and could be defined by the AS (or the API it=E2=80=99s = protecting).=20 >>>=20 >>> I think you need to reread the 00 draft. Only one type of = authorization request is allowed. >>>=20 >>> - OAuth style for deployments where that works fine. >>> - RAR style for deployments that need the extra granularity of RAR >>> - list of RAR style for deployments that support multiple resource = servers that require independent access tokens. >>> =20 >>>=20 >>> 5. The different kinds of authz requests in (4) create separate = tokens.This is very different from both OAuth 2 and XYZ, where you get = back a single access token. And in XAuth there is no way to get, for = example, two access tokens that are both described by RAR requests, so = this seems like a very arbitrary and syntactically-driven separation.=20 >>>=20 >>> I don't think you understood what is in the draft. See above. >>=20 >> Apologies on these points =E2=80=94 I didn=E2=80=99t catch that this = had changed from the earlier drafts.=20 >>=20 >> We can scratch this concern from the list then. Yeah! >=20 > Well, kind of =E2=80=94 XAuth doesn=E2=80=99t allow the combination of = an API-specified element (a scope, a simple string value) and a more = fine grained access request. >=20 > I don't think you went back to reread -00. The oauth-rich type = includes a scope, and an authorizations_details.=20 >=20 > I made that change as it was not clear when I looked at RAR (which is = still developing) that it did not include the scope. I did go back to re-read. It seems that you are re-stating what my = stated assumption was: that the RAR does not include scope internally, = and that since XAuth makes them exclusive with each other then it=E2=80=99= s a choice. What am I missing?=20 > =20 >> Yes. I think freedom from having to make a choice makes things easier = to implement and deploy.=20 >> For deployments where another mechanism will be significantly better, = the choice is available. =E2=80=98 >=20 > These statements contradict each other. Are you advocating for = =E2=80=9Cfreedom from choice=E2=80=9D or that the =E2=80=9Cchoice is = available=E2=80=9D for this particular feature? I am arguing in favor of = making choice available in the case of key presentation and removing = choice in terms of request format (as in, the core payload).=20 >=20 > Freedom from choice: if I don't want to have to make a choice, the = choice is made. These are frequently called defaults. They have proven = useful. =3D) >=20 > Stated another way: here is what you do unless you have a good reason = to do something else.=20 >=20 > While I think JOSE is a better default, I'm open to another method = being a default. I do strongly think there should be a default. What I think is more valuable is a mandatory-to-implement, specifically = for the AS to support. That tends to make a better =E2=80=9Cdefault=E2=80=9D= , especially for security mechanisms like this. I think :what: the = mandatory implement item is can be up for debate. > =20 >=20 >>=20 >> Is there something about JOSE that you think is problematic to make = it the default? >=20 > Yes, it leads to reliance on putting everything of note in the JOSE = payload as part of the base protocol. >=20 > In XAuth, I factored out all the JOSE. Once again, have you read -00, = or -01? >=20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-3 = >=20 > All payloads are JSON. The JOSE section describes how to use JOSE for = message and header signing. >=20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-8 = Yes, I did read; please stop assuming that I haven=E2=80=99t, which you = have done several times in your replies on this thread. In fact, I have = already thanked you for refactoring, and have stated that I think = that=E2=80=99s moving in a good direction. I answered a specific and direct question specific and directly. You = asked what the problem with JOSE as the default was, which is the = question that I answered. I did not state that XAuth, as currently = written, suffers from these deficiencies, but that they are problematic = trends the I have seen in many JOSE-based designs in the past. JOSE = isn=E2=80=99t the problem, over-reliance on JOSE as the sole container = for information is. > =20 > As explained previously, I want to be able to use HTTP as more than an = entity body carrier. We should be using headers and methods and URLs =E2=80= =94 and importantly, content types. >=20 > I agree.=20 >=20 > XAuth uses POST, GET and DELETE >=20 > It uses the Authorization header and different parameters to indicate = the type of token. > It uses content type to indicate what the content type is. This will = assist an AS that supports multiple Client authentication methods=20 Good. > =20 > I think JOSE should be switched with things like Content-Type headers = and Accept headers, and that JSON bodies should be the default as = they=E2=80=99re more universal across different signing and presentation = mechanisms.=20 >=20 > My Java XYZ implementation does use JOSE, but by using JWS in a = detached fashion to sign the body instead of an internal fashion. The = reason for this is that it allows the request and response to be = =E2=80=9Capplication/json=E2=80=9D and not =E2=80=9Capplication/jws=E2=80=9D= .=20 >=20 > Detached signatures work, but I have found them to be problematic in = practice, which is why I chose "application/jws". There is no canonical = form for JSON, so it can get modified, and still be valid JSON, but the = signature does not match. Passing around the signature independent of = the payload is more complex. >=20 > A JWS can be easily passed between components and is self contained, = with no worries that the JSON was modified by parsing and re-serializing = it. I understand and agree with the limitations of detached signatures. This = is the key brilliance of JOSE, and what I love most about it. But the = internal payload also makes it difficult to impossible to incorporate = additional information, such as headers and other bits of context that = we might want to protect.=20 > =20 >=20 > In all of these cases, I do not think it is a good idea to use JWT = claims in the TxAuth request or response namespaces. Where we use JOSE, = we should avoid JWT. >=20 > I agree. JWT is good for claims. Not so good messages. Great.=20 > =20 >=20 > I still agree that they should be able to easily use TxAuth, which = just a stronger argument for the signature/proofing mechanism to be a = pluggable thing and that the request/response bodies not be JOSE objects = but JSON objects. >=20 > We discussed this in early drafts, and XAuth is JSON, with JOSE added = on. Yes, and this is the right way to layer it. But I also think that the = =E2=80=9Cdefault" method should use =E2=80=9Capplication/json=E2=80=9D = specifically, though I could be convinced if there=E2=80=99s a better = approach. > =20 >>=20 >> The word transaction is muddying what I think you are suggesting = here. It more like a conversation. Transactions from a DB point of view = are a set of actions that all happen, or none happen. >=20 > I=E2=80=99ve explained previously that the database interpretation is = not the only or full interpretation of the word =E2=80=9Ctransaction=E2=80= =9D here, so I won=E2=80=99t go back into it. Conversation is perhaps = more accurate, but =E2=80=9CCxAuth=E2=80=9D is a problematic acronym. = :-D >=20 > Naming is hard. =3D) > =20 >=20 >> =20 >>=20 >> Both continuation and refresh are saying to the AS =E2=80=9Crun this = transaction again and if I can get a token (or claims or whatever) in = its current state, give me that=E2=80=9D. However, they can=E2=80=99t = really exist at the same time, so having two separate items to ask the = same question doesn=E2=80=99t make much sense.=20 >>=20 >> They have different purposes. The completion (now authorization) = handle is to check if the AS is done with its request processing, and if = so, provide the results, which includes zero or more identity claims, = and zero or more access tokens/handles. >>=20 >> The refresh handle is to refresh a specific access token/handle. >>=20 >=20 > I don=E2=80=99t see these as being different, and that=E2=80=99s where = we disagree. The access token is the end result of the processing. = Refreshing is an act of continuing that processing. I do not see a good = argument for treating them separately.=20 >=20 > Developers are already familiar with refreshing a token Some are, many get it wrong today.=20 For those that are doing it right today, we=E2=80=99re telling them a = new way to do what they=E2=80=99re already doing that largely amounts to = the same thing they=E2=80=99re doing today: =E2=80=9Ctake this value = that I give you alongside the access token and send it back to me with = your credentials to get a new access token=E2=80=9D. In XYZ that=E2=80=99s= the same exact call that they make to continue the transaction, in = XAuth it=E2=80=99s a different (but similar) call to a different = endpoint. > =20 >=20 >> =20 >>=20 >>>=20 >>> I think a transaction handle is to course grained. I don't think = that the AS should be returning all the claims in a refresh. And if = there are multiple access tokens returned from the AS, then each has = their own refresh handle. >>=20 >> I think this requires a deeper discussion, since the whole idea of = multiple access tokens is a very different kind of approach here.=20 >>=20 >> It is a feature of XAuth.=20 >=20 > Kind of. XAuth allows multiple access tokens in one limited context, = and only when using rich authorization requests to do so. >=20 > Given that existing implementations using scopes only support one = access token, it did not seem limiting to only have a oauth_rich_list, = particularly since a RAR request is a superset of functionality of a = scope request. > =20 > I would rather see us have a general mechanism that allows us to get = multiple access tokens in a way that=E2=80=99s parallel to how you get = one access token. >=20 > A general mechanism sounds fine and dandy. Currently we don't have = other ways to request authorization except for oauth scopes and RAR, = which is a super set of RAR. If and when we need a more general = mechanism, we could define a new type.=20 I think instead we should define a syntactical way to say =E2=80=9CI = want multiple kinds of things and I want them back in different access = tokens=E2=80=9D. Maybe it=E2=80=99s as simple as a list of resource = lists instead of a single list of resources? But I think it=E2=80=99s = cleaner to have them be more in parallel with the single token request.=20= > =20 >=20 >>=20 >> In OAuth today, the bearer token is like a movie ticket. Whoever has = the movie ticket gets in the movie. >> Using OAuth to obtain a bearer token is like buying a movie ticket. >>=20 >> Sometimes I want to go to more than one movie. OAuth today makes me = wait in line to buy each ticket. Why not let me buy multiple tickets at = once? >=20 > That=E2=80=99s not true. You can get one ticket that=E2=80=99s good = for two movies, to borrow your metaphor.=20 >=20 > Which is all you can do in OAuth today. Get one ticket. > =20 >=20 > The semantics of requesting multiple access tokens in parallel is = something the working group might want to consider. I am not a fan of = how XAuth handles this, with packing things into the authorization list. = I think it=E2=80=99s a concept we should consider though. >=20 > If you have other ideas, please share them! So here=E2=80=99s a terrible straw man: taking XYZ=E2=80=99s = =E2=80=9Cresources=E2=80=9D component as the basis, what I=E2=80=99d = like to see is a way for a client to send multiple =E2=80=9Cresources=E2=80= =9D requests in parallel, indicating that it wants several access = tokens. So let=E2=80=99s say the client sends: resources: [ =E2=80=9Cfoo", =E2=80=9Cbar=E2=80=9D, { =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatman=E2=80=9D, =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D } ] Then it means =E2=80=9CI want one access token that does all these three = things=E2=80=9D. But if the client sends: resources: [ [=E2=80=9Cfoo=E2=80=9D], [=E2=80=9Cbar=E2=80=9D], [{ =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatman=E2=80=9D, =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D }] ] Then it means =E2=80=9CI want three access tokens, one for each of these = three things=E2=80=9D.=20 There=E2=80=99s a lot I hate about this syntax (like the fact that it = could be easy to smush the two together and make things really = confusing), so please don=E2=80=99t tear down the specifics of the = example. But the concept of being able to ask for one or more-than-one = of the same kind of thing is what I=E2=80=99m after. We could use two = different field names like XAuth does for the different structures, and = make them mutually exclusive, but that=E2=80=99s got drawbacks too.=20 We could alternatively force the client to pick identifiers for its = different access tokens, like: resources: { =E2=80=9Cfootoken=E2=80=9D: [=E2=80=9Cfoo=E2=80=9D], =E2=80=9Cbartoken": [=E2=80=9Cbar=E2=80=9D], =E2=80=9Cbatmanisnotatoken": [{ =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatman= =E2=80=9D, =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D }] } This means that the client wants three tokens, as above, but that it = wants them back with specific names in the output. So you=E2=80=99d get = something like: access_tokens: { =E2=80=9Cfootoken=E2=80=9D: { value: =E2=80=A6, proof: =E2=80=A6 } =E2=80=9Cbartoken=E2=80=9D: { value: =E2=80=A6., proof: =E2=80=A6. } =E2=80=9Cbatmanisnotatoken=E2=80=9D: { value =E2=80=A6, proof: =E2=80=A6= } } This has the downside of making the client pick values, but the upside = of having a clear way to reference which token goes with which part of = the request. This might be a complex enough use case that making the = client pay the complexity cost might pay off here.=20 The output would need to have similar parallels, regardless of how we do = it. >=20 > To elaborate on my metaphor. >=20 > A family is going to the movies. The Father (one component of the = family), is going to purchase tickets. Billy (age 8) can pick from the G = rated movies. Sally (age 15) can pick from G, PG, and PG-13 movies, and = Father can pick anything.=20 >=20 > Father does not want to buy 3 tickets that are identical and can work = for any movie. (effectively what an access token is today) He only wants = them to go to a movie he has approved, at the time he has selected. >=20 > Father wants to buy 3 different tickets, and give the appropriate = ticket to each child. >=20 > The metaphor breaks down here, but each child needs to be able to = refresh their ticket independent of the other's, which is why a refresh = handle is required. The transaction handle is not granular enough. I understand what you=E2=80=99re describing, but I question how = realistic it is. That would require a very sophisticated client doing a = very specific set of optimizations. Is it worth it doing that kind of = optimization? And it actually makes me wonder if your use case is less of a = =E2=80=9Crefresh=E2=80=9D and more of an =E2=80=9Ctoken exchange=E2=80=9D = with some kind of augmentation. I don=E2=80=99t have a syntax for that = defined in XYZ yet, but it=E2=80=99s in my notes as something we might = want to consider. It=E2=80=99s already in charter because OAuth has = several mechanisms for access token exchange. > =20 >=20 >> =20 >>=20 >> I see refresh much as it is in OAuth2 and UMA, where it refers to the = authorization that was granted. This means that you can do downscoping = to get lower-powered access tokens that are a subset of the overall = grant, and I think that TxAuth should be able to do a step-up auth where = you can build some additional request on top of an existing approval.=20 >>=20 >> Is "step-up auth" authentication or authorization, ... or both? >=20 > I think the question you asked is unintentionally misleading because = =E2=80=9Cstep up=E2=80=9D authentication could be seen from the client = or the AS=E2=80=99s perspective.=20 >=20 > Well, your statement was unclear as "auth" can be one or the other! = =46rom below, you intended authorization. > =20 >=20 > The =E2=80=9Cstep up=E2=80=9D that I mean here is from the client=E2=80=99= s perspective, not from the AS/IdP=E2=80=99s perspective. The client = wants more of something =E2=80=94 more access to an API, more user = information, etc. It=E2=80=99s likely that the AS is going to want to = interact with the user to include whatever additional access the client = is asking for, but the client doesn=E2=80=99t want to start from = scratch. You=E2=80=99ve got a ticket that=E2=80=99s good to see one = movie, and you want to add another movie to it for after. The theater = already knows who you are and how to get your money, so they can just = add it on. >=20 > It=E2=80=99s entirely feasible that the process of asking for more = information would prompt the AS to re-authenticate the user, including = prompting them for additional credentials. However, from the client=E2=80=99= s view, that=E2=80=99s a side-effect of its request. >=20 > The step-up authentication is a policy decision independent of the = Client. The User is having to provide additional authorization. But the user might have to provide it at the request of the client, = because of what the client wants to know about the user (as stated by = the AS). > =20 >> Remembering user consent and delivering claims are two completely = separate problems and should not be conflated here. I was addressing the = former.=20 >>=20 >> They are related though. If you are not wanting to ask for consent on = each delivery, how do you know you have consent? >=20 > We are talking past each other. They=E2=80=99re related in the sense = that they=E2=80=99re both a part of the authorization process, but = consenting to the release of information and the delivery of that = information are completely separate from each other.=20 >=20 > Consent is required to release the information. That is how they are = related.=20 > =20 >=20 > Consent is not the client=E2=80=99s policy, that=E2=80=99s the AS=E2=80=99= s policy. My consent is stored on the AS. >=20 > Maybe. Maybe not. The client can=E2=80=99t know what I consented to, only what it got back = from its request. And it=E2=80=99s certainly in no position to know what = I=E2=80=99ve consented to if it=E2=80=99s asking me to log in, since it = doesn=E2=80=99t know who I am. > =20 > The client can't know if this is the =E2=80=9Cfirst=E2=80=9D time or = not because it doesn=E2=80=99t know who I am yet, so it can=E2=80=99t = ask if I should consent again. If the client knows who I am, it = doesn=E2=80=99t need to ask the AS to log me in in the first place.=20 >=20 > Did you spend anytime looking at my "authentication first" proposal in = -01? Yes. >=20 > The Client asks the AS to authenticate the User, and send that result, = then the Client can decide what, if anything it wants to request for = that User. The AS no longer needs to maintain state. > =20 >=20 > However, once I=E2=80=99m interacting with the AS, the AS has a chance = of figuring things out. The AS can determine if it=E2=80=99s seen the = same client before, if it=E2=80=99s seen the same user before, and if = the same client is making the same request for the same user, and the AS = knows that it can make that decision without prompting the user. We = already do exactly this today with OAuth 2 and OIDC systems.=20 >=20 > Sometimes. Sometimes not. The specifications are mute on saving state. I think you might be reading too much into =E2=80=9Csaving state=E2=80=9D = as being something like a database write operation. I just mean that the = AS needs to know, somehow, that it=E2=80=99s made a decision. There are = a lot of ways to pull that off, including wrapping information about the = user that the client can present again. In fact, XYZ=E2=80=99s =E2=80=9Cuser handle=E2=80=9D construct is a = great way to manage that. > =20 >=20 > But the AS does :not: know which profile and identity claims the = client actually :needs:. The only party able to make that decision is = the client, and it can only make that decision once it has a reference = to which user is there (in terms of an identifier). The AS can (and I = argue should) give the client some kind of key for helping make that = decision.=20 >=20 > The push of user information into an OAuth-protected API, and = separating it from the authentication context, is one of the best parts = of OpenID Connect. Yes, the client can always request the user info as = long as it has the access token =E2=80=94 and to me that=E2=80=99s a = feature, because the client is the component that knows when it needs = updated info.=20 >=20 > This is where consent and delivery are related. If the user info has = been updated, has the User provided consent for the Client to receive = it? The AS is the endpoint that can interact with the user, not the = UserInfo endpoint. >=20 > Why not just go back to the AS and ask for the data again. If consent = is not required, the AS returns the data. If consent is required, the AS = can interact with the User to get it. >=20 > The UserInfo endpoint seems redundant if the Client can get the claims = from the AS. If the client is just going to go back to the AS with a separate call to = get profile information, why conflate it with the transaction request, = especially when doing so can lead to the privacy issues that I=E2=80=99ve = outlined? I=E2=80=99m not convinced the optimization is worth the risk, = much in the way that the implicit flow was an optimization that=E2=80=99s = turned out to be not worth the risk. >=20 > =20 >=20 >> =20 >>=20 >>>=20 >>> Your comments have inspired me on a solution that can be done with = XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC. >>>=20 >>> I'll add that to the XAuth draft and publish it.=20 >>> =20 >>>=20 >>> 11. XAuth defines an explicit discovery step because the client now = needs to know several things about the server. The mix-up attack and a = few other attacks in OAuth 2 stem from this kind of process. In XYZ, the = client really only needs to know the transaction endpoint URL and it = learns everything else from that point. Yes, the client needs to = discover that someplace =E2=80=94 but it was a deliberate decision in = limiting the amount of upfront information that the client needs to get = started. >>>=20 >>> That is still discovery, is it not? >>=20 >> I literally just called it that in the sentence above, so yes. :) = What you=E2=80=99re discovering is different though. And doesn=E2=80=99t = the client still need to =E2=80=9Cdiscover=E2=80=9D the discovery = endpoint in XAuth? >>=20 >> What discovery endpoint? =20 >=20 > The charter currently includes =E2=80=9CAS discovery=E2=80=9D, per = your request to add it. To me, and I would argue to most, = =E2=80=9Cdiscovery=E2=80=9D is a programmatic process. If it=E2=80=99s = manual, it=E2=80=99s not really the client =E2=80=9Cdiscovering=E2=80=9D = anything, it=E2=80=99s being told things manually by a developer. = That=E2=80=99s not discovery as the term is generally known, and I think = this is a key source of confusion here. There is no =E2=80=9Cdiscovery=E2=80= =9D that=E2=80=99s not programmatic =E2=80=94 that=E2=80=99s = configuration. >=20 > I think of discovery is going to the AS and learning what it can do -- = since discovery is learning. That can be the developer going to the AS = docs and reading, or the Client calling a discovery API.=20 >=20 > After manual discovery, the developer decides how to manually = configure the Client, based on what was discovered when reading the = documentation. >=20 > I have found it useful to call out the manual discovery so that = implementors know where the information comes from. IE it is not in the = specification. >=20 I would recommend not using the term =E2=80=9Cdiscovery=E2=80=9D to = refer to this, as I believe =E2=80=9Cdiscovery=E2=80=9D is well-known* = to be a programmatic process. *Pun fully intended. :) =E2=80=94 Justin > =E1=90=A7 --Apple-Mail=_36EEAD85-DFAC-4C3E-9750-ED5F25F84F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jan 31, 2020, at 5:28 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

On Fri, Jan 31, 2020 at 3:22 AM Justin = Richer <jricher@mit.edu> wrote:
On Jan 30, 2020, at 11:13 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:
On Thu, Jan 30, 2020 at 1:05 AM Justin Richer = <jricher@mit.edu> wrote:
On Jan 30, 2020, = at 12:25 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
On Wed, Jan 29, 2020 at 8:26 AM Justin Richer = <jricher@mit.edu> wrote:
I think XAuth has an interesting take on the = problem space that TxAuth is looking to solve, but in my opinion it = generally veers too closely to OAuth2/OIDC/JWT in its solution = approach.

Reusing aspects of OAuth2/OIDC/JWT that = are working fine for deployments will minimize the migration effort for = them to take advantage of the security features of this work such as not = using the redirect for passing parameters. I think XAuth supports the = following clause of the current draft charter: "the group = will attempt to simplify porting from OAuth 2.0 and OpenID Connect = to the new protocol where = possible.=E2=80=9D

I = understand the goals here, but I disagree that using the constructs as = directly as they have been here is the most appropriate = approach.

Ok. I think we have reasonable clarity = on the disagreement.
 


<snip>
 
1. = XAuth removes =E2=80=9Chandles=E2=80=9D as stand-ins for various = elements. In XYZ, the =E2=80=9Chandle=E2=80=9D concept is a key = abstraction point with specific semantics. A =E2=80=9Chandle=E2=80=9D is = an identifier to a specific instantiation of a JSON object structure. = Using the =E2=80=9Chandle=E2=80=9D for Keys, for Resources, and even the = whole Transaction lets you do a lot of core things in a parallel and = reusable way. XAuth re-invents a few of these as separate items, listed = below, and I see this as a = regression.

XAuth took the transaction handle and = forked it into a completion handle and a refresh handle so that it is = clear what the Client is wanting to happen.

It was not clear the value of the other = handles that were listed in = XYZ. 

I think this may = be that you misunderstood the purposes of the handles, as you=E2=80=99ve = reinvented nearly all of them with different labels in XAuth. = :)

I understand what a handle is, and what it represents. It = appears that the handles provide a reference to the display, resource, = user, and key objects. XYZ says the AS may issue those, but I could not = find determine when the AS sends them back to the RC. I understand the = value of the transaction handle XYZ, and built on that in XAuth, but = XAuth always sends the display, resource, user and key information by = value, not by reference, so your statement 

you=E2=80=99ve reinvented nearly all of them with different = labels in XAuth

is confusing.

I think what you=E2=80=99= re missing is that the dynamically generated handles are not the only = handles in the system.

I did not understand that handles could = be generated by the AS and hand configured, and had missed the sentence = in Section 2 for each object that the RC can present a handle = instead.

The = Client ID in most deployments is a handle by this definition. The AS = generates it, and the Client presents it in future calls to represent = all the Client information.

My assumption is you did not want to call them identifiers, = as you want to use the term handle everywhere, and make dynamic handles = and static handles interchangeable. = Correct?

I wanted =E2=80=9Cstatic=E2=80=9D and = =E2=80=9Cdynamic=E2=80=9D handles to be the same kind of entity, with = the only difference being how they came into existence. What they = represent and how they=E2=80=99re used is the same. 

As for the term, I didn=E2=80=99t want to use = =E2=80=9Cidentifier=E2=80=9D because that was already weighed down with = the history of =E2=80=9Cclient ID=E2=80=9D and there=E2=80=99s a certain = specificity to it that I didn=E2=80=99t like. I also rejected using = =E2=80=9Cartifact=E2=80=9D, =E2=80=9Cticket=E2=80=9D, and =E2=80=9Ctoken=E2= =80=9D for similar baggage, but =E2=80=9Chandle=E2=80=9D seemed to have = the right kind of connotation for =E2=80=9Cthis is a small simple thing = that represents a big complex thing=E2=80=9D. I=E2=80=99m more than = happy to bike shed the name of this construct, but I feel strongly on = the nature of the element itself.


It is unclear what value a dynamic display, resource, user, = or key handle has for a given transaction, as the information is all = represented by your transaction handle. 

Static handles, and reusing a dynamic = handle in a subsequent request allows a developer to pass by reference = rather than value, but it is not clear what real benefit that provides = over just passing the = value. 

These handles are for use across transactions. = It=E2=80=99s an optimization for where you want to do it. I designed = this as an equivalent to a dynamic client registration, but instead of = getting back a single identifier representing the client (the client = ID), you get back identifiers (which I called handles as per the above) = that represent parts of the presented information.

I split them out because each section of the = request could vary independently. One of the things I did when I first = started implementing XYZ was to refactor the request into specific = sections that were somewhat orthogonal and internally related. What=E2=80=99= s in there is what I=E2=80=99d come up with from OAuth 2, OIDC, and = UMA:

 - The key that the client = uses to identify itself and protect the requests to the = AS
 - The things the client needs to display to the user = for UX purposes at the AS
 - How the client is able to = interact with the user (including any information the AS needs to know = in order to get the user back in a secure way)
 - = Information the client has about the user
 - Information = about the resources the client is requesting

=46rom XAuth I think we can also = add:

 - Identity information = about the user being requested by the client

All of these can be established separately at = different points of a client=E2=80=99s lifecycle. A dynamic client is = probably going to want to call the same AS multiple times, possibly even = for multiple users. Therefore giving it a way to identify its key and = its display information makes sense to me. (I=E2=80=99ll note that I = considered collapsing these two into one, but that didn=E2=80=99t feel = right for reasons I can=E2=80=99t quite articulate yet =E2=80=94 so this = is something to debate during the WG). But the things that it asks for = (resources and identity), the details of interaction, and the = information the client might have about the current user are all things = that we already know are going to vary based on the circumstances of the = request. 

So why not have all = of those be passed by value? Currently in XYZ, interaction is always = passed by value because I=E2=80=99m not convinced that it should have a = shortcut, but I could be wrong there. The ability to use OAuth2 style = scope strings as well as rich objects is something that I think is = clearly desired, both in terms of a means of transition from OAuth2 but = also in terms of making things easier for developers. The pattern of = assigning a human-readable string to a set of API access details is well = established. The user handle, and in particular the dynamic user handle = issued by the AS, is a porting of UMA2=E2=80=99s =E2=80=9Cpersisted = claims token=E2=80=9D, which lets the client say =E2=80=9CI=E2=80=99m = pretty sure this is the same user as before, I=E2=80=99m just making a = new request on that same user=E2=80=99s behalf=E2=80=9D. The AS can = figure out if it needs to interact with the user or not depending on how = much it trusts the client and what is being asked for. This is = particularly useful for step-up authorizations over = time. 

The key handle is a = little special in that it can help the AS determine :how: the rest of = the fields could vary, or even which fields could vary at all, much in = the way a client ID does. I called it a key handle because = fundamentally, it represents a way for the AS to reference a public key = in lieu of having the key itself passed by value.


The transaction handle is different as = it represents all the context the AS has for the transaction, which the = Client does not have access to. All the other handles seem like they are = just shorter version, and are more of an = identifier.

I agree that the transaction handle is different = from the others in some ways, since it represents an ongoing context. = However, I realized that it has much of the same properties as the rest = of them =E2=80=94 in that it=E2=80=99s a string that stands in for a = larger object known by the AS, it has a value assigned by the AS, and = it=E2=80=99s a value presented by the client. It=E2=80=99s possible that = these concepts are further apart from each other than I think they are, = so it=E2=80=99s something to consider.


 
What is broken = with Client ID? What identifier are you proposing in = XYZ?

I am proposing that the key information = takes the place of the client ID for all kinds of clients. As discussed = below, the key handle is not a key ID or a key hash =E2=80=94 but more = on that in a bit. What=E2=80=99s important is that it=E2=80=99s an = identifier that the AS can look at and ask itself, =E2=80=9CI=E2=80=99ve = seen this ID, what authentication method and policy should I use for its = requests?=E2=80=9D This is the first step in an OAuth 2 AS = implementation, where the AS sees the client ID and asks =E2=80=9Cwhat = authentication method and policy should I use for this request?=E2=80=9D = This is why I see the key handle =E2=80=94 and not a higher level = construct like a client handle / client ID =E2=80=94 as the component = that you would branch your decisions off of at the AS. Once I=E2=80=99ve = validated the key, whether by value or by reference, I now know which = client I=E2=80=99m talking to. I don=E2=80=99t need a separate client = identifier.

Got it.

So far the Client ID and the key handle = look to me to be the same for Registered Clients. What is the = information referenced by a Client ID at the AS, that would NOT be = referenced by a key handle?

I=E2=80=99m not sure there=E2=80=99s a clean = answer to that question, but here=E2=80=99s how things = look:

The redirect URL value (which = is now able to vary within rules, as it can in PAR), the specific = display information that the client wants to use in the context of this = request (which might be locale-specific or context specific), and even = the details of a rich request. All of these could be :limited: by either = the key handle or client ID. 

 
I know that we = don=E2=80=99t do it this way in OAuth 2, and I think that=E2=80=99s a = limiting decision that we=E2=80=99ve gotten = incorrect.

Use cases that are limited by that = decision would help understand why you think it was = incorrect. 

It limits us to a model that =E2=80=9Call clients = have a single identifier, and the identifier is the key to all aspects = of a client=E2=80=99s policies. 

Instead, I think we need to think in terms of = =E2=80=9Cwhat can the presenter of this key do?=E2=80=9D, especially if = it=E2=80=99s a key we=E2=80=99ve never seen before. This kind of = thinking allows us to move beyond a client identifier that the AS = already knows into a world where the AS can make a policy decision based = on the authentication properties of the request. It=E2=80=99s a shift in = mental model that I=E2=80=99m trying to get at here.

 

In the mental model of = XYZ, the policy is then tied to whatever software that key represents, = and since keys aren=E2=80=99t shared between clients, you get the = property of a unique identification system as well. For dynamic clients, = they don=E2=80=99t have to send an ID at all =E2=80=94 they send the key = itself by value, since the ID won=E2=80=99t reference anything that the = AS knows about.
So we have an = identifier for the clients that want a stable reference, a method for = passing values for clients that don=E2=80=99t have a stable reference, = and a clear way to upgrade from passing by value to passing by reference = for clients that want to do the equivalent of =E2=80=9CDynamic = Registration=E2=80=9D. There are a number of deployments where DynReg is = used :just: to give clients in the field a client ID because OAuth 2 = requires a client ID, and there=E2=80=99s a key that=E2=80=99s = recognized during the DynReg process. But if the server can recognize my = key, I ask: why not just start there when you do the request? You = can=E2=80=99t in OAuth 2 because of the redirect-first model and keys = don=E2=80=99t even show up there. You can in TxAuth because the model = allows the client to talk to the AS directly first, and present its = keys. 


So calling it a key handle lets you call it the same thing = for both Registered Clients and Dynamic Clients? The advantage to a = Dynamic Client is that it can present a reference instead of its public = key again on subsequent calls? Is there another advantage?

The AS could also = compute a fingerprint of the Dynamic Client key and use that as its = ephemeral identifier for the Dynamic = Client.

If the AS chooses, it could do that, yes. But the = AS might decide it doesn=E2=80=99t need any kind of =E2=80=9Cidentifier=E2= =80=9D for such an ephemeral client. 

  
And it=E2=80=99s really important to know = that handles do not need to match or be derived from the information = that they represent.

Yes. I understand what a handle is. = =3D)
 

No, my proposal is that a public key is what the AS uses to = recognize a preregistered client, and that public key can be represented = by a handle. I would expect the handle to be stable over time, like a = client ID, but more specific. 

Which public key?  = XAuth describes how different instances of a Registered Client can have = their own private key, so the matching public key is different for each = Client instance. The Client can have a certificate signed by a private = key matching the public key registered for the Client at the = As. 

So here we start to see where the OAuth2 model of = what a =E2=80=9CClient=E2=80=9D is breaks down: instances of a client = vs. a client. There is no =E2=80=9Cinstance of a client=E2=80=9D in XYZ, = there=E2=80=99s just a client. If it=E2=80=99s got its own key, it=E2=80=99= s its own client, even if they=E2=80=99re running the exact same = software. 

If you want to tie = several pieces of software together, that should be done at a different = layer like we did with the =E2=80=9Csoftware ID=E2=80=9D in DynReg, or = by using information associated with the public keys as you mention = above. So I think ultimately we have the same kind of model between XYZ = and XAuth, but using different terms and underlying = imagery. 

 

In OAuth 2, the client = ID wraps together all of the different aspects of the client and its = associated policies. In XYZ, I sought to separate those into different = handles because, as we=E2=80=99ve found in OAuth 2, different parts of = the client system can vary over time. Our notion of what a =E2=80=9Cclient= =E2=80=9D is in OAuth 2 is also pretty vague. We have developers all = over the place sharing client IDs between different web servers = (production and development environments, for example), different = instances of software (mobile applications, SPAs, and =E2=80=9Cpublic=E2=80= =9D clients), and different pieces of software altogether = (micro-components that are tied together in a single = pseudo-app).

I don't think it is vague. The "client" = is not a specific piece of software. =46rom the User or RS's = perspective, it is the "service" that was provided the identity claims = and/or authorization. They don't want to have to re-authorize as they = move between a mobile client, a desktop client, or a web client for the = same service.

Are you sure they don=E2=80=99t want to = re-authorize? I would be really freaked out if I installed Twitter on my = phone and it knew my account information without me telling it.


What is clearly problematic is sharing = the client secret across all of these places. Implementations I have = worked on have centralized the client secret in one place, and then = handed out the access token to the software component for it to directly = call the RS.

As I discussed above, = certificates let a complex Client have each component independently make = calls to the AS.

I think those are specific deployment = considerations that need to be discussed and considered. 

  
 
And we also have = the explosion of Client IDs for apps using DynReg for things like = ephemeral instances that get used once and then stop = existing. 

As we have discussed, Client IDs for = Dynamic Clients is problematic. The only information an AS has about a = Dynamic Client is what it has done with the Client previously. Note that = a mobile app can be a Dynamic Client, and have a long = lifetime.

Right, and this is where some of the value of the = handles comes in. It lets a long-lived dynamic client identify itself = and its values in future transactions, without having an explicit, = separate =E2=80=9CRegistration=E2=80=9D step. 

In other words, XYZ seeks to collapse the = discovery, registration, and authorization-start steps into a single = call using a sensible mechanism. 

 
The AS would return = interaction responses that are the intersection of:

 - methods the = client indicates it can do in the request
 - = methods the AS knows it can support
 - methods = allowed by the policy governing the request

I don=E2=80=99t understand the second = part of this question, because the AS still =E2=80=9Csupports the one = the client wants to use=E2=80=9D in the XYZ = model.

I'm looking for a use case where the AS = needs to select from a list, rather than use the one mechanism that the = Client wants to use. Why the extra = negotiation?

The AS isn=E2=80=99t selecting a single = value from the list. It=E2=80=99s responding to what the client wants to = use, and it could respond to all of them. If the client wants to use one = mechanism, it sends only one mechanism. XYZ enables all of the functions = of XAuth=E2=80=99s interaction methods, and then = some.

I understand how it works, and that it = is more powerful. It is also more complex. What does practical value = does this provide an = implementor?

It allows developers of clients to support = multiple interaction methods simultaneously and not have to pick a = single one before they know what=E2=80=99s possible. It=E2=80=99s the = client telling the AS =E2=80=9Cif you need to talk to the user, these = are the ways that I can do it=E2=80=9D. If there=E2=80=99s only one way, = then the client developer sends only one way. 

It allows AS developers to choose the appropriate = interaction method based on the context of the request, including any = internal policies governing consent and information release. So from the = other thread you have a question about the AS knowing whether it has the = consent to release updated claims information to a client, and this lets = the client say with each login request =E2=80=9Cif you need to talk to = the user, these are the ways I can do it=E2=80=9D. 

And again, having actually implemented both of = these types, it=E2=80=99s actually much LESS complicated to do it the = way that XYZ does, on both the client and AS side.

 

 

As for a concrete example, look at how we handle the = =E2=80=9Cqrcode=E2=80=9D interaction case, based on OAuth 2=E2=80=99s = device flow. In this, you want to send a URI to the client that it can = render as a QR code as well as a code that the user can type into a = page, in case they can=E2=80=99t scan the QR code. OAuth 2 manages this = by having a user code as well as a pre-composed URL containing the code = to be used for rendering. XYZ used to have a mode for this similar to = XAuth, but we realized that we could describe this using two separate = flags: 

 - I can communicate a short code that the user can type = in at a static URL
 - I can get the user to go = to an arbitrary URL

The second one is the same mechanism we can use for = redirect-based auth. 

I got that. I thought = being more crisp in the interaction makes it easier for implementors to = understand. 

I don=E2=80=99t think it=E2=80=99s more = crisp, I think it=E2=80=99s more limiting, and it leads to more = confusing code paths. Having implemented both styles in XYZ in several = languages, I vastly prefer the current XYZ = style. 

It is more crisp. And it is more = limiting, and I think it leads to simpler code = paths.

Again, I=E2=80=99ve implemented this, and the code = paths are simpler for XYZ. I know this because I have written the code = paths. The XAuth style is not more crisp, just more = limiting. 


 

When you have the =E2=80=9Ctype=E2=80=9D = field, you then have to specify what different responses mean in the = context of different types, like what XAuth does in =C2=A74.2. In XYZ, = the response fields have a single meaning, and the client does what it = can with them. I think it=E2=80=99s presumptuous to assume =E2=80=9Cqrcode= =E2=80=9D as a scannable format, for = instance.

A QR Code is a scannable format by = definition.
 
Does the AS = actually care how the client communicates the URL to the user? Not = really.

As I noted in XAuth, the AS does care. = While a really long URL works fine in a redirect or popup, it does not = work in a QR code. The AS can return a short URL for the QR code that = redirects to the long URL. The AS does not want to impose the redirect = latency on the redirect or = popup.

That=E2=80=99s not really true in either the = specific or the abstract. QR codes don=E2=80=99t have a lot of trouble = scaling for rendering. And if the AS has the capability of having enough = information in the short URL to redirect to a URL that it can actually = use, wouldn=E2=80=99t it just get the information directly at the short = URL without a redirect? Yes you could implement it as a redirect from = short to long, but if you=E2=80=99re worried about latency, then don=E2=80= =99t do that.

 
Even if we were to optimize this for the client and have the = AS return an image instead of a URL, I think the AS should be able to = return an arbitrary image for the client to display to the = user. 

In XAuth I asked if we wanted to allow = the Client to over a webview for the AS to load whatever it = wants.

Again, it=E2=80=99s all about getting the user in = front of the AS with a web page. I don=E2=80=99t agree that the AS cares = much how the user gets there.


Additionally, since we are designing all of this to be = extensible, if another use case comes up with a different interaction = method, we can just add a new = type.

And in XYZ, if there=E2=80=99s a new interaction = method, you add a new flag (or object) to the interaction object to = signal that. If the AS supports it, it can give whatever the appropriate = response for that is to the client. If the AS doesn=E2=80=99t, it can = still pick another type.

I=E2=80=99ll = note here that in XYZ, you=E2=80=99ve also got the ability for the = client to support a legacy interaction method while a new one rolls out = in parallel. With XAuth, you=E2=80=99ve got to make sure that it=E2=80=99s= supported at every possible AS the client can talk to before the client = makes that switch. 

 


 


In the case where the AS = interacts with an RO that is not the User, there would be nothing the = Client would need to do. Perhaps there is a use case for something = different? If so, please elaborate.
 

4. XAuth allows OAuth-style scopes next to RAR-style data = structures (and next to OIDC claims structures). They are treated as = completely separate from each other. In OAuth 2, RAR is defined in the = context of scope (and resource and audience and other parameters), and = this combination is a matter of some debate still that needs to be = solved. However, it=E2=80=99s clear that they=E2=80=99re combined. In = XYZ, the only resource request defined is the object inside the resource = request. You can mimic =E2=80=9Cscope=E2=80=9D behavior by using a = Resource Handle, which again is defined as a single string that stands = in for the whole object and could be defined by the AS (or the API = it=E2=80=99s protecting). 

I think you need to = reread the 00 draft. Only one type of authorization request is = allowed.

- = OAuth style for deployments where that works fine.
- = RAR style for deployments that need the extra granularity of = RAR
- list of RAR style for deployments that = support multiple resource servers that require independent access = tokens.
 

5. The = different kinds of authz requests in (4) create separate tokens.This is = very different from both OAuth 2 and XYZ, where you get back a single = access token. And in XAuth there is no way to get, for example, two = access tokens that are both described by RAR requests, so this seems = like a very arbitrary and syntactically-driven = separation. 

I don't think you understood what is in = the draft. See = above.
<= div class=3D"">
Apologies on these = points =E2=80=94 I didn=E2=80=99t catch that this had changed from the = earlier drafts. 

We can scratch this concern from the = list then. Yeah!

Well, kind of =E2=80=94 XAuth doesn=E2=80= =99t allow the combination of an API-specified element (a scope, a = simple string value) and a more fine grained access = request.

I don't think you went back to reread = -00. The oauth-rich type includes a scope, and an = authorizations_details. 

I made that change as it was not clear = when I looked at RAR (which is still developing) that it did not include = the scope.

I did go back to re-read. It seems that you are = re-stating what my stated assumption was: that the RAR does not include = scope internally, and that since XAuth makes them exclusive with each = other then it=E2=80=99s a choice. What am I missing? 

 
Yes. I = think freedom from having to make a choice makes things easier to = implement and deploy. 
For deployments where = another mechanism will be significantly better, the choice is available. = =E2=80=98

These statements contradict each other. = Are you advocating for =E2=80=9Cfreedom from choice=E2=80=9D or that the = =E2=80=9Cchoice is available=E2=80=9D for this particular feature? I am = arguing in favor of making choice available in the case of key = presentation and removing choice in terms of request format (as in, the = core payload). 

Freedom from choice: if I don't want to = have to make a choice, the choice is made. These are frequently called = defaults. They have proven useful. =3D)

Stated another way: here is what you do = unless you have a good reason to do something else. 

While I think JOSE is a = better default, I'm open to another method being a default. I do = strongly think there should be a = default.

What I think is more valuable is a = mandatory-to-implement, specifically for the AS to support. That tends = to make a better =E2=80=9Cdefault=E2=80=9D, especially for security = mechanisms like this. I think :what: the mandatory implement item is can = be up for debate.

 


Is there something about JOSE that you = think is problematic to make it the = default?

Yes, it leads to reliance on putting = everything of note in the JOSE payload as part of the base = protocol.

In XAuth, I factored out all the JOSE. = Once again, have you read -00, or -01?

https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#secti= on-3

All payloads are JSON. The JOSE section describes how to use = JOSE for message and header signing.

https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#secti= on-8

Yes, I did read; please stop assuming that I = haven=E2=80=99t, which you have done several times in your replies on = this thread. In fact, I have already thanked you for refactoring, and = have stated that I think that=E2=80=99s moving in a good = direction.

I answered a specific and = direct question specific and directly. You asked what the problem with = JOSE as the default was, which is the question that I answered. I did = not state that XAuth, as currently written, suffers from these = deficiencies, but that they are problematic trends the I have seen in = many JOSE-based designs in the past. JOSE isn=E2=80=99t the problem, = over-reliance on JOSE as the sole container for information is.

 
As explained previously, I want to be able to use HTTP as = more than an entity body carrier. We should be using headers and methods = and URLs =E2=80=94 and importantly, content = types.

I agree. 

XAuth uses POST, GET and = DELETE

It uses = the Authorization header and different parameters to indicate the type = of token.
It uses content type to indicate what the = content type is. This will assist an AS that supports multiple Client = authentication = methods 

Good.

 
I think JOSE should be switched with things like Content-Type = headers and Accept headers, and that JSON bodies should be the default = as they=E2=80=99re more universal across different signing and = presentation mechanisms. 

My Java XYZ implementation does use = JOSE, but by using JWS in a detached fashion to sign the body instead of = an internal fashion. The reason for this is that it allows the request = and response to be =E2=80=9Capplication/json=E2=80=9D and not = =E2=80=9Capplication/jws=E2=80=9D. 

Detached signatures = work, but I have found them to be problematic in practice, which is why = I chose "application/jws". There is no canonical form for JSON, so it = can get modified, and still be valid JSON, but the signature does not = match. Passing around the signature independent of the payload is more = complex.

A JWS = can be easily passed between components and is self contained, with no = worries that the JSON was modified by parsing and re-serializing = it.

I = understand and agree with the limitations of detached signatures. This = is the key brilliance of JOSE, and what I love most about it. But the = internal payload also makes it difficult to impossible to incorporate = additional information, such as headers and other bits of context that = we might want to protect. 

 

In all of these cases, I do not think = it is a good idea to use JWT claims in the TxAuth request or response = namespaces. Where we use JOSE, we should avoid = JWT.

I agree. JWT is good for claims. Not so = good messages.

Great. 

 

I still agree that they should be able = to easily use TxAuth, which just a stronger argument for the = signature/proofing mechanism to be a pluggable thing and that the = request/response bodies not be JOSE objects but JSON = objects.

We discussed this in early drafts, and = XAuth is JSON, with JOSE added = on.

Yes, and this is the right way to layer it. But I = also think that the =E2=80=9Cdefault" method should use = =E2=80=9Capplication/json=E2=80=9D specifically, though I could be = convinced if there=E2=80=99s a better approach.

 

The word transaction is muddying what I = think you are suggesting here. It more like a conversation. Transactions = from a DB point of view are a set of actions that all happen, or none = happen.

I=E2=80=99ve explained previously that = the database interpretation is not the only or full interpretation of = the word =E2=80=9Ctransaction=E2=80=9D here, so I won=E2=80=99t go back = into it. Conversation is perhaps more accurate, but =E2=80=9CCxAuth=E2=80=9D= is a problematic acronym. :-D

Naming is hard. = =3D)
 

 

Both = continuation and refresh are saying to the AS =E2=80=9Crun this = transaction again and if I can get a token (or claims or whatever) in = its current state, give me that=E2=80=9D. However, they can=E2=80=99t = really exist at the same time, so having two separate items to ask the = same question doesn=E2=80=99t make much = sense. 

They have different purposes. The = completion (now authorization) handle is to check if the AS is done with = its request processing, and if so, provide the results, which includes = zero or more identity claims, and zero or more access = tokens/handles.

The refresh handle is to refresh a specific access = token/handle.


I don=E2=80=99t see these as being = different, and that=E2=80=99s where we disagree. The access token is the = end result of the processing. Refreshing is an act of continuing that = processing. I do not see a good argument for treating them = separately. 

Developers are already familiar with = refreshing a token

Some are, many get it wrong = today. 

For those that are = doing it right today, we=E2=80=99re telling them a new way to do what = they=E2=80=99re already doing that largely amounts to the same thing = they=E2=80=99re doing today: =E2=80=9Ctake this value that I give you = alongside the access token and send it back to me with your credentials = to get a new access token=E2=80=9D. In XYZ that=E2=80=99s the same exact = call that they make to continue the transaction, in XAuth it=E2=80=99s a = different (but similar) call to a different endpoint.

 

 


I think a transaction handle is to course grained. I don't = think that the AS should be returning all the claims in a refresh. And = if there are multiple access tokens returned from the AS, then each has = their own refresh = handle.
=

I think this = requires a deeper discussion, since the whole idea of multiple access = tokens is a very different kind of approach = here. 

It is a feature of = XAuth. 

Kind of. XAuth allows multiple access = tokens in one limited context, and only when using rich authorization = requests to do so.

Given that existing implementations = using scopes only support one access token, it did not seem limiting to = only have a oauth_rich_list, particularly since a RAR request is a = superset of functionality of a scope request.
 
I would rather see us have a general mechanism that allows us = to get multiple access tokens in a way that=E2=80=99s parallel to how = you get one access token.

A general mechanism = sounds fine and dandy. Currently we don't have other ways to request = authorization except for oauth scopes and RAR, which is a super set of = RAR. If and when we need a more general mechanism, we could define a new = type. 

I think instead we should define a syntactical way = to say =E2=80=9CI want multiple kinds of things and I want them back in = different access tokens=E2=80=9D. Maybe it=E2=80=99s as simple as a list = of resource lists instead of a single list of resources? But I think = it=E2=80=99s cleaner to have them be more in parallel with the single = token request. 

 


In OAuth today, the bearer token is like a movie ticket. = Whoever has the movie ticket gets in the movie.
Using= OAuth to obtain a bearer token is like buying a movie ticket.

Sometimes I want to go = to more than one movie. OAuth today makes me wait in line to buy each = ticket. Why not let me buy multiple tickets at = once?

That=E2=80=99s not true. You can get = one ticket that=E2=80=99s good for two movies, to borrow your = metaphor. 

Which is all you can do in OAuth today. = Get one ticket.
 

The semantics of requesting multiple = access tokens in parallel is something the working group might want to = consider. I am not a fan of how XAuth handles this, with packing things = into the authorization list. I think it=E2=80=99s a concept we should = consider though.

If you have other ideas, please share = them!

So here=E2=80=99s a terrible straw man: taking = XYZ=E2=80=99s =E2=80=9Cresources=E2=80=9D component as the basis, what = I=E2=80=99d like to see is a way for a client to send multiple = =E2=80=9Cresources=E2=80=9D requests in parallel, indicating that it = wants several access tokens. So let=E2=80=99s say the client = sends:

resources: = [
   =E2=80=9Cfoo",
  =  =E2=80=9Cbar=E2=80=9D,
   { =E2=80=9Cname=E2=80=9D= : =E2=80=9Cbatman=E2=80=9D,
     =E2=80=9Cknight=E2= =80=9D: =E2=80=9Cdark=E2=80=9D
  =  }
]

Then it means =E2=80=9CI want one access = token that does all these three things=E2=80=9D. But if the client = sends:

resources: = [
   [=E2=80=9Cfoo=E2=80=9D],
  =  [=E2=80=9Cbar=E2=80=9D],
   [{ =E2=80=9Cname=E2=80= =9D: =E2=80=9Cbatman=E2=80=9D,
    =  =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D
  =  }]
]

Then it means =E2=80=9CI want three access = tokens, one for each of these three things=E2=80=9D. 

There=E2=80=99s a lot I hate about this syntax = (like the fact that it could be easy to smush the two together and make = things really confusing), so please don=E2=80=99t tear down the = specifics of the example. But the concept of being able to ask for one = or more-than-one of the same kind of thing is what I=E2=80=99m after. We = could use two different field names like XAuth does for the different = structures, and make them mutually exclusive, but that=E2=80=99s got = drawbacks too. 

We could = alternatively force the client to pick identifiers for its different = access tokens, like:

resources: = {
   =E2=80=9Cfootoken=E2=80=9D: = [=E2=80=9Cfoo=E2=80=9D],
   =E2=80=9Cbartoken": = [=E2=80=9Cbar=E2=80=9D],
   =E2=80=9Cbatmanisnotatoken= ": [{ =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatman=E2=80=9D,
  =    =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D
&n= bsp;  }]
}

This means that the client wants three tokens, as above, but = that it wants them back with specific names in the output. So you=E2=80=99= d get something like:

access_tokens: {
  =  =E2=80=9Cfootoken=E2=80=9D: { value: =E2=80=A6, proof: =E2=80=A6 = }
   =E2=80=9Cbartoken=E2=80=9D: { value: = =E2=80=A6., proof: =E2=80=A6. }
  =  =E2=80=9Cbatmanisnotatoken=E2=80=9D: { value =E2=80=A6, proof: =E2=80= =A6 }
}

This has the downside of making the = client pick values, but the upside of having a clear way to reference = which token goes with which part of the request. This might be a complex = enough use case that making the client pay the complexity cost might pay = off here. 

The output = would need to have similar parallels, regardless of how we do = it.


To elaborate on my = metaphor.

A = family is going to the movies. The Father (one component of the family), = is going to purchase tickets. Billy (age 8) can pick from the G rated = movies. Sally (age 15) can pick from G, PG, and PG-13 movies, and Father = can pick anything. 

Father does not want to buy 3 tickets that are identical and = can work for any movie. (effectively what an access token is today) He = only wants them to go to a movie he has approved, at the time he has = selected.

Father= wants to buy 3 different tickets, and give the appropriate ticket to = each child.

The = metaphor breaks down here, but each child needs to be able to refresh = their ticket independent of the other's, which is why a refresh handle = is required. The transaction handle is not granular = enough.

I understand what you=E2=80=99re describing, but I = question how realistic it is. That would require a very sophisticated = client doing a very specific set of optimizations. Is it worth it doing = that kind of optimization?

And it = actually makes me wonder if your use case is less of a =E2=80=9Crefresh=E2= =80=9D and more of an =E2=80=9Ctoken exchange=E2=80=9D with some kind of = augmentation. I don=E2=80=99t have a syntax for that defined in XYZ yet, = but it=E2=80=99s in my notes as something we might want to consider. = It=E2=80=99s already in charter because OAuth has several mechanisms for = access token exchange.

 

 

I see refresh much as it is in OAuth2 and UMA, where it = refers to the authorization that was granted. This means that you can do = downscoping to get lower-powered access tokens that are a subset of the = overall grant, and I think that TxAuth should be able to do a step-up = auth where you can build some additional request on top of an existing = approval. 

Is "step-up auth" authentication or = authorization, ... or both?

I think the question you = asked is unintentionally misleading because =E2=80=9Cstep up=E2=80=9D = authentication could be seen from the client or the AS=E2=80=99s = perspective. 

Well, your statement was unclear as = "auth" can be one or the other! =46rom below, you intended = authorization.
 

The =E2=80=9Cstep up=E2=80=9D that I = mean here is from the client=E2=80=99s perspective, not from the = AS/IdP=E2=80=99s perspective. The client wants more of something =E2=80=94= more access to an API, more user information, etc. It=E2=80=99s likely = that the AS is going to want to interact with the user to include = whatever additional access the client is asking for, but the client = doesn=E2=80=99t want to start from scratch. You=E2=80=99ve got a ticket = that=E2=80=99s good to see one movie, and you want to add another movie = to it for after. The theater already knows who you are and how to get = your money, so they can just add it on.

It=E2=80=99s entirely feasible that the = process of asking for more information would prompt the AS to = re-authenticate the user, including prompting them for additional = credentials. However, from the client=E2=80=99s view, that=E2=80=99s a = side-effect of its request.

The step-up = authentication is a policy decision independent of the Client. The User = is having to provide additional = authorization.

But the user might have to provide it at the = request of the client, because of what the client wants to know about = the user (as stated by the AS).

 
Remembering user consent and delivering = claims are two completely separate problems and should not be conflated = here. I was addressing the former. 

They are related though. = If you are not wanting to ask for consent on each delivery, how do you = know you have consent?

We are talking past each = other. They=E2=80=99re related in the sense that they=E2=80=99re both a = part of the authorization process, but consenting to the release of = information and the delivery of that information are completely separate = from each other. 

Consent is required to release the = information. That is how they are related. 
 

Consent is not the = client=E2=80=99s policy, that=E2=80=99s the AS=E2=80=99s policy. My = consent is stored on the AS.

Maybe. Maybe = not.

The client can=E2=80=99t know what I consented to, = only what it got back from its request. And it=E2=80=99s certainly in no = position to know what I=E2=80=99ve consented to if it=E2=80=99s asking = me to log in, since it doesn=E2=80=99t know who I am.

 
The client can't know if this is the =E2=80=9Cfirst=E2=80=9D = time or not because it doesn=E2=80=99t know who I am yet, so it can=E2=80=99= t ask if I should consent again. If the client knows who I am, it = doesn=E2=80=99t need to ask the AS to log me in in the first = place. 

Did you spend anytime looking at my = "authentication first" proposal in = -01?

Yes.


The Client asks the AS = to authenticate the User, and send that result, then the Client can = decide what, if anything it wants to request for that User. The AS no = longer needs to maintain state.
 

However, once I=E2=80=99m = interacting with the AS, the AS has a chance of figuring things out. The = AS can determine if it=E2=80=99s seen the same client before, if it=E2=80=99= s seen the same user before, and if the same client is making the same = request for the same user, and the AS knows that it can make that = decision without prompting the user. We already do exactly this today = with OAuth 2 and OIDC systems. 

Sometimes. Sometimes = not. The specifications are mute on saving = state.

I think you might be reading too much into = =E2=80=9Csaving state=E2=80=9D as being something like a database write = operation. I just mean that the AS needs to know, somehow, that it=E2=80=99= s made a decision. There are a lot of ways to pull that off, including = wrapping information about the user that the client can present = again.

In fact, XYZ=E2=80=99s = =E2=80=9Cuser handle=E2=80=9D construct is a great way to manage = that.

 

But the AS does :not: = know which profile and identity claims the client actually :needs:. The = only party able to make that decision is the client, and it can only = make that decision once it has a reference to which user is there (in = terms of an identifier). The AS can (and I argue should) give the client = some kind of key for helping make that decision. 

The push of user = information into an OAuth-protected API, and separating it from the = authentication context, is one of the best parts of OpenID Connect. Yes, = the client can always request the user info as long as it has the access = token =E2=80=94 and to me that=E2=80=99s a feature, because the client = is the component that knows when it needs updated = info. 

This is where consent and delivery are = related. If the user info has been updated, has the User provided = consent for the Client to receive it? The AS is the endpoint that can = interact with the user, not the UserInfo endpoint.

Why not just go back to = the AS and ask for the data again. If consent is not required, the AS = returns the data. If consent is required, the AS can interact with the = User to get it.

The UserInfo endpoint seems redundant if the Client can get = the claims from the AS.

If the client is just going to go back to the AS = with a separate call to get profile information, why conflate it with = the transaction request, especially when doing so can lead to the = privacy issues that I=E2=80=99ve outlined? I=E2=80=99m not convinced the = optimization is worth the risk, much in the way that the implicit flow = was an optimization that=E2=80=99s turned out to be not worth the = risk.


 

 


Your comments have = inspired me on a solution that can be done with XAuth (or XYZ) that = can't be done with OAuth 2.0/OIDC.

I'll add that to the XAuth draft and = publish it. 
 

11. XAuth defines an explicit discovery step because the = client now needs to know several things about the server. The mix-up = attack and a few other attacks in OAuth 2 stem from this kind of = process. In XYZ, the client really only needs to know the transaction = endpoint URL and it learns everything else from that point. Yes, the = client needs to discover that someplace =E2=80=94 but it was a = deliberate decision in limiting the amount of upfront information that = the client needs to get = started.

That is still discovery, is it = not?

I literally just called it that in the = sentence above, so yes. :) What you=E2=80=99re discovering is different = though. And doesn=E2=80=99t the client still need to =E2=80=9Cdiscover=E2=80= =9D the discovery endpoint in XAuth?

What discovery = endpoint?  

The charter currently = includes =E2=80=9CAS discovery=E2=80=9D, per your request to add it. To = me, and I would argue to most, =E2=80=9Cdiscovery=E2=80=9D is a = programmatic process. If it=E2=80=99s manual, it=E2=80=99s not really = the client =E2=80=9Cdiscovering=E2=80=9D anything, it=E2=80=99s being = told things manually by a developer. That=E2=80=99s not discovery as the = term is generally known, and I think this is a key source of confusion = here. There is no =E2=80=9Cdiscovery=E2=80=9D that=E2=80=99s not = programmatic =E2=80=94 that=E2=80=99s = configuration.

I think of discovery is going to the AS = and learning what it can do -- since discovery is learning. That can be = the developer going to the AS docs and reading, or the Client calling a = discovery API. 

After manual discovery, the developer decides how to manually = configure the Client, based on what was discovered when reading the = documentation.

I= have found it useful to call out the manual discovery so that = implementors know where the information comes from. IE it is not in the = specification.


I would recommend not using the term =E2=80=9Cdiscovery=E2= =80=9D to refer to this, as I believe =E2=80=9Cdiscovery=E2=80=9D is = well-known* to be a programmatic process.

*Pun fully intended. :)

 =E2=80=94 Justin
3D""=E1=90=A7

= --Apple-Mail=_36EEAD85-DFAC-4C3E-9750-ED5F25F84F5D-- From nobody Sun Feb 2 07:52:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4159412011D for ; Sun, 2 Feb 2020 07:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=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=hashedhyphen.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL_Jq_AuIVSr for ; Sun, 2 Feb 2020 07:52:26 -0800 (PST) Received: from 133-130-107-8.hashedhyphen.com (v133-130-107-8.a036.g.tyo1.static.cnode.io [133.130.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7EB12003F for ; Sun, 2 Feb 2020 07:52:25 -0800 (PST) Received: from hh-mbp.local (p2548003-ipngn21801marunouchi.tokyo.ocn.ne.jp [124.98.237.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by 133-130-107-8.hashedhyphen.com (Postfix) with ESMTPSA id 700AE2E06B4 for ; Mon, 3 Feb 2020 00:52:24 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hashedhyphen.com; s=dkim; t=1580658744; bh=IlyWMtYqITWAoKAfpOkny2ACcEagpPNo65KRo5XzHRM=; h=To:References:From:Subject:Date:In-Reply-To:From; b=WH714huS14Fq39vB3CMirRfVvL6NOCs3Sbr0HYHQ40bcxohBRSPGbLN+5sOECbcKL wQSRwSV0HiKV4SSgzxty74cJlG9mFCUPflmVr0Qdbomrl9G8G8xjnunI+7w+IOkrm8 C8VTnjQppV+KNAIKXWRRyGzXswXyyxaIF04jp2GY= To: txauth@ietf.org References: <18D187E5-1D6A-40C0-8F34-E6F911DF7E67@mit.edu> From: Ryo Kato Openpgp: preference=signencrypt Autocrypt: addr=me@hashedhyphen.com; keydata= mQINBF2fZNwBEACW47rFtrKEo6wtlHjEqmzKTeIekak61KVxtIX2Ql+LX40T2GN40VFahOTb AKey+Nu/RUVy+xwv8Y+lxiqB/qX+SVY9j2XnE0tH72DfpKRBsUCwG6my1mRW/XjktfRMmd9n Jr+jz83+TVh0trKS8i4gVEHiw0nyCBcCkXSkHpI6glfubSlYg3ChqjM0GsyXBmqI7k0o5C+0 2rkZUFFst2vPFMF51thTj79flmtRd/tzFHpBXtVX00+w7E/B5ss/omwW8d1rq3CGXNIHSNBr IrF2p6BYGranYDQAcgCKlkr//0ux1CeZ/wS3+2gavX6dyjC6dJ45C0Q5W010i3Yu8PNwbS5v G5Zw4PJAg/KYE1VuJS6R07Ba6hxOy0fzityiF9WZovBWcks7UBiiqYCvqrTs4ZLjC/GAt44S 6Snrv7FMGyGnXK6xXtt0kEQhswF8leokb/jloIMFH8roYdhdmIdjX/mNeIyAsJVvZDEKcZQ7 tuFBviu1kHqUVZzUbI9Vh0litdYrdE8hS3YwVbq4UaGGcGeSDzzC7jKTUX1dqStMnsz63Q4P 6Q0dYGthot51varDcYqYZ+mosKtUdb/j5TKFP6MTPmz6QzYWl5kdRup7thlO54ZS6+Qq03vd h6uubqxGIF6oMfdyNU30LZgMbPW+QW5QzZYDQcPivCN1zOahhQARAQABtB5SeW8gS2F0byA8 bWVAaGFzaGVkaHlwaGVuLmNvbT6JAlQEEwEIAD4WIQScmViC3YJ7PSsszvhWbmajCW3E3AUC XZ9k3AIbAwUJAeEzgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBWbmajCW3E3L0OD/4k PMfrW0rDgEgPCZwqHIppplwqRzyswOhTR+/gqPlZvBXuQmiN8WhCIfbirL86Hz4V0zttGhE5 Syd1ydEyk9s6xSYJIeriz9AxDro4Ko0LdR2TJFMkOolSu3HROFKWQgc8jgdIYgzu9pcHbiwq 81oLV8vMwz0JWGnwm0EfnEfWIgW9DSMaY9Dohj2Ea4253e4Fr1MH5DHP76WhijCc1bF/S3AI Db/0xI9oo4hVyuUnXdoGhF9xaSYIO9CKAWrE0VrEVP4wUAOGL7Ak2aj9wQzy3LqLUdcsGbFc 5U4JJcndAWOFcSkg5rOyydnN8M/7fJtqKJhhxZxq3BuV5zPZ1BAuepAPwE1PsG0HClrJenuM 0PeXfOy+3QGxFDXqUkvhxeUUxwMGKTyE/oKuoEMLuGey3LPCV6H5pgJwCyBKw/QQs5EoycAU V1rylHekE56Y0KKasYAU392kj93msl4GQoM1V0WkszKMgq+0I55eUo2xLyzYhqTu+JZVBnHy HseJzFe3PstI87Gbxtc/Fb+16A8gw7lOAdSUXmg5ZkLlrHxmLCJDld95TJFvw2ovTdBnIKjF t6vs62mrKDx/Mamodbu5Bxq8R4U6R5xiqgatwT6LgFPuUH79vltOSZsu1wT202+9vucd8lLl +CHJGsas9MLU1rIM58wjFW5WZI28sgG0IrkCDQRdn2TcARAAwIcME2A2WvTiiOKqOdIeeyW7 06Pd+d7OnHyiGGMah+liJ9R25v43RjR3P6FPqiUTCwY5Mis6Nkyc+InylUjQ35aNrE1LnuOT QjeD3lVAfBxnBsDMSC2xZT0PN+7D2CSD9Zazf+0XjvHHkI9AyGh3WOor4MkChZmZLbxCf8QL YnkchZZnPu9nrJvhZXxG7pjDg78JF4yGNcdinBasF1wzw3a5YVb10tqxzcEVxNX47aFY2Mb3 oJzocNMBMv3TpxfwVRX3RRVKq8yjYpNJiPIcplcjDnizKDXqsxvr/sTAv8DsnCJH+O4RvuKH SIo+qiAEC3HhyYpXG8b6OxesBSh6ofrbCgNVyGqrg7ETI9UpNkcGZIsWJNhg/50hbn1lfdOj vFDf0YEV2Tkg0RLj5fo1GkKK9h//Ch1UPNPRdsw4/0E3qvbyMsPa3tSOHOxv4aaBJabbnCPB DCZiMxpfNv3bx+hNImOGBZ0c2+3McHFzlTPdQHvau0glEr0WCyn4zisLe/z8H1MFfp0laorz EwRBGrSS+aEUneKUbZjY2pXTzojf1KuuG8WuA1q6Aoq0xcQcIRFk8SUIKUyvkxtscqX3MUev zuTGRmdnOjwr+mvrYVsk6K3pRFMQfaetrBDOyRbLcaAAOqKno+HKBwb+Px6LPnq57naE0CWs 4IjbJYB0HJkAEQEAAYkCPAQYAQgAJhYhBJyZWILdgns9KyzO+FZuZqMJbcTcBQJdn2TcAhsM BQkB4TOAAAoJEFZuZqMJbcTc+f4P/RqPZO5PT75R2QgDdofVXfec9gTq2QVs0jeMk46jFOgT 1tv5Hz/KyOFM1mdO7fG81e2IF/kLaskhcdPNEodEFdqsnptRm6IdJqN1hv/n2oeJS+t5qZkV QXy0ecZvdghfZsP3Cfloi5WuTpElVJMClfqeB5lBWFV7HhGg8KDnPsaMh1IXoR/qBb/XcIty ejmuainZcCvX7+MPMH4EbuJRO34/diC2/Ig+J+Swj1/t1ONFOdtliXpYOJmY9XKVO9orVUXL bdW5ChiqFVOODiAmJjmez2QvXzT03WJHjivy8xlJ+Zyv5uni+Os+Hz5nwRW/+DuMJvpHDsxT FuQgSTn/0jLW9THhFcMAFxTIXMx1282BSy0jqw4a7e8r3WRLM7ms5e1EUjsz1essa4rnVFBK BWRS9vYITSFuuLOi0m5EHlvWIwSu/Xlr8FIW5wZY5Fkl0KzUA3gIvPmoaW/kqYeGF3aFxfUA agVoBt/4LoE3joR4W2T6Ek94k52aX7cwHdjYyKCWHPl4tkAdBAIAPhulJ19TSlMeaPfyWoL9 llYxVwarCeVC9HBT/3fU4Wuw6P895AibDw+ZTaKJri8HgpSw3Al/TjD248uJeZTROPQZpcJ2 pG7Rd0HsdtW0edvI3AMhJD92l1Azyk3hCtiUlJQ7KTaZA21VA7ml3hNnNGe204Ue Message-ID: <8b0d44aa-459c-8125-409a-6645467d9b2f@hashedhyphen.com> Date: Mon, 3 Feb 2020 00:52:23 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <18D187E5-1D6A-40C0-8F34-E6F911DF7E67@mit.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sDY0KKfJ7jvTMTFLbS68MEUgsemDCwj7x" Archived-At: Subject: Re: [Txauth] Questions on key validations by RS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 15:52:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sDY0KKfJ7jvTMTFLbS68MEUgsemDCwj7x Content-Type: multipart/mixed; boundary="L2pCHAE9HCGwKiBACbe76R4tvT3Pubzfm"; protected-headers="v1" From: Ryo Kato To: txauth@ietf.org Message-ID: <8b0d44aa-459c-8125-409a-6645467d9b2f@hashedhyphen.com> Subject: Re: [Txauth] Questions on key validations by RS References: <18D187E5-1D6A-40C0-8F34-E6F911DF7E67@mit.edu> In-Reply-To: <18D187E5-1D6A-40C0-8F34-E6F911DF7E67@mit.edu> --L2pCHAE9HCGwKiBACbe76R4tvT3Pubzfm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Justin, Thank you for detailed explanation. > I think it=E2=80=99s important for TxAuth that the token presentation mechanism and the client key proofing mechanism used during the transaction are separable. I agree with you. In the future, more detailed instructions would help RS implementers because RS will have to accept all possible algorithms (HTTP Signing, MTLS, DPoP, and so on) without any prior negotiation. - Ryo On 2020/02/02 6:49, Justin Richer wrote: > Hi Ryo, > > You are absolutely right that the =E2=80=9CJWSD=E2=80=9D method from th= e spec only works with POST and PUT methods, since it only protects the b= ody. This is a known major limitation of this method, in addition to it n= ot protecting headers or adding replay protection. I only put this method= in as a stop-gap demonstration of the concept of a general key presentat= ion mechanism, and it does manage to work OK for the tx endpoint (since t= here=E2=80=99s always a body there). I think it=E2=80=99s debatable wheth= er the specifics of this method are generally useful. > > Regardless, for presentation to the RS, I think that HTTP Signing and M= TLS are much more useful general-purpose key binding mechanisms. Even DPo= P, which has its own limitations, is usable across different method types= and could be used here. > > I think it=E2=80=99s important for TxAuth that the token presentation m= echanism and the client key proofing mechanism used during the transactio= n are separable. It makes the most sense for the client to be able to use= the same thing in both places, but I don=E2=80=99t think that should be = a hard equivalence since that puts requirements on the RS that might not = apply. > > =E2=80=94 Justin > >> On Jan 31, 2020, at 3:13 PM, Ryo Kato wrote: >> >> Hi, >> >> I'm reading the draft 04, and I have some questions now. >> >> The draft says: >> ``` >> The Resource Server (RS) accepts tokens from the RC and validates them= >> ``` >> and also >> ``` >> Any keys presented by the RC to the AS or RS MUST be validated as part= of >> the transaction in which they are presented. >> ``` >> >> Therefore, I understand that the *RS* MUST validate the proof of >> possession of >> RC's keys when accepting tokens from the RC. >> (And I understand this procedure is for so called "sender-constrained >> token") >> >> However, I think it is a bit ambiguous about the way for *RS* to >> validate that keys. >> >> Assuming the `proof` parameter is `jwsd`, i.e. Detached JWS. >> >> The current draft 04 says: >> >> ``` >> the RC takes the serialized body of the request and signs it >> ``` >> >> Yes, RC's transaction (continuation) requests to AS are always HTTP PO= ST >> requests, >> and their body is always a non-empty JSON object. >> >> Whereas, RC's requests to *RS* are not always POST, so they can be pla= in >> GET requests. >> Since GET request body is missing in general, the input for JWS will b= e >> missing too. >> >> In this case, what should we take for JWS instead of request body? >> >> - Ryo >> >> >> >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --L2pCHAE9HCGwKiBACbe76R4tvT3Pubzfm-- --sDY0KKfJ7jvTMTFLbS68MEUgsemDCwj7x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEnJlYgt2Cez0rLM74Vm5mowltxNwFAl428DcACgkQVm5mowlt xNzxiA//QZ9GsKPFccKnFawLh5CYP25fRqCOzdTR5zq8hBlmuMSLifWrT07+mneo g3GE1XKTr7fjECvGw3XavZHmVjBliWtaq5wmFQ5YFcHNPqyK0YbauLgPyVrvF3iY dHU/3nzmq4ucLHrkd9RXmAWUEKcCH19nlPKUTSsLhurf7HYXS9z5jjWjgbSARPLe 2aDMQ0zS/9wOZPpKh91WA/m+kjkr0qLADrn23xW5R67KedTh4gcrb4Tr+uBPHJuU rpCvKrQHJ466MxJbvk7/1Pkd+coxMh5u/cBs4xykcyofnfrf5qEUV7VxqdmDUDB7 vSCYAt5qSg3VghMQfbTy29F/C7Oua0FQYztdwv3MDiRluew3N7T5Rt5WhTEsgwMD uOqrGato3jgz23faOwrOo3qPzdtLC7CEcbFOz2hICt5svgeXA+HpKlvvTdsKq37x 6AEYbUYmuMUfPLACMsnujbuZCABWNAtNjryB8J0HwBhvXwb1Xlxi7AqQti6jStg7 nVl0CflG6oNIwRFbXFtcRwcqCxQIJYkn3BG3WdvQUihN0KdqInzGi9tFIH6+Xa0i kWS0OakTBX2EWhes18VoFqyt/IwBfskX1Jf2++t3aLFZmFDzaDddj7w7Rr5t5UtG zE2c+LxOQj6SSwew/nwSKadk15kb8SXau30rHYwFf29bj0q626g= =VhsS -----END PGP SIGNATURE----- --sDY0KKfJ7jvTMTFLbS68MEUgsemDCwj7x-- From nobody Mon Feb 3 11:54:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCBB12012D for ; Mon, 3 Feb 2020 11:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 ofzP0ZgQREwz for ; Mon, 3 Feb 2020 11:54:46 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 231D5120BDD for ; Mon, 3 Feb 2020 11:54:45 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 013Jse7c026214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Feb 2020 14:54:41 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <8b0d44aa-459c-8125-409a-6645467d9b2f@hashedhyphen.com> Date: Mon, 3 Feb 2020 14:54:40 -0500 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7488AA42-5AE3-4696-A14F-C802564E7F4C@mit.edu> References: <18D187E5-1D6A-40C0-8F34-E6F911DF7E67@mit.edu> <8b0d44aa-459c-8125-409a-6645467d9b2f@hashedhyphen.com> To: Ryo Kato X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Questions on key validations by RS X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 19:54:48 -0000 > In the future, more detailed instructions would help RS implementers > because RS will have to accept all possible algorithms (HTTP Signing, > MTLS, DPoP, and so on) without any prior negotiation. >=20 I see what you=E2=80=99re saying, but I don=E2=80=99t think that=E2=80=99s= completely true.=20 It=E2=80=99s going to be between the RS and AS to figure out what kind = of tokens are issued and accepted for a given API. So if the RS = doesn=E2=80=99t support the signing mechanism associated with a given = token, it wouldn=E2=80=99t accept that token. If an AS is issuing tokens = that its RS=E2=80=99s can=E2=80=99t accept (and validate), then that=E2=80= =99s a problem with the relationship between the AS and the RS.=20 I also want to note that there are many implementations out there that = let the API offload the processing of the token request to another = component, like a gateway or a proxy, or use another external service to = check the incoming request=E2=80=99s parameters to see if they fit the = security policy for the API in question. In all of these cases, the = =E2=80=9CRS=E2=80=9D is the logical combination of all of these, and so = the =E2=80=9CRS=E2=80=9D can be adapted to accept different types = through its security layer and not necessarily the API code directly. =E2=80=94 Justin= From nobody Mon Feb 3 13:04:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA458120CA1 for ; Mon, 3 Feb 2020 13:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHoe9tiN8ZOA for ; Mon, 3 Feb 2020 13:04:04 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (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 52FBC120BD8 for ; Mon, 3 Feb 2020 13:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580763844; x=1612299844; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+pQsj1DOhOdHZI1AxtPpU/OLNKQUjah58+AVjSX4ktM=; b=AEUfSHFxAjQJzVY5EndMqNKWgAEWVEiuYnalD0lggfhN+58XIxr1dzyZ v6I6XUM7dcd26NXMRE5Z+Ef9spY5alW1ceJwdh42jshC3tdNtV3Z+5OVe eiHx8KsCBHXyBlkE+jT3AwJ/mTUU7Xc9+o7fzxY9FFul9AlDuImZ3ZLGQ A=; IronPort-SDR: 0sgRDUyusqzeCcJ8St+f2Gx645aKdBzy9LNv4+4ZUM+G2jObKZG9dZi58fmkr8F3PJQjrXDjPz NDiag1rP6Amg== X-IronPort-AV: E=Sophos; i="5.70,398,1574121600"; d="scan'208,217"; a="15494850" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 03 Feb 2020 21:04:03 +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-97fdccfd.us-east-1.amazon.com (Postfix) with ESMTPS id 810FCA191F; Mon, 3 Feb 2020 21:04:01 +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; Mon, 3 Feb 2020 21:04:00 +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; Mon, 3 Feb 2020 21:04:00 +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, 3 Feb 2020 21:04:00 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Yaron Sheffer CC: "txauth@ietf.org" Thread-Topic: [Txauth] use case document? Thread-Index: AQHV2Ic/v3OjqehvrkC0bTXLFbJPJqgGp4wAgABByYCAAAIMgIAAADyAgAKIIQA= Date: Mon, 3 Feb 2020 21:04:00 +0000 Message-ID: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.50] Content-Type: multipart/alternative; boundary="_000_9125637D21F347C28BC207CD14B15DE1amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 21:04:07 -0000 --_000_9125637D21F347C28BC207CD14B15DE1amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGZvbGxvdyB0aGUgbG9naWMgb2YgZGVmZXJyaW5nIHRoaXMsIHNpbmNlIHRoZSBj aGFydGVyIGRlZmluZXMgdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBXZeKAmXJlIGFs bCBjb21wYXJpbmcgdGhlIGNoYXJ0ZXIgZHJhZnRzIGFnYWluc3Qgb3VyIHVzZSBjYXNlcyBhbnl3 YXk7IGRvaW5nIHRoYXQgb3V0IGluIHRoZSBvcGVuIHNlZW1zIGxlc3MgbGlrZWx5IHRvIGxlYWQg dG8gYXJndW1lbnRzIGRvd24gdGhlIHJvYWQgb3ZlciB3aGV0aGVyIHNvbWV0aGluZyBmYWxscyB3 aXRoaW4gdGhlIHNjb3BlIGxhaWQgb3V0IGluIHRoZSBjaGFydGVyLg0KDQpGb3Igd2hhdCBpdOKA mXMgd29ydGgsIEp1c3RpbiBwdXQgdGhpcyB0b2dldGhlciBiYWNrIGluIEF1Z3VzdDogaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC92OFRka3J1Q3p3SDQzRk1LUzU5 OElDMlNoZW8NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkN Cg0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpEYXRlOiBTYXR1cmRheSwgRmVicnVh cnkgMSwgMjAyMCBhdCAyOjI1IFBNDQpUbzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21h aWwuY29tPg0KQ2M6ICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW1R4YXV0aF0gdXNlIGNhc2UgZG9jdW1lbnQ/DQoNCldvcmtzIGZvciBtZS4NCg0KT24g U2F0LCBGZWIgMSwgMjAyMCBhdCAyOjIzIFBNIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdt YWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpJdOKAmXMgaGFy ZCB0byDigJx0ZWFzZSBvdXTigJ0gd2hhdOKAmXMgaW4gc2NvcGUsIGFuZCBpbiBwYXJ0aWN1bGFy IHdoYXTigJlzICpub3QqIGluIHNjb3BlLCBiZWZvcmUgeW91IGhhdmUgYSBXRy4gSSBhbSB3b3Jy aWVkIGFib3V0IHNjb3BlIGNyZWVwIHdoaWNoIGlzIGxpa2VseSB0byBoYXBwZW4gb25jZSB0aGlz IGlzIGEgV0cgYW5kIG1vcmUgcGVvcGxlIGFyZSBpbnZvbHZlZC4gSU1PIHRoZSBiZXN0IHdheSB0 byBhdm9pZCBpdCBpcyBieSBvbmx5IGhhdmluZyB0aGlzIGRpc2N1c3Npb24gb25jZSBldmVyeWJv ZHkgaXMgb24gYm9hcmQuDQoNClRoYW5rcywNCiAgICAgICAgICAgICAgICBZYXJvbg0KDQpGcm9t OiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20+Pg0KRGF0ZTogU3VuZGF5LCBGZWJydWFyeSAyLCAyMDIwIGF0IDAwOjE2DQpUbzogWWFy b24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFp bC5jb20+Pg0KQ2M6IDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW1R4YXV0aF0gdXNlIGNhc2UgZG9jdW1lbnQ/DQoNCkkgd2FzIHRoaW5raW5n IGEgcm91Z2ggZHJhZnQgb2YgYSB1c2UgY2FzZSBkb2N1bWVudCB3b3VsZCBhc3Npc3QgaW4gdGVh c2luZyBvdXQgd2hhdCBpcyBpbiBzY29wZSBhbmQgbm90IGZvciB0aGUgV0cuDQoNCkkndmUgYmVl biBhZGRpbmcgdXNlIGNhc2VzIHRvIHRoZSBYQXV0aCBJRCB0byB0ZWFzZSBvdXQgd2hhdCB3b3Vs ZCBiZSBpbiBhbmQgb3V0IG9mIHNjb3BlLg0KDQpJdCB3b3VsZCBhbHNvIHByb3ZpZGUgY2xhcml0 eSBvbiB3aHkgdGhpcyBXRyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgT0F1dGggV0cuDQoNCk9uIFNh dCwgRmViIDEsIDIwMjAgYXQgMTA6MjAgQU0gWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21h aWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkkgc3VwcG9ydCBz dWNoIGEgZG9jdW1lbnQgaW4gcHJpbmNpcGxlLiBJIGFncmVlIHRoYXQgaGF2aW5nIGEgbGlzdCBv ZiB1c2UgY2FzZXMgd291bGQgaGVscCB0byBzY29wZSB0aGUgcHJvdG9jb2wgZG9jdW1lbnQocyku DQoNCkhvd2V2ZXIgSSB0aGluayBub3cgaXMgbm90IHRoZSByaWdodCB0aW1lLCBiZWNhdXNlIGEg dXNlIGNhc2UgZG9jdW1lbnQgaXMgb25seSB1c2VmdWwgaW4gZGVmaW5pbmcgc2NvcGUgb25jZSBp dCBpcyBtb3JlIG9yIGxlc3Mgc3RhYmxlIGFuZCBlbmpveXMgcm91Z2ggY29uc2Vuc3VzLiBXZSBj YW4gb25seSBkZW1vbnN0cmF0ZSBjb25zZW5zdXMgb25jZSB3ZSBtb3ZlIHBhc3QgdGhlIEJvRiBz dGFnZSBhbmQgaW50byBhIFdHLiBTbyBJIGJlbGlldmUgaXQgb25seSBtYWtlcyBzZW5zZSB0byBw cm9kdWNlIHRoZSB1c2UgY2FzZSBkb2Mgd2hlbiB3ZSBoYXZlIGEgY2hhcnRlcmVkIFdHLg0KDQpU aGFua3MsDQogICAgICAgICAgICAgICAgWWFyb24NCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tPj4NCkRhdGU6IFNhdHVyZGF5LCBGZWJydWFyeSAxLCAyMDIwIGF0IDAwOjM4DQpUbzog PHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFtUeGF1 dGhdIHVzZSBjYXNlIGRvY3VtZW50Pw0KDQpBcyBJIHJlZmxlY3Qgb24gbXkgY29udmVyc2F0aW9u cyB3aXRoIEp1c3RpbiwgYSBzZXQgb2YgdXNlIGNhc2VzIHdvdWxkIGhlbHAgZ3VpZGUgdXMuIFdl IGNvdWxkIHRoZW4gcmVmZXIgdG8gYSB1c2UgY2FzZSBhcyB3aHkgYSBmZWF0dXJlIGlzIHByZXNl bnQgYW5kIHNlZSBob3cgZGlmZmVyZW50IGZlYXR1cmVzIHN1cHBvcnQgKG9yIGRvbid0IHN1cHBv cnQpIGRpZmZlcmVudCB1c2UgY2FzZXMuDQoNCldlIGNhbiBhbHNvIHVzZSB0aGUgZG9jdW1lbnQg dG8gZGVjaWRlIHdoaWNoIHVzZSBjYXNlcyBhcmUgaW4gc2NvcGUsIG9yIG91dCBvZiBzY29wZS4N Cg0KSSdsbCBwdXQgdXAgbXkgaGFuZCB0byBlZGl0LiBXaG8gaXMgaW50ZXJlc3RlZCBpbiBjb250 cmlidXRpbmc/DQoNCi9EaWNrDQpFcnJvciEgRmlsZW5hbWUgbm90IHNwZWNpZmllZC7hkKcNCi0t IFR4YXV0aCBtYWlsaW5nIGxpc3QgVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo= --_000_9125637D21F347C28BC207CD14B15DE1amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <881D39A361498D429BF62EA6CC150189@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiRXVwaGVtaWEgVUNBUyI7DQoJcGFub3NlLTE6MiAx MSA1IDMgNCAxIDIgMiAxIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBmb2xsb3cgdGhlIGxvZ2ljIG9mIGRlZmVycmluZyB0aGlz LCBzaW5jZSB0aGUgY2hhcnRlciBkZWZpbmVzIHRoZSBzY29wZSBvZiB0aGUgd29ya2luZyBncm91 cC4gV2XigJlyZSBhbGwgY29tcGFyaW5nIHRoZSBjaGFydGVyIGRyYWZ0cyBhZ2FpbnN0IG91ciB1 c2UgY2FzZXMgYW55d2F5OyBkb2luZyB0aGF0IG91dCBpbiB0aGUgb3BlbiBzZWVtcyBsZXNzIGxp a2VseSB0byBsZWFkIHRvIGFyZ3VtZW50cw0KIGRvd24gdGhlIHJvYWQgb3ZlciB3aGV0aGVyIHNv bWV0aGluZyBmYWxscyB3aXRoaW4gdGhlIHNjb3BlIGxhaWQgb3V0IGluIHRoZSBjaGFydGVyLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igd2hhdCBpdOKAmXMgd29ydGgsIEp1c3RpbiBwdXQg dGhpcyB0b2dldGhlciBiYWNrIGluIEF1Z3VzdDoNCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvdjhUZGtydUN6d0g0M0ZNS1M1OThJQzJTaGVvIj4N Cmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvdjhUZGtydUN6d0g0 M0ZNS1M1OThJQzJTaGVvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0O3R4YXV0 aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7ZGljay5o YXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBGZWJydWFyeSAx LCAyMDIwIGF0IDI6MjUgUE08YnI+DQo8Yj5UbzogPC9iPllhcm9uIFNoZWZmZXIgJmx0O3lhcm9u Zi5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9y ZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W1R4YXV0aF0gdXNlIGNhc2UgZG9jdW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3JrcyBmb3IgbWUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEZlYiAxLCAyMDIwIGF0 IDI6MjMgUE0gWWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdt YWlsLmNvbSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SXTigJlzIGhhcmQgdG8g4oCcdGVhc2Ugb3V04oCdIHdoYXTigJlzIGluIHNjb3BlLCBh bmQgaW4gcGFydGljdWxhciB3aGF04oCZcyAqPGI+bm90PC9iPiogaW4gc2NvcGUsIGJlZm9yZSB5 b3UgaGF2ZSBhIFdHLiBJIGFtIHdvcnJpZWQgYWJvdXQgc2NvcGUgY3JlZXAgd2hpY2ggaXMgbGlr ZWx5IHRvIGhhcHBlbiBvbmNlIHRoaXMNCiBpcyBhIFdHIGFuZCBtb3JlIHBlb3BsZSBhcmUgaW52 b2x2ZWQuIElNTyB0aGUgYmVzdCB3YXkgdG8gYXZvaWQgaXQgaXMgYnkgb25seSBoYXZpbmcgdGhp cyBkaXNjdXNzaW9uIG9uY2UgZXZlcnlib2R5IGlzIG9uIGJvYXJkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIEZlYnJ1YXJ5IDIsIDIw MjAgYXQgMDA6MTY8YnI+DQo8Yj5UbzogPC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Jmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gdXNlIGNhc2UgZG9jdW1lbnQ/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSB3YXMgdGhpbmtpbmcgYSByb3VnaCBkcmFmdCBvZiBhIHVzZSBjYXNlIGRvY3VtZW50IHdvdWxk IGFzc2lzdCBpbiB0ZWFzaW5nIG91dCB3aGF0IGlzIGluIHNjb3BlIGFuZCBub3QgZm9yIHRoZSBX Ry48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ3Zl IGJlZW4gYWRkaW5nIHVzZSBjYXNlcyB0byB0aGUgWEF1dGggSUQgdG8gdGVhc2Ugb3V0IHdoYXQg d291bGQgYmUgaW4gYW5kIG91dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdvdWxkIGFsc28gcHJvdmlkZSBjbGFy aXR5IG9uIHdoeSB0aGlzIFdHIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBPQXV0aCBXRy4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFNhdCwgRmViIDEsIDIwMjAgYXQgMTA6MjAgQU0gWWFyb24gU2hlZmZlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlh cm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHN1cHBvcnQgc3VjaCBhIGRvY3VtZW50 IGluIHByaW5jaXBsZS4gSSBhZ3JlZSB0aGF0IGhhdmluZyBhIGxpc3Qgb2YgdXNlIGNhc2VzIHdv dWxkIGhlbHAgdG8gc2NvcGUgdGhlIHByb3RvY29sIGRvY3VtZW50KHMpLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SG93ZXZlciBJIHRoaW5rIG5vdyBpcyBub3QgdGhlIHJpZ2h0IHRpbWUs IGJlY2F1c2UgYSB1c2UgY2FzZSBkb2N1bWVudCBpcyBvbmx5IHVzZWZ1bCBpbiBkZWZpbmluZyBz Y29wZSBvbmNlIGl0IGlzIG1vcmUgb3IgbGVzcyBzdGFibGUgYW5kIGVuam95cyByb3VnaCBjb25z ZW5zdXMuIFdlIGNhbiBvbmx5IGRlbW9uc3RyYXRlDQogY29uc2Vuc3VzIG9uY2Ugd2UgbW92ZSBw YXN0IHRoZSBCb0Ygc3RhZ2UgYW5kIGludG8gYSBXRy4gU28gSSBiZWxpZXZlIGl0IG9ubHkgbWFr ZXMgc2Vuc2UgdG8gcHJvZHVjZSB0aGUgdXNlIGNhc2UgZG9jIHdoZW4gd2UgaGF2ZSBhIGNoYXJ0 ZXJlZCBXRy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFlhcm9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PlR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5TYXR1cmRheSwgRmVicnVhcnkgMSwgMjAyMCBhdCAwMDozODxicj4NCjxiPlRvOiA8L2I+Jmx0 OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bVHhhdXRoXSB1c2UgY2FzZSBk b2N1bWVudD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BcyBJIHJlZmxlY3Qgb24gbXkgY29udmVyc2F0aW9ucyB3aXRoIEp1 c3RpbiwgYSBzZXQgb2YgdXNlIGNhc2VzIHdvdWxkIGhlbHAgZ3VpZGUgdXMuIFdlIGNvdWxkIHRo ZW4gcmVmZXIgdG8gYSB1c2UgY2FzZSBhcyB3aHkgYSBmZWF0dXJlIGlzIHByZXNlbnQgYW5kIHNl ZSBob3cgZGlmZmVyZW50IGZlYXR1cmVzDQogc3VwcG9ydCAob3IgZG9uJ3Qgc3VwcG9ydCkgZGlm ZmVyZW50IHVzZSBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XZSBjYW4gYWxzbyB1c2UgdGhlIGRvY3VtZW50IHRvIGRlY2lkZSB3aGljaCB1 c2UgY2FzZXMgYXJlIGluIHNjb3BlLCBvciBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdsbCBwdXQgdXAgbXkgaGFuZCB0byBl ZGl0LiBXaG8gaXMgaW50ZXJlc3RlZCBpbiBjb250cmlidXRpbmc/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi9EaWNrPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGluIj5FcnJvciEgRmlsZW5hbWUgbm90IHNwZWNpZmllZC48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RXVwaGVtaWEgVUNBUyZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0gVHhhdXRoIG1haWxpbmcgbGlzdA0KPGEgaHJlZj0i bWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwv YT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoPC9hPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_9125637D21F347C28BC207CD14B15DE1amazoncom_-- From nobody Mon Feb 3 14:01:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F20512090D for ; Mon, 3 Feb 2020 14:01:34 -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_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001] autolearn=unavailable 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 Yy442eZgi3Za for ; Mon, 3 Feb 2020 14:01:28 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::728]) (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 293B2120133 for ; Mon, 3 Feb 2020 14:01:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jyhW7CNXHWW2/tmuIcxWuGH66O03GnCqBShxOKwxVlepZMk8zwOL/f1dO5uBxxsKz0bBJMxOobijzmGgzQR3ZdYk0VBPd7Tw1mupiBNCiVn9MQWw6OaohHu+ZpwtKzySPgwJm7Pjwqq2zGdNqz0xDdzg7KaWG766YvEkWiW72m8Emf2fzO9glAFQEUhRQW5NG10LqYPo1FOh28/ePDNNO+Z0hhWDVnbuyljuKxtq4ftakUo4JJ7cgumc/tqI/hXMsnMNAtuB7hkDdzvb16Pbxj++TCqFCNBjmyPlt8ggZVPspBQysaMu3OR53r3X4BaoSusMzpMRtvzWxsu0nr6IeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=okB+FeqC1TABG7CqKR1SKjgUJN3fzS/oOUSroS5GZFY=; b=PqZj4DGqSZ4i03V0sO2kYv7ym2ji/2uKo0Egtbi6RRXI7TeosSWjHmPv6UI248wCanbyjUyNTe3yZKD9jsCOfCRyvXMXTviDSYqb3xlfWdJdtXENjB3tZTQ1p1GDa+8oNgfoTFbbFQJDgRmSrlLKklh2gjaL5RyNA3VxcRJ3nnxGFHdYa5i7CuePynde5dspxU90bGUtnXQOqzqk6se8R4BkSCc60ojVfDw0FRMEMyT3GNCwsfJGgEcM6IcrAVcyppMyCHtA8ipvCW4aBo2LnmJCoroilOgWB57cLbGsCLTV1gHofluVAEFVc+8C9Q4d+5uIFZGJWPb8tf7FstVjuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=okB+FeqC1TABG7CqKR1SKjgUJN3fzS/oOUSroS5GZFY=; b=T0o7iPqn2Ga0E+bjQXVTf29a6XEkF742OL+GNGm3gzOt4ErEBoFmL3xbJvhyDZTuZfcHhyOUwft5sw4E+F/c0nwu9QZL56Ab0FeVv2J691qTP99fXfWKxqEWnbddYzBalcubW35CvoLWtzoOhqbtpRYPSOqXbYR3v9HVZqLihnQ= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (10.141.184.216) by DM6PR00MB0556.namprd00.prod.outlook.com (20.179.49.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2742.0; Mon, 3 Feb 2020 22:01:26 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::14b9:506:d536:fd07%8]) with mapi id 15.20.2741.000; Mon, 3 Feb 2020 22:01:26 +0000 From: Mike Jones To: Dick Hardt , Yaron Sheffer , "Richard Backman, Annabelle" CC: "txauth@ietf.org" Thread-Topic: [Txauth] use case document? Thread-Index: AQHV2tV+19EGbGzKGU2TdDGwjx/QKqgKBRuR Date: Mon, 3 Feb 2020 22:01:25 +0000 Message-ID: References: , <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> In-Reply-To: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-03T22:00:45.9920301Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [62.28.240.114] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c5eff0ea-ea0a-4d27-2b3f-08d7a8f49d69 x-ms-traffictypediagnostic: DM6PR00MB0556: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(396003)(136003)(366004)(39860400002)(189003)(199004)(26005)(186003)(478600001)(6506007)(33656002)(10290500003)(52536014)(53546011)(91956017)(66476007)(966005)(64756008)(66946007)(76116006)(66446008)(5660300002)(8936002)(81156014)(81166006)(8676002)(66556008)(4326008)(2906002)(9686003)(55016002)(7696005)(110136005)(86362001)(8990500004)(71200400001)(19627235002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0556; H:DM6PR00MB0682.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dU/W7/vgSkaybMmCA4BwyBh75C1uCD/HCNOXn5ZO2VbR5nrgn8/FR4UDqFggXECasqODlzx3ITYRn0Auh5rvhdmfdpy20WR48it2puGUxtIE+KnfkPQsNmLlY+zHZzsAUfSfe9KX1BD1l/kIUmGoniBynqUyR1U0d+twKdVNBtzQ86sCWtVcaSyC3QFJaS718PFNmeOKcJcdHrnwqC0QgxYH//aD8JDiCNIRHZhlG4peGxM5OdLGt3Jw0Ng4zh8CVuIrvpmmirZzR+t+3b5J/wWTMN86UdBGwi0nuzJtPtTFd7K/0BO7zfTUp/xgi4JfZarJiqOtYuHQGTPPUhFf6U2txZCnLyUkiVcSZvU79C+EljhTXwjL8YQ+KmbCHAQO8VhTU4SsZkPEo7YpnZP2Ukp4Bk7JB+bSGt2B1ZDc8hHoXglH6XQRjUt9CVDL5y/fAsIc8SK56Zg1Dptb7U+BDUOmYiyJbrZdcbzM+r235Luqzgfttr0XH84/cm/VMZa1DxV3fWm3W+cPM5T5APgkag== x-ms-exchange-antispam-messagedata: vG5+9JwQSFvedpIMN2Jadm5IWq7nnff4E8M08nZE/8wqjOyr1tYTmf1ISCu+vpbMyG1t/KhRNUQpTSXk/OmBg4aIflElNXkq6lfok+gq9y/SrRNN8Q+lOjaat2Of5s4ROHZycRE4ftRVoBfpTzr0IA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06823B9BD155E9A144102546F5000DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5eff0ea-ea0a-4d27-2b3f-08d7a8f49d69 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 22:01:25.8494 (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-CrossTenant-userprincipalname: +ds8iOLdFNZO8u4onMF5zgx2iqIQhHI1cl5qeK50Z26sAcTRLJKTGyj/TNko8aIshlOWmqGzI6Y1OuT0VhXPug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0556 Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 22:01:34 -0000 --_000_DM6PR00MB06823B9BD155E9A144102546F5000DM6PR00MB0682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4gSSdkIHJhdGhlciBzZWUgdXNlIGNhc2VzIHNvb25lciB0aGFuIGxhdGVyLg0KDQot LSBNaWtlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVHhhdXRoIDx0 eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDMsIDIwMjAgOTowNDowMCBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPjsgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPg0KQ2M6 IHR4YXV0aEBpZXRmLm9yZyA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVjdDogW0VYVEVSTkFMXSBS ZTogW1R4YXV0aF0gdXNlIGNhc2UgZG9jdW1lbnQ/DQoNCg0KSSBkb27igJl0IGZvbGxvdyB0aGUg bG9naWMgb2YgZGVmZXJyaW5nIHRoaXMsIHNpbmNlIHRoZSBjaGFydGVyIGRlZmluZXMgdGhlIHNj b3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBXZeKAmXJlIGFsbCBjb21wYXJpbmcgdGhlIGNoYXJ0 ZXIgZHJhZnRzIGFnYWluc3Qgb3VyIHVzZSBjYXNlcyBhbnl3YXk7IGRvaW5nIHRoYXQgb3V0IGlu IHRoZSBvcGVuIHNlZW1zIGxlc3MgbGlrZWx5IHRvIGxlYWQgdG8gYXJndW1lbnRzIGRvd24gdGhl IHJvYWQgb3ZlciB3aGV0aGVyIHNvbWV0aGluZyBmYWxscyB3aXRoaW4gdGhlIHNjb3BlIGxhaWQg b3V0IGluIHRoZSBjaGFydGVyLg0KDQoNCg0KRm9yIHdoYXQgaXTigJlzIHdvcnRoLCBKdXN0aW4g cHV0IHRoaXMgdG9nZXRoZXIgYmFjayBpbiBBdWd1c3Q6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvb2F1dGgvdjhUZGtydUN6d0g0M0ZNS1M1OThJQzJTaGVvPGh0dHBzOi8v bmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRm9hdXRoJTJGdjhUZGtydUN6d0g0 M0ZNS1M1OThJQzJTaGVvJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQu Y29tJTdDZTNlMmQ0Njk5OTM0NGY4MGE2MTUwOGQ3YThlYzllMjQlN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTYzNjA2NTUwNDU5MjY0JnNkYXRhPWp1OHBi cWgxd3hXOUFsQTNzQnVCMzRUajIxWEpRTDdINVg4M1ViSTVIdkElM0QmcmVzZXJ2ZWQ9MD4NCg0K DQoNCuKAkw0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCkFXUyBJZGVudGl0eQ0KDQoN Cg0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkRhdGU6IFNhdHVyZGF5LCBGZWJy dWFyeSAxLCAyMDIwIGF0IDI6MjUgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBn bWFpbC5jb20+DQpDYzogInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD8NCg0KDQoNCldvcmtzIGZvciBtZS4N Cg0KDQoNCk9uIFNhdCwgRmViIDEsIDIwMjAgYXQgMjoyMyBQTSBZYXJvbiBTaGVmZmVyIDx5YXJv bmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0K DQpJdOKAmXMgaGFyZCB0byDigJx0ZWFzZSBvdXTigJ0gd2hhdOKAmXMgaW4gc2NvcGUsIGFuZCBp biBwYXJ0aWN1bGFyIHdoYXTigJlzICpub3QqIGluIHNjb3BlLCBiZWZvcmUgeW91IGhhdmUgYSBX Ry4gSSBhbSB3b3JyaWVkIGFib3V0IHNjb3BlIGNyZWVwIHdoaWNoIGlzIGxpa2VseSB0byBoYXBw ZW4gb25jZSB0aGlzIGlzIGEgV0cgYW5kIG1vcmUgcGVvcGxlIGFyZSBpbnZvbHZlZC4gSU1PIHRo ZSBiZXN0IHdheSB0byBhdm9pZCBpdCBpcyBieSBvbmx5IGhhdmluZyB0aGlzIGRpc2N1c3Npb24g b25jZSBldmVyeWJvZHkgaXMgb24gYm9hcmQuDQoNCg0KDQpUaGFua3MsDQoNCiAgICAgICAgICAg ICAgICBZYXJvbg0KDQoNCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMiwg MjAyMCBhdCAwMDoxNg0KVG86IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4NCkNjOiA8dHhhdXRoQGlldGYub3JnPG1haWx0 bzp0eGF1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIHVzZSBjYXNlIGRvY3Vt ZW50Pw0KDQoNCg0KSSB3YXMgdGhpbmtpbmcgYSByb3VnaCBkcmFmdCBvZiBhIHVzZSBjYXNlIGRv Y3VtZW50IHdvdWxkIGFzc2lzdCBpbiB0ZWFzaW5nIG91dCB3aGF0IGlzIGluIHNjb3BlIGFuZCBu b3QgZm9yIHRoZSBXRy4NCg0KDQoNCkkndmUgYmVlbiBhZGRpbmcgdXNlIGNhc2VzIHRvIHRoZSBY QXV0aCBJRCB0byB0ZWFzZSBvdXQgd2hhdCB3b3VsZCBiZSBpbiBhbmQgb3V0IG9mIHNjb3BlLg0K DQoNCg0KSXQgd291bGQgYWxzbyBwcm92aWRlIGNsYXJpdHkgb24gd2h5IHRoaXMgV0cgaXMgZGlm ZmVyZW50IGZyb20gdGhlIE9BdXRoIFdHLg0KDQoNCg0KT24gU2F0LCBGZWIgMSwgMjAyMCBhdCAx MDoyMCBBTSBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9u Zi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIHN1cHBvcnQgc3VjaCBhIGRvY3VtZW50IGlu IHByaW5jaXBsZS4gSSBhZ3JlZSB0aGF0IGhhdmluZyBhIGxpc3Qgb2YgdXNlIGNhc2VzIHdvdWxk IGhlbHAgdG8gc2NvcGUgdGhlIHByb3RvY29sIGRvY3VtZW50KHMpLg0KDQoNCg0KSG93ZXZlciBJ IHRoaW5rIG5vdyBpcyBub3QgdGhlIHJpZ2h0IHRpbWUsIGJlY2F1c2UgYSB1c2UgY2FzZSBkb2N1 bWVudCBpcyBvbmx5IHVzZWZ1bCBpbiBkZWZpbmluZyBzY29wZSBvbmNlIGl0IGlzIG1vcmUgb3Ig bGVzcyBzdGFibGUgYW5kIGVuam95cyByb3VnaCBjb25zZW5zdXMuIFdlIGNhbiBvbmx5IGRlbW9u c3RyYXRlIGNvbnNlbnN1cyBvbmNlIHdlIG1vdmUgcGFzdCB0aGUgQm9GIHN0YWdlIGFuZCBpbnRv IGEgV0cuIFNvIEkgYmVsaWV2ZSBpdCBvbmx5IG1ha2VzIHNlbnNlIHRvIHByb2R1Y2UgdGhlIHVz ZSBjYXNlIGRvYyB3aGVuIHdlIGhhdmUgYSBjaGFydGVyZWQgV0cuDQoNCg0KDQpUaGFua3MsDQoN CiAgICAgICAgICAgICAgICBZYXJvbg0KDQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tPj4NCkRhdGU6IFNhdHVyZGF5LCBGZWJydWFyeSAxLCAyMDIwIGF0IDAwOjM4DQpUbzogPHR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFtUeGF1dGhd IHVzZSBjYXNlIGRvY3VtZW50Pw0KDQoNCg0KQXMgSSByZWZsZWN0IG9uIG15IGNvbnZlcnNhdGlv bnMgd2l0aCBKdXN0aW4sIGEgc2V0IG9mIHVzZSBjYXNlcyB3b3VsZCBoZWxwIGd1aWRlIHVzLiBX ZSBjb3VsZCB0aGVuIHJlZmVyIHRvIGEgdXNlIGNhc2UgYXMgd2h5IGEgZmVhdHVyZSBpcyBwcmVz ZW50IGFuZCBzZWUgaG93IGRpZmZlcmVudCBmZWF0dXJlcyBzdXBwb3J0IChvciBkb24ndCBzdXBw b3J0KSBkaWZmZXJlbnQgdXNlIGNhc2VzLg0KDQoNCg0KV2UgY2FuIGFsc28gdXNlIHRoZSBkb2N1 bWVudCB0byBkZWNpZGUgd2hpY2ggdXNlIGNhc2VzIGFyZSBpbiBzY29wZSwgb3Igb3V0IG9mIHNj b3BlLg0KDQoNCg0KSSdsbCBwdXQgdXAgbXkgaGFuZCB0byBlZGl0LiBXaG8gaXMgaW50ZXJlc3Rl ZCBpbiBjb250cmlidXRpbmc/DQoNCg0KDQovRGljaw0KDQpFcnJvciEgRmlsZW5hbWUgbm90IHNw ZWNpZmllZC7hkKcNCg0KLS0gVHhhdXRoIG1haWxpbmcgbGlzdCBUeGF1dGhAaWV0Zi5vcmc8bWFp bHRvOlR4YXV0aEBpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGg8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdHhh dXRoJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDZTNlMmQ0 Njk5OTM0NGY4MGE2MTUwOGQ3YThlYzllMjQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM3MTYzNjA2NTUwNDY0MjYzJnNkYXRhPSUyQmhsTVJnUVJCcEY4aiUy QnNOYkpPZXdkSHhReU5XWTZUVTJMcUc1UmNFdTg4JTNEJnJlc2VydmVkPTA+DQo= --_000_DM6PR00MB06823B9BD155E9A144102546F5000DM6PR00MB0682namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iIHN0eWxlPSJkaXJlY3Rpb246IGx0cjsgbWFyZ2luOiAwOyBwYWRkaW5nOiAwOyBmb250LWZh bWlseTogc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjogYmxhY2s7ICI+DQpJIGFn cmVlLiBJJ2QgcmF0aGVyIHNlZSB1c2UgY2FzZXMgc29vbmVyIHRoYW4gbGF0ZXIuPGJyPg0KPGJy Pg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyBtYXJnaW46 IDA7IHBhZGRpbmc6IDA7IGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7 IGNvbG9yOiBibGFjazsgIj4NCi0tIE1pa2U8YnI+DQo8L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxh eTppbmxpbmUtYmxvY2s7d2lkdGg6OTglIiB0YWJpbmRleD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBs eUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0eWxl PSJmb250LXNpemU6MTFwdCIgY29sb3I9IiMwMDAwMDAiPjxiPkZyb206PC9iPiBUeGF1dGggJmx0 O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAzLCAyMDIwIDk6MDQ6MDAgUE08YnI+ DQo8Yj5Ubzo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OzsgWWFy b24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g dHhhdXRoQGlldGYub3JnICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIHVzZSBjYXNlIGRvY3VtZW50PzwvZm9udD4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Ik1TIE1pbmNobyJ9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgifQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpfQ0KQGZvbnQtZmFjZQ0K CXt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJFdXBoZW1pYSBVQ0FTIn0NCnAueF9Nc29O b3JtYWwsIGxpLnhfTXNvTm9ybWFsLCBkaXYueF9Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZn0NCmE6bGluaywgc3Bhbi54X01zb0h5cGVybGluaw0KCXtjb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpzcGFuLnhfRW1haWxTdHlsZTE4 DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHR9 DQoueF9Nc29DaHBEZWZhdWx0DQoJe2ZvbnQtc2l6ZToxMC4wcHR9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlufQ0KZGl2LnhfV29yZFNlY3Rpb24x DQoJe30NCi0tPg0KPC9zdHlsZT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0ieF9Xb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj5JIGRvbuKAmXQgZm9sbG93IHRoZSBsb2dpYyBvZiBkZWZlcnJpbmcgdGhpcywgc2lu Y2UgdGhlIGNoYXJ0ZXIgZGVmaW5lcyB0aGUgc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIFdl 4oCZcmUgYWxsIGNvbXBhcmluZyB0aGUgY2hhcnRlciBkcmFmdHMgYWdhaW5zdCBvdXIgdXNlIGNh c2VzIGFueXdheTsgZG9pbmcgdGhhdCBvdXQgaW4gdGhlIG9wZW4gc2VlbXMgbGVzcyBsaWtlbHkg dG8gbGVhZCB0byBhcmd1bWVudHMNCiBkb3duIHRoZSByb2FkIG92ZXIgd2hldGhlciBzb21ldGhp bmcgZmFsbHMgd2l0aGluIHRoZSBzY29wZSBsYWlkIG91dCBpbiB0aGUgY2hhcnRlci48L3A+DQo8 cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ Rm9yIHdoYXQgaXTigJlzIHdvcnRoLCBKdXN0aW4gcHV0IHRoaXMgdG9nZXRoZXIgYmFjayBpbiBB dWd1c3Q6DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRmLm9yZyUyRmFyY2glMkZt c2clMkZvYXV0aCUyRnY4VGRrcnVDendINDNGTUtTNTk4SUMyU2hlbyZhbXA7ZGF0YT0wMiU3QzAx JTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0NlM2UyZDQ2OTk5MzQ0ZjgwYTYxNTA4 ZDdhOGVjOWUyNCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzcxNjM2MDY1NTA0NTkyNjQmYW1wO3NkYXRhPWp1OHBicWgxd3hXOUFsQTNzQnVCMzRUajIxWEpR TDdINVg4M1ViSTVIdkElM0QmYW1wO3Jlc2VydmVkPTAiIG9yaWdpbmFsc3JjPSJodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL3Y4VGRrcnVDendINDNGTUtTNTk4SUMy U2hlbyIgc2hhc2g9ImRmY1FHajl2TGViVmhUYVI2cVQvUDdpJiM0MztxYll4SXM1Z09UZjlSRGhy VGViYlhDLzBLRkdKN2dyV3Z2Wk55Wmw3VnBqQUFTemdxSVdqb3g4T3FEaFNTTEdSWWFaNjJKY0Rw TjhWWXlNUUk5RjZWSmozdHN4Q2tEUVp3QngvY29jRUhxbnlpdmlOMzlHcVJzbnczb1JxcXZMRldZ c0U4OFNRaSYjNDM7dHc2MGFkQTdZPSI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL29hdXRoL3Y4VGRrcnVDendINDNGTUtTNTk4SUMyU2hlbzwvYT48L3A+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJMmbmJzcDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i eF9Nc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xv cjpibGFjayI+VHhhdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm IG9mIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5TYXR1cmRheSwgRmVicnVhcnkgMSwgMjAyMCBhdCAyOjI1IFBNPGJyPg0KPGI+VG86IDwv Yj5ZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhdIHVzZSBjYXNlIGRvY3VtZW50Pzwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+V29ya3MgZm9yIG1lLjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+T24gU2F0LCBGZWIgMSwgMjAyMCBhdCAyOjIzIFBNIFlh cm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPnlh cm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0OyBw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0OyBtYXJnaW4tbGVmdDo0LjhwdDsgbWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+SXTi gJlzIGhhcmQgdG8g4oCcdGVhc2Ugb3V04oCdIHdoYXTigJlzIGluIHNjb3BlLCBhbmQgaW4gcGFy dGljdWxhciB3aGF04oCZcyAqPGI+bm90PC9iPiogaW4gc2NvcGUsIGJlZm9yZSB5b3UgaGF2ZSBh IFdHLiBJIGFtIHdvcnJpZWQgYWJvdXQgc2NvcGUgY3JlZXAgd2hpY2ggaXMgbGlrZWx5IHRvIGhh cHBlbiBvbmNlIHRoaXMgaXMgYSBXRyBhbmQgbW9yZSBwZW9wbGUgYXJlIGludm9sdmVkLiBJTU8g dGhlDQogYmVzdCB3YXkgdG8gYXZvaWQgaXQgaXMgYnkgb25seSBoYXZpbmcgdGhpcyBkaXNjdXNz aW9uIG9uY2UgZXZlcnlib2R5IGlzIG9uIGJvYXJkLjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCIgc3R5bGU9IiI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj5U aGFua3MsPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiIHN0 eWxlPSIiPiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIiBzdHlsZT0iIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsg Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0OyBjb2xvcjpibGFjayI+RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIEZlYnJ1YXJ5IDIsIDIwMjAgYXQgMDA6MTY8YnI+ DQo8Yj5UbzogPC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0 ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOiA8L2I+Jmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW1R4YXV0aF0gdXNlIGNhc2UgZG9jdW1lbnQ/PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj5JIHdhcyB0aGlua2luZyBhIHJv dWdoIGRyYWZ0IG9mIGEgdXNlIGNhc2UgZG9jdW1lbnQgd291bGQgYXNzaXN0IGluIHRlYXNpbmcg b3V0IHdoYXQgaXMgaW4gc2NvcGUgYW5kIG5vdCBmb3IgdGhlIFdHLjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+SSd2ZSBiZWVuIGFkZGluZyB1c2UgY2FzZXMg dG8gdGhlIFhBdXRoIElEIHRvIHRlYXNlIG91dCB3aGF0IHdvdWxkIGJlIGluIGFuZCBvdXQgb2Yg c2NvcGUuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0i Ij4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiIHN0eWxl PSIiPkl0IHdvdWxkIGFsc28gcHJvdmlkZSBjbGFyaXR5IG9uIHdoeSB0aGlzIFdHIGlzIGRpZmZl cmVudCBmcm9tIHRoZSBPQXV0aCBXRy4mbmJzcDsmbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+T24gU2F0LCBGZWIgMSwgMjAyMCBhdCAx MDoyMCBBTSBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7IHBhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7IG1hcmdp bi1sZWZ0OjQuOHB0OyBtYXJnaW4tdG9wOjUuMHB0OyBtYXJnaW4tcmlnaHQ6MGluOyBtYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHls ZT0iIj5JIHN1cHBvcnQgc3VjaCBhIGRvY3VtZW50IGluIHByaW5jaXBsZS4gSSBhZ3JlZSB0aGF0 IGhhdmluZyBhIGxpc3Qgb2YgdXNlIGNhc2VzIHdvdWxkIGhlbHAgdG8gc2NvcGUgdGhlIHByb3Rv Y29sIGRvY3VtZW50KHMpLjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+Jm5i c3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj5Ib3dldmVyIEkgdGhpbmsg bm93IGlzIG5vdCB0aGUgcmlnaHQgdGltZSwgYmVjYXVzZSBhIHVzZSBjYXNlIGRvY3VtZW50IGlz IG9ubHkgdXNlZnVsIGluIGRlZmluaW5nIHNjb3BlIG9uY2UgaXQgaXMgbW9yZSBvciBsZXNzIHN0 YWJsZSBhbmQgZW5qb3lzIHJvdWdoIGNvbnNlbnN1cy4gV2UgY2FuIG9ubHkgZGVtb25zdHJhdGUg Y29uc2Vuc3VzIG9uY2Ugd2UgbW92ZSBwYXN0IHRoZSBCb0Ygc3RhZ2UNCiBhbmQgaW50byBhIFdH LiBTbyBJIGJlbGlldmUgaXQgb25seSBtYWtlcyBzZW5zZSB0byBwcm9kdWNlIHRoZSB1c2UgY2Fz ZSBkb2Mgd2hlbiB3ZSBoYXZlIGEgY2hhcnRlcmVkIFdHLjwvcD4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCIgc3R5bGU9IiI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0i Ij5UaGFua3MsPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi IHN0eWxlPSIiPiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9InhfTXNvTm9ybWFsIiBzdHlsZT0iIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDsgY29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0OyBjb2xvcjpibGFjayI+VHhhdXRoICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGgtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBGZWJydWFyeSAxLCAyMDIwIGF0IDAwOjM4 PGJyPg0KPGI+VG86IDwvYj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PltUeGF1dGhdIHVzZSBjYXNlIGRvY3VtZW50Pzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+QXMgSSByZWZsZWN0IG9uIG15IGNvbnZl cnNhdGlvbnMgd2l0aCBKdXN0aW4sIGEgc2V0IG9mIHVzZSBjYXNlcyB3b3VsZCBoZWxwIGd1aWRl IHVzLiBXZSBjb3VsZCB0aGVuIHJlZmVyIHRvIGEgdXNlIGNhc2UgYXMgd2h5IGEgZmVhdHVyZSBp cyBwcmVzZW50IGFuZCBzZWUgaG93IGRpZmZlcmVudCBmZWF0dXJlcyBzdXBwb3J0IChvciBkb24n dCBzdXBwb3J0KSBkaWZmZXJlbnQgdXNlIGNhc2VzLjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCIgc3R5bGU9IiI+V2UgY2FuIGFsc28gdXNlIHRoZSBkb2N1bWVudCB0byBkZWNp ZGUgd2hpY2ggdXNlIGNhc2VzIGFyZSBpbiBzY29wZSwgb3Igb3V0IG9mIHNjb3BlLjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+SSdsbCBwdXQgdXAgbXkgaGFu ZCB0byBlZGl0LiBXaG8gaXMgaW50ZXJlc3RlZCBpbiBjb250cmlidXRpbmc/PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9IiI+L0RpY2s8 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9 IiI+PGI+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0OyBwYWRkaW5n OjBpbiI+RXJyb3IhIEZpbGVuYW1lIG5vdCBzcGVjaWZpZWQuPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtFdXBoZW1pYSBVQ0FTJnF1b3Q7 LHNhbnMtc2VyaWY7IGNvbG9yOndoaXRlIj7hkKc8L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSIiPi0tIFR4YXV0aCBtYWlsaW5nIGxpc3QgPGEgaHJlZj0i bWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KVHhhdXRoQGlldGYub3Jn PC9hPiA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZ0eGF1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t JTdDZTNlMmQ0Njk5OTM0NGY4MGE2MTUwOGQ3YThlYzllMjQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTYzNjA2NTUwNDY0MjYzJmFtcDtzZGF0YT0lMkJo bE1SZ1FSQnBGOGolMkJzTmJKT2V3ZEh4UXlOV1k2VFUyTHFHNVJjRXU4OCUzRCZhbXA7cmVzZXJ2 ZWQ9MCIgb3JpZ2luYWxzcmM9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoIiBzaGFzaD0iZzhnSiYjNDM7R2VZL2dmbjExdFlkQndBbGNKTnZSYzYvN3VoTXptVnRP UUdIa1l1NFRURmlrUnRIV3VwRktIZFJoWTdCU2tyQ1VxL29zNWFyL2JBbGNzSEpINWs0LzhleGFD TnpxRDVjM2NxZ1FtTklqTkxIQWRMaTRsbnhNb0RTZmdTNUUvU0pIL0QyeWpMeWt1WWRNZE14cXJv Y1FmYVhOYlllZjJGd2JBc3o3VT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPiA8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR00MB06823B9BD155E9A144102546F5000DM6PR00MB0682namp_-- From nobody Tue Feb 4 08:17:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79406120143 for ; Tue, 4 Feb 2020 08:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 0LTxVMWRSuSg for ; Tue, 4 Feb 2020 08:17:13 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3E731120144 for ; Tue, 4 Feb 2020 08:17:13 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 014GH79T002621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Feb 2020 11:17:09 -0500 From: Justin Richer Message-Id: <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF96DDA2-E33B-43F9-B2AA-90D5CDF80EE7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Feb 2020 11:17:07 -0500 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , "Richard Backman, Annabelle" , "txauth@ietf.org" To: Mike Jones References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:17:15 -0000 --Apple-Mail=_FF96DDA2-E33B-43F9-B2AA-90D5CDF80EE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m fine with use cases as input to work, but they should always = be taken as non-binding and non-normative. In other words, they=E2=80=99re= a great way for us to write something down and say =E2=80=9Cyeah that = makes sense for something for us to work on=E2=80=9D. But I don=E2=80=99t = think it makes sense as a way to enforce direction or decision within = the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases document, = we=E2=80=99re not going to talk about it=E2=80=9D), or as a formal = output of the document.=20 Therefore if it=E2=80=99s an openly accessible and editable document = that people can put things in, I think it=E2=80=99s a helpful tool. The = moment it becomes burdensome to update and continue use, we need to = question whether we should keep doing it. =E2=80=94 Justin > On Feb 3, 2020, at 5:01 PM, Mike Jones = wrote: >=20 > I agree. I'd rather see use cases sooner than later. >=20 > -- Mike > From: Txauth on behalf of Richard Backman, = Annabelle > Sent: Monday, February 3, 2020 9:04:00 PM > To: Dick Hardt ; Yaron Sheffer = > Cc: txauth@ietf.org > Subject: [EXTERNAL] Re: [Txauth] use case document? > =20 > I don=E2=80=99t follow the logic of deferring this, since the charter = defines the scope of the working group. We=E2=80=99re all comparing the = charter drafts against our use cases anyway; doing that out in the open = seems less likely to lead to arguments down the road over whether = something falls within the scope laid out in the charter. > =20 > For what it=E2=80=99s worth, Justin put this together back in August: = https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo = > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Txauth on behalf of Dick Hardt = > Date: Saturday, February 1, 2020 at 2:25 PM > To: Yaron Sheffer > Cc: "txauth@ietf.org" > Subject: Re: [Txauth] use case document? > =20 > Works for me. > =20 > On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer > wrote: > It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in = scope, and in particular what=E2=80=99s *not* in scope, before you have = a WG. I am worried about scope creep which is likely to happen once this = is a WG and more people are involved. IMO the best way to avoid it is by = only having this discussion once everybody is on board. > =20 > Thanks, > Yaron > =20 > From: Dick Hardt > > Date: Sunday, February 2, 2020 at 00:16 > To: Yaron Sheffer > > Cc: > > Subject: Re: [Txauth] use case document? > =20 > I was thinking a rough draft of a use case document would assist in = teasing out what is in scope and not for the WG. > =20 > I've been adding use cases to the XAuth ID to tease out what would be = in and out of scope. > =20 > It would also provide clarity on why this WG is different from the = OAuth WG. =20 > =20 > On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer > wrote: > I support such a document in principle. I agree that having a list of = use cases would help to scope the protocol document(s). > =20 > However I think now is not the right time, because a use case document = is only useful in defining scope once it is more or less stable and = enjoys rough consensus. We can only demonstrate consensus once we move = past the BoF stage and into a WG. So I believe it only makes sense to = produce the use case doc when we have a chartered WG. > =20 > Thanks, > Yaron > =20 > From: Txauth > on behalf of Dick Hardt = > > Date: Saturday, February 1, 2020 at 00:38 > To: > > Subject: [Txauth] use case document? > =20 > As I reflect on my conversations with Justin, a set of use cases would = help guide us. We could then refer to a use case as why a feature is = present and see how different features support (or don't support) = different use cases. > =20 > We can also use the document to decide which use cases are in scope, = or out of scope. > =20 > I'll put up my hand to edit. Who is interested in contributing? > =20 > /Dick > Error! Filename not specified.=E1=90=A7 > -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_FF96DDA2-E33B-43F9-B2AA-90D5CDF80EE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m fine with use cases as input to work, but they should always be = taken as non-binding and non-normative. In other words, they=E2=80=99re = a great way for us to write something down and say =E2=80=9Cyeah that = makes sense for something for us to work on=E2=80=9D. But I don=E2=80=99t = think it makes sense as a way to enforce direction or decision within = the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases document, = we=E2=80=99re not going to talk about it=E2=80=9D), or as a formal = output of the document. 

Therefore if it=E2=80=99s an openly accessible and editable = document that people can put things in, I think it=E2=80=99s a helpful = tool. The moment it becomes burdensome to update and continue use, we = need to question whether we should keep doing it.
= --Apple-Mail=_FF96DDA2-E33B-43F9-B2AA-90D5CDF80EE7-- From nobody Tue Feb 4 08:57:51 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D0120251 for ; Tue, 4 Feb 2020 08:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=hopebailie.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNMQk-auN50p for ; Tue, 4 Feb 2020 08:57:45 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0: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 48B4E1207FE for ; Tue, 4 Feb 2020 08:57:45 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id h9so17712070otj.11 for ; Tue, 04 Feb 2020 08:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S1JKmLeOOj8zmvq1tBYiG3RGL8c/RCXiME0uDCtXArc=; b=ODFGvMQQoPmBGR+il6SC72UnMTEGZGt4m0TKXKZ6mVajyIMuTny5lYX5Yl0Czv+5J9 EMxFd0LnV7tG8NdMF6TAr4PRJHJrw4g6nvo3VDWSZ6nQRrrgD+MNnJuBlhgPD/U/UCps xZwkahdsxuGpwNmReHTZf8/uzaqEOMUbM4Mbw= 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=S1JKmLeOOj8zmvq1tBYiG3RGL8c/RCXiME0uDCtXArc=; b=nVfdLxOQLxfEsLnNVI+g03A4+3TozpaJhsJd+bGmI+4uXqXnC7azcAmTbZGqlV0mn5 8DIOFv+9HFKq95CSBoUBn5rfpWki0kEMIS3v8Mp8PAvcifuruxESfQ2gRyeajSHru/42 dHftNB8aE+SYHvQFkSFA77XwZEK12DwLcnxlEyI6sfuDZ40xaUu8YD+zedwVs6oSjdWH Xnfra1L5kTVdi7jnU7Jii1L3p0x6KpjHtGePTE7FRoyQ/sDAGkqFOvljv033wEzsZUgd ROrBteH1xDee+9NDGYVoue+89wpUTIYAymE8ZmGYEhVdYzhzxtEX3gJJ3KKleTZx0Utu cUlg== X-Gm-Message-State: APjAAAU9SMYUwRr41sGIYdY39ckO6NmFpzH4JMI25YnmJPCZV7pME+01 8F3GHCk84z/+HMho6izPq3q2Xw4cshD0iOV5JJC5AA== X-Google-Smtp-Source: APXvYqwhyLkW+iPu6rW9/wX4GL9C089zEwJeFMse0nrY8pEE62SYdSbh9XsYF8GGSUOqzAKcBXWcHjwE8Bzsvnoib2M= X-Received: by 2002:a9d:7083:: with SMTP id l3mr21846575otj.193.1580835464346; Tue, 04 Feb 2020 08:57:44 -0800 (PST) MIME-Version: 1.0 References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> In-Reply-To: <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> From: Adrian Hope-Bailie Date: Tue, 4 Feb 2020 18:57:32 +0200 Message-ID: To: Justin Richer Cc: Mike Jones , Yaron Sheffer , "Richard Backman, Annabelle" , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000004d1103059dc2f0a3" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:57:50 -0000 --0000000000004d1103059dc2f0a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the way to use this document is to inform decisions around the scope of the charter. Once the WG is formed this will be a useful reference for evaluating design decisions but could just as easily be left to go stale as the point of reference for the WG on issues of scope will be the charter itself. On Tue, 4 Feb 2020 at 18:17, Justin Richer wrote: > I=E2=80=99m fine with use cases as input to work, but they should always = be taken > as non-binding and non-normative. In other words, they=E2=80=99re a great= way for > us to write something down and say =E2=80=9Cyeah that makes sense for som= ething for > us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a way= to enforce > direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not i= n the use cases > document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a for= mal output of the > document. > > Therefore if it=E2=80=99s an openly accessible and editable document that= people > can put things in, I think it=E2=80=99s a helpful tool. The moment it bec= omes > burdensome to update and continue use, we need to question whether we > should keep doing it. > > =E2=80=94 Justin > > On Feb 3, 2020, at 5:01 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I agree. I'd rather see use cases sooner than later. > > -- Mike > ------------------------------ > *From:* Txauth on behalf of Richard Backman, > Annabelle > *Sent:* Monday, February 3, 2020 9:04:00 PM > *To:* Dick Hardt ; Yaron Sheffer < > yaronf.ietf@gmail.com> > *Cc:* txauth@ietf.org > *Subject:* [EXTERNAL] Re: [Txauth] use case document? > > I don=E2=80=99t follow the logic of deferring this, since the charter def= ines the > scope of the working group. We=E2=80=99re all comparing the charter draft= s against > our use cases anyway; doing that out in the open seems less likely to lea= d > to arguments down the road over whether something falls within the scope > laid out in the charter. > > > For what it=E2=80=99s worth, Justin put this together back in August: > https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo > > > > =E2=80=93 > Annabelle Richard Backman > AWS Identity > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Saturday, February 1, 2020 at 2:25 PM > *To: *Yaron Sheffer > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] use case document? > > > Works for me. > > > On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer > wrote: > > It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope,= and in particular what=E2=80=99s **not** > in scope, before you have a WG. I am worried about scope creep which is > likely to happen once this is a WG and more people are involved. IMO the > best way to avoid it is by only having this discussion once everybody is = on > board. > > > Thanks, > Yaron > > > *From: *Dick Hardt > *Date: *Sunday, February 2, 2020 at 00:16 > *To: *Yaron Sheffer > *Cc: * > *Subject: *Re: [Txauth] use case document? > > > I was thinking a rough draft of a use case document would assist in > teasing out what is in scope and not for the WG. > > > I've been adding use cases to the XAuth ID to tease out what would be in > and out of scope. > > > It would also provide clarity on why this WG is different from the OAuth > WG. > > > On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer > wrote: > > I support such a document in principle. I agree that having a list of use > cases would help to scope the protocol document(s). > > > However I think now is not the right time, because a use case document is > only useful in defining scope once it is more or less stable and enjoys > rough consensus. We can only demonstrate consensus once we move past the > BoF stage and into a WG. So I believe it only makes sense to produce the > use case doc when we have a chartered WG. > > > Thanks, > Yaron > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Saturday, February 1, 2020 at 00:38 > *To: * > *Subject: *[Txauth] use case document? > > > As I reflect on my conversations with Justin, a set of use cases would > help guide us. We could then refer to a use case as why a feature is > present and see how different features support (or don't support) differe= nt > use cases. > > > We can also use the document to decide which use cases are in scope, or > out of scope. > > > I'll put up my hand to edit. Who is interested in contributing? > > > /Dick > *Error! Filename not specified.*=E1=90=A7 > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000004d1103059dc2f0a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the way to use this document is to inform decisi= ons around the scope of the charter.
Once the WG is formed this will be= a useful reference for evaluating design decisions but could just as easil= y be left to go stale as the point of reference for the WG on issues of sco= pe will be the charter itself.

On Tue, 4 Feb 2020 at 18:17, Justin Ric= her <jricher@mit.edu> wrote:
I=E2=80=99m fine with use cases as input to work, = but they should always be taken as non-binding and non-normative. In other = words, they=E2=80=99re a great way for us to write something down and say = =E2=80=9Cyeah that makes sense for something for us to work on=E2=80=9D. Bu= t I don=E2=80=99t think it makes sense as a way to enforce direction or dec= ision within the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases do= cument, we=E2=80=99re not going to talk about it=E2=80=9D), or as a formal = output of the document.=C2=A0

Therefore if it=E2=80=99s = an openly accessible and editable document that people can put things in, I= think it=E2=80=99s a helpful tool. The moment it becomes burdensome to upd= ate and continue use, we need to question whether we should keep doing it.<= /div>

=C2=A0=E2=80=94 Justin

On Feb 3, 2020, at 5:01 PM, Mike Jones <Michael= .Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I agree. = I'd rather see use cases sooner than later.

-- Mike
=
From:=C2=A0Txauth <txauth-bounces@ietf= .org> on behalf of Richard Backman, Annabelle <richanna=3D40amaz= on.com@dmarc.ietf.org>
Sent:=C2=A0Monday, Feb= ruary 3, 2020 9:04:00 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com= >; Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0<= a href=3D"mailto:txauth@ietf.org" target=3D"_blank">txauth@ietf.org <= ;txauth@ietf.org&g= t;
Subject:=C2=A0[EXTERNAL] Re: [Txauth] use case do= cument?
=C2=A0
I don=E2=80=99t follow the logic of deferring this, since the = charter defines the scope of the working group. We=E2=80=99re all comparing= the charter drafts against our use cases anyway; doing that out in the ope= n seems less likely to lead to arguments down the road over whether somethi= ng falls within the scope laid out in the charter.

=C2=A0

<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">For what it=E2=80=99s worth, Justin put this together back in Augu= st:=C2=A0https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMK= S598IC2Sheo

=C2=A0

=E2=80=93=C2=A0
Annabelle Richard Backman
AWS Identity

=C2=A0

=C2=A0

=
From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>Date:=C2=A0Saturday, February 1, 2020 at 2:25 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:= =C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re: [= Txauth] use case document?

=C2=A0

<= div>
Works for me.

=C2=A0

yaronf.ietf@gmail.com> wrote:
It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what= =E2=80=99s in scope, and in particular what=E2=80=99s *not* in scope= , before you have a WG. I am worried about scope creep which is likely to h= appen once this is a WG and more people are involved. IMO the best way to a= void it is by only having this discussion once everybody is on board.
=

=C2=A0

Thanks,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

= From:=C2=A0Dick Hardt <dick.= hardt@gmail.com>
Date:=C2=A0Sunday, February = 2, 2020 at 00:16
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0= <txauth@ietf.org>
Subje= ct:=C2=A0Re: [Txauth] use case document?

=C2=A0

I was thinking a rough draft o= f a use case document would assist in teasing out what is in scope and not = for the WG.

=C2=A0

I've been = adding use cases to the XAuth ID to tease out what would be in and out of s= cope.

=C2=A0

It would also = provide clarity on why this WG is different from the OAuth WG.=C2=A0=C2=A0<= /div>

=C2=A0

On Sat, Feb 1, 2020 = at 10:20 AM Yaron Sheffer <yaronf.ietf@gm= ail.com> wrote:
I support= such a document in principle. I agree that having a list of use cases woul= d help to scope the protocol document(s).

=C2=A0

= However I think now is not the right time, because a use case document is o= nly useful in defining scope once it is more or less stable and enjoys roug= h consensus. We can only demonstrate consensus once we move past the BoF st= age and into a WG. So I believe it only makes sense to produce the use case= doc when we have a chartered WG.

=C2=A0

Thanks,<= /div>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

Fr= om:=C2=A0Txauth <= txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>= ;
Date:=C2=A0Saturday, February 1, 2020 at 00:38
= To:=C2=A0<txauth@ietf.org= >
Subject:=C2=A0[Txauth] use case document?

=C2=A0

As I reflect o= n my conversations with Justin, a set of use cases would help guide us. We = could then refer to a use case as why a feature is present and see how diff= erent features support (or don't support) different use cases.

=C2=A0

We can also use the document to de= cide which use cases are in scope, or out of scope.

=C2= =A0

I'll put up my hand to edit. Who is interes= ted in contributing?

=C2=A0

/Dick
Error! Filename not specified.=E1=90=A7
-= -=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/= txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000004d1103059dc2f0a3-- From nobody Tue Feb 4 15:06:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE0120152 for ; Tue, 4 Feb 2020 15:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.77 X-Spam-Level: X-Spam-Status: No, score=0.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MALFORMED_FREEMAIL=1.122, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 xevgL-V_sIfC for ; Tue, 4 Feb 2020 15:06:11 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-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 E23D91200B7 for ; Tue, 4 Feb 2020 15:06:10 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id p8so191473iln.12 for ; Tue, 04 Feb 2020 15:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=kaeam/KuYuYtS9jpiDZX/n9IkQpxEryWCkmeEa5SjCc=; b=ufWBE+ByEyDe37Wvv6H0UBNoxGOxQUo+Niunh8kFKfFNLJwHxqQxKcWb7cuf/o/rmO 0H9wPEHTZ/B0E+HceEQNLvJc4BGOIoew4XoqSOvqq5KM/UFGHArzke4jITr2yy8FZIs9 AD7fHGLhbJSAlRUNOVvq/ZDgp2y0d2hpFElJFR6R9i2h/w6Z29nRX+/ytJl9S7PaB6wZ dtCYuBdxJ4FFpa7dRmJBjEc+5AGCM2Hh6odSGzJdf05G7el2X6PVe21Lvh3RU6WN1I6M dCBBibYd20aI0MFGxOE5OPdMI0zNoNDU0hrN1mRYemTyVaWwdfZbAj76k8gpKIj1/WKc xHig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=kaeam/KuYuYtS9jpiDZX/n9IkQpxEryWCkmeEa5SjCc=; b=e7FmLp80RV5/cw+HzaDKiHjtRc1bLS4CH8RtHul0ZI+Ut3xzuylUUi+hVvgXYpDdvq ITkrAbOv7p4c21LnTeL4t8xD+OaBVZL1rZnx7AJ/Ii1Kwr3WpFuqQEVw3GFCGWEZVm2E JLb87AhZ7AQw5OAZAxlT+c9g+S0yePcLjBPspLtjORjhkxLPp9gUURChh2Z4PHE4CYsR eOscYs4DU+bsIptST6a0vBm5HUDVe0Mbh4uFLrxkqHc031x8OuPpuSDUowbYxxz6ijyt PTyaX3a+jDkRWEe/7I/nQztlIgkVGZVJvkCK+Nba5emSJVDEK6d2x7tnG2xYaJODWYn+ LwuA== X-Gm-Message-State: APjAAAXpvzEl1aThuas97ECp2VGcFZg7cpwnXwNFahae4hUWuu27Olki F8bwcnz8xpi7cvGQE7jH8m8= X-Google-Smtp-Source: APXvYqzPGAWqHjeQfn9jBbXAqqaL2ubjVV+lLTmdGdNXlN9lLkGZ1DEcu1AdRd2IQTRoqMcQgLr9Fg== X-Received: by 2002:a92:8f44:: with SMTP id j65mr29341624ild.144.1580857570214; Tue, 04 Feb 2020 15:06:10 -0800 (PST) Received: from [172.20.4.96] ([50.226.71.195]) by smtp.gmail.com with ESMTPSA id m189sm7025911ioa.17.2020.02.04.15.06.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2020 15:06:09 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Tue, 04 Feb 2020 18:42:54 +0200 From: Yaron Sheffer To: Justin Richer , Mike Jones CC: Dick Hardt , "Richard Backman, Annabelle" , "txauth@ietf.org" Message-ID: <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> Thread-Topic: [Txauth] use case document? References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> In-Reply-To: <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3663709569_2147318975" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 23:06:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3663709569_2147318975 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Once this is a working group, we will need to make decisions on scope: what= goes into the base document, what we might want as extensions, and what the= WG doesn=E2=80=99t want to work on in the near term. =20 If we have a use case document, that would be the natural place to have the= se discussions =E2=80=93 you clarify each particular use case and make sure everyb= ody agrees on what it means, and then the group decides which bucket to put = it in: base document, extension, defer. Otherwise I=E2=80=99m not sure what the do= cument is intended to achieve. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Justin Richer Date: Tuesday, February 4, 2020 at 18:17 To: Mike Jones Cc: Dick Hardt , Yaron Sheffer , "Richard Backman, Annabelle" , "txa= uth@ietf.org" Subject: Re: [Txauth] use case document? =20 I=E2=80=99m fine with use cases as input to work, but they should always be taken= as non-binding and non-normative. In other words, they=E2=80=99re a great way for= us to write something down and say =E2=80=9Cyeah that makes sense for something f= or us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a way to enforce = direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases= document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a formal output of = the document.=20 =20 Therefore if it=E2=80=99s an openly accessible and editable document that people = can put things in, I think it=E2=80=99s a helpful tool. The moment it becomes burd= ensome to update and continue use, we need to question whether we should kee= p doing it. =20 =E2=80=94 Justin On Feb 3, 2020, at 5:01 PM, Mike Jones wrote: =20 I agree. I'd rather see use cases sooner than later. -- Mike From: Txauth on behalf of Richard Backman, Annabe= lle Sent: Monday, February 3, 2020 9:04:00 PM To: Dick Hardt ; Yaron Sheffer Cc: txauth@ietf.org Subject: [EXTERNAL] Re: [Txauth] use case document? =20 I don=E2=80=99t follow the logic of deferring this, since the charter defines the= scope of the working group. We=E2=80=99re all comparing the charter drafts agains= t our use cases anyway; doing that out in the open seems less likely to lead= to arguments down the road over whether something falls within the scope la= id out in the charter. =20 For what it=E2=80=99s worth, Justin put this together back in August: https://mai= larchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo =20 =E2=80=93=20 Annabelle Richard Backman AWS Identity =20 =20 From: Txauth on behalf of Dick Hardt Date: Saturday, February 1, 2020 at 2:25 PM To: Yaron Sheffer Cc: "txauth@ietf.org" Subject: Re: [Txauth] use case document? =20 Works for me. =20 On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer wrote: It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, and in particular what=E2=80=99= s *not* in scope, before you have a WG. I am worried about scope creep which= is likely to happen once this is a WG and more people are involved. IMO the= best way to avoid it is by only having this discussion once everybody is on= board. =20 Thanks, Yaron =20 From: Dick Hardt Date: Sunday, February 2, 2020 at 00:16 To: Yaron Sheffer Cc: Subject: Re: [Txauth] use case document? =20 I was thinking a rough draft of a use case document would assist in teasing= out what is in scope and not for the WG. =20 I've been adding use cases to the XAuth ID to tease out what would be in an= d out of scope. =20 It would also provide clarity on why this WG is different from the OAuth WG= . =20 =20 On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer wrote= : I support such a document in principle. I agree that having a list of use c= ases would help to scope the protocol document(s). =20 However I think now is not the right time, because a use case document is o= nly useful in defining scope once it is more or less stable and enjoys rough= consensus. We can only demonstrate consensus once we move past the BoF stag= e and into a WG. So I believe it only makes sense to produce the use case do= c when we have a chartered WG. =20 Thanks, Yaron =20 From: Txauth on behalf of Dick Hardt Date: Saturday, February 1, 2020 at 00:38 To: Subject: [Txauth] use case document? =20 As I reflect on my conversations with Justin, a set of use cases would help= guide us. We could then refer to a use case as why a feature is present and= see how different features support (or don't support) different use cases. =20 We can also use the document to decide which use cases are in scope, or out= of scope. =20 I'll put up my hand to edit. Who is interested in contributing? =20 /Dick Error! Filename not specified.=E1=90=A7 -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --B_3663709569_2147318975 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Once this is a working grou= p, we will need to make decisions on scope: what goes into the base document= , what we might want as extensions, and what the WG doesn=E2=80=99t want to work o= n in the near term.

 

If we have a use case document, that would be the natural p= lace to have these discussions =E2=80=93 you clarify each particular use case and = make sure everybody agrees on what it means, and then the group decides whic= h bucket to put it in: base document, extension, defer. Otherwise I=E2=80=99m not = sure what the document is intended to achieve.

 

Thanks,

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

 

From: Justin Richer <jricher@mit.edu>
Date: Tuesday, February 4= , 2020 at 18:17
To: Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org>
Cc: Dick Hardt <dick.hardt@gmail.com>, Yar= on Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabelle&q= uot; <richanna=3D40amazon.com@dmarc.ietf.org>, "txauth@ietf.org&quo= t; <txauth@ietf.org>
Subject: Re: [Txauth] use case document= ?

 

I=E2=80=99m fine with use cases as input to work, but they = should always be taken as non-binding and non-normative. In other words, the= y=E2=80=99re a great way for us to write something down and say =E2=80=9Cyeah that makes= sense for something for us to work on=E2=80=9D. But I don=E2=80=99t think it makes sens= e as a way to enforce direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99= s not in the use cases document, we=E2=80=99re not going to talk about it=E2=80=9D), or = as a formal output of the document. 

 

Therefore if it=E2=80=99s a= n openly accessible and editable document that people can put things in, I t= hink it=E2=80=99s a helpful tool. The moment it becomes burdensome to update and c= ontinue use, we need to question whether we should keep doing it.=

 

 =E2=80=94 Justin



On Feb 3, 2020, at 5:01 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:

&nb= sp;

I agree. I'd rather see use cases so= oner than later.

-- Mike

From: Txauth <= ;txauth-bounces@ietf.org> on= behalf of Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>
Sent:=  Monday, February 3, 2020 = 9:04:00 PM
To: Dick = Hardt <dick.hardt@gmail.com>= ; Yaron Sheffer <yaronf.ietf@gmail= .com>
Cc: txauth@ietf.org <txauth@ietf.org>
Subject: [EXTERNAL] Re: [Txauth] use case document?

 <= /o:p>

I don=E2=80=99t foll= ow the logic of deferring this, since the charter defines the scope of the w= orking group. We=E2=80=99re all comparing the charter drafts against our use cases= anyway; doing that out in the open seems less likely to lead to arguments d= own the road over whether something falls within the scope laid out in the c= harter.

 

For what it=E2=80=99s wo= rth, Justin put this together back in August: https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo<= /a>

 

 

 

From: = ;Txauth <txauth-bounces@ietf.org> on behalf of Dick = Hardt <dick.hardt@gmail.com>=
Date: Saturday, Feb= ruary 1, 2020 at 2:25 PM
To: Yaron Sheffer <yaronf.iet= f@gmail.com>
Cc: = "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] use case document?

 

Works for me.

 

On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

<= /div>

It=E2=80=99s hard to =E2=80=9Ctease out= =E2=80=9D what=E2=80=99s in scope, and in particular what=E2=80=99s *not* in scope, bef= ore you have a WG. I am worried about scope creep which is likely to happen = once this is a WG and more people are involved. IMO the best way to avoid it= is by only having this discussion once everybody is on board.

 

Thanks,

          &nb= sp;     Yaron

 

From: Dick Hardt= <dick.hardt@gmail.= com>
Date: Su= nday, February 2, 2020 at 00:16
To:&= nbsp;Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: <txauth@ietf.org>
Subject:=  Re: [Txauth] use case document?

=

&nbs= p;

I was thinking a rough d= raft of a use case document would assist in teasing out what is in scope and= not for the WG.

 

I've been adding use cases to the XAuth ID to tease out what would be= in and out of scope.

 

<= p class=3DMsoNormal>It would also provide clarity on why this WG is different = from the OAuth WG.  

 

On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer <= ;yaronf.ietf@gmail.co= m> wrote:

I support such a document in principle. I agree that having a lis= t of use cases would help to scope the protocol document(s).

<= /div>

 

However I think now is not the right time= , because a use case document is only useful in defining scope once it is mo= re or less stable and enjoys rough consensus. We can only demonstrate consen= sus once we move past the BoF stage and into a WG. So I believe it only make= s sense to produce the use case doc when we have a chartered WG.<= /p>

 =

Thanks,

          &= nbsp;     Yaron

 

From: Txauth &= lt;txauth-bounces@i= etf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Saturday, February 1, 2020 at 00:38
= To: <txauth@ietf.org>
Subject: [Txauth] use case document?

 

As I reflect on my conversations with Justin, a set of use cases would hel= p guide us. We could then refer to a use case as why a feature is present an= d see how different features support (or don't support) different use cases.=

 

We can al= so use the document to decide which use cases are in scope, or out of scope.=

 

I'll put = up my hand to edit. Who is interested in contributing?

<= /div>

 

/Dick

Error! Filename not specified.=E1=90=A7

-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

  --B_3663709569_2147318975-- From nobody Wed Feb 5 00:49:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46ABF120271 for ; Wed, 5 Feb 2020 00:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj6a3Wg3hGnu for ; Wed, 5 Feb 2020 00:49:43 -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 2A14F120288 for ; Wed, 5 Feb 2020 00:49:43 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id r27so1194685otc.8 for ; Wed, 05 Feb 2020 00:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cbF4al3kl1K/8Juw65Y3Bs6dO4pkHHGo9gVZYiCE5Mc=; b=UTGfdn4gXeaoF3gOmKsHo+diO6sZThpaJyfSUJ6ukCt//jJUoy6Se9rYhqSLufWWyj fF5iSmGq2wZmmO/gUwPnBm0XQbLE3Y/5SMinj+Rmveb3Ybw0QXqmgJMV7BGq96YoRKpN BJTFrPPsIViqUkulblNZt8NO0xj+cx2d7jzyo= 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=cbF4al3kl1K/8Juw65Y3Bs6dO4pkHHGo9gVZYiCE5Mc=; b=RaqkmTHEF6aCX1ErKnVQiamPeVVHblNhV6Dq3feq7F/bAi5wcZiYouRRuFOrL/1UIU PxqIJylrYpWsPfZ4opAnFg6270W29uHNSw7t/C+/GPmPSBZ2sVazCfaTy7FNcx5XySyI cdg7y4VVGfHxjmb+8KMqqR8FA/ytKPrwLiM39TSBNZR8qkxYBu9Wd/pnsepD0Br3Q+/E zMa7DfZVwwIklmQNIbtVYxxkxcVnKSLbc9saQd85MEGulhQZVcgD0i+vkethBHdVz/KM LIJh7FgqCTsgoVvyb0qts/L8/0Wu7WACg7asurzPfNDsrgDusstivQuTFCRrCaeymn6y ZeJg== X-Gm-Message-State: APjAAAX/CWMFsbzTVCryDeK2CwCaYGSPVDCMtp+PeUGlsFUU3KDuZOIR s5azgw11iL+iKy9pGj4aKkJEHiH/Tt7MKHS/ykp+Jg== X-Google-Smtp-Source: APXvYqxzKb+8hfQkw5+xcwbb+FTaJvOs7kwNP5ZxgV87ELMpd8q12MNh3XEkVtAnkMeXKCx4lJy0CqVVw1fFeSFJo/4= X-Received: by 2002:a9d:6045:: with SMTP id v5mr23977511otj.252.1580892582105; Wed, 05 Feb 2020 00:49:42 -0800 (PST) MIME-Version: 1.0 References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> From: Adrian Hope-Bailie Date: Wed, 5 Feb 2020 10:49:30 +0200 Message-ID: To: Yaron Sheffer Cc: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000c8e914059dd03cc0" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 08:49:46 -0000 --000000000000c8e914059dd03cc0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's my understanding that the scope needs to be decided before we have a WG (i.e. defined in the charter). On Wed, 5 Feb 2020 at 01:06, Yaron Sheffer wrote: > Once this is a working group, we will need to make decisions on scope: > what goes into the base document, what we might want as extensions, and > what the WG doesn=E2=80=99t want to work on in the near term. > > > > If we have a use case document, that would be the natural place to have > these discussions =E2=80=93 you clarify each particular use case and make= sure > everybody agrees on what it means, and then the group decides which bucke= t > to put it in: base document, extension, defer. Otherwise I=E2=80=99m not = sure what > the document is intended to achieve. > > > > Thanks, > > Yaron > > > > *From: *Justin Richer > *Date: *Tuesday, February 4, 2020 at 18:17 > *To: *Mike Jones > *Cc: *Dick Hardt , Yaron Sheffer < > yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" 40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" > *Subject: *Re: [Txauth] use case document? > > > > I=E2=80=99m fine with use cases as input to work, but they should always = be taken > as non-binding and non-normative. In other words, they=E2=80=99re a great= way for > us to write something down and say =E2=80=9Cyeah that makes sense for som= ething for > us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a way= to enforce > direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not i= n the use cases > document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a for= mal output of the > document. > > > > Therefore if it=E2=80=99s an openly accessible and editable document that= people > can put things in, I think it=E2=80=99s a helpful tool. The moment it bec= omes > burdensome to update and continue use, we need to question whether we > should keep doing it. > > > > =E2=80=94 Justin > > > > On Feb 3, 2020, at 5:01 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > > > I agree. I'd rather see use cases sooner than later. > > -- Mike > ------------------------------ > > *From:* Txauth on behalf of Richard Backman, > Annabelle > *Sent:* Monday, February 3, 2020 9:04:00 PM > *To:* Dick Hardt ; Yaron Sheffer < > yaronf.ietf@gmail..com > > *Cc:* txauth@ietf.org > *Subject:* [EXTERNAL] Re: [Txauth] use case document? > > > > I don=E2=80=99t follow the logic of deferring this, since the charter def= ines the > scope of the working group. We=E2=80=99re all comparing the charter draft= s against > our use cases anyway; doing that out in the open seems less likely to lea= d > to arguments down the road over whether something falls within the scope > laid out in the charter. > > > > For what it=E2=80=99s worth, Justin put this together back in August: > https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo > > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Saturday, February 1, 2020 at 2:25 PM > *To: *Yaron Sheffer > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] use case document? > > > > Works for me. > > > > On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer > wrote: > > It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope,= and in particular what=E2=80=99s **not** > in scope, before you have a WG. I am worried about scope creep which is > likely to happen once this is a WG and more people are involved. IMO the > best way to avoid it is by only having this discussion once everybody is = on > board. > > > > Thanks, > > Yaron > > > > *From: *Dick Hardt > *Date: *Sunday, February 2, 2020 at 00:16 > *To: *Yaron Sheffer > *Cc: * > *Subject: *Re: [Txauth] use case document? > > > > I was thinking a rough draft of a use case document would assist in > teasing out what is in scope and not for the WG. > > > > I've been adding use cases to the XAuth ID to tease out what would be in > and out of scope. > > > > It would also provide clarity on why this WG is different from the OAuth > WG. > > > > On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer > wrote: > > I support such a document in principle. I agree that having a list of use > cases would help to scope the protocol document(s). > > > > However I think now is not the right time, because a use case document is > only useful in defining scope once it is more or less stable and enjoys > rough consensus. We can only demonstrate consensus once we move past the > BoF stage and into a WG. So I believe it only makes sense to produce the > use case doc when we have a chartered WG. > > > > Thanks, > > Yaron > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com > > *Date: *Saturday, February 1, 2020 at 00:38 > *To: * > *Subject: *[Txauth] use case document? > > > > As I reflect on my conversations with Justin, a set of use cases would > help guide us. We could then refer to a use case as why a feature is > present and see how different features support (or don't support) differe= nt > use cases. > > > > We can also use the document to decide which use cases are in scope, or > out of scope. > > > > I'll put up my hand to edit. Who is interested in contributing? > > > > /Dick > > *Error! Filename not specified.*=E1=90=A7 > > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c8e914059dd03cc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It's my understanding that the scope needs to be decid= ed before we have a WG (i.e. defined in the charter).

 =E2=80=94 Justin

On Feb 3, 2020, at 5:01 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I agree. I'd rather see use = cases sooner than later.

-- Mike
From: Txauth <txauth-bounces@ietf.org> on behalf of Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>
Sent: Monday, February 3, 2020 = 9:04:00 PM
To: Dick Hardt <dick.hardt@gmail.com>; Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: txauth@ietf.org <txauth@ietf.org>
Subject: [EXTERNAL] Re: [Txauth] use = case document?
 
I don=E2=80=99t follow the logic of = deferring this, since the charter defines the scope of the working = group. We=E2=80=99re all comparing the charter drafts against our use = cases anyway; doing that out in the open seems less likely to lead to = arguments down the road over whether something falls within the scope = laid out in the charter.

 

For what = it=E2=80=99s worth, Justin put this together back in August: https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS59= 8IC2Sheo

 

=E2=80=93 
Annabelle Richard = Backman
AWS Identity

 

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Saturday, February 1, = 2020 at 2:25 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] use case = document?

 

Works for me.

 

On Sat, Feb 1, 2020 at = 2:23 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
It=E2=80=99s hard to = =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, and in particular = what=E2=80=99s *not* in scope, before you have a WG. I = am worried about scope creep which is likely to happen once this is a WG = and more people are involved. IMO the best way to avoid it is by only = having this discussion once everybody is on board.

 

Thanks,
          &nb= sp;     Yaron

 

From: Dick Hardt <dick.hardt@gmail.com>
Date: Sunday, February 2, = 2020 at 00:16
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: <txauth@ietf.org>
Subject: Re: [Txauth] use case = document?

 

I was thinking a rough draft of a use = case document would assist in teasing out what is in scope and not for = the WG.

 

I've been adding use cases to the XAuth ID to tease out what = would be in and out of scope.

 

It would also provide = clarity on why this WG is different from the OAuth = WG.  

 

On Sat, Feb 1, 2020 at 10:20 AM Yaron = Sheffer <yaronf.ietf@gmail.com> wrote:
I support such a document in principle. = I agree that having a list of use cases would help to scope the protocol = document(s).

 

However I = think now is not the right time, because a use case document is only = useful in defining scope once it is more or less stable and enjoys rough = consensus. We can only demonstrate consensus once we move past the BoF = stage and into a WG. So I believe it only makes sense to produce the use = case doc when we have a chartered WG.

 

Thanks,
          &nb= sp;     Yaron

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Saturday, February 1, = 2020 at 00:38
To: <txauth@ietf.org>
Subject: [Txauth] use case = document?

 

As I reflect on my conversations with = Justin, a set of use cases would help guide us. We could then refer to a = use case as why a feature is present and see how different features = support (or don't support) different use cases.

 

We can also use the = document to decide which use cases are in scope, or out of = scope.

 

I'll put up my hand to edit. Who is interested in = contributing?

 

/Dick
Error! = Filename not specified.=E1=90=A7
-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

On Wed, 5 Feb 2020 a= t 01:06, Yaron Sheffer <yaronf.= ietf@gmail.com> wrote:

Once this is = a working group, we will need to make decisions on scope: what goes into th= e base document, what we might want as extensions, and what the WG doesn=E2= =80=99t want to work on in the near term.

=C2=A0

If we have a use case= document, that would be the natural place to have these discussions =E2=80= =93 you clarify each particular use case and make sure everybody agrees on = what it means, and then the group decides which bucket to put it in: base d= ocument, extension, defer. Otherwise I=E2=80=99m not sure what the document= is intended to achieve.

=C2= =A0

Thanks,

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

<= u>=C2=A0

=

From: = Justin Richer <jricher@mit.edu>Date: Tuesday, February 4, 2020 at 18:17
To: Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Cc: Dick Hard= t <dick.hardt@= gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, = Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org>Subject: Re: [Txauth] use case document?

<= /div>

=C2=A0

I=E2=80=99m fine with use cases as input to work, but they shoul= d always be taken as non-binding and non-normative. In other words, they=E2= =80=99re a great way for us to write something down and say =E2=80=9Cyeah t= hat makes sense for something for us to work on=E2=80=9D. But I don=E2=80= =99t think it makes sense as a way to enforce direction or decision within = the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases document, we=E2= =80=99re not going to talk about it=E2=80=9D), or as a formal output of the= document.=C2=A0

=C2=A0=

Therefore if it=E2=80=99s an o= penly accessible and editable document that people can put things in, I thi= nk it=E2=80=99s a helpful tool. The moment it becomes burdensome to update = and continue use, we need to question whether we should keep doing it.

=C2=A0

=C2=A0=E2=80=94 Justin

=



On Feb 3, 2020, at= 5:01 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.iet= f.org> wrote:

= =C2=A0

I agree. I'd rather se= e use cases sooner than later.

-- Mike<= u>

From:=C2=A0Txauth <txauth-bounces@ietf.org= > on behalf of Richard Backman, Annabelle <richanna=3D40amazon.com@d= marc.ietf.org>
Sent:=C2=A0Monday, February 3,= 2020 9:04:00 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>= ; Yaron Sheffer <yaronf.ietf@gmail..com>
Cc:=C2=A0txauth@ietf.org <txauth@ietf.org>
= Subject:=C2=A0[EXTERNAL] Re: [Txauth] use case document= ?<= /p>

=C2=A0

I don=E2=80=99t follow the logic of deferring this, since th= e charter defines the scope of the working group. We=E2=80=99re all compari= ng the charter drafts against our use cases anyway; doing that out in the o= pen seems less likely to lead to arguments down the road over whether somet= hing falls within the scope laid out in the charter.

=C2=A0

For what it=E2=80=99s worth, Justin put this together back i= n August:=C2=A0https://mailarchive.ietf.o= rg/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From= :=C2=A0Txauth <txauth-bounces@i= etf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:= =C2=A0Saturday, February 1, 2020 at 2:25 PM
To:=C2= =A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0<= /b>"txauth@ietf.o= rg" <txaut= h@ietf.org>
Subject:=C2=A0Re: [Txauth] use ca= se document?

=C2=A0

Works for me.

=C2=A0

On S= at, Feb 1, 2020 at 2:23 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:=

It= =E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, and= in particular what=E2=80=99s *not* in scope, before you have a WG. = I am worried about scope creep which is likely to happen once this is a WG = and more people are involved. IMO the best way to avoid it is by only havin= g this discussion once everybody is on board.

=C2=A0

Thanks,

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

=C2=A0

=C2=A0

I was thinking a rough draft of a use case document would assis= t in teasing out what is in scope and not for the WG.

=C2=A0

<= div>

I've been adding use cases to the XAuth= ID to tease out what would be in and out of scope.

=

=C2=A0

It would also provide clarity on why th= is WG is different from the OAuth WG.=C2=A0=C2=A0

=C2=A0

On Sat, Feb 1, 2020 at 10:20 AM Yaron She= ffer <yaronf.= ietf@gmail.com> wrote:

I support such a document in principle. = I agree that having a list of use cases would help to scope the protocol do= cument(s).

=C2= =A0

However I think now is not= the right time, because a use case document is only useful in defining sco= pe once it is more or less stable and enjoys rough consensus. We can only d= emonstrate consensus once we move past the BoF stage and into a WG. So I be= lieve it only makes sense to produce the use case doc when we have a charte= red WG.

=C2=A0<= u>

Thanks,

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

=

=C2=A0

From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.c= om>
Date:=C2=A0Saturday, February 1, 2020 at = 00:38
To:=C2=A0<txauth@ietf.org>
Subject:=C2=A0[Txauth] use case document?

=

=C2=A0

As I reflect on my conversations with Justin, a se= t of use cases would help guide us. We could then refer to a use case as wh= y a feature is present and see how different features support (or don't= support) different use cases.

=C2=A0

We can also use the document to decide which use cases are in scop= e, or out of scope.

=C2=A0

I&= #39;ll put up my hand to edit. Who is interested in contributing?=

=C2=A0<= u>

/Dick=

Error! Filename not specified.=E1=90=A7

<= p class=3D"MsoNormal">-- Txauth mailing list=C2=A0Txauth@ietf.org=C2=A0= https://www.ietf.org/mailman/listinfo/txauth

--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth

=C2=A0

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000c8e914059dd03cc0-- From nobody Wed Feb 5 01:33:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F2512083C for ; Wed, 5 Feb 2020 01:33:36 -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_HELO_NONE=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=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBEhmGL60x7I for ; Wed, 5 Feb 2020 01:33:33 -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 5CB1B1202DD for ; Wed, 5 Feb 2020 01:33:33 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id t2so1800129wrr.1 for ; Wed, 05 Feb 2020 01:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ztA2Nv15b3p7jmnvkW6dXD7mHJSZi6Glz4aeLVOeXyc=; b=gkQ0CEwzvtKwr+0kjhEEc1xo9SPhnyo2b7sU5/YHIx03zhUC3hSIEr9HKRwoQi5yst Umj5F7lPooKn8kHTy03ffbcxAjYj02R5DoyzfOL0RSimvu937RkmA1pTCiyHyOdcuSXE 1SeIfH39UzaF/y6wDDJE1czProOjFahyjDdEoRZHzQiu7QAW+IWm3qpJwE9WlQtORE5J veqw4iPodRIV4O9i+t+ULmsIIUzhPHJZni/OrqPagDoY1Gpggd4RxFJV/1wIXnohwOzb 0CU652G9z2J6HQim3ewsy+TzOImto3GkGkkSDEKru6dHDUHm381hPiDV8LeeljckdW81 l76Q== 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=ztA2Nv15b3p7jmnvkW6dXD7mHJSZi6Glz4aeLVOeXyc=; b=ewcBxx8nL/9dJiuCRAmjvsfyaXg8mjuZq4RTSsoWBN3nbqUkIehyLFsko9uSN7Rp/9 JE4SIL/7A+UfTOjm5xkKpZMYcs4wHZrgm8SLAsl/zK1ObSHScdPo6mVmC8isrL2kmQ/P JFDeaaE8GyuEe2tcbfjPPVccCwANAMiNWARAnqDM0kGw0T0eICHIC0WMKH4ozcI7IZ+t 9IROkcH7od3/g2By6xeGlnECzyen7EBACWAwxNr/wU0xbxJdaCcOH5I8ryuYhh4e3ryb iDgj7DCVs8fGerad9YPd5WyUVAHh9qSQZbo7DlVygxhfenPlI+3MoEuJlmcJ+gqLHDy8 C8kg== X-Gm-Message-State: APjAAAXvI1dIESkyouukDg6SXvWyx8QwcQMZM3qKAeDPp8bcu3QETOMW LpfUsH6w4ohNvzCCPN+YebK6wA== X-Google-Smtp-Source: APXvYqygupi8R+C5dXspr1ZrLrEGj+LEBLlG0DHk1XFQVgQAABK/b/s9kPQsK6nPxMZNlZ4/yCNutA== X-Received: by 2002:a5d:568a:: with SMTP id f10mr29221133wrv.180.1580895211896; Wed, 05 Feb 2020 01:33:31 -0800 (PST) Received: from [192.168.71.111] (p5B0D93B3.dip0.t-ipconnect.de. [91.13.147.179]) by smtp.gmail.com with ESMTPSA id r15sm7168362wmh.21.2020.02.05.01.33.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2020 01:33:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <981F5914-8757-4F76-8142-FD62A954F8C0@amazon.com> Date: Wed, 5 Feb 2020 10:32:05 +0100 Cc: Kim Cameron , "txauth@ietf.org" , Justin Richer , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: <25539A9E-E9B8-4871-A59F-3F31B1CFCCE9@lodderstedt.net> References: <7735E1FF-B2E1-4AAF-A5D3-60432B8411E1@amazon.com> <981F5914-8757-4F76-8142-FD62A954F8C0@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Questions on the TxAuth charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 09:33:40 -0000 Hi Annabelle,=20 > On 29. Jan 2020, at 21:15, Richard Backman, Annabelle = wrote: >=20 > I am well aware of the fact that OIDC Core predates ODC4IDA, and that = the claims I am referring to are defined in the former, as noted in my = previous message. Telling me to use verified_claims is not helpful when = I=E2=80=99ve already stated that I have looked at that spec and it does = not appear to address my use case. I=E2=80=99d appreciate less = condescension and more attention to message content, thanks. sorry, I did not intend to sound condescending. I always appreciate your = contributions and did not change my mind. I tried to enter into a = conversation how OIDC4IDA could address your use case and I believe I = have read all of your messages. Let me recapitulate: You stated that=20 > =E2=80=A2 The ..._verified claims don=E2=80=99t define how or = when verification occurred. =20 I replied by stating that OIDC4IDA indeed supports the =E2=80=9Chow" and = the =E2=80=9Cwhen" by means of the =E2=80=9Cmethod" and =E2=80=9Ctime" = elements in the =E2=80=9Cverification=E2=80=9D sub-element.=20 You replied=20 > I was referring to the email_verified and phone_number_verified claims = defined in OIDC Core. The mechanisms defined in IA don=E2=80=99t appear = to apply to those claims. Am I missing something? Which kind of puzzled me since your previous statement was related to = OIDC4IDA and not the OIDC claims.=20 That=E2=80=99s why I replied by pointing out the obvious (perhaps I = should have stated clearer) that email_verified and = phone_number_verified was invented before OIDC4IDA and so does not use = its concepts/constructs. I also tried to explained how you (potentially) = could use OIDC4IDA for your purposes. > It requires a trust framework id determining the trust framework = governing the verification along with identifiers for verification = methods etc. This is how it could look like {=20 "verified_claims":{=20 "verification":{=20 "trust_framework":"email_trust_framework", "time":"2018-05-21T18:25:43.511+01", "evidence":[=20 {=20 "method":"code_in_email" } ] }, "claims":{=20 "email":"joe@doe.org" } } } It=E2=80=99s just a guess. OIDC4IDA was developed with assurance of = natural person claims in mind. But I would like to find out with your = help whether it also fits a broader scope. best regards, Torsten.=20 > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Torsten Lodderstedt > Date: Wednesday, January 29, 2020 at 11:45 AM > To: "Richard Backman, Annabelle" > Cc: Kim , "txauth@ietf.org" , = Justin Richer , Dick Hardt > Subject: [UNVERIFIED SENDER] Re: [Txauth] Questions on the TxAuth = charter > =20 > =20 >=20 >=20 >> Am 29.01.2020 um 19:49 schrieb Richard Backman, Annabelle = : >>=20 >> =EF=BB=BF >> I was referring to the email_verified and phone_number_verified = claims defined in OIDC Core. The mechanisms defined in IA don=E2=80=99t = appear to apply to those claims. Am I missing something? > =20 > Those claims pre-date OIDC4IDA. If they do not suite your needs, you = may use verified_claims to represent the verification status. It = requires a trust framework id determining the trust framework governing = the verification along with identifiers for verification methods etc. >=20 >=20 >> =20 >> (I do have some feedback regarding claims in IA=E2=80=A6getting on = the IA working group list and providing it is on my far-too-long todo = list=E2=80=A6) > =20 > look forward to getting your feedback. >=20 >=20 >> =E2=80=93=20 >> Annabelle Richard Backman >> AWS Identity >> =20 >> =20 >> From: Txauth on behalf of Torsten = Lodderstedt >> Date: Tuesday, January 28, 2020 at 9:13 PM >> To: "Richard Backman, Annabelle" = >> Cc: Kim , "txauth@ietf.org" , = Justin Richer , Dick Hardt >> Subject: Re: [Txauth] Questions on the TxAuth charter >> =20 >> =20 >>=20 >>=20 >>=20 >>> Am 28.01.2020 um 18:00 schrieb Richard Backman, Annabelle = : >>>=20 >>> The ..._verified claims don=E2=80=99t define how or when = verification occurred. >> =20 >> Sure, they do. Look at the time and method fields.=20 >> =20 >> Since OpenId Connect for Identity Assurance (aka verified_claims) is = ongoing work feel free to contribute. >> =20 >> https://openid.net/wg/ekyc-ida/ From nobody Wed Feb 5 09:46:14 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E978120815 for ; Wed, 5 Feb 2020 09:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUBTH0T20wTB for ; Wed, 5 Feb 2020 09:46:10 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (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 129B412011B for ; Wed, 5 Feb 2020 09:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580924771; x=1612460771; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FCqMJVIUhmyoBd6tM3bBF+yu1usgJK6yea0n0YYyKhY=; b=Y0VBuPG6plzHdsxWSuaAOzuHyj1bMjGZauAv3yTPDkmhtm0wOqN9Lxcf JQATtayd98K9on0hbQ+9tFeRexR7VIktq81W+j92ShOy0HJOo232MS9Ai Pkpwne4DDGFT/24+4+q9SJ829cDL3EQpOfqlUiqkWFZt4V+WHi6V2Wlam Y=; IronPort-SDR: jnvD/Dtq1RPofr+G8sKzhnRAumpjmX6Afj/c+YEjrh2M1e3gPyMXzaqYJC8wiwK+jsurqC8gXC pPTU7sSykklQ== X-IronPort-AV: E=Sophos;i="5.70,406,1574121600"; d="scan'208";a="23255460" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-c300ac87.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 05 Feb 2020 17:45:41 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-c300ac87.us-west-2.amazon.com (Postfix) with ESMTPS id 9E805A2120; Wed, 5 Feb 2020 17:45:40 +0000 (UTC) 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, 5 Feb 2020 17:45:40 +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, 5 Feb 2020 17:45:40 +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, 5 Feb 2020 17:45:39 +0000 From: "Richard Backman, Annabelle" To: Torsten Lodderstedt CC: Kim Cameron , "txauth@ietf.org" , Justin Richer , Dick Hardt Thread-Topic: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] [Txauth] Questions on the TxAuth charter Thread-Index: AQHV3Admv1FpovDeOUKT7y+kj7IzPagM4BpY Date: Wed, 5 Feb 2020 17:45:39 +0000 Message-ID: <05B357DE-CA98-4579-8FDA-AEF208C76B4D@amazon.com> References: <7735E1FF-B2E1-4AAF-A5D3-60432B8411E1@amazon.com> <981F5914-8757-4F76-8142-FD62A954F8C0@amazon.com>, <25539A9E-E9B8-4871-A59F-3F31B1CFCCE9@lodderstedt.net> In-Reply-To: <25539A9E-E9B8-4871-A59F-3F31B1CFCCE9@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Questions on the TxAuth charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 17:46:13 -0000 DQo+IE9uIEZlYiA1LCAyMDIwLCBhdCAxOjM0IEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3Jz dGVuPTQwbG9kZGVyc3RlZHQubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gDQo+IFdoaWNo IGtpbmQgb2YgcHV6emxlZCBtZSBzaW5jZSB5b3VyIHByZXZpb3VzIHN0YXRlbWVudCB3YXMgcmVs YXRlZCB0byBPSURDNElEQSBhbmQgbm90IHRoZSBPSURDIGNsYWltcy4NCg0KSSBhbSByZWFsbHkg bm90IHN1cmUgd2hlcmUgeW91IGFyZSBnZXR0aW5nIHRoaXMgaWRlYSBmcm9tLiBJIHdhcyBwb2lu dGluZyBvdXQgaXNzdWVzL2xpbWl0YXRpb25zIHdpdGggT0lEQyBjbGFpbXMsIGFuZCByZWZlcmVu Y2VkIGNsYWltcyBkZWZpbmVkIGluIENvcmUuIEkgZGlkIG5vdCBicmluZyB1cCBPSURDNElEQSBh dCBhbGwgdW50aWwgeW91IGRpZC4NCg0KUmVnYXJkbGVzcywgd2hpbGUgYm90aCB1c2UgdGhlIHdv cmQg4oCcdmVyaWZpZWTigJ0gSeKAmW0gbm90IHN1cmUgdGhhdCB0aGUgdXNlIGNhc2VzIGZvciB0 aGVzZSBjbGFpbXMgaW4gQ29yZSBhY3R1YWxseSBtYXRjaCB1cCB0aGF0IHdlbGwgd2l0aCB0aG9z ZSBvZiBPSURDNElEQS4gQnV0IHRoYXTigJlzIGEgdG9waWMgZm9yIGEgZGlmZmVyZW50IG1haWxp bmcgbGlzdC4NCg0KDQo= From nobody Wed Feb 5 11:55:34 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECFA12083D for ; Wed, 5 Feb 2020 11:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MALFORMED_FREEMAIL=1.122, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu6hmO0Jdo3G for ; Wed, 5 Feb 2020 11:55:28 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 447761208A7 for ; Wed, 5 Feb 2020 11:55:28 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id t3so4274255wru.7 for ; Wed, 05 Feb 2020 11:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=22uNvoTETkRemTY5aABuU+/h3+7xXFsY+0O5Kw+uQfs=; b=udEvC8zV5Td6h5dO7vwaTOJi2US+AbURKXAsD+WiJvGCquJr3wsBQ8n9X3zOMHD8HV 2Bt0Ug1/tpAHiEVinUwhB497avPX23OkaFEKrxk5JiVhtLFyqPKvp2v5N4PojgqJHx4X zGC02TiByhHUH1N4JGpTRdWNzQBoXOiI4U3rQy9arQ88IatWBTDTipAAH4ZLm490WVb0 49daQ1CKcpnZHcgt4NpExCIm3meBKtMGUffESKRUIsKwLkqgCqU6lgZfERAhsmaTPZLV pyKNyS+bvquX0jM/hFacZlnSQLS7m/BUp7PVS40YzZ/DAeKLeJ+QK7btzQDxjmKXNLmv uvsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=22uNvoTETkRemTY5aABuU+/h3+7xXFsY+0O5Kw+uQfs=; b=EoyPLGwTLpbvRzhWkTl2U3cRwRuIHTLPOX3hWOoBweEkIweKMtApXXYS2vr/59Wuqf J7Un4StSJges+XZ8yAN6k0GJagaxlRUx2JsMxIoXRViRzmcwMvMgJmqgrjviUA5naqyx raB/6Cna/sATP7V1seLm4y0cPckn7EFirgGnr871xb2zWg1zmXg0UkNgnDuk3Z0SbjfA 3Z+aIUrQQws3aar858Q0CPKE6U6ZQr7a5IyyBLE56nr/am4xEE2zCgkmtCedG4EG/Iu+ vhVymC4CsiI6i2Dc46DH2Q1WLPo47IWhax6VD3LaP4lfNAxr3uZCLclledjl48vb/RXo PPaw== X-Gm-Message-State: APjAAAWJ2wm2/0VWuSSaoBDrvckwel0TMmt+aV0r2Vz42r2VgpJf1Njz sCto1YytY3AqbGvBESA4YM8= X-Google-Smtp-Source: APXvYqyPOVTSHU/LQkFzLiHwluONVpZPdX2+a9bZ+B9HGdGcxqSAsVR6CM8eMSrJaRtnlEzc2DIvMw== X-Received: by 2002:adf:d4cc:: with SMTP id w12mr139308wrk.249.1580932526680; Wed, 05 Feb 2020 11:55:26 -0800 (PST) Received: from [192.168.43.104] ([2.53.26.43]) by smtp.gmail.com with ESMTPSA id f1sm1053850wro.85.2020.02.05.11.55.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2020 11:55:25 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Wed, 05 Feb 2020 11:55:17 -0800 From: Yaron Sheffer To: Adrian Hope-Bailie CC: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , "txauth@ietf.org" , Dick Hardt Message-ID: Thread-Topic: [Txauth] use case document? References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3663748523_1315740288" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 19:55:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3663748523_1315740288 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Yes, but it=E2=80=99s on us to decide at what level of granularity. Typically a u= se case document would go deeper that what you would expect in a WG charter. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Adrian Hope-Bailie Date: Wednesday, February 5, 2020 at 00:49 To: Yaron Sheffer Cc: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , "txauth@ietf.org" , Dick Hardt Subject: Re: [Txauth] use case document? =20 It's my understanding that the scope needs to be decided before we have a W= G (i.e. defined in the charter). =20 On Wed, 5 Feb 2020 at 01:06, Yaron Sheffer wrote: Once this is a working group, we will need to make decisions on scope: what= goes into the base document, what we might want as extensions, and what the= WG doesn=E2=80=99t want to work on in the near term. =20 If we have a use case document, that would be the natural place to have the= se discussions =E2=80=93 you clarify each particular use case and make sure everyb= ody agrees on what it means, and then the group decides which bucket to put = it in: base document, extension, defer. Otherwise I=E2=80=99m not sure what the do= cument is intended to achieve. =20 Thanks, Yaron =20 From: Justin Richer Date: Tuesday, February 4, 2020 at 18:17 To: Mike Jones Cc: Dick Hardt , Yaron Sheffer , "Richard Backman, Annabelle" , "txa= uth@ietf.org" Subject: Re: [Txauth] use case document? =20 I=E2=80=99m fine with use cases as input to work, but they should always be taken= as non-binding and non-normative. In other words, they=E2=80=99re a great way for= us to write something down and say =E2=80=9Cyeah that makes sense for something f= or us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a way to enforce = direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases= document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a formal output of = the document.=20 =20 Therefore if it=E2=80=99s an openly accessible and editable document that people = can put things in, I think it=E2=80=99s a helpful tool. The moment it becomes burd= ensome to update and continue use, we need to question whether we should kee= p doing it. =20 =E2=80=94 Justin =20 On Feb 3, 2020, at 5:01 PM, Mike Jones wrote: =20 I agree. I'd rather see use cases sooner than later. -- Mike From: Txauth on behalf of Richard Backman, Annabe= lle Sent: Monday, February 3, 2020 9:04:00 PM To: Dick Hardt ; Yaron Sheffer Cc: txauth@ietf.org Subject: [EXTERNAL] Re: [Txauth] use case document? =20 I don=E2=80=99t follow the logic of deferring this, since the charter defines the= scope of the working group. We=E2=80=99re all comparing the charter drafts agains= t our use cases anyway; doing that out in the open seems less likely to lead= to arguments down the road over whether something falls within the scope la= id out in the charter. =20 For what it=E2=80=99s worth, Justin put this together back in August: https://mai= larchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo =20 =E2=80=93=20 Annabelle Richard Backman AWS Identity =20 =20 From: Txauth on behalf of Dick Hardt Date: Saturday, February 1, 2020 at 2:25 PM To: Yaron Sheffer Cc: "txauth@ietf.org" Subject: Re: [Txauth] use case document? =20 Works for me. =20 On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer wrote: It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, and in particular what=E2=80=99= s *not* in scope, before you have a WG. I am worried about scope creep which= is likely to happen once this is a WG and more people are involved. IMO the= best way to avoid it is by only having this discussion once everybody is on= board. =20 Thanks, Yaron =20 From: Dick Hardt Date: Sunday, February 2, 2020 at 00:16 To: Yaron Sheffer Cc: Subject: Re: [Txauth] use case document? =20 I was thinking a rough draft of a use case document would assist in teasing= out what is in scope and not for the WG. =20 I've been adding use cases to the XAuth ID to tease out what would be in an= d out of scope. =20 It would also provide clarity on why this WG is different from the OAuth WG= . =20 =20 On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer wrote= : I support such a document in principle. I agree that having a list of use c= ases would help to scope the protocol document(s). =20 However I think now is not the right time, because a use case document is o= nly useful in defining scope once it is more or less stable and enjoys rough= consensus. We can only demonstrate consensus once we move past the BoF stag= e and into a WG. So I believe it only makes sense to produce the use case do= c when we have a chartered WG. =20 Thanks, Yaron =20 From: Txauth on behalf of Dick Hardt Date: Saturday, February 1, 2020 at 00:38 To: Subject: [Txauth] use case document? =20 As I reflect on my conversations with Justin, a set of use cases would help= guide us. We could then refer to a use case as why a feature is present and= see how different features support (or don't support) different use cases. =20 We can also use the document to decide which use cases are in scope, or out= of scope. =20 I'll put up my hand to edit. Who is interested in contributing? =20 /Dick Error! Filename not specified.=E1=90=A7 -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --B_3663748523_1315740288 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Yes, but it=E2=80=99s on us to de= cide at what level of granularity. Typically a use case document would go de= eper that what you would expect in a WG charter.

 

Thanks,

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

 

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wednes= day, February 5, 2020 at 00:49
To: Yaron Sheffer <yaronf.ietf@g= mail.com>
Cc: Justin Richer <jricher@mit.edu>, Mike Jones= <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, "Richard Backman= , Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>, "txauth= @ietf.org" <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com= >
Subject: Re: [Txauth] use case document?

 

It's my understanding that the scope needs to be decided before we hav= e a WG (i.e. defined in the charter).

 

On Wed, 5 Feb 2020 at 01:= 06, Yaron Sheffer <yaronf.ietf@gma= il.com> wrote:

Once this is a working group, we will need to mak= e decisions on scope: what goes into the base document, what we might want a= s extensions, and what the WG doesn=E2=80=99t want to work on in the near term.

 

If we have a use case document, that wo= uld be the natural place to have these discussions =E2=80=93 you clarify each part= icular use case and make sure everybody agrees on what it means, and then th= e group decides which bucket to put it in: base document, extension, defer. = Otherwise I=E2=80=99m not sure what the document is intended to achieve.

 

Thanks,

   &nbs= p;            Yaron

 

From: Ju= stin Richer <jricher@mit= .edu>
Date: Tuesday, February 4, 2020 at 18:17
To: Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Cc: Dick= Hardt <dick.hardt@= gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabe= lle" <richanna=3D40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [T= xauth] use case document?

 

I=E2=80=99m fine with use cases as input to work, but they should alw= ays be taken as non-binding and non-normative. In other words, they=E2=80=99re a g= reat way for us to write something down and say =E2=80=9Cyeah that makes sense for= something for us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a way= to enforce direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not in t= he use cases document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a forma= l output of the document. 

 

Therefore if it=E2=80=99s an openly accessible and editable document th= at people can put things in, I think it=E2=80=99s a helpful tool. The moment it be= comes burdensome to update and continue use, we need to question whether we = should keep doing it.

 

=

 =E2=80=94 Justin

 

On Feb 3, 2020, at 5:01 PM, = Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:=

 

I agree. I'd rather see use cases sooner than later.

-= - Mike

From: = Txauth <txauth-b= ounces@ietf.org> on behalf of Richard Backman, Annabelle <richanna=3D40ama= zon.com@dmarc.ietf.org>
Sent: Monday, February 3, 2020= 9:04:00 PM
To: Dick Hardt <dick.hardt@gmail.com>; Yaron Sheffer <yaronf.ietf@gmail..com>
Cc: tx= auth@ietf.org <txaut= h@ietf.org>
Subject: [EXTERNAL] Re: [Txauth] use case = document?

 

I don=E2=80=99t fo= llow the logic of deferring this, since the charter defines the scope of the= working group. We=E2=80=99re all comparing the charter drafts against our use cas= es anyway; doing that out in the open seems less likely to lead to arguments= down the road over whether something falls within the scope laid out in the= charter.

&n= bsp;

For what it=E2=80=99s worth, Justin put this together ba= ck in August: https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCz= wH43FMKS598IC2Sheo

 

=E2=80=93 

=

Annabelle Richard Backman=

AWS Identity

 

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com&g= t;
Date: Saturday, February 1, 2020 at 2:25 PM
To: = ;Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: = ;Re: [Txauth] use case document?

<= p style=3D'margin:0in;margin-bottom:.0001pt'> 

<= div>

Works for me.

 

On Sat, Feb 1, 2020 at 2= :23 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope, and in p= articular what=E2=80=99s *not* in scope, before you have a WG. I am worried= about scope creep which is likely to happen once this is a WG and more peop= le are involved. IMO the best way to avoid it is by only having this discuss= ion once everybody is on board.

 

Thanks,

=

           &nb= sp;    Yaron

 

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >I was thinking a rough draft of a use case document would assist in teasing= out what is in scope and not for the WG.

 

I'= ve been adding use cases to the XAuth ID to tease out what would be in and o= ut of scope.

 

It would also provide cla= rity on why this WG is different from the OAuth WG.  

 <= /o:p>

On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer <= yaronf.ietf@gmail.com= > wrote:

I suppo= rt such a document in principle. I agree that having a list of use cases wou= ld help to scope the protocol document(s).

 

However I think n= ow is not the right time, because a use case document is only useful in defi= ning scope once it is more or less stable and enjoys rough consensus. We can= only demonstrate consensus once we move past the BoF stage and into a WG. S= o I believe it only makes sense to produce the use case doc when we have a c= hartered WG.

 

Thanks,

  =             &nbs= p; Yaron

&nb= sp;

From: = Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dic= k.hardt@gmail.com>
Date: Saturday, February 1, 2020 at= 00:38
To: <txauth@ietf.org>
Subject: [Txauth] use case documen= t?

 

As I reflect on my conversat= ions with Justin, a set of use cases would help guide us. We could then refe= r to a use case as why a feature is present and see how different features s= upport (or don't support) different use cases.

 

We can also use the document to decide which use cases are in scope, or o= ut of scope.

 

I'll put up my hand to edit. Wh= o is interested in contributing?

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >/Dick

Error! Filename not specified.<= span style=3D'font-size:7.5pt;font-family:"Euphemia UCAS",sans-serif;color:whi= te'>=E1=90=A7

-- Txauth mailing list = Txauth@ietf.org https://www.ietf.org/ma= ilman/listinfo/txauth

-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman= /listinfo/txauth

 <= o:p>

--
Txauth mailing lis= t
Txauth@ietf.orghttp= s://www.ietf.org/mailman/listinfo/txauth

--B_3663748523_1315740288-- From nobody Wed Feb 5 14:07:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3238120845 for ; Wed, 5 Feb 2020 14:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 TVb501jE5aan for ; Wed, 5 Feb 2020 14:06:56 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7771200A4 for ; Wed, 5 Feb 2020 14:06:55 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q8so3951873ljb.2 for ; Wed, 05 Feb 2020 14:06:55 -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=g0JpoeXKFfZ2X93KAp2eE50Q0tpT/YFmuzxctGBZbiM=; b=by5dMM5pP6ssN9rMaRqpY1j1Ftf6v1v8qeO6VcPU5Ch+mLM4KEK3jjqg23/s4/A0GB n8IiZ0hkdkl5zPtSYavnUjjSkkNUD2yFvVO+c/nu/ytdBsFhcndioaq/IhafhsZZ1sp0 p1WCgwplsNKjs3oXaCy4YHnbSAOrHqyskpTSoDsCE/fbWvq7DjiTBHBNCQt1dyT23r+6 Y1NmPvskzqo4n60oadPyuSVNI2jsMOySvHEUMG/IXDAheBkatC7UGyn0AU156UgEPJ1x TyWnbqNHHSVNxL6QIsod4MnLz6oEFozKCj6JvKrOAd6tDSbq93PLZ8eDCh0D8xVeDfEN MlXw== 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=g0JpoeXKFfZ2X93KAp2eE50Q0tpT/YFmuzxctGBZbiM=; b=VddIXgEwFe/xHa7p+TUhX6zuieL/0WCmdsN0WwKB1e3sLKR1MrZ9nyVTFsU3RnGV5w jiJMis55U1CSj9WlWY09pNPbS60IvvwyfRO9BEp0tH3V6UC8aJ8qbzdkihaIktQcZ+Mo QiSpwvd4SeuYmjFinB3/jQfN0rqap3ot2IHiodVdjQ7Mj/M7BTNBnW/mIUw0gXi3hi7K GNGJvYG6Ks3RLCtkf0p3O5Ltplu19teb7q5mHq0nASH4mwE5VXMqHhhgtSFnranv3SJC BO7KImYC3JsGqs4A9VySLqeWoESCH5N50bCiaj3geutOE7r4pAJDhCaLIHi1sxYj3kHw qI5A== X-Gm-Message-State: APjAAAXGGSCyQGAx/zIsLG9xW7OHgGX9R20HiDnjBiVMgjfVCq8EjSP4 ScY/hpzAAvRAjBk05M7QBeYOWV1qGgssQBf6S68= X-Google-Smtp-Source: APXvYqxaay75wIYBW5r+kGZDNgz7153U1Gu6l6A7qLzdZOi9stjt1v8dDN5BqHXFsz2Mqnb+IQmOnNhXHGLKFdDxL74= X-Received: by 2002:a2e:730e:: with SMTP id o14mr21181108ljc.51.1580940413533; Wed, 05 Feb 2020 14:06:53 -0800 (PST) MIME-Version: 1.0 References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: From: Dick Hardt Date: Wed, 5 Feb 2020 14:06:26 -0800 Message-ID: To: Yaron Sheffer Cc: Adrian Hope-Bailie , Justin Richer , Mike Jones , "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c28431059ddb5f13" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 22:07:00 -0000 --000000000000c28431059ddb5f13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I proposed a use case document so that there is a common understand of what the WG is working to solve. In my discussions online with Justin, it is clear that he and I don't share a common set of requirements for this WG, and I suspect that is the case for many. First, I don't think there is a common understanding of all the use cases that OAuth 2.0 and OpenID Connect are solving today. Second, in the latest charter we have "new use cases not enabled by OAuth 2.0.", which is somewhat based on a number of those use cases that were presented in the BoF in Singapore, but in ad hoc discussions, I think there are many use cases that people desire to be solved, but are not widely understood. In my opinion, the use case document acts as the WGs requirements. Without it, there are disagreements in the IDs because participants are wanting to solve different use cases, but they don't know they have different use cases, so the disagreements surface in the ID. Sometimes those disagreements are resolved in a side meeting, but the knowledge is not captured and the "why" fades away. I'd advocate that if someone is wanting a feature, there needs to a a use case the WG has agreed to that requires the feature. If the use case is not in the use case document, it needs to be written up and adopted by the WG. While this adds some overhead to the process, I think it will assist in in alignment on the rest of the work products. I don't want this WG to be Perl6. =3D) =E1=90=A7 On Wed, Feb 5, 2020 at 11:55 AM Yaron Sheffer wrote= : > Yes, but it=E2=80=99s on us to decide at what level of granularity. Typic= ally a > use case document would go deeper that what you would expect in a WG > charter. > > > > Thanks, > > Yaron > > > > *From: *Adrian Hope-Bailie > *Date: *Wednesday, February 5, 2020 at 00:49 > *To: *Yaron Sheffer > *Cc: *Justin Richer , Mike Jones 40microsoft.com@dmarc.ietf.org>, "Richard Backman, Annabelle" 40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" , Dick > Hardt > *Subject: *Re: [Txauth] use case document? > > > > It's my understanding that the scope needs to be decided before we have a > WG (i.e. defined in the charter). > > > > On Wed, 5 Feb 2020 at 01:06, Yaron Sheffer wrote: > > Once this is a working group, we will need to make decisions on scope: > what goes into the base document, what we might want as extensions, and > what the WG doesn=E2=80=99t want to work on in the near term. > > > > If we have a use case document, that would be the natural place to have > these discussions =E2=80=93 you clarify each particular use case and make= sure > everybody agrees on what it means, and then the group decides which bucke= t > to put it in: base document, extension, defer. Otherwise I=E2=80=99m not = sure what > the document is intended to achieve. > > > > Thanks, > > Yaron > > > > *From: *Justin Richer > *Date: *Tuesday, February 4, 2020 at 18:17 > *To: *Mike Jones > *Cc: *Dick Hardt , Yaron Sheffer < > yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" 40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" > *Subject: *Re: [Txauth] use case document? > > > > I=E2=80=99m fine with use cases as input to work, but they should always = be taken > as non-binding and non-normative. In other words, they=E2=80=99re a great= way for > us to write something down and say =E2=80=9Cyeah that makes sense for som= ething for > us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a way= to enforce > direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not i= n the use cases > document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a for= mal output of the > document. > > > > Therefore if it=E2=80=99s an openly accessible and editable document that= people > can put things in, I think it=E2=80=99s a helpful tool. The moment it bec= omes > burdensome to update and continue use, we need to question whether we > should keep doing it. > > > > =E2=80=94 Justin > > > > On Feb 3, 2020, at 5:01 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > > > I agree. I'd rather see use cases sooner than later. > > -- Mike > ------------------------------ > > *From:* Txauth on behalf of Richard Backman, > Annabelle > *Sent:* Monday, February 3, 2020 9:04:00 PM > *To:* Dick Hardt ; Yaron Sheffer < > yaronf.ietf@gmail..com > > *Cc:* txauth@ietf.org > *Subject:* [EXTERNAL] Re: [Txauth] use case document? > > > > I don=E2=80=99t follow the logic of deferring this, since the charter def= ines the > scope of the working group. We=E2=80=99re all comparing the charter draft= s against > our use cases anyway; doing that out in the open seems less likely to lea= d > to arguments down the road over whether something falls within the scope > laid out in the charter. > > > > For what it=E2=80=99s worth, Justin put this together back in August: > https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo > > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Saturday, February 1, 2020 at 2:25 PM > *To: *Yaron Sheffer > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] use case document? > > > > Works for me. > > > > On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer > wrote: > > It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope,= and in particular what=E2=80=99s **not** > in scope, before you have a WG. I am worried about scope creep which is > likely to happen once this is a WG and more people are involved. IMO the > best way to avoid it is by only having this discussion once everybody is = on > board. > > > > Thanks, > > Yaron > > > > *From: *Dick Hardt > *Date: *Sunday, February 2, 2020 at 00:16 > *To: *Yaron Sheffer > *Cc: * > *Subject: *Re: [Txauth] use case document? > > > > I was thinking a rough draft of a use case document would assist in > teasing out what is in scope and not for the WG. > > > > I've been adding use cases to the XAuth ID to tease out what would be in > and out of scope. > > > > It would also provide clarity on why this WG is different from the OAuth > WG. > > > > On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer > wrote: > > I support such a document in principle. I agree that having a list of use > cases would help to scope the protocol document(s). > > > > However I think now is not the right time, because a use case document is > only useful in defining scope once it is more or less stable and enjoys > rough consensus. We can only demonstrate consensus once we move past the > BoF stage and into a WG. So I believe it only makes sense to produce the > use case doc when we have a chartered WG. > > > > Thanks, > > Yaron > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com > > *Date: *Saturday, February 1, 2020 at 00:38 > *To: * > *Subject: *[Txauth] use case document? > > > > As I reflect on my conversations with Justin, a set of use cases would > help guide us. We could then refer to a use case as why a feature is > present and see how different features support (or don't support) differe= nt > use cases. > > > > We can also use the document to decide which use cases are in scope, or > out of scope. > > > > I'll put up my hand to edit. Who is interested in contributing? > > > > /Dick > > *Error! Filename not specified.*=E1=90=A7 > > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000c28431059ddb5f13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I proposed a use case document so that there is a= common understand of what the WG is working to solve. In my discussions on= line with=C2=A0Justin, it is clear that he and I don't share a common s= et of requirements for this WG, and I suspect that is the case for many.

First, I don't think there is a common understan= ding of all the use cases that OAuth 2.0 and OpenID Connect are solving tod= ay.

Second, in the latest charter we have "ne= w use cases not enabled by OAuth 2.0.", which is somewhat based on=C2= =A0a number of those use cases that were presented in the BoF in Singapore,= but in ad hoc discussions, I think there are many use cases that people de= sire to be solved, but are not widely understood.

= In my opinion, the use case document acts as the WGs requirements. Without = it, there are disagreements in the IDs because participants are wanting to = solve different use cases, but they don't know they have different use = cases, so the disagreements surface in the ID. Sometimes those disagreement= s=C2=A0are resolved in a side meeting, but the knowledge is not captured an= d the "why" fades away.

I'd advocate= that if someone is wanting a feature, there needs to a a use case the WG h= as agreed to that requires the feature. If the use case is not in the use c= ase document, it needs to be written up and adopted by the WG.
While this adds some overhead to the process, I think it will = assist in in alignment on the rest of the work products.

I don't want this WG to be Perl6. =3D)

3D""=E1=90=A7

On Wed, Feb 5, 2020 at 11:55 AM Yaron Sheffer <= ;yaronf.ietf@gmail.com> wro= te:

Yes, but it=E2=80=99s on us to decide at what level of granular= ity. Typically a use case document would go deeper that what you would expe= ct in a WG charter.

=C2=A0

Thanks,

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

= =C2=A0

From: Adrian Hope-Bailie <adrian@hopebailie.co= m>
Date: Wednesday, February 5, 2020 at 00:49
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Mike= Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, "Richard B= ackman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>, "txauth@ietf.org"= <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Txauth] use case= document?

=C2=A0

It's my understandi= ng that the scope needs to be decided before we have a WG (i.e. defined in = the charter).

=C2=A0

On Wed, 5 Feb 2020 at 01:06, Yaro= n Sheffer <ya= ronf.ietf@gmail.com> wrote:

Once this is a working group, we wil= l need to make decisions on scope: what goes into the base document, what w= e might want as extensions, and what the WG doesn=E2=80=99t want to work on= in the near term.

=C2=A0=

If we have a use case document, that would b= e the natural place to have these discussions =E2=80=93 you clarify each pa= rticular use case and make sure everybody agrees on what it means, and then= the group decides which bucket to put it in: base document, extension, def= er. Otherwise I=E2=80=99m not sure what the document is intended to achieve= .

=C2=A0

Thanks,

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

=C2=A0

<= div style=3D"border-right:none;border-bottom:none;border-left:none;border-t= op:1pt solid rgb(181,196,223);padding:3pt 0in 0in">

<= b>From: Justin Richer <jricher@mit.edu>
Date: Tuesday= , February 4, 2020 at 18:17
To: Mike Jones <Michael.Jones=3D40microso= ft.com@dmarc.ietf.org>
Cc: Dick Hardt <dick.hardt@gmail.com>, Yar= on Sheffer <y= aronf.ietf@gmail.com>, "Richard Backman, Annabelle" <ri= channa=3D4= 0amazon.com@dmarc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: = [Txauth] use case document?

=C2=A0

I=E2=80=99m= fine with use cases as input to work, but they should always be taken as n= on-binding and non-normative. In other words, they=E2=80=99re a great way f= or us to write something down and say =E2=80=9Cyeah that makes sense for so= mething for us to work on=E2=80=9D. But I don=E2=80=99t think it makes sens= e as a way to enforce direction or decision within the group (ie, =E2=80=9C= that=E2=80=99s not in the use cases document, we=E2=80=99re not going to ta= lk about it=E2=80=9D), or as a formal output of the document.=C2=A0<= u>

=C2=A0

Therefore if it=E2=80=99s an openly accessible and edi= table document that people can put things in, I think it=E2=80=99s a helpfu= l tool. The moment it becomes burdensome to update and continue use, we nee= d to question whether we should keep doing it.

=

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Feb 3, 2020,= at 5:01 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.= ietf.org> wrote:

=C2= =A0

I agree. I'd rathe= r see use cases sooner than later.

-- Mike

From:=C2=A0Txaut= h <txauth-b= ounces@ietf.org> on behalf of Richard Backman, Annabelle <richan= na=3D40amazon.com@dmarc.ietf.org>
Sent:=C2=A0Monday, Febru= ary 3, 2020 9:04:00 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>; Yaron= Sheffer <yar= onf.ietf@gmail..com>
Cc:=C2=A0txauth@ietf.org <txauth@ietf.org>
Subject:=C2=A0= [EXTERNAL] Re: [Txauth] use case document?

=C2=A0

I = don=E2=80=99t follow the logic of deferring this, since the charter defines= the scope of the working group. We=E2=80=99re all comparing the charter dr= afts against our use cases anyway; doing that out in the open seems less li= kely to lead to arguments down the road over whether something falls within= the scope laid out in the charter.

=C2=A0

Fo= r what it=E2=80=99s worth, Justin put this together back in August:=C2=A0https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH4= 3FMKS598IC2Sheo

=C2=A0

=

=E2=80=93=C2=A0<= /span>

Annabelle Richard Backman

=

AWS Identity

=C2=A0<= /u>

=C2=A0

=

From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om>
Date:=C2=A0Saturday, February 1, 2020 at 2:25 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0"txauth@ietf.org" = <txauth@ietf.org>
Subject:=C2=A0Re: [Txauth] use case document?=

=C2=A0<= /u>

It=E2=80=99s hard to =E2=80=9C= tease out=E2=80=9D what=E2=80=99s in scope, and in particular what=E2=80=99= s *not* in scope, before you have a WG. I am worried about scope cre= ep which is likely to happen once this is a WG and more people are involved= . IMO the best way to avoid it is by only having this discussion once every= body is on board.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron<= /p>

=C2=A0

= From:=C2=A0Dick Hardt <dick.hardt@gmail.com>
Date:=C2=A0Sunday, Febru= ary 2, 2020 at 00:16
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
= Cc:=C2=A0<tx= auth@ietf.org>
Subject:=C2=A0Re: [Txauth] use case documen= t?

=C2=A0

I was = thinking a rough draft of a use case document would assist in teasing out w= hat is in scope and not for the WG.

=C2=A0

I've been adding use cases to the XAuth ID to tease out = what would be in and out of scope.

=C2=A0

It would also provide clarity on why this WG is differen= t from the OAuth WG.=C2=A0=C2=A0

=C2=A0

On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

=C2=A0=

=C2=A0

=

Thanks,

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

=C2=A0

From:=C2=A0Txauth <txauth-bounces@iet= f.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:=C2=A0Saturday, February 1, 2020 at 00:38
To:=C2=A0<txauth@ietf.org>
Subject= :=C2=A0[Txauth] use case document?

=

=C2=A0

As I reflect on my conversations with Justin,= a set of use cases would help guide us. We could then refer to a use case = as why a feature is present and see how different features support (or don&= #39;t support) different use cases.

=C2=A0

We can also use the document to decide which use cases are i= n scope, or out of scope.

=C2=A0

I'll put up my hand to edit. Who is interested in contributing?<= /u>

= =C2=A0

/Dick=

Error! Filename not specified= .=E1=90=A7

= --=C2=A0
Txauth mail= ing list
Txauth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth=

=C2=A0=

--
Txauth mailing list=
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--000000000000c28431059ddb5f13-- From nobody Thu Feb 6 00:14:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DE012081E for ; Thu, 6 Feb 2020 00:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=hopebailie.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnH4SdVFonJU for ; Thu, 6 Feb 2020 00:14:18 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 D053B120041 for ; Thu, 6 Feb 2020 00:14:17 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id r16so4704549otd.2 for ; Thu, 06 Feb 2020 00:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hUqwodRer7zIZmRs/PjVA/MipbBFFygdh/zJbQMfiMg=; b=PYBjRhaaAt9zIPsKhuWdQ5qtHGW6lwHJoiSsi9C2szd5QCjAYu56aAmKWSKrro9o5x H43CCZMbRoscjxjbsLdPG2fbz3ITeBmml9UU0JtPlq1Ff5+9t4M2Akb2z797WLhKJzue aXrEAg/gVCS5nLBFITeqY0YMzYFVdgGQuHUgk= 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=hUqwodRer7zIZmRs/PjVA/MipbBFFygdh/zJbQMfiMg=; b=rwAge2AyU/fMk417ef2Ec2T8ND4WklhkWBOanqF+/NXzYKWvhuS/YMA2VDogCgmxBt H2KTVZpsA90Z0GXaSn0daNeO5PSIXRcXStUHYHEOF+0dgebmoN4fc9Gi4w579WFVEAMV NcbIqPRfdLayysTgEovUVMbC7EsmhUw3CB+d1HiYIwninbPH7AytgnlGMtyeQ/YhE4bp KZfvOk/w9z1cX5wnyrvE1UcMunUr0aPnj+Pyb+++ymH1/RXW+xgs2BAiFeKUF1XnIoef eIvXZnT3ZugsnK62zd+8Hm52ieMXd0ihN0hodlb2tzmqdBThuXtXSZq3GJpaQ46Ec3v0 LOYg== X-Gm-Message-State: APjAAAUzsBLutt38Pt/UUFpyQ9SukwmKvMHi6qccAIozG/1HWkS41UCJ CPnfToGBREyOZsaP6/7E4/gOtVtO9vFwAH17zW1hyQ== X-Google-Smtp-Source: APXvYqyxQUZlZYzVqjF8awYN6b/lJadgYoqKAtrq/rvw7QsvSu/Co0/GIPS+Y42GedgbxsQh6s3zMpEFa2lPVUPye/o= X-Received: by 2002:a9d:69ce:: with SMTP id v14mr30062032oto.248.1580976856799; Thu, 06 Feb 2020 00:14:16 -0800 (PST) MIME-Version: 1.0 References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: From: Adrian Hope-Bailie Date: Thu, 6 Feb 2020 10:14:04 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f2ad4b059de3db9a" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 08:14:24 -0000 --000000000000f2ad4b059de3db9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree on the the purpose of the document. My concern, and this is not unique to IETF, is that the desire to tightly define the scope in the charter of the WG means participants are compelled to already design solutions and use these to frame the scope. The effect is to charter a WG that is already bound to a particular solution. I would be very supportive of coming to consensus on a set of use cases as a better way of agreeing on scope and basing the charter off of this shared understanding. My point is that following the formation of the WG I don't expect us to be bound by the use case document but rather the charter, which, as has been pointed out already, may be less specific. E.g. we may add use cases post chartering that the WG considers important IF they fit within the scope as defined in the charter. TL;DR: let's build a use case document. We are keen to contribute the cases that are important to us On Thu, Feb 6, 2020 at 00:06 Dick Hardt wrote: > > I proposed a use case document so that there is a common understand of > what the WG is working to solve. In my discussions online with Justin, it > is clear that he and I don't share a common set of requirements for this > WG, and I suspect that is the case for many. > > First, I don't think there is a common understanding of all the use cases > that OAuth 2.0 and OpenID Connect are solving today. > > Second, in the latest charter we have "new use cases not enabled by OAuth > 2.0.", which is somewhat based on a number of those use cases that were > presented in the BoF in Singapore, but in ad hoc discussions, I think the= re > are many use cases that people desire to be solved, but are not widely > understood. > > In my opinion, the use case document acts as the WGs requirements. Withou= t > it, there are disagreements in the IDs because participants are wanting t= o > solve different use cases, but they don't know they have different use > cases, so the disagreements surface in the ID. Sometimes those > disagreements are resolved in a side meeting, but the knowledge is not > captured and the "why" fades away. > > I'd advocate that if someone is wanting a feature, there needs to a a use > case the WG has agreed to that requires the feature. If the use case is n= ot > in the use case document, it needs to be written up and adopted by the WG= . > > While this adds some overhead to the process, I think it will assist in i= n > alignment on the rest of the work products. > > I don't want this WG to be Perl6. =3D) > > =E1=90=A7 > > On Wed, Feb 5, 2020 at 11:55 AM Yaron Sheffer > wrote: > >> Yes, but it=E2=80=99s on us to decide at what level of granularity. Typi= cally a >> use case document would go deeper that what you would expect in a WG >> charter. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Adrian Hope-Bailie >> *Date: *Wednesday, February 5, 2020 at 00:49 >> *To: *Yaron Sheffer >> *Cc: *Justin Richer , Mike Jones > 40microsoft.com@dmarc.ietf.org>, "Richard Backman, Annabelle" > 40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" , Dick >> Hardt >> *Subject: *Re: [Txauth] use case document? >> >> >> >> It's my understanding that the scope needs to be decided before we have = a >> WG (i.e. defined in the charter). >> >> >> >> On Wed, 5 Feb 2020 at 01:06, Yaron Sheffer wrote= : >> >> Once this is a working group, we will need to make decisions on scope: >> what goes into the base document, what we might want as extensions, and >> what the WG doesn=E2=80=99t want to work on in the near term. >> >> >> >> If we have a use case document, that would be the natural place to have >> these discussions =E2=80=93 you clarify each particular use case and mak= e sure >> everybody agrees on what it means, and then the group decides which buck= et >> to put it in: base document, extension, defer. Otherwise I=E2=80=99m not= sure what >> the document is intended to achieve. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Justin Richer >> *Date: *Tuesday, February 4, 2020 at 18:17 >> *To: *Mike Jones >> *Cc: *Dick Hardt , Yaron Sheffer < >> yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" > 40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" >> *Subject: *Re: [Txauth] use case document? >> >> >> >> I=E2=80=99m fine with use cases as input to work, but they should always= be taken >> as non-binding and non-normative. In other words, they=E2=80=99re a grea= t way for >> us to write something down and say =E2=80=9Cyeah that makes sense for so= mething for >> us to work on=E2=80=9D. But I don=E2=80=99t think it makes sense as a wa= y to enforce >> direction or decision within the group (ie, =E2=80=9Cthat=E2=80=99s not = in the use cases >> document, we=E2=80=99re not going to talk about it=E2=80=9D), or as a fo= rmal output of the >> document. >> >> >> >> Therefore if it=E2=80=99s an openly accessible and editable document tha= t people >> can put things in, I think it=E2=80=99s a helpful tool. The moment it be= comes >> burdensome to update and continue use, we need to question whether we >> should keep doing it. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Feb 3, 2020, at 5:01 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> >> >> I agree. I'd rather see use cases sooner than later. >> >> -- Mike >> ------------------------------ >> >> *From:* Txauth on behalf of Richard Backman, >> Annabelle >> *Sent:* Monday, February 3, 2020 9:04:00 PM >> *To:* Dick Hardt ; Yaron Sheffer < >> yaronf.ietf@gmail..com > >> *Cc:* txauth@ietf.org >> *Subject:* [EXTERNAL] Re: [Txauth] use case document? >> >> >> >> I don=E2=80=99t follow the logic of deferring this, since the charter de= fines the >> scope of the working group. We=E2=80=99re all comparing the charter draf= ts against >> our use cases anyway; doing that out in the open seems less likely to le= ad >> to arguments down the road over whether something falls within the scope >> laid out in the charter. >> >> >> >> For what it=E2=80=99s worth, Justin put this together back in August: >> https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo >> >> >> >> >> =E2=80=93 >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *Txauth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Saturday, February 1, 2020 at 2:25 PM >> *To: *Yaron Sheffer >> *Cc: *"txauth@ietf.org" >> *Subject: *Re: [Txauth] use case document? >> >> >> >> Works for me. >> >> >> >> On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer >> wrote: >> >> It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in scope= , and in particular what=E2=80=99s **not** >> in scope, before you have a WG. I am worried about scope creep which is >> likely to happen once this is a WG and more people are involved. IMO the >> best way to avoid it is by only having this discussion once everybody is= on >> board. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Dick Hardt >> *Date: *Sunday, February 2, 2020 at 00:16 >> *To: *Yaron Sheffer >> *Cc: * >> *Subject: *Re: [Txauth] use case document? >> >> >> >> I was thinking a rough draft of a use case document would assist in >> teasing out what is in scope and not for the WG. >> >> >> >> I've been adding use cases to the XAuth ID to tease out what would be in >> and out of scope. >> >> >> >> It would also provide clarity on why this WG is different from the OAuth >> WG. >> >> >> >> On Sat, Feb 1, 2020 at 10:20 AM Yaron Sheffer >> wrote: >> >> I support such a document in principle. I agree that having a list of us= e >> cases would help to scope the protocol document(s). >> >> >> >> However I think now is not the right time, because a use case document i= s >> only useful in defining scope once it is more or less stable and enjoys >> rough consensus. We can only demonstrate consensus once we move past the >> BoF stage and into a WG. So I believe it only makes sense to produce the >> use case doc when we have a chartered WG. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Txauth on behalf of Dick Hardt < >> dick.hardt@gmail.com > >> *Date: *Saturday, February 1, 2020 at 00:38 >> *To: * >> *Subject: *[Txauth] use case document? >> >> >> >> As I reflect on my conversations with Justin, a set of use cases would >> help guide us. We could then refer to a use case as why a feature is >> present and see how different features support (or don't support) differ= ent >> use cases. >> >> >> >> We can also use the document to decide which use cases are in scope, or >> out of scope. >> >> >> >> I'll put up my hand to edit. Who is interested in contributing? >> >> >> >> /Dick >> >> *Error! Filename not specified.*=E1=90=A7 >> >> -- Txauth mailing list Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- Sent from a mobile device, please excuse any typos --000000000000f2ad4b059de3db9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree on the the purpose of the document.

My concern, and this is not unique= to IETF, is that the desire to tightly define the scope in the charter of = the WG means participants are compelled to already design solutions and use= these to frame the scope. The effect is to charter a WG that is already bo= und to a particular solution.

I would be very supportive of coming to consensus on a set of use cas= es as a better way of agreeing on scope and basing the charter off of this = shared understanding.

My= point is that following the formation of the WG I don't expect us to b= e bound by the use case document but rather the charter, which, as has been= pointed out already, may be less specific.

E.g. we may add use cases post chartering that the WG c= onsiders important IF they fit within the scope as defined in the charter.<= /div>

TL;DR: let's build a= use case document. We are keen to contribute the cases that are important = to us

On Thu, Feb 6, 2020 at 00:06 Dick Hardt <dick.hardt@gmail.com> wrote:

I proposed a use case document so tha= t there is a common understand of what the WG is working to solve. In my di= scussions online with=C2=A0Justin, it is clear that he and I don't shar= e a common set of requirements for this WG, and I suspect that is the case = for many.

First, I don't think there is a comm= on understanding of all the use cases that OAuth 2.0 and OpenID Connect are= solving today.

Second, in the latest charter we h= ave "new use cases not enabled by OAuth 2.0.", which is somewhat = based on=C2=A0a number of those use cases that were presented in the BoF in= Singapore, but in ad hoc discussions, I think there are many use cases tha= t people desire to be solved, but are not widely understood.

=
In my opinion, the use case document acts as the WGs requirement= s. Without it, there are disagreements in the IDs because participants are = wanting to solve different use cases, but they don't know they have dif= ferent use cases, so the disagreements surface in the ID. Sometimes those d= isagreements=C2=A0are resolved in a side meeting, but the knowledge is not = captured and the "why" fades away.

I'= ;d advocate that if someone is wanting a feature, there needs to a a use ca= se the WG has agreed to that requires the feature. If the use case is not i= n the use case document, it needs to be written up and adopted by the WG.

While this adds some overhead to the process, I thi= nk it will assist in in alignment on the rest of the work products.

I don't want this WG to be Perl6. =3D)

=
=E1=90=A7

On Wed, Feb 5, 20= 20 at 11:55 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Yes, but it=E2=80=99s = on us to decide at what level of granularity. Typically a use case document= would go deeper that what you would expect in a WG charter.<= /p>

=C2=A0

Th= anks,

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

=C2=A0

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wednesday, Febr= uary 5, 2020 at 00:49
To: Yaron Sheffer <yaronf.ietf@gmail.com>
C= c: Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.i= etf.org>, "Richard Backman, Annabelle" <richanna=3D40amazon.com@d= marc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Su= bject: Re: [Txauth] use case document?

=C2=A0

It's my understanding that the scope needs to be decided befor= e we have a WG (i.e. defined in the charter).

=C2=A0

O= n Wed, 5 Feb 2020 at 01:06, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Once = this is a working group, we will need to make decisions on scope: what goes= into the base document, what we might want as extensions, and what the WG = doesn=E2=80=99t want to work on in the near term.

=C2=A0

If we have a = use case document, that would be the natural place to have these discussion= s =E2=80=93 you clarify each particular use case and make sure everybody ag= rees on what it means, and then the group decides which bucket to put it in= : base document, extension, defer. Otherwise I=E2=80=99m not sure what the = document is intended to achieve.

= =C2=A0

Thanks,

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

=C2=A0

From:= Justin Richer <jricher@mit.edu><= br>Date: Tuesday, February 4, 2020 at 18:17
To: Mike Jones= <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Cc: Dick Har= dt <dick.hardt= @gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman,= Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org><= br>Subject: Re: [Txauth] use case document?

=

=C2=A0

I=E2=80=99m fine with use cases as input to work, but they shou= ld always be taken as non-binding and non-normative. In other words, they= =E2=80=99re a great way for us to write something down and say =E2=80=9Cyea= h that makes sense for something for us to work on=E2=80=9D. But I don=E2= =80=99t think it makes sense as a way to enforce direction or decision with= in the group (ie, =E2=80=9Cthat=E2=80=99s not in the use cases document, we= =E2=80=99re not going to talk about it=E2=80=9D), or as a formal output of = the document.=C2=A0

=C2=A0<= /u>

Therefore if it=E2=80=99s a= n openly accessible and editable document that people can put things in, I = think it=E2=80=99s a helpful tool. The moment it becomes burdensome to upda= te and continue use, we need to question whether we should keep doing it.

=C2=A0

<= /div>

=C2=A0=E2=80=94 Justin

=C2=A0=

On Feb 3, 2020, at 5:01 PM, Mike Jones <Michael.Jon= es=3D40microsoft.com@dmarc.ietf.org> wrote:

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

I agree. I'd rather see use cases sooner than later.

-- Mike

<= p class=3D"MsoNormal">From:=C2=A0Txauth <txauth-bounces@ietf.org> on beh= alf of Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.o= rg>
Sent:=C2=A0Monday, February 3, 2020 9:04:00 PM
T= o:=C2=A0Dick Hardt <dick.hardt@gmail.com>; Yaron Sheffer <yaronf.ietf@gmail..com><= br>Cc:=C2=A0txa= uth@ietf.org <t= xauth@ietf.org>
Subject:=C2=A0[EXTERNAL] Re: [Txauth] use = case document?

=C2=A0

<= /div>

I don=E2=80=99t follow the logic= of deferring this, since the charter defines the scope of the working grou= p. We=E2=80=99re all comparing the charter drafts against our use cases any= way; doing that out in the open seems less likely to lead to arguments down= the road over whether something falls within the scope laid out in the cha= rter.

=C2=A0=

For what it=E2=80=99s worth, Jus= tin put this together back in August:=C2=A0https://mai= larchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo<= /u>

=C2=A0

=E2=80=93=C2=A0

=

Annabelle Richar= d Backman

AWS Identity

=C2=A0

=C2=A0

From:=C2=A0Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:=C2=A0Saturd= ay, February 1, 2020 at 2:25 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com<= /a>>
Cc:=C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re: [Tx= auth] use case document?

=C2=A0

Works for me.

=C2=A0

On Sat, Feb 1, 2020 at 2:23 PM Yaron Sheffer <yaronf.ietf@gmail.com> wro= te:

It=E2=80=99s hard to =E2=80=9Ctease out=E2=80=9D what=E2=80=99s in = scope, and in particular what=E2=80=99s *not* in scope, before you h= ave a WG. I am worried about scope creep which is likely to happen once thi= s is a WG and more people are involved. IMO the best way to avoid it is by = only having this discussion once everybody is on board.

=C2=A0

Thanks,

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

=C2=A0

From:=C2= =A0Dick Hardt <dick.hardt@gmail.com>
= Date:=C2=A0Sunday, February 2, 2020 at 00:16
To:=C2=A0Yaro= n Sheffer <ya= ronf.ietf@gmail.com>
Cc:=C2=A0<txauth@ietf.org>
Subject:=C2=A0Re: [Txauth] use case document?

=

=C2=A0

I was thinking a rough draft of a use case documen= t would assist in teasing out what is in scope and not for the WG.

=C2=A0

I've been adding use cases= to the XAuth ID to tease out what would be in and out of scope.<= /u>

=C2=A0<= u>

It would also provide clar= ity on why this WG is different from the OAuth WG.=C2=A0=C2=A0

=C2=A0

On Sat, Feb 1, 2020 at 10:20= AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I support such a document in= principle. I agree that having a list of use cases would help to scope the= protocol document(s).

=C2=A0

However I think= now is not the right time, because a use case document is only useful in d= efining scope once it is more or less stable and enjoys rough consensus. We= can only demonstrate consensus once we move past the BoF stage and into a = WG. So I believe it only makes sense to produce the use case doc when we ha= ve a chartered WG.

=C2=A0

Thanks,

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

=C2=A0

From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>= ;
Date:=C2=A0Saturday, February 1, 2020 at 00:38
To:=C2=A0<= /b><txauth@ietf.org= >
Subject:=C2=A0[Txauth] use case document?<= u>

=C2=A0

As I reflect on my conv= ersations with Justin, a set of use cases would help guide us. We could the= n refer to a use case as why a feature is present and see how different fea= tures support (or don't support) different use cases.

=

=C2=A0

We can also use the document to decide = which use cases are in scope, or out of scope.

=

=C2=A0

I'll put up my hand to edit. Who is interested= in contributing?

=C2=A0

/Dick

Error! Fi= lename not specified.=E1=90=A7

<= /div>
--= =C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

= =C2=A0

--
Txa= uth mailing list
Tx= auth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Sent from a mobile device, please excuse= any typos
--000000000000f2ad4b059de3db9a-- From nobody Thu Feb 6 02:05:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9D120271 for ; Thu, 6 Feb 2020 02:04:59 -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_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 MXjCBHBTNZrz for ; Thu, 6 Feb 2020 02:04:56 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 AE88E1200D6 for ; Thu, 6 Feb 2020 02:04:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ml3ZuilezsY1otXS9/TJEFwi9fiwz0eggswP1W5dZpOHc5bMGsm+KHP9MZaKk/MOllNPUIGtuLrvADaZ8cXG9uQEzhooScq5B14NpPkvVJUlMORAxUhaDcnIWtWF05XayS0/Pl+Neio1klKIWexAddP++rYbP4xBzEd7InkkEyrgRTaMFxsYIFz7v8AmnP2/es5oVjXLIht+OkpsSWHMkgH0RWF7YI4bJvRTRVnGeeE8rcYIs5lviGpYpvn7FS6q3zw0KZMayIdhrLVVfZNkowz9eSQO7u1n5ji8Njytcd9tQs7sfj1+KJXab+1V25X5cZJAkpQgjrkKAHtMShvjHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aj0lUmtyWRLet/2qZl82hDu6l23/oWqG3sa/dNsxEW4=; b=It4ek3fyukK4zjHvBHuWvBWVgI2bdBcyEg9wdq7OwJIPkKbekdx784aa4bpIaKD/XRiOrEJimKhH9Wn0Ek+IL2hEJvPuFCIoRmraYKoFCU9BgYaZU5PisgW5osgewE54PrM+7sSY4ILBTxNbDsIr31sjmuwP5KY+Np+TWwomY4Cn3YnoTHDA52nYTFd9s1j84EhCxJkwNkrnw1xwRUNj3gNONCcCh7FaxUPv7QBv6/h8AqFVupeRQALHcnrjW6Okv5K8aleaYJEPMvnEXu6ZdldhFwIsoUbUniHumNb9A2Df8hIM5vD7+uBjoDjaBdvpIR6f+1YLFDtYqNsQt9Wgww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aj0lUmtyWRLet/2qZl82hDu6l23/oWqG3sa/dNsxEW4=; b=IZTxXveoIpK0Ts4L/0NfZm20z6AXrnzSpHkk5mvnMYXHqlahpVWas8fj8lu4pmCzcezP4kLyZSQJran+m8M06odeotlDM+17wo6AJ99/azzuLrhT6KC2BnEKOmltWcTxwATbKCwW6xezEDlfHBMVOW4l/0ZLe6L7M7poTRJ7OwI= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (20.180.6.215) by CH2PR00MB0745.namprd00.prod.outlook.com (10.186.137.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2749.0; Thu, 6 Feb 2020 10:04:48 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::5499:1e9a:18f0:2711]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::5499:1e9a:18f0:2711%7]) with mapi id 15.20.2748.000; Thu, 6 Feb 2020 10:04:48 +0000 From: Mike Jones To: Dick Hardt , Yaron Sheffer CC: Adrian Hope-Bailie , Justin Richer , "Richard Backman, Annabelle" , "txauth@ietf.org" Thread-Topic: [EXTERNAL] Re: [Txauth] use case document? Thread-Index: AQHV3F469Sfjh3egikOQ4+eunInaZqgNKEgAgADIqOA= Date: Thu, 6 Feb 2020 10:04:48 +0000 Message-ID: References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6599eff4-d851-4e96-a688-000056359670; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-06T10:04:38Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [62.28.240.114] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ee4fdc89-3a87-49ec-823e-08d7aaec0009 x-ms-traffictypediagnostic: CH2PR00MB0745: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(366004)(136003)(39860400002)(396003)(189003)(199004)(53546011)(8676002)(110136005)(52536014)(54906003)(6506007)(76236002)(5660300002)(8990500004)(8936002)(81156014)(81166006)(2906002)(316002)(66476007)(66946007)(966005)(4326008)(71200400001)(55016002)(76116006)(9686003)(186003)(64756008)(66556008)(33656002)(7696005)(10290500003)(66446008)(478600001)(86362001)(26005)(99710200001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0745; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2OawIrb97xAvLIPT/Iy+94KEN2FwHnmnbvq4QZAn3/V4YdMEm7uxckAdMpAQixZFVwIZtVO3m8C3cv/6EnHnN8xKDs+2YMhWsT67LkUgfN6fUH8/q0P2E1IPa4WwUXbVGr3RYwziGe8DyrEYyAyvrJEW5ivKh051VulXQsLoNEou5xzeG7dlP3ZVBbC2VhSwBDnUbo3xgZFhrAS3wKvzNkUbLLfqj9+gR4VCt56WbhoyM12e2sINv0u6erWY8yAVfR3YVUU3BbYAdlVfIqXmvzDR2EUCI7tpfc27RF7qFOdj3MP1CTDSmXLhXhO4xDVKkfDxU9Vda/vz3KBktCrFm5y5gcZn5NMYuSR7UHpFNEamKqrTHGjlFta7v+WedUO2FGZvgNBYHiOH7Or7GhUqAILVOM05F3uOp8d1FsOD6iNjYvFqTv5KaURDtNJ2LtGNKqrQNhekuKTHo77cG2a/BqmjhGN+A+2bzlN+e38vadiOzM8AuM1gN4lm7fZFdYk9YWuUZwKdbVWYs8Gt4oEArOpzoHnCe1tukUNaczgnQuZTTlyR5dluWg/soYOl4F3s3wo8oOybaTDGcOVW+OU8Ug== x-ms-exchange-antispam-messagedata: U+irVkrv2/CPz5domDM33jc92C39wC4gP7HT5g07jO6NDALQg3tEJTFMhKDnaLXFlxXCDyKp9E+GECiciJ/LzdB2nJsWos4kx0cRjowBS3tMJDAB9i2TRQ7NvQnkq8RZfkL1qHSacb/yUL3+lcX/wA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678119EB9927D7E2023699EF51D0CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee4fdc89-3a87-49ec-823e-08d7aaec0009 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 10:04:48.4387 (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-CrossTenant-userprincipalname: m5COSpo51u7OODfM6txWfrCDDQP82w+yoxe5wc1t3TZgA0AA4pgoPRitMDhYgzZwzyTlA9Hd7GQ0uCHMnFeBLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0745 Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 10:04:59 -0000 --_000_CH2PR00MB0678119EB9927D7E2023699EF51D0CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTZW50OiBXZWRu ZXNkYXksIEZlYnJ1YXJ5IDUsIDIwMjAgMjowNiBQTQ0KVG86IFlhcm9uIFNoZWZmZXIgPHlhcm9u Zi5pZXRmQGdtYWlsLmNvbT4NCkNjOiBBZHJpYW4gSG9wZS1CYWlsaWUgPGFkcmlhbkBob3BlYmFp bGllLmNvbT47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxy aWNoYW5uYUBhbWF6b24uY29tPjsgdHhhdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbRVhURVJOQUxd IFJlOiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD8NCg0KDQpJIHByb3Bvc2VkIGEgdXNlIGNh c2UgZG9jdW1lbnQgc28gdGhhdCB0aGVyZSBpcyBhIGNvbW1vbiB1bmRlcnN0YW5kIG9mIHdoYXQg dGhlIFdHIGlzIHdvcmtpbmcgdG8gc29sdmUuIEluIG15IGRpc2N1c3Npb25zIG9ubGluZSB3aXRo IEp1c3RpbiwgaXQgaXMgY2xlYXIgdGhhdCBoZSBhbmQgSSBkb24ndCBzaGFyZSBhIGNvbW1vbiBz ZXQgb2YgcmVxdWlyZW1lbnRzIGZvciB0aGlzIFdHLCBhbmQgSSBzdXNwZWN0IHRoYXQgaXMgdGhl IGNhc2UgZm9yIG1hbnkuDQoNCkZpcnN0LCBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgY29tbW9u IHVuZGVyc3RhbmRpbmcgb2YgYWxsIHRoZSB1c2UgY2FzZXMgdGhhdCBPQXV0aCAyLjAgYW5kIE9w ZW5JRCBDb25uZWN0IGFyZSBzb2x2aW5nIHRvZGF5Lg0KDQpTZWNvbmQsIGluIHRoZSBsYXRlc3Qg Y2hhcnRlciB3ZSBoYXZlICJuZXcgdXNlIGNhc2VzIG5vdCBlbmFibGVkIGJ5IE9BdXRoIDIuMC4i LCB3aGljaCBpcyBzb21ld2hhdCBiYXNlZCBvbiBhIG51bWJlciBvZiB0aG9zZSB1c2UgY2FzZXMg dGhhdCB3ZXJlIHByZXNlbnRlZCBpbiB0aGUgQm9GIGluIFNpbmdhcG9yZSwgYnV0IGluIGFkIGhv YyBkaXNjdXNzaW9ucywgSSB0aGluayB0aGVyZSBhcmUgbWFueSB1c2UgY2FzZXMgdGhhdCBwZW9w bGUgZGVzaXJlIHRvIGJlIHNvbHZlZCwgYnV0IGFyZSBub3Qgd2lkZWx5IHVuZGVyc3Rvb2QuDQoN CkluIG15IG9waW5pb24sIHRoZSB1c2UgY2FzZSBkb2N1bWVudCBhY3RzIGFzIHRoZSBXR3MgcmVx dWlyZW1lbnRzLiBXaXRob3V0IGl0LCB0aGVyZSBhcmUgZGlzYWdyZWVtZW50cyBpbiB0aGUgSURz IGJlY2F1c2UgcGFydGljaXBhbnRzIGFyZSB3YW50aW5nIHRvIHNvbHZlIGRpZmZlcmVudCB1c2Ug Y2FzZXMsIGJ1dCB0aGV5IGRvbid0IGtub3cgdGhleSBoYXZlIGRpZmZlcmVudCB1c2UgY2FzZXMs IHNvIHRoZSBkaXNhZ3JlZW1lbnRzIHN1cmZhY2UgaW4gdGhlIElELiBTb21ldGltZXMgdGhvc2Ug ZGlzYWdyZWVtZW50cyBhcmUgcmVzb2x2ZWQgaW4gYSBzaWRlIG1lZXRpbmcsIGJ1dCB0aGUga25v d2xlZGdlIGlzIG5vdCBjYXB0dXJlZCBhbmQgdGhlICJ3aHkiIGZhZGVzIGF3YXkuDQoNCkknZCBh ZHZvY2F0ZSB0aGF0IGlmIHNvbWVvbmUgaXMgd2FudGluZyBhIGZlYXR1cmUsIHRoZXJlIG5lZWRz IHRvIGEgYSB1c2UgY2FzZSB0aGUgV0cgaGFzIGFncmVlZCB0byB0aGF0IHJlcXVpcmVzIHRoZSBm ZWF0dXJlLiBJZiB0aGUgdXNlIGNhc2UgaXMgbm90IGluIHRoZSB1c2UgY2FzZSBkb2N1bWVudCwg aXQgbmVlZHMgdG8gYmUgd3JpdHRlbiB1cCBhbmQgYWRvcHRlZCBieSB0aGUgV0cuDQoNCldoaWxl IHRoaXMgYWRkcyBzb21lIG92ZXJoZWFkIHRvIHRoZSBwcm9jZXNzLCBJIHRoaW5rIGl0IHdpbGwg YXNzaXN0IGluIGluIGFsaWdubWVudCBvbiB0aGUgcmVzdCBvZiB0aGUgd29yayBwcm9kdWN0cy4N Cg0KSSBkb24ndCB3YW50IHRoaXMgV0cgdG8gYmUgUGVybDYuID0pDQoNCuGQpw0KDQpPbiBXZWQs IEZlYiA1LCAyMDIwIGF0IDExOjU1IEFNIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWls LmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpZZXMsIGJ1dCBpdOKA mXMgb24gdXMgdG8gZGVjaWRlIGF0IHdoYXQgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIFR5cGljYWxs eSBhIHVzZSBjYXNlIGRvY3VtZW50IHdvdWxkIGdvIGRlZXBlciB0aGF0IHdoYXQgeW91IHdvdWxk IGV4cGVjdCBpbiBhIFdHIGNoYXJ0ZXIuDQoNClRoYW5rcywNCiAgICAgICAgICAgICAgICBZYXJv bg0KDQpGcm9tOiBBZHJpYW4gSG9wZS1CYWlsaWUgPGFkcmlhbkBob3BlYmFpbGllLmNvbTxtYWls dG86YWRyaWFuQGhvcGViYWlsaWUuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgRmVicnVhcnkgNSwg MjAyMCBhdCAwMDo0OQ0KVG86IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4NCkNjOiBKdXN0aW4gUmljaGVyIDxqcmljaGVy QG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29t QGRtYXJjLmlldGYub3JnPj4sICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5h PTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLi5p ZXRmLm9yZz4+LCAidHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+IiA8dHhh dXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+PiwgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NClN1YmplY3Q6IFJl OiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD8NCg0KSXQncyBteSB1bmRlcnN0YW5kaW5nIHRo YXQgdGhlIHNjb3BlIG5lZWRzIHRvIGJlIGRlY2lkZWQgYmVmb3JlIHdlIGhhdmUgYSBXRyAoaS5l LiBkZWZpbmVkIGluIHRoZSBjaGFydGVyKS4NCg0KT24gV2VkLCA1IEZlYiAyMDIwIGF0IDAxOjA2 LCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRm QGdtYWlsLmNvbT4+IHdyb3RlOg0KT25jZSB0aGlzIGlzIGEgd29ya2luZyBncm91cCwgd2Ugd2ls bCBuZWVkIHRvIG1ha2UgZGVjaXNpb25zIG9uIHNjb3BlOiB3aGF0IGdvZXMgaW50byB0aGUgYmFz ZSBkb2N1bWVudCwgd2hhdCB3ZSBtaWdodCB3YW50IGFzIGV4dGVuc2lvbnMsIGFuZCB3aGF0IHRo ZSBXRyBkb2VzbuKAmXQgd2FudCB0byB3b3JrIG9uIGluIHRoZSBuZWFyIHRlcm0uDQoNCklmIHdl IGhhdmUgYSB1c2UgY2FzZSBkb2N1bWVudCwgdGhhdCB3b3VsZCBiZSB0aGUgbmF0dXJhbCBwbGFj ZSB0byBoYXZlIHRoZXNlIGRpc2N1c3Npb25zIOKAkyB5b3UgY2xhcmlmeSBlYWNoIHBhcnRpY3Vs YXIgdXNlIGNhc2UgYW5kIG1ha2Ugc3VyZSBldmVyeWJvZHkgYWdyZWVzIG9uIHdoYXQgaXQgbWVh bnMsIGFuZCB0aGVuIHRoZSBncm91cCBkZWNpZGVzIHdoaWNoIGJ1Y2tldCB0byBwdXQgaXQgaW46 IGJhc2UgZG9jdW1lbnQsIGV4dGVuc2lvbiwgZGVmZXIuIE90aGVyd2lzZSBJ4oCZbSBub3Qgc3Vy ZSB3aGF0IHRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBhY2hpZXZlLi4NCg0KVGhhbmtzLA0K ICAgICAgICAgICAgICAgIFlhcm9uDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDQs IDIwMjAgYXQgMTg6MTcNClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn Pj4NCkNjOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20+PiwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0 bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8 cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21A ZG1hcmMuaWV0Zi5vcmc+PiwgInR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3Jn PiIgPHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD8NCg0KSeKAmW0gZmluZSB3aXRoIHVzZSBjYXNl cyBhcyBpbnB1dCB0byB3b3JrLCBidXQgdGhleSBzaG91bGQgYWx3YXlzIGJlIHRha2VuIGFzIG5v bi1iaW5kaW5nIGFuZCBub24tbm9ybWF0aXZlLiBJbiBvdGhlciB3b3JkcywgdGhleeKAmXJlIGEg Z3JlYXQgd2F5IGZvciB1cyB0byB3cml0ZSBzb21ldGhpbmcgZG93biBhbmQgc2F5IOKAnHllYWgg dGhhdCBtYWtlcyBzZW5zZSBmb3Igc29tZXRoaW5nIGZvciB1cyB0byB3b3JrIG9u4oCdLiBCdXQg SSBkb27igJl0IHRoaW5rIGl0IG1ha2VzIHNlbnNlIGFzIGEgd2F5IHRvIGVuZm9yY2UgZGlyZWN0 aW9uIG9yIGRlY2lzaW9uIHdpdGhpbiB0aGUgZ3JvdXAgKGllLCDigJx0aGF04oCZcyBub3QgaW4g dGhlIHVzZSBjYXNlcyBkb2N1bWVudCwgd2XigJlyZSBub3QgZ29pbmcgdG8gdGFsayBhYm91dCBp dOKAnSksIG9yIGFzIGEgZm9ybWFsIG91dHB1dCBvZiB0aGUgZG9jdW1lbnQuDQoNClRoZXJlZm9y ZSBpZiBpdOKAmXMgYW4gb3Blbmx5IGFjY2Vzc2libGUgYW5kIGVkaXRhYmxlIGRvY3VtZW50IHRo YXQgcGVvcGxlIGNhbiBwdXQgdGhpbmdzIGluLCBJIHRoaW5rIGl04oCZcyBhIGhlbHBmdWwgdG9v bC4gVGhlIG1vbWVudCBpdCBiZWNvbWVzIGJ1cmRlbnNvbWUgdG8gdXBkYXRlIGFuZCBjb250aW51 ZSB1c2UsIHdlIG5lZWQgdG8gcXVlc3Rpb24gd2hldGhlciB3ZSBzaG91bGQga2VlcCBkb2luZyBp dC4NCg0KIOKAlCBKdXN0aW4NCg0KT24gRmViIDMsIDIwMjAsIGF0IDU6MDEgUE0sIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpN aWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpJ IGFncmVlLiBJJ2QgcmF0aGVyIHNlZSB1c2UgY2FzZXMgc29vbmVyIHRoYW4gbGF0ZXIuDQotLSBN aWtlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVHhhdXRoIDx0eGF1 dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9uLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYu b3JnPj4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMywgMjAyMCA5OjA0OjAwIFBNDQpUbzogRGlj ayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t Pj47IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLi5jb208bWFpbHRvOnlhcm9uZi5p ZXRmQGdtYWlsLmNvbT4+DQpDYzogdHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5v cmc+IDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBb RVhURVJOQUxdIFJlOiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD8NCg0KSSBkb27igJl0IGZv bGxvdyB0aGUgbG9naWMgb2YgZGVmZXJyaW5nIHRoaXMsIHNpbmNlIHRoZSBjaGFydGVyIGRlZmlu ZXMgdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBXZeKAmXJlIGFsbCBjb21wYXJpbmcg dGhlIGNoYXJ0ZXIgZHJhZnRzIGFnYWluc3Qgb3VyIHVzZSBjYXNlcyBhbnl3YXk7IGRvaW5nIHRo YXQgb3V0IGluIHRoZSBvcGVuIHNlZW1zIGxlc3MgbGlrZWx5IHRvIGxlYWQgdG8gYXJndW1lbnRz IGRvd24gdGhlIHJvYWQgb3ZlciB3aGV0aGVyIHNvbWV0aGluZyBmYWxscyB3aXRoaW4gdGhlIHNj b3BlIGxhaWQgb3V0IGluIHRoZSBjaGFydGVyLg0KDQoNCkZvciB3aGF0IGl04oCZcyB3b3J0aCwg SnVzdGluIHB1dCB0aGlzIHRvZ2V0aGVyIGJhY2sgaW4gQXVndXN0OiBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL3Y4VGRrcnVDendINDNGTUtTNTk4SUMyU2hlbzxo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRmLm9yZyUyRmFyY2glMkZtc2clMkZvYXV0aCUyRnY4VGRr cnVDendINDNGTUtTNTk4SUMyU2hlbyZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3QzNiNmRiOGVjZTIyOTQ5NzgxNjM0MDhkN2FhODdiYTJiJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NTM3MjI1Nzk5NzA1MCZzZGF0 YT00OVRpRWNEN3V6TFk1RnpPR3ZibzN2NnVKcU1SQmRTakg5OWlsb2ZTd3M0JTNEJnJlc2VydmVk PTA+DQoNCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0K DQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRo LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBn bWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IFNhdHVyZGF5LCBG ZWJydWFyeSAxLCAyMDIwIGF0IDI6MjUgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpDYzogInR4YXV0aEBp ZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86 dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVu dD8NCg0KDQpXb3JrcyBmb3IgbWUuDQoNCg0KT24gU2F0LCBGZWIgMSwgMjAyMCBhdCAyOjIzIFBN IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQpJdOKAmXMgaGFyZCB0byDigJx0ZWFzZSBvdXTigJ0gd2hhdOKA mXMgaW4gc2NvcGUsIGFuZCBpbiBwYXJ0aWN1bGFyIHdoYXTigJlzICpub3QqIGluIHNjb3BlLCBi ZWZvcmUgeW91IGhhdmUgYSBXRy4gSSBhbSB3b3JyaWVkIGFib3V0IHNjb3BlIGNyZWVwIHdoaWNo IGlzIGxpa2VseSB0byBoYXBwZW4gb25jZSB0aGlzIGlzIGEgV0cgYW5kIG1vcmUgcGVvcGxlIGFy ZSBpbnZvbHZlZC4uIElNTyB0aGUgYmVzdCB3YXkgdG8gYXZvaWQgaXQgaXMgYnkgb25seSBoYXZp bmcgdGhpcyBkaXNjdXNzaW9uIG9uY2UgZXZlcnlib2R5IGlzIG9uIGJvYXJkLg0KDQoNClRoYW5r cywNCiAgICAgICAgICAgICAgICBZYXJvbg0KDQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpEYXRlOiBTdW5kYXks IEZlYnJ1YXJ5IDIsIDIwMjAgYXQgMDA6MTYNClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpDYzogPHR4YXV0aEBp ZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSB1 c2UgY2FzZSBkb2N1bWVudD8NCg0KDQpJIHdhcyB0aGlua2luZyBhIHJvdWdoIGRyYWZ0IG9mIGEg dXNlIGNhc2UgZG9jdW1lbnQgd291bGQgYXNzaXN0IGluIHRlYXNpbmcgb3V0IHdoYXQgaXMgaW4g c2NvcGUgYW5kIG5vdCBmb3IgdGhlIFdHLg0KDQoNCkkndmUgYmVlbiBhZGRpbmcgdXNlIGNhc2Vz IHRvIHRoZSBYQXV0aCBJRCB0byB0ZWFzZSBvdXQgd2hhdCB3b3VsZCBiZSBpbiBhbmQgb3V0IG9m IHNjb3BlLg0KDQoNCkl0IHdvdWxkIGFsc28gcHJvdmlkZSBjbGFyaXR5IG9uIHdoeSB0aGlzIFdH IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBPQXV0aCBXRy4NCg0KDQpPbiBTYXQsIEZlYiAxLCAyMDIw IGF0IDEwOjIwIEFNIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpJIHN1cHBvcnQgc3VjaCBhIGRvY3VtZW50 IGluIHByaW5jaXBsZS4gSSBhZ3JlZSB0aGF0IGhhdmluZyBhIGxpc3Qgb2YgdXNlIGNhc2VzIHdv dWxkIGhlbHAgdG8gc2NvcGUgdGhlIHByb3RvY29sIGRvY3VtZW50KHMpLg0KDQoNCkhvd2V2ZXIg SSB0aGluayBub3cgaXMgbm90IHRoZSByaWdodCB0aW1lLCBiZWNhdXNlIGEgdXNlIGNhc2UgZG9j dW1lbnQgaXMgb25seSB1c2VmdWwgaW4gZGVmaW5pbmcgc2NvcGUgb25jZSBpdCBpcyBtb3JlIG9y IGxlc3Mgc3RhYmxlIGFuZCBlbmpveXMgcm91Z2ggY29uc2Vuc3VzLiBXZSBjYW4gb25seSBkZW1v bnN0cmF0ZSBjb25zZW5zdXMgb25jZSB3ZSBtb3ZlIHBhc3QgdGhlIEJvRiBzdGFnZSBhbmQgaW50 byBhIFdHLiBTbyBJIGJlbGlldmUgaXQgb25seSBtYWtlcyBzZW5zZSB0byBwcm9kdWNlIHRoZSB1 c2UgY2FzZSBkb2Mgd2hlbiB3ZSBoYXZlIGEgY2hhcnRlcmVkIFdHLg0KDQoNClRoYW5rcywNCiAg ICAgICAgICAgICAgICBZYXJvbg0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sg SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLi5jb20+ Pg0KRGF0ZTogU2F0dXJkYXksIEZlYnJ1YXJ5IDEsIDIwMjAgYXQgMDA6MzgNClRvOiA8dHhhdXRo QGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1R4YXV0aF0gdXNl IGNhc2UgZG9jdW1lbnQ/DQoNCg0KQXMgSSByZWZsZWN0IG9uIG15IGNvbnZlcnNhdGlvbnMgd2l0 aCBKdXN0aW4sIGEgc2V0IG9mIHVzZSBjYXNlcyB3b3VsZCBoZWxwIGd1aWRlIHVzLiBXZSBjb3Vs ZCB0aGVuIHJlZmVyIHRvIGEgdXNlIGNhc2UgYXMgd2h5IGEgZmVhdHVyZSBpcyBwcmVzZW50IGFu ZCBzZWUgaG93IGRpZmZlcmVudCBmZWF0dXJlcyBzdXBwb3J0IChvciBkb24ndCBzdXBwb3J0KSBk aWZmZXJlbnQgdXNlIGNhc2VzLg0KDQoNCldlIGNhbiBhbHNvIHVzZSB0aGUgZG9jdW1lbnQgdG8g ZGVjaWRlIHdoaWNoIHVzZSBjYXNlcyBhcmUgaW4gc2NvcGUsIG9yIG91dCBvZiBzY29wZS4NCg0K DQpJJ2xsIHB1dCB1cCBteSBoYW5kIHRvIGVkaXQuIFdobyBpcyBpbnRlcmVzdGVkIGluIGNvbnRy aWJ1dGluZz8NCg0KDQovRGljaw0KRXJyb3IhIEZpbGVuYW1lIG5vdCBzcGVjaWZpZWQuLuGQpw0K LS0gVHhhdXRoIG1haWxpbmcgbGlzdCBUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRm Lm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8aHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdHhhdXRoJmRhdGE9MDIlN0Mw MSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDM2I2ZGI4ZWNlMjI5NDk3ODE2MzQw OGQ3YWE4N2JhMmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM3MTY1MzcyMjU4MDA3MDQxJnNkYXRhPWxRcUI5a2FHem9rNnpKOGpzaDRyZGhtb2c3U2Z0dzlK Wm5Sb215eU5qbkklM0QmcmVzZXJ2ZWQ9MD4NCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1 dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHhhdXRoPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnR4YXV0aCZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9z b2Z0LmNvbSU3QzNiNmRiOGVjZTIyOTQ5NzgxNjM0MDhkN2FhODdiYTJiJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NTM3MjI1ODAxNzA0NSZzZGF0YT1D SEJkTDNGcEpocyUyQlcwN3dMekNyQ1FFd2pGRDBEUlIxWW4yNCUyQjE0eUhSayUzRCZyZXNlcnZl ZD0wPg0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpU eGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4 YXV0aDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0eGF1dGgm ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0MzYjZkYjhlY2Uy Mjk0OTc4MTYzNDA4ZDdhYTg3YmEyYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzcxNjUzNzIyNTgwMjcwNDAmc2RhdGE9d3VMQlRYa1pmJTJCNCUyRldYNmhB bVBZZ1hZdHEyTU4lMkZ3cGI3NVJYRnhEdXlRVSUzRCZyZXNlcnZlZD0wPg0K --_000_CH2PR00MB0678119EB9927D7E2023699EF51D0CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBEaWNrIEhhcmR0ICZs dDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg RmVicnVhcnkgNSwgMjAyMCAyOjA2IFBNPGJyPg0KPGI+VG86PC9iPiBZYXJvbiBTaGVmZmVyICZs dDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBZHJpYW4gSG9wZS1C YWlsaWUgJmx0O2FkcmlhbkBob3BlYmFpbGllLmNvbSZndDs7IEp1c3RpbiBSaWNoZXIgJmx0O2py aWNoZXJAbWl0LmVkdSZndDs7IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYUBhbWF6b24u Y29tJmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0g UmU6IFtUeGF1dGhdIHVzZSBjYXNlIGRvY3VtZW50PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBwcm9wb3NlZCBhIHVzZSBjYXNlIGRvY3VtZW50IHNvIHRoYXQgdGhlcmUgaXMgYSBjb21tb24g dW5kZXJzdGFuZCBvZiB3aGF0IHRoZSBXRyBpcyB3b3JraW5nIHRvIHNvbHZlLiBJbiBteSBkaXNj dXNzaW9ucyBvbmxpbmUgd2l0aCZuYnNwO0p1c3RpbiwgaXQgaXMgY2xlYXIgdGhhdCBoZSBhbmQg SSBkb24ndCBzaGFyZSBhIGNvbW1vbiBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciB0aGlzIFdHLCBh bmQgSSBzdXNwZWN0DQogdGhhdCBpcyB0aGUgY2FzZSBmb3IgbWFueS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmlyc3QsIEkgZG9uJ3QgdGhp bmsgdGhlcmUgaXMgYSBjb21tb24gdW5kZXJzdGFuZGluZyBvZiBhbGwgdGhlIHVzZSBjYXNlcyB0 aGF0IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgYXJlIHNvbHZpbmcgdG9kYXkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY29uZCwg aW4gdGhlIGxhdGVzdCBjaGFydGVyIHdlIGhhdmUgJnF1b3Q7bmV3IHVzZSBjYXNlcyBub3QgZW5h YmxlZCBieSBPQXV0aCAyLjAuJnF1b3Q7LCB3aGljaCBpcyBzb21ld2hhdCBiYXNlZCBvbiZuYnNw O2EgbnVtYmVyIG9mIHRob3NlIHVzZSBjYXNlcyB0aGF0IHdlcmUgcHJlc2VudGVkIGluIHRoZSBC b0YgaW4gU2luZ2Fwb3JlLCBidXQgaW4gYWQgaG9jIGRpc2N1c3Npb25zLCBJIHRoaW5rIHRoZXJl IGFyZSBtYW55IHVzZSBjYXNlcw0KIHRoYXQgcGVvcGxlIGRlc2lyZSB0byBiZSBzb2x2ZWQsIGJ1 dCBhcmUgbm90IHdpZGVseSB1bmRlcnN0b29kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBteSBvcGluaW9uLCB0aGUgdXNlIGNhc2UgZG9j dW1lbnQgYWN0cyBhcyB0aGUgV0dzIHJlcXVpcmVtZW50cy4gV2l0aG91dCBpdCwgdGhlcmUgYXJl IGRpc2FncmVlbWVudHMgaW4gdGhlIElEcyBiZWNhdXNlIHBhcnRpY2lwYW50cyBhcmUgd2FudGlu ZyB0byBzb2x2ZSBkaWZmZXJlbnQgdXNlIGNhc2VzLCBidXQgdGhleSBkb24ndCBrbm93IHRoZXkg aGF2ZSBkaWZmZXJlbnQgdXNlIGNhc2VzLCBzbyB0aGUgZGlzYWdyZWVtZW50cw0KIHN1cmZhY2Ug aW4gdGhlIElELiBTb21ldGltZXMgdGhvc2UgZGlzYWdyZWVtZW50cyZuYnNwO2FyZSByZXNvbHZl ZCBpbiBhIHNpZGUgbWVldGluZywgYnV0IHRoZSBrbm93bGVkZ2UgaXMgbm90IGNhcHR1cmVkIGFu ZCB0aGUgJnF1b3Q7d2h5JnF1b3Q7IGZhZGVzIGF3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBhZHZvY2F0ZSB0aGF0IGlmIHNvbWVv bmUgaXMgd2FudGluZyBhIGZlYXR1cmUsIHRoZXJlIG5lZWRzIHRvIGEgYSB1c2UgY2FzZSB0aGUg V0cgaGFzIGFncmVlZCB0byB0aGF0IHJlcXVpcmVzIHRoZSBmZWF0dXJlLiBJZiB0aGUgdXNlIGNh c2UgaXMgbm90IGluIHRoZSB1c2UgY2FzZSBkb2N1bWVudCwgaXQgbmVlZHMgdG8gYmUgd3JpdHRl biB1cCBhbmQgYWRvcHRlZCBieSB0aGUgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoaXMgYWRkcyBzb21lIG92ZXJoZWFkIHRv IHRoZSBwcm9jZXNzLCBJIHRoaW5rIGl0IHdpbGwgYXNzaXN0IGluIGluIGFsaWdubWVudCBvbiB0 aGUgcmVzdCBvZiB0aGUgd29yayBwcm9kdWN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB3YW50IHRoaXMgV0cgdG8gYmUgUGVy bDYuID0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGltZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRp bjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNyIgc3JjPSJodHRwczovL21haWxmb29n YWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMD0mYW1w O3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9YzBlMWI0YjctOWUyNC00ZGJlLTgwNmYtOGY2Zjgw MDgwMjgwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dh ZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiA1LCAyMDIwIGF0 IDExOjU1IEFNIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBn bWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlllcywgYnV0IGl04oCZcyBvbiB1cyB0byBkZWNpZGUgYXQgd2hhdCBsZXZlbCBvZiBn cmFudWxhcml0eS4gVHlwaWNhbGx5IGEgdXNlIGNhc2UgZG9jdW1lbnQgd291bGQgZ28gZGVlcGVy IHRoYXQgd2hhdCB5b3Ugd291bGQgZXhwZWN0IGluIGEgV0cgY2hhcnRlci48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFkcmlhbiBIb3BlLUJhaWxpZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBob3BlYmFpbGllLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmFkcmlhbkBob3BlYmFpbGllLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2Rh eSwgRmVicnVhcnkgNSwgMjAyMCBhdCAwMDo0OTxicj4NCjxiPlRvOiA8L2I+WWFyb24gU2hlZmZl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5KdXN0aW4g UmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFu ayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDssIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9 PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDtSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRv OjQwYW1hem9uLmNvbUBkbWFyYy4uaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGFtYXpvbi5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86dHhhdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBp ZXRmLm9yZzwvYT4mZ3Q7LCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JdCdzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgc2NvcGUgbmVlZHMgdG8gYmUgZGVj aWRlZCBiZWZvcmUgd2UgaGF2ZSBhIFdHIChpLmUuIGRlZmluZWQgaW4gdGhlIGNoYXJ0ZXIpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwg NSBGZWIgMjAyMCBhdCAwMTowNiwgWWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlh cm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbmNlIHRoaXMgaXMgYSB3b3JraW5nIGdyb3VwLCB3ZSB3aWxsIG5lZWQg dG8gbWFrZSBkZWNpc2lvbnMgb24gc2NvcGU6IHdoYXQgZ29lcyBpbnRvIHRoZSBiYXNlIGRvY3Vt ZW50LCB3aGF0IHdlIG1pZ2h0IHdhbnQgYXMgZXh0ZW5zaW9ucywgYW5kIHdoYXQgdGhlIFdHIGRv ZXNu4oCZdCB3YW50IHRvIHdvcmsgb24NCiBpbiB0aGUgbmVhciB0ZXJtLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SWYgd2UgaGF2ZSBhIHVzZSBjYXNlIGRvY3VtZW50LCB0aGF0IHdvdWxk IGJlIHRoZSBuYXR1cmFsIHBsYWNlIHRvIGhhdmUgdGhlc2UgZGlzY3Vzc2lvbnMg4oCTIHlvdSBj bGFyaWZ5IGVhY2ggcGFydGljdWxhciB1c2UgY2FzZSBhbmQgbWFrZSBzdXJlIGV2ZXJ5Ym9keSBh Z3JlZXMgb24gd2hhdCBpdCBtZWFucywNCiBhbmQgdGhlbiB0aGUgZ3JvdXAgZGVjaWRlcyB3aGlj aCBidWNrZXQgdG8gcHV0IGl0IGluOiBiYXNlIGRvY3VtZW50LCBleHRlbnNpb24sIGRlZmVyLiBP dGhlcndpc2UgSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUgZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8g YWNoaWV2ZS4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBZYXJvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5KdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJn ZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVl c2RheSwgRmVicnVhcnkgNCwgMjAyMCBhdCAxODoxNzxicj4NCjxiPlRvOiA8L2I+TWlrZSBKb25l cyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29t PC9hPiZndDssIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Oywg JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTxhIGhy ZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWls dG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhhdXRo XSB1c2UgY2FzZSBkb2N1bWVudD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIGZpbmUgd2l0aCB1c2UgY2FzZXMgYXMgaW5wdXQg dG8gd29yaywgYnV0IHRoZXkgc2hvdWxkIGFsd2F5cyBiZSB0YWtlbiBhcyBub24tYmluZGluZyBh bmQgbm9uLW5vcm1hdGl2ZS4gSW4gb3RoZXIgd29yZHMsIHRoZXnigJlyZSBhIGdyZWF0IHdheSBm b3IgdXMgdG8gd3JpdGUgc29tZXRoaW5nIGRvd24gYW5kDQogc2F5IOKAnHllYWggdGhhdCBtYWtl cyBzZW5zZSBmb3Igc29tZXRoaW5nIGZvciB1cyB0byB3b3JrIG9u4oCdLiBCdXQgSSBkb27igJl0 IHRoaW5rIGl0IG1ha2VzIHNlbnNlIGFzIGEgd2F5IHRvIGVuZm9yY2UgZGlyZWN0aW9uIG9yIGRl Y2lzaW9uIHdpdGhpbiB0aGUgZ3JvdXAgKGllLCDigJx0aGF04oCZcyBub3QgaW4gdGhlIHVzZSBj YXNlcyBkb2N1bWVudCwgd2XigJlyZSBub3QgZ29pbmcgdG8gdGFsayBhYm91dCBpdOKAnSksIG9y IGFzIGEgZm9ybWFsIG91dHB1dCBvZg0KIHRoZSBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZWZvcmUgaWYgaXTigJlz IGFuIG9wZW5seSBhY2Nlc3NpYmxlIGFuZCBlZGl0YWJsZSBkb2N1bWVudCB0aGF0IHBlb3BsZSBj YW4gcHV0IHRoaW5ncyBpbiwgSSB0aGluayBpdOKAmXMgYSBoZWxwZnVsIHRvb2wuIFRoZSBtb21l bnQgaXQgYmVjb21lcyBidXJkZW5zb21lIHRvIHVwZGF0ZSBhbmQgY29udGludWUNCiB1c2UsIHdl IG5lZWQgdG8gcXVlc3Rpb24gd2hldGhlciB3ZSBzaG91bGQga2VlcCBkb2luZyBpdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw O+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGZWIg MywgMjAyMCwgYXQgNTowMSBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh ZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSBhZ3JlZS4gSSdk IHJhdGhlciBzZWUgdXNlIGNhc2VzIHNvb25lciB0aGFuIGxhdGVyLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0tIE1pa2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTQ0 MCIgc3R5bGU9IndpZHRoOjE1LjBpbiIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImdtYWlsLW1fLTU4MjM3OTM1OTIxNDYxMzA5MzRnbWFpbC1tXy00NDkzNzIzMDI4Mzk1NDI4OTQ4 ZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiZuYnNw O1R4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYT00 MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYT00MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO01v bmRheSwgRmVicnVhcnkgMywgMjAyMCA5OjA0OjAwIFBNPGJyPg0KPGI+VG86PC9iPiZuYnNwO0Rp Y2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs7IFlhcm9uIFNoZWZmZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55 YXJvbmYuaWV0ZkBnbWFpbC4uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1tFWFRF Uk5BTF0gUmU6IFtUeGF1dGhdIHVzZSBjYXNlIGRvY3VtZW50PzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb27igJl0IGZvbGxvdyB0aGUgbG9naWMgb2YgZGVmZXJy aW5nIHRoaXMsIHNpbmNlIHRoZSBjaGFydGVyIGRlZmluZXMgdGhlIHNjb3BlIG9mIHRoZSB3b3Jr aW5nIGdyb3VwLiBXZeKAmXJlIGFsbCBjb21wYXJpbmcgdGhlIGNoYXJ0ZXIgZHJhZnRzIGFnYWlu c3Qgb3VyIHVzZSBjYXNlcyBhbnl3YXk7IGRvaW5nDQogdGhhdCBvdXQgaW4gdGhlIG9wZW4gc2Vl bXMgbGVzcyBsaWtlbHkgdG8gbGVhZCB0byBhcmd1bWVudHMgZG93biB0aGUgcm9hZCBvdmVyIHdo ZXRoZXIgc29tZXRoaW5nIGZhbGxzIHdpdGhpbiB0aGUgc2NvcGUgbGFpZCBvdXQgaW4gdGhlIGNo YXJ0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Gb3Igd2hhdCBpdOKAmXMgd29ydGgsIEp1c3RpbiBwdXQgdGhpcyB0b2dl dGhlciBiYWNrIGluIEF1Z3VzdDombmJzcDs8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5p ZXRmLm9yZyUyRmFyY2glMkZtc2clMkZvYXV0aCUyRnY4VGRrcnVDendINDNGTUtTNTk4SUMyU2hl byZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0MzYjZk YjhlY2UyMjk0OTc4MTYzNDA4ZDdhYTg3YmEyYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjUzNzIyNTc5OTcwNTAmYW1wO3NkYXRhPTQ5VGlFY0Q3dXpM WTVGek9HdmJvM3Y2dUpxTVJCZFNqSDk5aWxvZlN3czQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL3Y4 VGRrcnVDendINDNGTUtTNTk4SUMyU2hlbzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkyZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+RnJvbTombmJzcDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UeGF1dGggJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGgtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24NCiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6Jm5ic3A7PC9iPlNhdHVyZGF5LCBGZWJydWFyeSAxLCAyMDIwIGF0IDI6MjUg UE08YnI+DQo8Yj5UbzombmJzcDs8L2I+WWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRv Onlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6Jm5ic3A7PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzp0 eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhh dXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5SZTogW1R4YXV0 aF0gdXNlIGNhc2UgZG9jdW1lbnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+V29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFNh dCwgRmViIDEsIDIwMjAgYXQgMjoyMyBQTSBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWls dG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl04oCZcyBoYXJkIHRvIOKAnHRlYXNl IG91dOKAnSB3aGF04oCZcyBpbiBzY29wZSwgYW5kIGluIHBhcnRpY3VsYXIgd2hhdOKAmXMgKjxi Pm5vdDwvYj4qIGluIHNjb3BlLCBiZWZvcmUgeW91IGhhdmUgYSBXRy4gSSBhbSB3b3JyaWVkIGFi b3V0IHNjb3BlIGNyZWVwIHdoaWNoIGlzIGxpa2VseSB0byBoYXBwZW4gb25jZSB0aGlzDQogaXMg YSBXRyBhbmQgbW9yZSBwZW9wbGUgYXJlIGludm9sdmVkLi4gSU1PIHRoZSBiZXN0IHdheSB0byBh dm9pZCBpdCBpcyBieSBvbmx5IGhhdmluZyB0aGlzIGRpc2N1c3Npb24gb25jZSBldmVyeWJvZHkg aXMgb24gYm9hcmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBZYXJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206Jm5ic3A7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6Jm5ic3A7PC9iPlN1bmRheSwgRmVicnVhcnkgMiwgMjAyMCBhdCAwMDoxNjxi cj4NCjxiPlRvOiZuYnNwOzwvYj5ZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFy b25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzombmJzcDs8L2I+Jmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6Jm5ic3A7PC9iPlJlOiBbVHhhdXRoXSB1c2UgY2FzZSBkb2N1bWVudD88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdhcyB0aGlua2luZyBhIHJv dWdoIGRyYWZ0IG9mIGEgdXNlIGNhc2UgZG9jdW1lbnQgd291bGQgYXNzaXN0IGluIHRlYXNpbmcg b3V0IHdoYXQgaXMgaW4gc2NvcGUgYW5kIG5vdCBmb3IgdGhlIFdHLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkndmUgYmVlbiBhZGRpbmcgdXNlIGNhc2VzIHRvIHRoZSBYQXV0aCBJRCB0 byB0ZWFzZSBvdXQgd2hhdCB3b3VsZCBiZSBpbiBhbmQgb3V0IG9mIHNjb3BlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgd291bGQgYWxzbyBwcm92aWRlIGNsYXJpdHkg b24gd2h5IHRoaXMgV0cgaXMgZGlmZmVyZW50IGZyb20gdGhlIE9BdXRoIFdHLiZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBGZWIgMSwgMjAy MCBhdCAxMDoyMCBBTSBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgc3VwcG9ydCBzdWNoIGEgZG9jdW1lbnQgaW4gcHJpbmNp cGxlLiBJIGFncmVlIHRoYXQgaGF2aW5nIGEgbGlzdCBvZiB1c2UgY2FzZXMgd291bGQgaGVscCB0 byBzY29wZSB0aGUgcHJvdG9jb2wgZG9jdW1lbnQocykuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVyIEkgdGhpbmsg bm93IGlzIG5vdCB0aGUgcmlnaHQgdGltZSwgYmVjYXVzZSBhIHVzZSBjYXNlIGRvY3VtZW50IGlz IG9ubHkgdXNlZnVsIGluIGRlZmluaW5nIHNjb3BlIG9uY2UgaXQgaXMgbW9yZSBvciBsZXNzIHN0 YWJsZSBhbmQgZW5qb3lzIHJvdWdoIGNvbnNlbnN1cy4gV2UgY2FuIG9ubHkgZGVtb25zdHJhdGUN CiBjb25zZW5zdXMgb25jZSB3ZSBtb3ZlIHBhc3QgdGhlIEJvRiBzdGFnZSBhbmQgaW50byBhIFdH LiBTbyBJIGJlbGlldmUgaXQgb25seSBtYWtlcyBzZW5zZSB0byBwcm9kdWNlIHRoZSB1c2UgY2Fz ZSBkb2Mgd2hlbiB3ZSBoYXZlIGEgY2hhcnRlcmVkIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOiZuYnNwOzwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlR4YXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbg0KIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBo cmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC4uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5o YXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6Jm5ic3A7PC9iPlNhdHVyZGF5LCBG ZWJydWFyeSAxLCAyMDIwIGF0IDAwOjM4PGJyPg0KPGI+VG86Jm5ic3A7PC9iPiZsdDs8YSBocmVm PSJtYWlsdG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5bVHhhdXRoXSB1c2UgY2FzZSBkb2N1 bWVudD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBJIHJl ZmxlY3Qgb24gbXkgY29udmVyc2F0aW9ucyB3aXRoIEp1c3RpbiwgYSBzZXQgb2YgdXNlIGNhc2Vz IHdvdWxkIGhlbHAgZ3VpZGUgdXMuIFdlIGNvdWxkIHRoZW4gcmVmZXIgdG8gYSB1c2UgY2FzZSBh cyB3aHkgYSBmZWF0dXJlIGlzIHByZXNlbnQgYW5kIHNlZSBob3cgZGlmZmVyZW50IGZlYXR1cmVz DQogc3VwcG9ydCAob3IgZG9uJ3Qgc3VwcG9ydCkgZGlmZmVyZW50IHVzZSBjYXNlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBjYW4gYWxzbyB1c2UgdGhlIGRvY3VtZW50IHRvIGRl Y2lkZSB3aGljaCB1c2UgY2FzZXMgYXJlIGluIHNjb3BlLCBvciBvdXQgb2Ygc2NvcGUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdsbCBwdXQgdXAgbXkgaGFuZCB0byBlZGl0LiBXaG8g aXMgaW50ZXJlc3RlZCBpbiBjb250cmlidXRpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5FcnJvciEgRmls ZW5hbWUgbm90IHNwZWNpZmllZC4uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRl Ij7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LS0gVHhhdXRoIG1haWxpbmcgbGlzdCZuYnNwOzxhIGhyZWY9Im1h aWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+ Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGdHhhdXRoJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNv bSU3QzNiNmRiOGVjZTIyOTQ5NzgxNjM0MDhkN2FhODdiYTJiJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE2NTM3MjI1ODAwNzA0MSZhbXA7c2RhdGE9bFFx QjlrYUd6b2s2eko4anNoNHJkaG1vZzdTZnR3OUpablJvbXl5TmpuSSUzRCZhbXA7cmVzZXJ2ZWQ9 MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4t LSZuYnNwOzxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhh dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnR4YXV0 aCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0MzYjZk YjhlY2UyMjk0OTc4MTYzNDA4ZDdhYTg3YmEyYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzcxNjUzNzIyNTgwMTcwNDUmYW1wO3NkYXRhPUNIQmRMM0ZwSmhz JTJCVzA3d0x6Q3JDUUV3akZEMERSUjFZbjI0JTJCMTR5SFJrJTNEJmFtcDtyZXNlcnZlZD0wIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGg8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpUeGF1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2 LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cu aWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0eGF1dGgmYW1wO2RhdGE9MDIlN0MwMSU3 Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDM2I2ZGI4ZWNlMjI5NDk3ODE2MzQwOGQ3 YWE4N2JhMmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3 MTY1MzcyMjU4MDI3MDQwJmFtcDtzZGF0YT13dUxCVFhrWmYlMkI0JTJGV1g2aEFtUFlnWFl0cTJN TiUyRndwYjc1UlhGeER1eVFVJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CH2PR00MB0678119EB9927D7E2023699EF51D0CH2PR00MB0678namp_-- From nobody Thu Feb 6 07:58:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FC61200DB for ; Thu, 6 Feb 2020 07:58:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 POm2in8H9zDZ for ; Thu, 6 Feb 2020 07:58:15 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCEB1200C7 for ; Thu, 6 Feb 2020 07:58:15 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id q8so6620643ljj.11 for ; Thu, 06 Feb 2020 07:58:15 -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=yPnIeJIkax6jKLooVdxIIcdTnzMdWNHkpM1TnHiA4iU=; b=A+PSkjQw+oMPCCLfZY1uE90wjX2bsBxCiCvk6PN4+Gw+CwIU5llGjHb1TYjx9V5spc 1TSyk2uIu1Mh+ppzx3/a4/iDf4gSlwVFNSjL+9DrNFBFxr0qYu8I+nzDTQb+nTViEhi6 ltn8WPWn8WeJMFOh2uxsiRmDGcyNrI1GqGZ+D0XDgDV6NOmEfQzcoRUco70t1JZa3ey8 YFlLfRBuK/FfLF0a8PrdaoAgDxAFFAGELloQNb9Ggze4TR5/sllnbgezPHRFo9TNBXzh v/SU2kLwxv0N8OIvC8Cjsn8t9OnBgGFpHAjoGf368FOJ9bcm2dcZG1br4a3y2XixBz0A T3KA== 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=yPnIeJIkax6jKLooVdxIIcdTnzMdWNHkpM1TnHiA4iU=; b=azJdLiUvCfsG9DyZhMqh1XCZxluX5fFGCgsDIkw3leFkiox4irhfSUvi7C7msQ0itJ cnDrv1B+IUlkAceDLlwLcTs/u4Xz7RsuWsnk1QBJgb7h3q7TqWCnARBQj/oZrRjgJFkY 3PpDrcPSpIeHo8pOHaug5fNY6+2JoDBLHEsrN9R4zKbA80lCeUKgeon6tdU4Am1BanSl CPE4/Faix+29sHSpwFQ3LaljZVm2Cw0nkfB2f+WrHy6W5Obh1emzoRXcyOTSDAb+IpUj w/+ESckPgurZAsIucoK3ZFM6FZo83MjkuGVOt3L2hmk9n6TvXC3COCCvXXT+YQ6ma2xT STjg== X-Gm-Message-State: APjAAAXNQNeaQJZkAQ7lzcI8v2dRDIj4LgHNIjoCig2r9qFqklEPKjh8 GBugI65guHloQu5GaQXo5rwsCCfnsUA5I4G5v3o= X-Google-Smtp-Source: APXvYqw8ltahfDrRZGK0Qo8gW5PEPYlEcFScx7cq+03weejMOtJRsGovJgZXAgCCZrBaMGIfL0ESOzc5n/pOct/Rg1c= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr2552621ljj.212.1581004693374; Thu, 06 Feb 2020 07:58:13 -0800 (PST) MIME-Version: 1.0 References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: From: Dick Hardt Date: Thu, 6 Feb 2020 07:57:47 -0800 Message-ID: To: Adrian Hope-Bailie Cc: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000230cb9059dea57e2" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 15:58:18 -0000 --000000000000230cb9059dea57e2 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 6, 2020 at 12:14 AM Adrian Hope-Bailie wrote: > > > My point is that following the formation of the WG I don't expect us to be > bound by the use case document but rather the charter, which, as has been > pointed out already, may be less specific. > > E.g. we may add use cases post chartering that the WG considers important > IF they fit within the scope as defined in the charter. > Agreed. Thank you for stating what I was trying to say more clearly! --000000000000230cb9059dea57e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 6, 2020 at 12:14 AM Adria= n Hope-Bailie <adrian@hopebaili= e.com> wrote:
<snip>

My point is that following the formation of the WG I don't expect u= s to be bound by the use case document but rather the charter, which, as ha= s been pointed out already, may be less specific.
E.g. we may add use cases post chartering that th= e WG considers important IF they fit within the scope as defined in the cha= rter.

Agreed. Thank you for sta= ting what I was trying to say more clearly!
=C2=A0
--000000000000230cb9059dea57e2-- From nobody Thu Feb 6 08:56:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFAB12085C for ; Thu, 6 Feb 2020 08:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 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, MALFORMED_FREEMAIL=1.122, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 f2vDzSe97JXX for ; Thu, 6 Feb 2020 08:56:02 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0: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 4F4F5120089 for ; Thu, 6 Feb 2020 08:56:02 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id q8so3403792pfh.7 for ; Thu, 06 Feb 2020 08:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=w0dZlJh7SaPIG6+9r/GF1cif9rikupqmgUzgn/YolkI=; b=P0DiFpb1nEyritttUZjHPdA+MOkpEbvmjjSjHCeh14W7Xkm6MI5QgyNsjqhlpPxQow sQLJspysc9KqZtmjqRtSPDQ4+ZmRgVDo3Nxthn6qigbcmJt7DRRSrQtWwhjrynTLPcqi lx72zfaS+p/78K1RRDlm9G/ABQuy9cMWRx6mq7EwgCqp8QZ5g+WZXUBUo092zD//9V6n tEQCY1vZufufkerRScXSbcUgtjg5h0Hi/CvnqIJil4KU/wJG5Rp7Xolzas0gH6gr5tCs PqzYzougQLrudSZfnhl0wh42DvMm1QczzZhwUfh2DNiGLkZOsyiaEapV7yXUekQ9Cua3 kvvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=w0dZlJh7SaPIG6+9r/GF1cif9rikupqmgUzgn/YolkI=; b=cBf8tuo1jrfVWQVydJQFke1rnr+LhrQ40SEt3U81ufu5ppeoGGXYxaFcQTGdDQJLq4 xUuXqjFVDI3SrsEZp+F44K6FN82GRkf74cvPffz7XYmEvN13lzNjd1zzkDRJLzqf5SYG eyiYUcjISzcePhJ3lpwf6/fXS7peJ7M+wabb2eRHT9Iubs6+5xHIPaQDMGN3fR5KCyxH Jvk2h2psc29/dH5/XqiN5eKDpSxgBGjAm9FG2PZvhJ2Ij6oZIWBoV7Al3oO6IDSQKwKD TjyTMx9ozLD4o/+NNU0HOzrNFstRcAABpDJ1iOmOk6ue+b+b+geRUAF4ipx3F7iLbcdE QW+A== X-Gm-Message-State: APjAAAUDZQ3dAYgA8rDMdufDaNcwaBTkwmBRgFW7S0AQW7U/LP1/k7wF vhbOLSEcIRMJA8IEWqVhKvs= X-Google-Smtp-Source: APXvYqxXczbd2pzL7Qze0frUWg9iUi13gDaVaEO4e4G1TTZjYB38gD3G0FbVdeMKsCAWGee6Y2Pyog== X-Received: by 2002:aa7:9f90:: with SMTP id z16mr4915521pfr.161.1581008161807; Thu, 06 Feb 2020 08:56:01 -0800 (PST) Received: from [10.106.184.76] ([167.220.56.76]) by smtp.gmail.com with ESMTPSA id g2sm4245254pgn.59.2020.02.06.08.56.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 08:56:00 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Thu, 06 Feb 2020 08:56:00 -0800 From: Yaron Sheffer To: Dick Hardt , Adrian Hope-Bailie CC: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , "txauth@ietf.org" Message-ID: Thread-Topic: [Txauth] use case document? References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3663824160_1921671388" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 16:56:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3663824160_1921671388 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I believe we all agree that we can start working on use cases for clarity now, but that the time to nail down a precise protocol scope is only after the WG has been chartered. From: Dick Hardt Date: Thursday, February 6, 2020 at 07:58 To: Adrian Hope-Bailie Cc: Justin Richer , Mike Jones , "Richard Backman, Annabelle" , Yaron Sheffer , "txauth@ietf.org" Subject: Re: [Txauth] use case document? On Thu, Feb 6, 2020 at 12:14 AM Adrian Hope-Bailie wrote: My point is that following the formation of the WG I don't expect us to be bound by the use case document but rather the charter, which, as has been pointed out already, may be less specific. E.g. we may add use cases post chartering that the WG considers important IF they fit within the scope as defined in the charter. Agreed. Thank you for stating what I was trying to say more clearly! --B_3663824160_1921671388 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I believe we all agree that we can start working o= n use cases for clarity now, but that the time to nail down a precise protoc= ol scope is only after the WG has been chartered.

 

From: Dick Hardt <dick.hardt@gmail.com>
Date: Thursday, Feb= ruary 6, 2020 at 07:58
To: Adrian Hope-Bailie <adrian@hopebaili= e.com>
Cc: Justin Richer <jricher@mit.edu>, Mike Jones &l= t;Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, "Richard Backman, A= nnabelle" <richanna=3D40amazon.com@dmarc.ietf.org>, Yaron Sheffer &= lt;yaronf.ietf@gmail.com>, "txauth@ietf.org" <txauth@ietf.or= g>
Subject: Re: [Txauth] use case document?

 

 

 <= /p>

On Thu, Feb 6, 2020 at 12:14 AM Adrian Hope-= Bailie <adrian@hopebailie.com&= gt; wrote:

<snip>

 

My point is= that following the formation of the WG I don't expect us to be bound by the= use case document but rather the charter, which, as has been pointed out al= ready, may be less specific.

 

E.g. we may add use cases po= st chartering that the WG considers important IF they fit within the scope a= s defined in the charter.

 

Agreed. Than= k you for stating what I was trying to say more clearly!

 

--B_3663824160_1921671388-- From nobody Thu Feb 6 11:43:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43593120103 for ; Thu, 6 Feb 2020 11:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuVGCv9wOTr6 for ; Thu, 6 Feb 2020 11:43:12 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 117A41200EC for ; Thu, 6 Feb 2020 11:43:11 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 016Jh6B6022048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Feb 2020 14:43:06 -0500 From: Justin Richer Message-Id: <3AD9AC7D-DD8B-42BF-B1A8-1CCC0C8E4CAF@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_6524187F-DFB6-46CB-A13F-696826531A65" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 6 Feb 2020 14:43:05 -0500 In-Reply-To: Cc: Dick Hardt , Adrian Hope-Bailie , Mike Jones , "Richard Backman, Annabelle" , "txauth@ietf.org" To: Yaron Sheffer References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 19:43:14 -0000 --Apple-Mail=_6524187F-DFB6-46CB-A13F-696826531A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 But before the WG can be chartered, we need a full WG charter. So = comments and suggestions on the charter text (on the other thread) would = still be helpful! =E2=80=94 Justin > On Feb 6, 2020, at 11:56 AM, Yaron Sheffer = wrote: >=20 > I believe we all agree that we can start working on use cases for = clarity now, but that the time to nail down a precise protocol scope is = only after the WG has been chartered. > =20 > From: Dick Hardt > Date: Thursday, February 6, 2020 at 07:58 > To: Adrian Hope-Bailie > Cc: Justin Richer , Mike Jones = , "Richard Backman, = Annabelle" , Yaron Sheffer = , "txauth@ietf.org" > Subject: Re: [Txauth] use case document? > =20 > =20 > =20 > On Thu, Feb 6, 2020 at 12:14 AM Adrian Hope-Bailie = > wrote: >> >> =20 >> My point is that following the formation of the WG I don't expect us = to be bound by the use case document but rather the charter, which, as = has been pointed out already, may be less specific. >> =20 >> E.g. we may add use cases post chartering that the WG considers = important IF they fit within the scope as defined in the charter. > =20 > Agreed. Thank you for stating what I was trying to say more clearly! --Apple-Mail=_6524187F-DFB6-46CB-A13F-696826531A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 But = before the WG can be chartered, we need a full WG charter. So comments = and suggestions on the charter text (on the other thread) would still be = helpful!

 =E2=80=94= Justin

On Feb 6, 2020, at 11:56 AM, Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

I believe = we all agree that we can start working on use cases for clarity now, but = that the time to nail down a precise protocol scope is only after the WG = has been chartered.
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thursday, February 6, = 2020 at 07:58
To: Adrian Hope-Bailie = <adrian@hopebailie.com>
Cc: Justin Richer <jricher@mit.edu>, Mike = Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, = "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>, Yaron Sheffer = <yaronf.ietf@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] use case = document?
 
 
 
On Thu, Feb 6, 2020 at = 12:14 AM Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
<snip>
 
My point is that following the = formation of the WG I don't expect us to be bound by the use case = document but rather the charter, which, as has been pointed out already, = may be less specific.
 
E.g. we may add use cases post chartering that the WG = considers important IF they fit within the scope as defined in the = charter.
 
Agreed. Thank you for stating what I was trying to say more = clearly!

= --Apple-Mail=_6524187F-DFB6-46CB-A13F-696826531A65-- From nobody Thu Feb 6 12:28:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE06120936 for ; Thu, 6 Feb 2020 12:28:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Zn2tAB4P56cC for ; Thu, 6 Feb 2020 12:28:10 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F9B1208A0 for ; Thu, 6 Feb 2020 12:28:08 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id v17so7551136ljg.4 for ; Thu, 06 Feb 2020 12:28:08 -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=IJozHhugAmQXrKHoDlmOe9pXDApCuemFl34kXXE0Mvc=; b=OF1d+QNIlKpmgST90jYYODpaQ5rh2lNd3q5AR+mggvU5SuWeg5obCK+hKZhdYhhAcj antNQ9LCgcUdNO/VQy7u6ArCusesASWEJkrpycR7rduxEivR/C85Utx2q3U1pdA72klL 345Sj6EMq8C+5qOkYJhenjheEFIGRiqrloVUs8Fo3s++fT9INVH11pO9LLFUTlZWtwat x8/RMW4ECwDjtNRSGxw6ZrKn1Xw9t1fD6UW3t3htpAoYzG2SlZYI0zwEBlyYMyIQNOzy 3kkdTa3pgf9BtSg6MCag0o3ZBRGlNKZmN/jOTP/Kw4vB6we1B9glSLBTJUr9n1JtNEDU UbVg== 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=IJozHhugAmQXrKHoDlmOe9pXDApCuemFl34kXXE0Mvc=; b=iTPznj+VQvqCy/wqGpEcoa9+O0TW3cCoNGSh/xArBL9Y59bUiWHzqZCc9aOZsi2cWy y3JFV8S/h5PMmfIv3iReQ8jFrfVFOLM93kL/0vcc5hAlua+b6fxMuKj3sF17EEBjfbf/ zzN4VhGzJgak+4hG/NhiPqdUhMr0qiC0Ga0a5dBN4h0ji/+6lqttZOVIhiCtaZo3tdtR hIvRJXzT2/8qTUhd6nCG0xa83DJn+G9qbVWSciif2vySvwUtHkm8LWBksfhAunbxlK5j 8FBbiCRAiHgxizIz4T4tVPgLpCzQWt3SU2c9tOa8QkRL2UGN3CHP8OoCxksD5u9gzxTr 3TJg== X-Gm-Message-State: APjAAAU7BzQjs8RfeDwNNwjj11DnNLlpFLYGpP4vSPk/8etymzvcK9cT YP5x/e7zUhdmpxfrYyiDwH7+yY87dxSR6Gu2dlE= X-Google-Smtp-Source: APXvYqzMxvXmvib1+5f8iQ7XRU7vpYczI65A2/Yic/hE+jFKimYCFvP9jef5lMWx8ubeoxfHXzayUjhsoM62X1AuPeo= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr3192977ljh.138.1581020886454; Thu, 06 Feb 2020 12:28:06 -0800 (PST) MIME-Version: 1.0 References: <9125637D-21F3-47C2-8BC2-07CD14B15DE1@amazon.com> <5EED5899-7A49-49C8-A18B-3F74BD703713@mit.edu> <4B471201-8D42-40BF-9FB3-CAA592C9BA0D@gmail.com> <3AD9AC7D-DD8B-42BF-B1A8-1CCC0C8E4CAF@mit.edu> In-Reply-To: <3AD9AC7D-DD8B-42BF-B1A8-1CCC0C8E4CAF@mit.edu> From: Dick Hardt Date: Thu, 6 Feb 2020 12:27:55 -0800 Message-ID: To: Justin Richer Cc: Adrian Hope-Bailie , Mike Jones , "Richard Backman, Annabelle" , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000051d4a5059dee1ccf" Archived-At: Subject: Re: [Txauth] use case document? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 20:28:15 -0000 --00000000000051d4a5059dee1ccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would you update with the latest comments and post? Unless I missed it, 3.5 was the latest. :) On Thu, Feb 6, 2020 at 11:43 AM Justin Richer wrote: > But before the WG can be chartered, we need a full WG charter. So comment= s > and suggestions on the charter text (on the other thread) would still be > helpful! > > =E2=80=94 Justin > > On Feb 6, 2020, at 11:56 AM, Yaron Sheffer wrote: > > I believe we all agree that we can start working on use cases for clarity > now, but that the time to nail down a precise protocol scope is only afte= r > the WG has been chartered. > > *From: *Dick Hardt > *Date: *Thursday, February 6, 2020 at 07:58 > *To: *Adrian Hope-Bailie > *Cc: *Justin Richer , Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org>, "Richard Backman, > Annabelle" , Yaron Sheffer < > yaronf.ietf@gmail.com>, "txauth@ietf.org" > *Subject: *Re: [Txauth] use case document? > > > > On Thu, Feb 6, 2020 at 12:14 AM Adrian Hope-Bailie > wrote: > > > > My point is that following the formation of the WG I don't expect us to b= e > bound by the use case document but rather the charter, which, as has been > pointed out already, may be less specific. > > E.g. we may add use cases post chartering that the WG considers important > IF they fit within the scope as defined in the charter. > > > Agreed. Thank you for stating what I was trying to say more clearly! > > > --00000000000051d4a5059dee1ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would you update with the latest comments and post? = Unless I missed it, 3.5 was the latest. :)

On Thu, Feb 6, 2020 = at 11:43 AM Justin Richer <jricher@mi= t.edu> wrote:
But before the WG can be= chartered, we need a full WG charter. So comments and suggestions on the c= harter text (on the other thread) would still be helpful!

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

On Feb 6,= 2020, at 11:56 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I believe we all agree that we can start worki= ng on use cases for clarity now, but that the time to nail down a precise p= rotocol scope is only after the WG has been chartered.
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
From:=C2=A0Dick Hardt <dick.hardt@gmail.com>
Dat= e:=C2=A0Thursday, February 6, 2020 at 07:58
To:=C2=A0Adrian Hope-Bailie <adrian@hopebailie.com>
Cc:=C2= =A0Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones= =3D40microsoft.com@dmarc.ietf.org>, "Richard Backman, Annabelle= " <richanna=3D40amazon.com@dmarc.ietf.org>, Yaron Sheffer &= lt;yaronf.ietf@g= mail.com>, "txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re= : [Txauth] use case document?
=C2=A0<= /div>
=C2=A0
On Thu, = Feb 6, 2020 at 12:14 AM Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
<snip>
=C2=A0
My p= oint is that following the formation of the WG I don't expect us to be = bound by the use case document but rather the charter, which, as has been p= ointed out already, may be less specific.
=C2=A0
E.g. we may add use c= ases post chartering that the WG considers important IF they fit within the= scope as defined in the charter.
=C2=A0
Agreed. Th= ank you for stating what I was trying to say more clearly!

--00000000000051d4a5059dee1ccf-- From nobody Fri Feb 7 08:58:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E512412084E for ; Fri, 7 Feb 2020 08:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 D7-8MtstE_2M for ; Fri, 7 Feb 2020 08:58:05 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7BF2612025D for ; Fri, 7 Feb 2020 08:58:05 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 017Gw3rB022091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 7 Feb 2020 11:58:04 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_41AFCFEE-8D1D-45F5-A2C1-89B05AA73F90" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 7 Feb 2020 11:58:03 -0500 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 16:58:08 -0000 --Apple-Mail=_41AFCFEE-8D1D-45F5-A2C1-89B05AA73F90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve updated the proposed charter text based on feedback and = conversation here on the list: This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. Additionally, the delegation process will allow for: - Fine-grained specification of access - Approval of AS attestation to identity claims - Approval of access to multiple resources and APIs in a single = interaction - Separation between the party authorizing access and the party = operating the client requesting access - A variety of client applications, including Web, mobile, single-page, = and interaction-constrained applications The group will define extension points for this protocol to allow for = flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of = possession=20 - User interaction mechanisms including web and non-web methods - Mechanism for conveying user, software, organization, and other pieces = of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation = process (including identity) Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Query of token rights by resource servers Although the artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back ported from TxAuth to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic = methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods.=20 The initial work will focus on using HTTP for communication between the = client and the authorization server, taking advantage of optimization = features of HTTP2 and HTTP3 where possible, and will strive to enable = simple mapping to other protocols such as COAP when doing so does not = conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures - Identity and authentication conveyance mechanisms - Guidelines for extension points We=E2=80=99ve scheduled a BoF for Vancouver, and there=E2=80=99s a = chance we can maybe get a charter approved and WG spun up in time to = have an official meeting. Either way, we=E2=80=99ll be meeting to = discuss TxAuth. =E2=80=94 Justin= --Apple-Mail=_41AFCFEE-8D1D-45F5-A2C1-89B05AA73F90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve updated the proposed charter text based on = feedback and conversation here on the list:


This group is chartered to = develop a fine-grained delegation protocol for authorization, identity, = and API access. This protocol will allow an authorizing party to = delegate access to client software through an authorization server. It = will expand upon the uses cases currently supported by OAuth 2.0 and = OpenID Connect (itself an extension of OAuth 2.0) to support = authorizations scoped as narrowly as a single transaction, provide a = clear framework for interaction among all parties involved in the = protocol flow, and remove unnecessary dependence on a browser or = user-agent for coordinating interactions. 

The delegation process will be acted = upon by multiple parties in the protocol, each performing a specific = role. The protocol will decouple the interaction channels, such as the = end user=E2=80=99s browser, from the delegation channel, which happens = directly between the client and the authorization server (in contrast = with OAuth 2.0 which is initiated by the client redirecting the user=E2=80= =99s browser). The client and AS will involve a user to make an = authorization decision as necessary through interaction mechanisms = indicated by the protocol. This decoupling avoids many of the security = concerns and technical challenges of OAuth 2.0 and provides a = non-invasive path for supporting future types of clients and interaction = channels.

Additionally, the = delegation process will allow for:

- = Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a = single interaction
- = Separation between the party authorizing access and the party operating = the client requesting access
- = A variety of client applications, including Web, mobile, single-page, = and interaction-constrained applications

The = group will define extension points for this protocol to allow for = flexibility in areas including:

- = Cryptographic agility for keys, message signatures, and proof of = possession 
- User = interaction mechanisms including web and non-web methods
- Mechanism for conveying user, software, = organization, and other pieces of information used in authorization = decisions
- Mechanisms for = presenting tokens to resource servers and binding resource requests to = tokens and associated cryptographic keys
- = Optimized inclusion of additional information through the delegation = process (including identity)

Additionally, the group will provide mechanisms for = management of the protocol lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource = servers

Although the = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.

This group is not chartered to develop = extensions to OAuth 2.0, and as such will focus on new technological = solutions not necessarily compatible with OAuth 2.0. Functionality that = builds directly on OAuth 2.0 will be developed in the OAuth Working = Group, including functionality back ported from TxAuth to OAuth = 2.0.

The group = is chartered to develop mechanisms for applying cryptographic methods, = such as JOSE and COSE, to the delegation process. This group is not = chartered to develop new cryptographic methods. 

The initial work will focus on using = HTTP for communication between the client and the authorization server, = taking advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP when doing so does not conflict with the primary = focus.

Milestones to include:
 - Core = delegation protocol
 - Key presentation = mechanism bindings to the core protocol for TLS, detached HTTP = signature, and embedded HTTP signatures
 - = Identity and authentication conveyance mechanisms
 - Guidelines for extension points




We=E2=80=99ve scheduled = a BoF for Vancouver, and there=E2=80=99s a chance we can maybe get a = charter approved and WG spun up in time to have an official meeting. = Either way, we=E2=80=99ll be meeting to discuss TxAuth.

 =E2=80=94 = Justin
= --Apple-Mail=_41AFCFEE-8D1D-45F5-A2C1-89B05AA73F90-- From nobody Fri Feb 7 19:42:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D49120044 for ; Fri, 7 Feb 2020 19:42:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KEnMOvCfCaeI for ; Fri, 7 Feb 2020 19:42:31 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 80CAE12001E for ; Fri, 7 Feb 2020 19:42:30 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id 203so661375lfa.12 for ; Fri, 07 Feb 2020 19:42: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=bWijIB2/y9um/bpc7qNbwE1Xyx6rhkRg4LFgFMAio6w=; b=UGivo5kx95u8I/DNDrxmUEm1ljWkRABD1RD+EF+e2mwUqwbLGrPDiZu1aajBWygeyb IrRvb/PXsVIZE3u4cBADz6CRemZ5vHYBy0hchky2R2Plxuxja7E9oxq8ZXYsvl07zSJN 5pnGSlFEDa+Z3wt46GgCDO9MSqVx6WMkkXxauObQADkWX+scmy8SD1JPrl7cZ1sOmlUV YwjkWGNdvCkkGXxYlU8eMXzi4fDHEs9qZUDsIJ4/Trfr3Gdmo4gh+j1YQ+qQ/sqHEk05 EjCoijJjtHhAdiWJrVGzrAZ0di9Ttkptj42jRPL9TSNdB5FUxMqDN6YCA7yO3dPPKEzj zgRA== 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=bWijIB2/y9um/bpc7qNbwE1Xyx6rhkRg4LFgFMAio6w=; b=fR/qQKqLRKVBNK3+dZFbriEmNxP5LqkZmWwDr+7RHDQT/1UOdSCSkWcsigvnujbgls NxnJsUCsN8Nmx3pNiPDcg0r4TbbsVovxed7gdaInWGxLlo/msO/fRwSPhMZKOZ9Y/nsQ tFWA9EJihpe7+PW/qtbhv2WqLCjP0Wjc7k2v8f5qA/V3xn/+6mozemfH5mvPUPGvGBlq aqW0LqnE7C9EnVufKU2iV18iXOrgDgnJrJbfEGO/sjZ3otAINC+AG2gBRqCMS6zR6QxZ LlBVe9ci4ZBC8iocc9QISC94tL6jGYehFaU9iZPLbvDW0T1A/Y7oIExBJtx6D0rGfj7W yeAA== X-Gm-Message-State: APjAAAVlG1Invh/8bskj0Ved+dtc7YcpSAnPZwV28G3gLH2I8l0dfX1W yGZ3S7R2akUZ/pba+Pa3ojv/qMeHtNoLkv08nWhOGdu0 X-Google-Smtp-Source: APXvYqynCWbpW65L7Oe8TC5OvDnGms+r8WwTSKifYGilgy+p4wSzkE2UHAEjhLzBVStEGRYn9n6qkk7S3mmjh53br2U= X-Received: by 2002:a19:7711:: with SMTP id s17mr1018929lfc.164.1581133348803; Fri, 07 Feb 2020 19:42:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 7 Feb 2020 19:42:02 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000991792059e084b61" Archived-At: Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 03:42:33 -0000 --000000000000991792059e084b61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Fri, Feb 7, 2020 at 8:58 AM Justin Richer wrote: > I=E2=80=99ve updated the proposed charter text based on feedback and conv= ersation > here on the list: > > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanism for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group > will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to t= he > new protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back ported > from TxAuth to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for extension points > > > > > We=E2=80=99ve scheduled a BoF for Vancouver, and there=E2=80=99s a chance= we can maybe get > a charter approved and WG spun up in time to have an official meeting. > Either way, we=E2=80=99ll be meeting to discuss TxAuth. > > =E2=80=94 Justin > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000991792059e084b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Fri, Feb 7, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve updated the proposed charter text based on feedb= ack and conversation here on the list:


This group is chartered to develop a fine-grained delegation protocol fo= r authorization, identity, and API access. This protocol will allow an auth= orizing party to delegate access to client software through an authorizatio= n server. It will expand upon the uses cases currently supported by OAuth 2= .0 and OpenID Connect (itself an extension of OAuth 2.0) to support authori= zations scoped as narrowly as a single transaction, provide a clear framewo= rk for interaction among all parties involved in the protocol flow, and rem= ove unnecessary dependence on a browser or user-agent for coordinating inte= ractions.=C2=A0

The delegation process will be act= ed upon by multiple parties in the protocol, each performing a specific rol= e. The protocol will decouple the interaction channels, such as the end use= r=E2=80=99s browser, from the delegation channel, which happens directly be= tween the client and the authorization server (in contrast with OAuth 2.0 w= hich is initiated by the client redirecting the user=E2=80=99s browser). Th= e client and AS will involve a user to make an authorization decision as ne= cessary through interaction mechanisms indicated by the protocol. This deco= upling avoids many of the security concerns and technical challenges of OAu= th 2.0 and provides a non-invasive path for supporting future types of clie= nts and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- App= roval of access to multiple resources and APIs in a single interaction
- Separation between the party authorizing access and the = party operating the client requesting access
- A varie= ty of client applications, including Web, mobile, single-page, and interact= ion-constrained applications

The group will define extension points for this protocol to allow for flex= ibility in areas including:

= - Cryptographic agility for keys, message signatures, and proof of possessi= on=C2=A0
- User interaction mechanisms including web a= nd non-web methods
- Mechanism for conveying user, sof= tware, organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to resour= ce servers and binding resource requests to tokens and associated cryptogra= phic keys
- Optimized inclusion of additional information through= the delegation process (including identity)

Additionally, the group will provide mechanisms for manage= ment of the protocol lifecycle including:

- Discovery of the authorization server
= - Revocation of active tokens
- Query of token rights = by resource servers

Although= the artifacts for this work are not intended or expected to be backwards-c= ompatible with OAuth 2.0 or OpenID Connect, the group will=C2=A0attempt to = simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol wh= ere possible.

This grou= p is not chartered to develop extensions to OAuth 2.0, and as such will foc= us on new technological solutions not necessarily compatible with OAuth 2.0= . Functionality that builds directly on OAuth 2.0 will be developed in the = OAuth Working Group, including functionality back ported from TxAuth to OAu= th 2.0.

The group is chartered to develop mechanis= ms for applying cryptographic methods, such as JOSE and COSE, to the delega= tion process. This group is not chartered to develop new cryptographic meth= ods.=C2=A0

The initial= work will focus on using HTTP for communication between the client and the= authorization server, taking advantage of optimization features of HTTP2 a= nd HTTP3=C2=A0where possible, and will strive to enable simple mapping to o= ther protocols such as COAP when doing so does not conflict with the primar= y focus.

Milestones to include:
=C2=A0- = Core delegation protocol
=C2=A0- Key presentation mechanism bindi= ngs to the core protocol for TLS, detached HTTP signature, and embedded HTT= P signatures
=C2=A0- Identity and authentication conveyance mecha= nisms
=C2=A0- Guidelines for extension points




We=E2=80=99ve scheduled a BoF for Vancouver, and there=E2=80=99s a chance = we can maybe get a charter approved and WG spun up in time to have an offic= ial meeting. Either way, we=E2=80=99ll be meeting to discuss TxAuth.
<= div>
=C2=A0=E2=80=94 Justin
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000991792059e084b61-- From nobody Fri Feb 7 19:49:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E0B12003F for ; Fri, 7 Feb 2020 19:49:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6hUjwzVzY8o0 for ; Fri, 7 Feb 2020 19:49:12 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 641CB12001E for ; Fri, 7 Feb 2020 19:49:11 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id l18so705682lfc.1 for ; Fri, 07 Feb 2020 19:49:11 -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=69ouybogkwwmF+7TGqq5d88etrjkFEK0jwrrQgnIWac=; b=jauE8vKPeua5q69nVHkXLw3i1kkxyvRAUnbaQHp/2FYMchVlHa1LwRpGAtra3FOZVE InAWeKozt9yJWJw6D1Wzjs+K8+7mnzmdNMWpqTMfSVBJ1bLHHC1/w5FzwfXXLnYEJnnl uo8JaEJJslw5Bazcoc5I2T5vgKuqP3DWa9cQKmwCpbCn6EOIALancoH54I5wvYM9uobH Hqd7RzX3f05GH7ZU0myQOqzKTDeN0ky3IUVVUG4eXsXDOVD7wTRSqhHSdGsazoUGebLJ XUY/aDkiRKlsGUduIvNZZQs8FZJYm3WQtybuWkuPyOIhvRLqImq/mxot+iA24u/Nadhl XVxA== 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=69ouybogkwwmF+7TGqq5d88etrjkFEK0jwrrQgnIWac=; b=r35E7gvQVU0aTHsC6i7PEWImVQraO3JxRTVb2pA3elqh9kkrkyYfFFTqzXUcHAQ/ws G/SCLTmi0IDCNj+KZneI7VxM8RWFJ6mycZ6YCfBewThz7QWYzWoicE28nRbInzy3ghyH 3fRew8qb6b69wdf7WvEnAar3BeGQLYxOmLBNMohGhZUTxLkzlU5hSVQj7Ytfsh4CeRrP wqf6q0aGyqWBIP8nyoe4A0oeCsM9g2d6VHj3AAlANq+g0L7v4TF18CbcQYSw3SIPki2/ vJ3Eat9bFDe5zAwKBnsqzwUjP5eMl9G4vOrkaRTIkpAW0bzapnOccKyg8C2o5TIUrg6H to5Q== X-Gm-Message-State: APjAAAVYGwcHu83IMEnVjXn4tzJfkzFXoO/IoyODu/f5ZndphFBP5xHK a//vQFq8A/ZAdhEylKn3Wa1oG+tffk3Ma0UbNtU= X-Google-Smtp-Source: APXvYqwOpnCaLvcNxRnBOU8rd/BcDtQ57fhEaRyy6xES1uBgFEciWzh6XboF9Wuks67GvZO0wxWQaAnN7s22CruYBsk= X-Received: by 2002:ac2:531b:: with SMTP id c27mr1022807lfh.91.1581133749342; Fri, 07 Feb 2020 19:49:09 -0800 (PST) MIME-Version: 1.0 References: <05467DBA-1B21-4F05-94EC-833C6E3FEBFB@mit.edu> <2E6A2343-3277-4090-AE7E-774158C08DB0@mit.edu> <67F6E009-99CB-4ABC-9EE9-28882D38929C@mit.edu> <013B66C6-01E6-4A38-B160-0C999F2EF274@mit.edu> In-Reply-To: <013B66C6-01E6-4A38-B160-0C999F2EF274@mit.edu> From: Dick Hardt Date: Fri, 7 Feb 2020 19:48:43 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Benjamin Kaduk , "rdd@cert.org" , Yaron Sheffer Content-Type: multipart/alternative; boundary="00000000000078d568059e0863d7" Archived-At: Subject: Re: [Txauth] XAuth - a revision of TxAuth X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 03:49:17 -0000 --00000000000078d568059e0863d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have updated XAuth to -02 based on your comments, and some new insights. =3D) Only a few questions left below ... =3D) On Sat, Feb 1, 2020 at 3:19 PM Justin Richer wrote: > > On Jan 31, 2020, at 5:28 PM, Dick Hardt wrote: > > > > So far the Client ID and the key handle look to me to be the same for > Registered Clients. What is the information referenced by a Client ID at > the AS, that would NOT be referenced by a key handle? > > > I=E2=80=99m not sure there=E2=80=99s a clean answer to that question, but= here=E2=80=99s how > things look: > > The redirect URL value (which is now able to vary within rules, as it can > in PAR), > In XAuth, the redirect URL is passed by value. It is no longer needed to identify the Client. There may be security issues related to the Client being able to specify its redirect URL, but none come to mind. > the specific display information that the client wants to use in the > context of this request (which might be locale-specific or context > specific), > If it is a Registered Client, the AS will often want to ensure the information presented to the User is correct, particularly if the transaction is sensitive. > and even the details of a rich request. All of these could be :limited: b= y > either the key handle or client ID. > > > >> I know that we don=E2=80=99t do it this way in OAuth 2, and I think that= =E2=80=99s a >> limiting decision that we=E2=80=99ve gotten incorrect. >> > > Use cases that are limited by that decision would help understand why you > think it was incorrect. > > > It limits us to a model that =E2=80=9Call clients have a single identifie= r, and > the identifier is the key to all aspects of a client=E2=80=99s policies. > Each Registered Client has a single identifier. That let's the GS have policies for that Client, and the information displayed to the User about the Client. > > Instead, I think we need to think in terms of =E2=80=9Cwhat can the prese= nter of > this key do?=E2=80=9D, especially if it=E2=80=99s a key we=E2=80=99ve nev= er seen before. This kind > of thinking allows us to move beyond a client identifier that the AS > already knows into a world where the AS can make a policy decision based = on > the authentication properties of the request. It=E2=80=99s a shift in men= tal model > that I=E2=80=99m trying to get at here. > I can see this for Dynamic Clients, but it seems problematic for a Registered Client. > > > >> >> In the mental model of XYZ, the policy is then tied to whatever software >> that key represents, and since keys aren=E2=80=99t shared between client= s, you get >> the property of a unique identification system as well. For dynamic >> clients, they don=E2=80=99t have to send an ID at all =E2=80=94 they sen= d the key itself by >> value, since the ID won=E2=80=99t reference anything that the AS knows a= bout. >> > So we have an identifier for the clients that want a stable reference, a >> method for passing values for clients that don=E2=80=99t have a stable r= eference, >> and a clear way to upgrade from passing by value to passing by reference >> for clients that want to do the equivalent of =E2=80=9CDynamic Registrat= ion=E2=80=9D. There >> are a number of deployments where DynReg is used :just: to give clients = in >> the field a client ID because OAuth 2 requires a client ID, and there=E2= =80=99s a >> key that=E2=80=99s recognized during the DynReg process. But if the serv= er can >> recognize my key, I ask: why not just start there when you do the reques= t? >> You can=E2=80=99t in OAuth 2 because of the redirect-first model and key= s don=E2=80=99t >> even show up there. You can in TxAuth because the model allows the clien= t >> to talk to the AS directly first, and present its keys. >> > > > So calling it a key handle lets you call it the same thing for both > Registered Clients and Dynamic Clients? The advantage to a Dynamic Client > is that it can present a reference instead of its public key again on > subsequent calls? Is there another advantage? > > The AS could also compute a fingerprint of the Dynamic Client key and use > that as its ephemeral identifier for the Dynamic Client. > > > If the AS chooses, it could do that, yes. But the AS might decide it > doesn=E2=80=99t need any kind of =E2=80=9Cidentifier=E2=80=9D for such an= ephemeral client. > It will want to know it is the same Client on subsequent requests won't it? > > > >> And it=E2=80=99s really important to know that handles do not need to ma= tch or be >> derived from the information that they represent. >> > > Yes. I understand what a handle is. =3D) > > >> >> No, my proposal is that a public key is what the AS uses to recognize a >> preregistered client, and that public key can be represented by a handle= . I >> would expect the handle to be stable over time, like a client ID, but mo= re >> specific. >> > > Which public key? XAuth describes how different instances of a Registere= d > Client can have their own private key, so the matching public key is > different for each Client instance. The Client can have a certificate > signed by a private key matching the public key registered for the Client > at the As. > > > So here we start to see where the OAuth2 model of what a =E2=80=9CClient= =E2=80=9D is > breaks down: instances of a client vs. a client. There is no =E2=80=9Cins= tance of a > client=E2=80=9D in XYZ, there=E2=80=99s just a client. If it=E2=80=99s go= t its own key, it=E2=80=99s its > own client, even if they=E2=80=99re running the exact same software. > I'm confused. The GS will want to have policies that apply to all instances of a Client. > > If you want to tie several pieces of software together, that should be > done at a different layer like we did with the =E2=80=9Csoftware ID=E2=80= =9D in DynReg, or > by using information associated with the public keys as you mention above= . > So I think ultimately we have the same kind of model between XYZ and XAut= h, > but using different terms and underlying imagery. > In XYZ the handle represents the instance and the transaction. It is not clear what advantage there is for separating the instance from the transaction for Registered Clients. > > > >> >> In OAuth 2, the client ID wraps together all of the different aspects of >> the client and its associated policies. In XYZ, I sought to separate tho= se >> into different handles because, as we=E2=80=99ve found in OAuth 2, diffe= rent parts >> of the client system can vary over time. Our notion of what a =E2=80=9Cc= lient=E2=80=9D is >> in OAuth 2 is also pretty vague. We have developers all over the place >> sharing client IDs between different web servers (production and >> development environments, for example), different instances of software >> (mobile applications, SPAs, and =E2=80=9Cpublic=E2=80=9D clients), and d= ifferent pieces of >> software altogether (micro-components that are tied together in a single >> pseudo-app). >> > > I don't think it is vague. The "client" is not a specific piece of > software. From the User or RS's perspective, it is the "service" that was > provided the identity claims and/or authorization. They don't want to hav= e > to re-authorize as they move between a mobile client, a desktop client, o= r > a web client for the same service. > > > Are you sure they don=E2=80=99t want to re-authorize? I would be really f= reaked > out if I installed Twitter on my phone and it knew my account information > without me telling it. > Your example is confusing authentication with authorization. If I install the the LinkedIn App on my phone, I would like it to be able to post to Twitter just as the LinkedIn web site is able to post to Twitter from a previous authorization. >> I don=E2=80=99t think it=E2=80=99s more crisp, I think it=E2=80=99s more= limiting, and it leads >> to more confusing code paths. Having implemented both styles in XYZ in >> several languages, I vastly prefer the current XYZ style. >> > > It is more crisp. And it is more limiting, and I think it leads to simple= r > code paths. > > > Again, I=E2=80=99ve implemented this, and the code paths are simpler for = XYZ. I > know this because I have written the code paths. The XAuth style is not > more crisp, just more limiting. > We disagree on this. > > > > >> >> When you have the =E2=80=9Ctype=E2=80=9D field, you then have to specify= what different >> responses mean in the context of different types, like what XAuth does i= n >> =C2=A74.2. In XYZ, the response fields have a single meaning, and the cl= ient >> does what it can with them. I think it=E2=80=99s presumptuous to assume = =E2=80=9Cqrcode=E2=80=9D as >> a scannable format, for instance. >> > > A QR Code is a scannable format by definition. > > >> Does the AS actually care how the client communicates the URL to the >> user? Not really. >> > > As I noted in XAuth, the AS does care. While a really long URL works fine > in a redirect or popup, it does not work in a QR code. The AS can return = a > short URL for the QR code that redirects to the long URL. The AS does not > want to impose the redirect latency on the redirect or popup. > > > That=E2=80=99s not really true in either the specific or the abstract. QR= codes > don=E2=80=99t have a lot of trouble scaling for rendering. > Yes they do. Speaking from building an app that used them. > And if the AS has the capability of having enough information in the shor= t > URL to redirect to a URL that it can actually use, wouldn=E2=80=99t it ju= st get the > information directly at the short URL without a redirect? > The AS has existing code that uses a really long URL. Why make them change? > Yes you could implement it as a redirect from short to long, but if you= =E2=80=99re > worried about latency, then don=E2=80=99t do that. > Latency for non-QR code use cases. I think there are lots of reasons why the AS wants to know how the User interaction will be transferred. Being explicit allows both the Client and the AS know exactly what will happen. > > >> Even if we were to optimize this for the client and have the AS return a= n >> image instead of a URL, I think the AS should be able to return an >> arbitrary image for the client to display to the user. >> > > In XAuth I asked if we wanted to allow the Client to over a webview for > the AS to load whatever it wants. > > > Again, it=E2=80=99s all about getting the user in front of the AS with a = web page. > I don=E2=80=99t agree that the AS cares much how the user gets there. > It might not be a web page. The AS may be an app on the User's phone. > > > Additionally, since we are designing all of this to be extensible, if > another use case comes up with a different interaction method, we can jus= t > add a new type. > > > And in XYZ, if there=E2=80=99s a new interaction method, you add a new fl= ag (or > object) to the interaction object to signal that. If the AS supports it, = it > can give whatever the appropriate response for that is to the client. If > the AS doesn=E2=80=99t, it can still pick another type. > > I=E2=80=99ll note here that in XYZ, you=E2=80=99ve also got the ability f= or the client to > support a legacy interaction method while a new one rolls out in parallel= . > With XAuth, you=E2=80=99ve got to make sure that it=E2=80=99s supported a= t every possible > AS the client can talk to before the client makes that switch. > The Client can query the AS. The vast majority of Clients have the AS preconfigured, so they know if the AS supports it or not. > >> Well, kind of =E2=80=94 XAuth doesn=E2=80=99t allow the combination of a= n API-specified >> element (a scope, a simple string value) and a more fine grained access >> request. >> > > I don't think you went back to reread -00. The oauth-rich type includes a > scope, and an authorizations_details. > > I made that change as it was not clear when I looked at RAR (which is > still developing) that it did not include the scope. > > > I did go back to re-read. It seems that you are re-stating what my stated > assumption was: that the RAR does not include scope internally, and that > since XAuth makes them exclusive with each other then it=E2=80=99s a choi= ce. What > am I missing? > XAuth does not make them exclusive to each other. type "oauth_scope" has a "scope" attribute type "oauth_rar" has a "scope" attribute and a "authorization_details" object > Is there something about JOSE that you think is problematic to make it th= e >> default? >> >> >> Yes, it leads to reliance on putting everything of note in the JOSE >> payload as part of the base protocol. >> > > In XAuth, I factored out all the JOSE. Once again, have you read -00, or > -01? > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-3 > > All payloads are JSON. The JOSE section describes how to use JOSE for > message and header signing. > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-8 > > > Yes, I did read; please stop assuming that I haven=E2=80=99t, which you h= ave done > several times in your replies on this thread. In fact, I have already > thanked you for refactoring, and have stated that I think that=E2=80=99s = moving in > a good direction. > > I answered a specific and direct question specific and directly. You aske= d > what the problem with JOSE as the default was, which is the question that= I > answered. I did not state that XAuth, as currently written, suffers from > these deficiencies, but that they are problematic trends the I have seen = in > many JOSE-based designs in the past. JOSE isn=E2=80=99t the problem, over= -reliance > on JOSE as the sole container for information is. > I was not precise in my question, so the answer did not match, which is why I was confused. I see we are aligned on JSON for the protocol, and JOSE being an option for Client Authentication. To clarify my question: "Is there something about JOSE that you think is problematic to make it the default *mechanism*?" > Detached signatures work, but I have found them to be problematic in > practice, which is why I chose "application/jws". There is no canonical > form for JSON, so it can get modified, and still be valid JSON, but the > signature does not match. Passing around the signature independent of the > payload is more complex. > > A JWS can be easily passed between components and is self contained, with > no worries that the JSON was modified by parsing and re-serializing it. > > > I understand and agree with the limitations of detached signatures. This > is the key brilliance of JOSE, and what I love most about it. But the > internal payload also makes it difficult to impossible to incorporate > additional information, such as headers and other bits of context that we > might want to protect. > The message body can wrap the message so that context can be included, but separated. See what I'm proposing for "jose+body" In XAuth / TxAuth, the message itself can have all the context needed -- and should. > > > >> >> In all of these cases, I do not think it is a good idea to use JWT claim= s >> in the TxAuth request or response namespaces. Where we use JOSE, we shou= ld >> avoid JWT. >> > > I agree. JWT is good for claims. Not so good messages. > > > Great. > > > >> >> I still agree that they should be able to easily use TxAuth, which just = a >> stronger argument for the signature/proofing mechanism to be a pluggable >> thing and that the request/response bodies not be JOSE objects but JSON >> objects. >> > > We discussed this in early drafts, and XAuth is JSON, with JOSE added on. > > > Yes, and this is the right way to layer it. But I also think that the > =E2=80=9Cdefault" method should use =E2=80=9Capplication/json=E2=80=9D sp= ecifically, though I could > be convinced if there=E2=80=99s a better approach. > Let's compare and contrast the approaches. I'm open to not having the default being JOSE if another approach is generally better at meeting most implementor needs. > > > >> I would rather see us have a general mechanism that allows us to get >> multiple access tokens in a way that=E2=80=99s parallel to how you get o= ne access >> token. >> > > A general mechanism sounds fine and dandy. Currently we don't have other > ways to request authorization except for oauth scopes and RAR, which is a > super set of RAR. If and when we need a more general mechanism, we could > define a new type. > > > I think instead we should define a syntactical way to say =E2=80=9CI want= multiple > kinds of things and I want them back in different access tokens=E2=80=9D.= Maybe > it=E2=80=99s as simple as a list of resource lists instead of a single li= st of > resources? But I think it=E2=80=99s cleaner to have them be more in paral= lel with > the single token request. > Good point. I made that adjustment in -02 of XAuth. > > > >> >> >> In OAuth today, the bearer token is like a movie ticket. Whoever has the >> movie ticket gets in the movie. >> Using OAuth to obtain a bearer token is like buying a movie ticket. >> >> Sometimes I want to go to more than one movie. OAuth today makes me wait >> in line to buy each ticket. Why not let me buy multiple tickets at once? >> >> >> That=E2=80=99s not true. You can get one ticket that=E2=80=99s good for = two movies, to >> borrow your metaphor. >> > > Which is all you can do in OAuth today. Get one ticket. > > >> >> The semantics of requesting multiple access tokens in parallel is >> something the working group might want to consider. I am not a fan of ho= w >> XAuth handles this, with packing things into the authorization list. I >> think it=E2=80=99s a concept we should consider though. >> > > If you have other ideas, please share them! > > > So here=E2=80=99s a terrible straw man: taking XYZ=E2=80=99s =E2=80=9Cres= ources=E2=80=9D component as the > basis, what I=E2=80=99d like to see is a way for a client to send multipl= e > =E2=80=9Cresources=E2=80=9D requests in parallel, indicating that it want= s several access > tokens. So let=E2=80=99s say the client sends: > > resources: [ > =E2=80=9Cfoo", > =E2=80=9Cbar=E2=80=9D, > { =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatman=E2=80=9D, > =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D > } > ] > > Then it means =E2=80=9CI want one access token that does all these three = things=E2=80=9D. > But if the client sends: > > resources: [ > [=E2=80=9Cfoo=E2=80=9D], > [=E2=80=9Cbar=E2=80=9D], > [{ =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatman=E2=80=9D, > =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D > }] > ] > > Then it means =E2=80=9CI want three access tokens, one for each of these = three > things=E2=80=9D. > > There=E2=80=99s a lot I hate about this syntax (like the fact that it cou= ld be > easy to smush the two together and make things really confusing), so plea= se > don=E2=80=99t tear down the specifics of the example. But the concept of = being able > to ask for one or more-than-one of the same kind of thing is what I=E2=80= =99m > after. We could use two different field names like XAuth does for the > different structures, and make them mutually exclusive, but that=E2=80=99= s got > drawbacks too. > > We could alternatively force the client to pick identifiers for its > different access tokens, like: > > resources: { > =E2=80=9Cfootoken=E2=80=9D: [=E2=80=9Cfoo=E2=80=9D], > =E2=80=9Cbartoken": [=E2=80=9Cbar=E2=80=9D], > =E2=80=9Cbatmanisnotatoken": [{ =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatma= n=E2=80=9D, > =E2=80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D > }] > } > > This means that the client wants three tokens, as above, but that it want= s > them back with specific names in the output. So you=E2=80=99d get somethi= ng like: > > access_tokens: { > =E2=80=9Cfootoken=E2=80=9D: { value: =E2=80=A6, proof: =E2=80=A6 } > =E2=80=9Cbartoken=E2=80=9D: { value: =E2=80=A6., proof: =E2=80=A6. } > =E2=80=9Cbatmanisnotatoken=E2=80=9D: { value =E2=80=A6, proof: =E2=80= =A6 } > } > > This has the downside of making the client pick values, but the upside of > having a clear way to reference which token goes with which part of the > request. This might be a complex enough use case that making the client p= ay > the complexity cost might pay off here. > I pondered the list vs the dictionary as well. I have list in -02, but personally would prefer the dictionary as it is clear what is being handed back. > > The output would need to have similar parallels, regardless of how we do > it. > x > Agreed > > > To elaborate on my metaphor. > > A family is going to the movies. The Father (one component of the family)= , > is going to purchase tickets. Billy (age 8) can pick from the G rated > movies. Sally (age 15) can pick from G, PG, and PG-13 movies, and Father > can pick anything. > > Father does not want to buy 3 tickets that are identical and can work for > any movie. (effectively what an access token is today) He only wants them > to go to a movie he has approved, at the time he has selected. > > Father wants to buy 3 different tickets, and give the appropriate ticket > to each child. > > The metaphor breaks down here, but each child needs to be able to refresh > their ticket independent of the other's, which is why a refresh handle is > required. The transaction handle is not granular enough. > > > I understand what you=E2=80=99re describing, but I question how realistic= it is. > That would require a very sophisticated client doing a very specific set = of > optimizations. Is it worth it doing that kind of optimization? > To clarify, I am describing that the Client can acquire more than one access token at a time. I mention refresh, as each access token would get refreshed independently, hence a refresh mechanism independent from the TxAuth transaction handle. I have heard of numerous people wanting multiple access tokens. There are different parts of the Client that do different things, so you want each of those to get the access token it needs. The other angle is that different resources need different access tokens, because they were built independently, but the Client needs to access both resources, so needs an access token for each. > > And it actually makes me wonder if your use case is less of a =E2=80=9Cre= fresh=E2=80=9D > and more of an =E2=80=9Ctoken exchange=E2=80=9D with some kind of augment= ation. I don=E2=80=99t > have a syntax for that defined in XYZ yet, but it=E2=80=99s in my notes a= s > something we might want to consider. It=E2=80=99s already in charter beca= use OAuth > has several mechanisms for access token exchange. > I'm confused as to how this is a refresh or token exchange example. > > >> >> Consent is not the client=E2=80=99s policy, that=E2=80=99s the AS=E2=80= =99s policy. My consent is >> stored on the AS. >> > > Maybe. Maybe not. > > > The client can=E2=80=99t know what I consented to, only what it got back = from its > request. And it=E2=80=99s certainly in no position to know what I=E2=80= =99ve consented to > if it=E2=80=99s asking me to log in, since it doesn=E2=80=99t know who I = am. > To clarify -- maybe my consent is stored at the AS. Maybe it is not. > > > >> The client can't know if this is the =E2=80=9Cfirst=E2=80=9D time or not= because it >> doesn=E2=80=99t know who I am yet, so it can=E2=80=99t ask if I should c= onsent again. If >> the client knows who I am, it doesn=E2=80=99t need to ask the AS to log = me in in >> the first place. >> > > Did you spend anytime looking at my "authentication first" proposal in -0= 1? > > > Yes. > > > The Client asks the AS to authenticate the User, and send that result, > then the Client can decide what, if anything it wants to request for that > User. The AS no longer needs to maintain state. > > >> >> However, once I=E2=80=99m interacting with the AS, the AS has a chance o= f >> figuring things out. The AS can determine if it=E2=80=99s seen the same = client >> before, if it=E2=80=99s seen the same user before, and if the same clien= t is making >> the same request for the same user, and the AS knows that it can make th= at >> decision without prompting the user. We already do exactly this today wi= th >> OAuth 2 and OIDC systems. >> > > Sometimes. Sometimes not. The specifications are mute on saving state. > > > I think you might be reading too much into =E2=80=9Csaving state=E2=80=9D= as being > something like a database write operation. I just mean that the AS needs = to > know, somehow, that it=E2=80=99s made a decision. There are a lot of ways= to pull > that off, including wrapping information about the user that the client c= an > present again. > Which instance of the Client? Client state (at the full service level) needs to be centrally stored as there may be multiple implementations of the Client. > Why not just go back to the AS and ask for the data again. If consent is > not required, the AS returns the data. If consent is required, the AS can > interact with the User to get it. > > The UserInfo endpoint seems redundant if the Client can get the claims > from the AS. > > > If the client is just going to go back to the AS with a separate call to > get profile information, why conflate it with the transaction request, > especially when doing so can lead to the privacy issues that I=E2=80=99ve= outlined? > Which privacy issues? > I=E2=80=99m not convinced the optimization is worth the risk, much in the= way that > the implicit flow was an optimization that=E2=80=99s turned out to be not= worth the > risk. > I'm not following your implication. > > I think of discovery is going to the AS and learning what it can do -- > since discovery is learning. That can be the developer going to the AS do= cs > and reading, or the Client calling a discovery API. > > After manual discovery, the developer decides how to manually configure > the Client, based on what was discovered when reading the documentation. > > I have found it useful to call out the manual discovery so that > implementors know where the information comes from. IE it is not in the > specification. > > > I would recommend not using the term =E2=80=9Cdiscovery=E2=80=9D to refer= to this, as I > believe =E2=80=9Cdiscovery=E2=80=9D is well-known* to be a programmatic p= rocess. > Changed in -02. > *Pun fully intended. :) > I got it. =3D) --00000000000078d568059e0863d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have updated XAuth to -02 based on your=C2=A0comments, and= some new insights. =3D)

Only a few questions left= below ... =3D)

On Sat, Feb 1, 2020 at 3:19 PM Justin Richer <jricher@mit.edu> wrote:

On Jan 31, 2020, at 5:28 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:
<snip>= ;=C2=A0

So far the Client ID and the key handle look t= o me to be the same for Registered Clients. What is the information referen= ced by a Client ID at the AS, that would NOT be referenced by a key handle?=

I=E2=80=99m not sure the= re=E2=80=99s a clean answer to that question, but here=E2=80=99s how things= look:

The redirect URL value (which is now able t= o vary within rules, as it can in PAR),
=
In XAuth, the redirect URL is passed by value. It is no long= er needed to identify the Client. There may be security issues related to t= he Client being able to specify its redirect URL, but none come to mind.
=C2=A0
=
the specific display information that the client wants to use in= the context of this request (which might be locale-specific or context spe= cific),

If it is a Regis= tered Client, the AS will often want to ensure the information presented to= the User is correct, particularly if the transaction is sensitive.
=C2=A0
=
and even the details of a rich request. All of these could be :limited= : by either the key handle or client ID.=C2=A0

=C2=A0
<= div>I know that we don=E2=80=99t do it this way in OAuth 2, and I think tha= t=E2=80=99s a limiting decision that we=E2=80=99ve gotten incorrect.
<= /div>

Use cases that are limited by t= hat decision would help understand why you think it was incorrect.=C2=A0

It limits us to a mod= el that =E2=80=9Call clients have a single identifier, and the identifier i= s the key to all aspects of a client=E2=80=99s policies.=C2=A0
<= /div>

Each Registered Client has a single i= dentifier. That let's the GS have policies for that Client, and the inf= ormation displayed to the User about the Client.
=C2=A0

Instead, I think we need to think in terms of =E2=80=9Cwhat can the presen= ter of this key do?=E2=80=9D, especially if it=E2=80=99s a key we=E2=80=99v= e never seen before. This kind of thinking allows us to move beyond a clien= t identifier that the AS already knows into a world where the AS can make a= policy decision based on the authentication properties of the request. It= =E2=80=99s a shift in mental model that I=E2=80=99m trying to get at here.<= /div>

I can see this for Dynami= c Clients, but it seems problematic for a Registered Client.
=C2= =A0

=C2=A0

In the mental model of XYZ, the policy = is then tied to whatever software that key represents, and since keys aren= =E2=80=99t shared between clients, you get the property of a unique identif= ication system as well. For dynamic clients, they don=E2=80=99t have to sen= d an ID at all =E2=80=94 they send the key itself by value, since the ID wo= n=E2=80=99t reference anything that the AS knows about.
So we have an identifier for the clients that want a stable reference, a m= ethod for passing values for clients that don=E2=80=99t have a stable refer= ence, and a clear way to upgrade from passing by value to passing by refere= nce for clients that want to do the equivalent of =E2=80=9CDynamic Registra= tion=E2=80=9D. There are a number of deployments where DynReg is used :just= : to give clients in the field a client ID because OAuth 2 requires a clien= t ID, and there=E2=80=99s a key that=E2=80=99s recognized during the DynReg= process. But if the server can recognize my key, I ask: why not just start= there when you do the request? You can=E2=80=99t in OAuth 2 because of the= redirect-first model and keys don=E2=80=99t even show up there. You can in= TxAuth because the model allows the client to talk to the AS directly firs= t, and present its keys.=C2=A0


So calling it a key handle lets you call it the s= ame thing for both Registered Clients and Dynamic Clients? The advantage to= a Dynamic Client is that it can present a reference instead of its public = key again on subsequent calls? Is there another advantage?

The AS could also compute a fingerprint of the Dynamic Client key = and use that as its ephemeral identifier for the Dynamic Client.

If the AS chooses, it c= ould do that, yes. But the AS might decide it doesn=E2=80=99t need any kind= of =E2=80=9Cidentifier=E2=80=9D for such an ephemeral client.=C2=A0
<= /div>

It will want to know it is the = same Client on subsequent requests won't it?
=C2=A0

=C2=A0=C2=A0
And it=E2=80=99s really important to know that handles= do not need to match or be derived from the information that they represen= t.

Yes. I understand what a han= dle is. =3D)
=C2=A0

No, my proposal is that a public k= ey is what the AS uses to recognize a preregistered client, and that public= key can be represented by a handle. I would expect the handle to be stable= over time, like a client ID, but more specific.=C2=A0

Which public key?=C2=A0 XAuth describes how d= ifferent instances of a Registered Client can have their own private key, s= o the matching public key is different for each Client instance. The Client= can have a certificate signed by a private key matching the public key reg= istered for the Client at the As.=C2=A0

So here we start to see where the OAuth2 model of what= a =E2=80=9CClient=E2=80=9D is breaks down: instances of a client vs. a cli= ent. There is no =E2=80=9Cinstance of a client=E2=80=9D in XYZ, there=E2=80= =99s just a client. If it=E2=80=99s got its own key, it=E2=80=99s its own c= lient, even if they=E2=80=99re running the exact same software.=C2=A0
=

I'm confused. The GS will = want to have policies that apply to all instances of a Client.=C2=A0
<= div>=C2=A0

If you want to tie several pieces of software together= , that should be done at a different layer like we did with the =E2=80=9Cso= ftware ID=E2=80=9D in DynReg, or by using information associated with the p= ublic keys as you mention above. So I think ultimately we have the same kin= d of model between XYZ and XAuth, but using different terms and underlying = imagery.=C2=A0

In XYZ the= handle represents the instance and the transaction. It is not clear what a= dvantage there is for separating the instance from the transaction for Regi= stered Clients.
=C2=A0

=C2=A0

In OAuth 2= , the client ID wraps together all of the different aspects of the client a= nd its associated policies. In XYZ, I sought to separate those into differe= nt handles because, as we=E2=80=99ve found in OAuth 2, different parts of t= he client system can vary over time. Our notion of what a =E2=80=9Cclient= =E2=80=9D is in OAuth 2 is also pretty vague. We have developers all over t= he place sharing client IDs between different web servers (production and d= evelopment environments, for example), different instances of software (mob= ile applications, SPAs, and =E2=80=9Cpublic=E2=80=9D clients), and differen= t pieces of software altogether (micro-components that are tied together in= a single pseudo-app).

I = don't think it is vague. The "client" is not a specific piece= of software. From the User or RS's perspective, it is the "servic= e" that was provided the identity claims and/or authorization. They do= n't want to have to re-authorize as they move between a mobile client, = a desktop client, or a web client for the same service.

Are you sure they don=E2=80=99t want t= o re-authorize? I would be really freaked out if I installed Twitter on my = phone and it knew my account information without me telling it.
=

Your example is confusing authentica= tion with authorization.

If I install the the Link= edIn App on my phone, I would like it to be able to post to Twitter just as= the LinkedIn web site is able to post to Twitter from a previous authoriza= tion.=C2=A0



I don=E2=80=99t think = it=E2=80=99s more crisp, I think it=E2=80=99s more limiting, and it leads t= o more confusing code paths. Having implemented both styles in XYZ in sever= al languages, I vastly prefer the current XYZ style.=C2=A0

It is more crisp. And it is more limiting= , and I think it leads to simpler code paths.

Again, I=E2=80=99ve implemented this, and the co= de paths are simpler for XYZ. I know this because I have written the code p= aths. The XAuth style is not more crisp, just more limiting.=C2=A0

We disagree on this.
= =C2=A0

=C2=A0

When you have the =E2= =80=9Ctype=E2=80=9D field, you then have to specify what different response= s mean in the context of different types, like what XAuth does in =C2=A74.2= . In XYZ, the response fields have a single meaning, and the client does wh= at it can with them. I think it=E2=80=99s presumptuous to assume =E2=80=9Cq= rcode=E2=80=9D as a scannable format, for instance.

A QR Code is a scannable format by definition.
=C2=A0
Does the AS actually care how the client communicates the URL to= the user? Not really.

As= I noted in XAuth, the AS does care. While a really long URL works fine in = a redirect or popup, it does not work in a QR code. The AS can return a sho= rt URL for the QR code that redirects to the long URL. The AS does not want= to impose the redirect latency on the redirect or popup.
=

That=E2=80=99s not really true in ei= ther the specific or the abstract. QR codes don=E2=80=99t have a lot of tro= uble scaling for rendering.

Yes they do. Speaking from building an app that used them.=C2=A0=C2=A0
=
And if the AS has the capability of having enough information in the = short URL to redirect to a URL that it can actually use, wouldn=E2=80=99t i= t just get the information directly at the short URL without a redirect?

The AS has existing code th= at uses a really long URL. Why make them change?
=C2=A0
Yes you could= implement it as a redirect from short to long, but if you=E2=80=99re worri= ed about latency, then don=E2=80=99t do that.

Latency for non-QR code use cases.

I think there are lots of reasons why the AS wants to know how the Us= er interaction will be transferred. Being explicit allows both the Client a= nd the AS know exactly what will happen.=C2=A0


=C2=A0
<= div>Even if we were to optimize this for the client and have the AS return = an image instead of a URL, I think the AS should be able to return an arbit= rary image for the client to display to the user.=C2=A0

In XAuth I asked if we wanted to allow the C= lient to over a webview for the AS to load whatever it wants.

Again, it=E2=80=99s all about ge= tting the user in front of the AS with a web page. I don=E2=80=99t agree th= at the AS cares much how the user gets there.

It might not be a web page. The AS may be an app on th= e User's phone.
=C2=A0


Addition= ally, since we are designing all of this to be extensible, if another use c= ase comes up with a different interaction method, we can just add a new typ= e.

And in XYZ, if t= here=E2=80=99s a new interaction method, you add a new flag (or object) to = the interaction object to signal that. If the AS supports it, it can give w= hatever the appropriate response for that is to the client. If the AS doesn= =E2=80=99t, it can still pick another type.

I=E2= =80=99ll note here that in XYZ, you=E2=80=99ve also got the ability for the= client to support a legacy interaction method while a new one rolls out in= parallel. With XAuth, you=E2=80=99ve got to make sure that it=E2=80=99s su= pported at every possible AS the client can talk to before the client makes= that switch.=C2=A0

The C= lient can query the AS.

The vast majority of Clien= ts have the AS preconfigured, so they know if the AS supports it or not.
=C2=A0
=

Well, kind of =E2=80=94 XAuth doesn=E2=80=99t all= ow the combination of an API-specified element (a scope, a simple string va= lue) and a more fine grained access request.
=

I don't think you went back to reread -00. The oaut= h-rich type includes a scope, and an authorizations_details.=C2=A0

I made that change as it was not clear when I looked at RA= R (which is still developing) that it did not include the scope.

I did go back to re-read. It = seems that you are re-stating what my stated assumption was: that the RAR d= oes not include scope internally, and that since XAuth makes them exclusive= with each other then it=E2=80=99s a choice. What am I missing?=C2=A0
=

XAuth does not make them exclu= sive to each other.

type "oauth_scope" h= as a "scope" attribute

type "oauth_= rar" has a "scope" attribute and a "authorization_detai= ls" object
=C2=A0
Is there something about JOSE that you think i= s problematic to make it the default?
<= div>
Yes, it leads to reliance on putting everything of note = in the JOSE payload as part of the base protocol.

In XAuth, I factored out all the JOSE. Once again,= have you read -00, or -01?


All payloads are JSON. The JOSE section describe= s how to use JOSE for message and header signing.


=
Yes, I did read; please stop assuming that I haven=E2=80=99t, which yo= u have done several times in your replies on this thread. In fact, I have a= lready thanked you for refactoring, and have stated that I think that=E2=80= =99s moving in a good direction.

I answered a spec= ific and direct question specific and directly. You asked what the problem = with JOSE as the default was, which is the question that I answered. I did = not state that XAuth, as currently written, suffers from these deficiencies= , but that they are problematic trends the I have seen in many JOSE-based d= esigns in the past. JOSE isn=E2=80=99t the problem, over-reliance on JOSE a= s the sole container for information is.

I was not precise in my question, so the answer did not mat= ch, which is why I was confused. I see we are aligned on JSON for the proto= col, and JOSE being an option for Client Authentication.

To clarify my question:
"Is there something about JOS= E that you think is problematic to make it the default mechanism?&qu= ot;
<= div class=3D"gmail_quote">
=C2=A0


=

Detached signatures work, but I have found them to be p= roblematic in practice, which is why I chose "application/jws". T= here is no canonical form for JSON, so it can get modified, and still be va= lid JSON, but the signature does not match. Passing around the signature in= dependent of the payload is more complex.

A JWS ca= n be easily passed between components and is self contained, with no worrie= s that the JSON was modified by parsing and re-serializing it.
<= /div>

I understand and agree with the= limitations of detached signatures. This is the key brilliance of JOSE, an= d what I love most about it. But the internal payload also makes it difficu= lt to impossible to incorporate additional information, such as headers and= other bits of context that we might want to protect.=C2=A0

The message body can wrap the message so= that context can be included, but separated. See what I'm proposing fo= r "jose+body"

In XAuth / TxAuth, the mes= sage itself can have all the context needed -- and should.
=C2=A0=

=C2=A0

In all of these cases, I do not think it i= s a good idea to use JWT claims in the TxAuth request or response namespace= s. Where we use JOSE, we should avoid JWT.

I agree. JWT is good for claims. Not so good messages.

Great.=C2=A0
=C2=A0

I still agree that they should be = able to easily use TxAuth, which just a stronger argument for the signature= /proofing mechanism to be a pluggable thing and that the request/response b= odies not be JOSE objects but JSON objects.
<= div>
We discussed this in early drafts, and XAuth is JSON, wi= th JOSE added on.

Y= es, and this is the right way to layer it. But I also think that the =E2=80= =9Cdefault" method should use =E2=80=9Capplication/json=E2=80=9D speci= fically, though I could be convinced if there=E2=80=99s a better approach.<= /div>

Let's compare and con= trast the approaches. I'm open to not having the default being JOSE if = another approach is generally better at meeting most implementor needs.
=C2=A0
<= div>

=
=C2=A0
I would rather see us have a general mechanism that allows us to get= multiple access tokens in a way that=E2=80=99s parallel to how you get one= access token.

A general = mechanism sounds fine and dandy. Currently we don't have other ways to = request authorization except for oauth scopes and RAR, which is a super set= of RAR. If and when we need a more general mechanism, we could define a ne= w type.=C2=A0

I thi= nk instead we should define a syntactical way to say =E2=80=9CI want multip= le kinds of things and I want them back in different access tokens=E2=80=9D= . Maybe it=E2=80=99s as simple as a list of resource lists instead of a sin= gle list of resources? But I think it=E2=80=99s cleaner to have them be mor= e in parallel with the single token request.=C2=A0

Good point. I made that adjustment in -02 of XAut= h.
=C2=A0
=

=C2=A0


In OAuth today,= the bearer token is like a movie ticket. Whoever has the movie ticket gets= in the movie.
Using OAuth to obtain a bearer token is like buyin= g a movie ticket.

Sometimes I want to go to more t= han one movie. OAuth today makes me wait in line to buy each ticket. Why no= t let me buy multiple tickets at once?
=

That=E2=80=99s not true. You can get one ticket that=E2= =80=99s good for two movies, to borrow your metaphor.=C2=A0

Which is all you can do in OAuth today. = Get one ticket.
=C2=A0

The semantics of requesting mult= iple access tokens in parallel is something the working group might want to= consider. I am not a fan of how XAuth handles this, with packing things in= to the authorization list. I think it=E2=80=99s a concept we should conside= r though.

If you have oth= er ideas, please share them!

<= /div>
So here=E2=80=99s a terrible straw man: taking XYZ=E2=80=99s =E2= =80=9Cresources=E2=80=9D component as the basis, what I=E2=80=99d like to s= ee is a way for a client to send multiple =E2=80=9Cresources=E2=80=9D reque= sts in parallel, indicating that it wants several access tokens. So let=E2= =80=99s say the client sends:

resources: [
=C2=A0 =C2=A0=E2=80=9Cfoo",
=C2=A0 =C2=A0=E2=80=9Cba= r=E2=80=9D,
=C2=A0 =C2=A0{ =E2=80=9Cname=E2=80=9D: =E2=80=9Cbatma= n=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cknight=E2=80=9D: =E2=80= =9Cdark=E2=80=9D
=C2=A0 =C2=A0}
]

<= /div>
Then it means =E2=80=9CI want one access token that does all thes= e three things=E2=80=9D. But if the client sends:

=
resources: [
=C2=A0 =C2=A0[=E2=80=9Cfoo=E2=80=9D],
=C2=A0 =C2=A0[=E2=80=9Cbar=E2=80=9D],
=C2=A0 =C2=A0[{ =E2=80=9Cn= ame=E2=80=9D: =E2=80=9Cbatman=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0=E2= =80=9Cknight=E2=80=9D: =E2=80=9Cdark=E2=80=9D
=C2=A0 =C2=A0}]
]

Then it means =E2=80=9CI want three= access tokens, one for each of these three things=E2=80=9D.=C2=A0

There=E2=80=99s a lot I hate about this syntax (like the f= act that it could be easy to smush the two together and make things really = confusing), so please don=E2=80=99t tear down the specifics of the example.= But the concept of being able to ask for one or more-than-one of the same = kind of thing is what I=E2=80=99m after. We could use two different field n= ames like XAuth does for the different structures, and make them mutually e= xclusive, but that=E2=80=99s got drawbacks too.=C2=A0

<= div>We could alternatively force the client to pick identifiers for its dif= ferent access tokens, like:

resources: {
=C2=A0 =C2=A0=E2=80=9Cfootoken=E2=80=9D: [=E2=80=9Cfoo=E2=80=9D],
=C2=A0 =C2=A0=E2=80=9Cbartoken": [=E2=80=9Cbar=E2=80=9D],
=
=C2=A0 =C2=A0=E2=80=9Cbatmanisnotatoken": [{ =E2=80=9Cname=E2=80= =9D: =E2=80=9Cbatman=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cknigh= t=E2=80=9D: =E2=80=9Cdark=E2=80=9D
=C2=A0 =C2=A0}]
}

This means that the client wants three tokens, as ab= ove, but that it wants them back with specific names in the output. So you= =E2=80=99d get something like:

access_tokens: {
=C2=A0 =C2=A0=E2=80=9Cfootoken=E2=80=9D: { value: =E2=80=A6, proof:= =E2=80=A6 }
=C2=A0 =C2=A0=E2=80=9Cbartoken=E2=80=9D: { value: = =E2=80=A6., proof: =E2=80=A6. }
=C2=A0 =C2=A0=E2=80=9Cbatmanisnot= atoken=E2=80=9D: { value =E2=80=A6, proof: =E2=80=A6 }
}

This has the downside of making the c= lient pick values, but the upside of having a clear way to reference which = token goes with which part of the request. This might be a complex enough u= se case that making the client pay the complexity cost might pay off here.= =C2=A0


I pondered the list vs the dictionary as well. I have list in -02, but p= ersonally would prefer the dictionary as it is clear what is being handed b= ack.
=C2=A0
Agreed
=C2=A0


To elaborate on my metaphor.

A family is going to the movies. The Father (one component of the family)= , is going to purchase tickets. Billy (age 8) can pick from the G rated mov= ies. Sally (age 15) can pick from G, PG, and PG-13 movies, and Father can p= ick anything.=C2=A0

Father does not want to buy 3 = tickets that are identical and can work for any movie. (effectively what an= access token is today) He only wants them to go to a movie he has approved= , at the time he has selected.

Father wants to buy= 3 different tickets, and give the appropriate ticket to each child.
<= div>
The metaphor breaks down here, but each child needs to b= e able to refresh their ticket independent of the other's, which is why= a refresh handle is required. The transaction handle is not granular enoug= h.

I understand wha= t you=E2=80=99re describing, but I question how realistic it is. That would= require a very sophisticated client doing a very specific set of optimizat= ions. Is it worth it doing that kind of optimization?

To clarify, I am describing that the Client ca= n acquire more than one access token at a time. I mention refresh, as each = access token would get refreshed independently, hence a refresh mechanism i= ndependent from the TxAuth transaction handle.

I h= ave heard of numerous people wanting multiple access tokens. There are diff= erent parts of the Client that do different things, so you want each of tho= se to get the access token it needs. The other angle is that different reso= urces need different access tokens, because they were built independently, = but the Client needs to access both resources, so needs an access token for= each.
=C2=A0

And it actually makes me wonder if your u= se case is less of a =E2=80=9Crefresh=E2=80=9D and more of an =E2=80=9Ctoke= n exchange=E2=80=9D with some kind of augmentation. I don=E2=80=99t have a = syntax for that defined in XYZ yet, but it=E2=80=99s in my notes as somethi= ng we might want to consider. It=E2=80=99s already in charter because OAuth= has several mechanisms for access token exchange.

I'm confused as to how this is a refresh or t= oken exchange example.
=C2=A0
=C2=A0

Consent= is not the client=E2=80=99s policy, that=E2=80=99s the AS=E2=80=99s policy= . My consent is stored on the AS.

Maybe. Maybe not.

The client can=E2=80=99t know what I consented to, only what it got= back from its request. And it=E2=80=99s certainly in no position to know w= hat I=E2=80=99ve consented to if it=E2=80=99s asking me to log in, since it= doesn=E2=80=99t know who I am.

To clarify -- maybe my consent is stored at the AS. Maybe it is not.=
=C2=A0

=C2=A0
The client can't know if this is the= =E2=80=9Cfirst=E2=80=9D time or not because it doesn=E2=80=99t know who I = am yet, so it can=E2=80=99t ask if I should consent again. If the client kn= ows who I am, it doesn=E2=80=99t need to ask the AS to log me in in the fir= st place.=C2=A0

Did you s= pend anytime looking at my "authentication first" proposal in -01= ?

Yes.


The Client asks the AS to authenticate the= User, and send that result, then the Client can decide what, if anything i= t wants to request for that User. The AS no longer needs to maintain state.=
=C2=A0

However, once I=E2=80=99m interacting with the = AS, the AS has a chance of figuring things out. The AS can determine if it= =E2=80=99s seen the same client before, if it=E2=80=99s seen the same user = before, and if the same client is making the same request for the same user= , and the AS knows that it can make that decision without prompting the use= r. We already do exactly this today with OAuth 2 and OIDC systems.=C2=A0

Sometimes. Sometimes not. T= he specifications are mute on saving state.

I think you might be reading too much into =E2=80= =9Csaving state=E2=80=9D as being something like a database write operation= . I just mean that the AS needs to know, somehow, that it=E2=80=99s made a = decision. There are a lot of ways to pull that off, including wrapping info= rmation about the user that the client can present again.
=

Which instance of the Client? Client state= (at the full service level) needs to be centrally stored as there may be m= ultiple implementations of the Client.
=C2=A0
Why not = just go back to the AS and ask for the data again. If consent is not requir= ed, the AS returns the data. If consent is required, the AS can interact wi= th the User to get it.

The UserInfo endpoint seems= redundant if the Client can get the claims from the AS.
<= /div>

If the client is just going to go bac= k to the AS with a separate call to get profile information, why conflate i= t with the transaction request, especially when doing so can lead to the pr= ivacy issues that I=E2=80=99ve outlined?

Which privacy issues?
=C2=A0
I=E2=80=99m not convince= d the optimization is worth the risk, much in the way that the implicit flo= w was an optimization that=E2=80=99s turned out to be not worth the risk.

I'm not following your= implication.
=C2=A0

I think of discovery is= going to the AS and learning what it can do -- since discovery is learning= . That can be the developer going to the AS docs and reading, or the Client= calling a discovery API.=C2=A0

After manual disco= very, the developer decides how to manually configure the Client, based on = what was discovered when reading the documentation.

I have found it useful to call out the manual discovery so that implement= ors know where the information comes from. IE it is not in the specificatio= n.


I woul= d recommend not using the term =E2=80=9Cdiscovery=E2=80=9D to refer to this= , as I believe =E2=80=9Cdiscovery=E2=80=9D is well-known* to be a programma= tic process.

Changed in -02.
=C2=A0
=C2=A0
*Pun fully intended. :)

I got it. =3D)
=C2=A0
 --00000000000078d568059e0863d7-- From nobody Fri Feb 7 19:59:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A8612003F for ; Fri, 7 Feb 2020 19:59: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3IqGwt9n2_qK for ; Fri, 7 Feb 2020 19:59:51 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 EF81612001E for ; Fri, 7 Feb 2020 19:59:50 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id z26so666893lfg.13 for ; Fri, 07 Feb 2020 19:59:50 -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=SJ6Az62OqFVIGJYATTLlZ3TuN5EVktRDbzGFR9PYcPY=; b=f01sZH+scL/rqxwyO+Dukdjm2giCDKdA4I5xDLPZKAwOMQNBD3wpKobeGhD6AwzmXY TFwz7MPKcWuuUqX3z6Ty4m6wwrM1c5Hlz+Pph+tR56eJO15kuWslVkT8ul4EOoKiVonH s8EPf6ETwM1pfg+y3hhMzV7yQ+Dp4OZ9KGuob/a2aoA9BX1Z2H7uP96HjW9mzwVey0B4 M2fV/ugiYoI2SQ5EwPYLYqc+iTWiWZPqKYulO8BAjXOKe/GG3yxfScEUJM128ptB2FRw g9ew74GMFOd1Ymgf5RmfFLdrAGopMSUBD9mDfezZ5jXaMORk3hkwLQiEN/pY8zzPQ4kl zH5Q== 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=SJ6Az62OqFVIGJYATTLlZ3TuN5EVktRDbzGFR9PYcPY=; b=Vq4fiBqEtUJ1pQk4xYwp8ltFPBy2/jYt29zwFbUbFaDbtxViVLn1ezd8TOH2KNJF97 eYRe9iPaYrWjZKzDy5J9hF3IvJKKMLNNeY9AS5UpSAxp5PMm1z72IUQ+LWAN1nXptylU d8Gd+rv67QSqVoFqYzjRGp6EWj97wKINiyxosj8gq1dD9xlaNY5VsJgQst96hfEJyFkO b7PNg5yEqBK54E+IyxEyxU/mTbc7uWflkhzkYecLkRj5V+FUI5T2NrvA1nInB1/+sVIv /zsJY93IiO5r57Vos1z9gh9foBuO6CxvREwuyLP8Iz28FYulENprMn7EKSBJdw1miXcE hG8A== X-Gm-Message-State: APjAAAWsbb6JdC6T154Z4L9R8oG7HKB/UsdPJEVspzZk1TgrtIaAuMCy UZAVd6e2PoJBn5p+sRY9q2uOS97eB2r9KxWzG9qmfnEizXs= X-Google-Smtp-Source: APXvYqwr1zBOhP2t+Jfiykn7viNuuBkNM0sOOmET6Ia/WeY0D/6E5+uCwS74iS/9qLK8F0wESMOEQ+++g+qe16YlS4c= X-Received: by 2002:a05:6512:4c6:: with SMTP id w6mr1031810lfq.157.1581134388839; Fri, 07 Feb 2020 19:59:48 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Fri, 7 Feb 2020 19:59:23 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000096c8d4059e08896d" Archived-At: Subject: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 03:59:53 -0000 --00000000000096c8d4059e08896d Content-Type: text/plain; charset="UTF-8" I've heavily revised XAuth again. https://tools.ietf.org/html/draft-hardt-xauth-protocol-02 A number of new ideas to bounce around: I have included a bunch of sequences to show different use cases possible. Rather than a transaction, I use a Grant as the central object. The interface is very RESTful. The AS is now a Grant Server (GS) This also seemed appropriate at it is both an OAuth AS, and an OIDC OP. Rather than a handle, the Grant has a URI. The endpoint URI for the GS is the GS URI, and is the GS identifier. An access token, refresh token etc. are all an Authorization. An Authorization has an AuthZ URI. The Grant URI and AuthZ URI all start with the GS URI. A Grant is created by doing a POST to the GS URI, returning a Grant URI. Metadata for the GS is done with an OPTIONS to the GS URI. The Client can do GET, UPDATE, and DELETE against a Grant URI. An access token refresh is a GET on the AuthZ URI. Adding in Reciprocal OAuth functionality was more straightforward than in OAuth 2.0 -- but not as straight forward as I would like -- but not clear how to make it better and start from the Client and GS having context of one authorization before swapping roles. Per my last emails, naming is hard, there are likely lots of mistakes, and lots of aspects that need normative language. Hopefully the concepts come through! /Dick --00000000000096c8d4059e08896d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've heavily revised XAuth again.
https://tools.ietf.org/html/draft-hardt-xauth-protocol-02

A number of new ideas to bounce around:

=
I have included a bunch of sequences to show different use cases= possible.

Rather than a transaction, I use a Gran= t as the central object.

The interface is very RES= Tful.

The AS is now a Grant Server (GS)
=
This also seemed appropriate at it is both an OAuth AS, and = an OIDC OP.

Rather than a handle, the Grant has a = URI.=C2=A0

The endpoint URI for the GS is the GS U= RI, and is the GS identifier.

An access token, ref= resh token etc. are all an Authorization. An Authorization has an AuthZ URI= .

The Grant URI and AuthZ URI all start with the G= S URI.

A Grant is created by doing a POST to the G= S URI, returning a Grant URI.

Metadata for the GS = is done with an OPTIONS to the GS URI.

The Client = can do GET, UPDATE, and DELETE against a Grant URI.

An access token refresh is a GET on the AuthZ URI.

Adding in Reciprocal OAuth functionality was more straightforward = than in OAuth 2.0 -- but not as straight forward as I would like -- but not= clear how to make it better and start from the Client and GS having contex= t of one authorization before swapping roles.

Per = my last emails, naming is hard, there are likely lots of mistakes, and lots= of aspects that need normative language. Hopefully the concepts come throu= gh!

/Dick
--00000000000096c8d4059e08896d-- From nobody Mon Feb 10 08:09:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762EF12025D for ; Mon, 10 Feb 2020 07:06:56 -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, 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=securekeytechnologies.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 LzqMkgGz-_Pi for ; Mon, 10 Feb 2020 07:06:53 -0800 (PST) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670104.outbound.protection.outlook.com [40.107.67.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771D0120273 for ; Mon, 10 Feb 2020 07:06:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CtDDFkv6Pcwh5sxnxsWwkAJ690Z/ikkF4OZFjuybL8wx9T7x/J/tuZCARYQyH+yMwRdD5LQhuXdE3Wd45Y2ETYdeZjOAN1NrFyhAndpa9RkaZHnl2oIbj1rBhDRLo3VEBcf2g557G5DcPcR6U5r5qdSmcG+F7R95QQ8J0VatJUPo42GmZ7EhUDhwetD4C+j59X4BDXTlpqxWz2e7q00ITL2qzIYGSxSuZYgFboDwyQHj8RmnddgKZHbr1BbgzBioh1DBW71DdON5WREM9YhykamLSAZHzTgGk191zUCZ538h+Rk66estFnVpGRLGm8DG9biHvkEn4Cec6ZPrvAVxxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5S5dTSsO7VZkY2wgDZJXBFVJAOmwH4NDipmrTH8A6Tw=; b=S7RB/c5T3A/rqw3xYoo2Z/rNAqkiV0hVwIb5pD1j6MVBQRDaJdANYhUpKtgX2LI5vbYKwJ2niE+KU7ZKfD3OeTjyV1Wtoaj+HByCZqS+CznAZGwZwpUJKfP0kfDnUCWsReoHR9DkQEpI/5ZlXd449a0m53XqcQlXprcRGa1j5iTI5QRnUL0DOIWY7gfJSi4NSBzeJJyojZfeVajuDQKef8gyLujKvnWtkapae2WB30dJJ8TdSOZ0amCKODWykSSC6617V2E/SgLP019+Tuibl5S+X9Ypv340DFTnyTIVmN6TKiJbTPOkQVoUFz5LvK26kG5c9kEU+DtImzmUoA/I9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekeytechnologies.onmicrosoft.com; s=selector1-securekeytechnologies-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5S5dTSsO7VZkY2wgDZJXBFVJAOmwH4NDipmrTH8A6Tw=; b=Zp7yUVYJcEiWtFOKejCqGOlxgeE2Kdeia68DCFQ2h7KiZr/8+6jK/c3gGpYKHKEL0TsEKo4rMrH3NfXx/91AvD0Lk0UBbgif5NvsYyqO5Q8dgrctZbS1MbNRx5KXKRngqTykFgxT3zghzv/2D6YM6Ww8kZo9gUkuLk5fgagt5Ys= Received: from YQXPR0101MB1703.CANPRD01.PROD.OUTLOOK.COM (52.132.80.17) by YQXPR0101MB1144.CANPRD01.PROD.OUTLOOK.COM (52.132.79.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.23; Mon, 10 Feb 2020 15:06:51 +0000 Received: from YQXPR0101MB1703.CANPRD01.PROD.OUTLOOK.COM ([fe80::a1c9:91d:7a07:a2c2]) by YQXPR0101MB1703.CANPRD01.PROD.OUTLOOK.COM ([fe80::a1c9:91d:7a07:a2c2%7]) with mapi id 15.20.2707.030; Mon, 10 Feb 2020 15:06:51 +0000 From: Mike Varley To: Justin Richer , "txauth@ietf.org" Thread-Topic: [Txauth] Updated Proposed TxAuth Charter Thread-Index: AQHV3dfKkmBYLDuwHUG0qUXbFHgR5agQp8IAgAOQLQA= Date: Mon, 10 Feb 2020 15:06:51 +0000 Message-ID: <43E8C572-943E-4BA1-91CD-D06B97AA0B52@securekey.com> 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=mike.varley@securekey.com; x-originating-ip: [38.110.71.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb8c3889-83fc-43a0-efbc-08d7ae3adb95 x-ms-traffictypediagnostic: YQXPR0101MB1144: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(376002)(346002)(366004)(136003)(396003)(39840400004)(189003)(199004)(33656002)(36756003)(186003)(8676002)(316002)(8936002)(2616005)(6486002)(2906002)(44832011)(76116006)(81166006)(66476007)(64756008)(66446008)(66556008)(81156014)(66946007)(6506007)(5660300002)(66574012)(53546011)(478600001)(6512007)(71200400001)(86362001)(110136005)(26005)(966005)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR0101MB1144; H:YQXPR0101MB1703.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: securekey.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uzZK3QpeGL6fyHj7LeSLSZFTBdZUPkgKqSBtUrQuYl9f6TBwv/OpSv/4C+ElO1nrXsQO1ylZs1lAsvFFIlYfOjW5sSWc5CvQoSJQ5mfgzPTEczbniGNiWpNvP3Wz/8S8xGpyUjZCyhby7InKnQHA/RaCpB08T6trv90Ymn6u4bX3OK8vx0CYPnEE5ig4f1Bx8qYrOmm5ftP3otpMFj3kAwfc5gx5ME47SZJeq65YLTN2Sb6x3+kP6rolB0lqImKS+gbZ5t7qwn7CFcbC9f5bQIZOPt4K+d7Oq8/GzQQ3v+HxNqDkc4vIWlxCwhit7c/OD+igm/gm9vz2vINmwiTWcq4x7k73zKALZw4Q8EMnWZh0rLi9n+Egbr7GgpptEqCA5z4tBrS5UoVHjhum6qJs5AOEwOWHR8mvxOp+gTp5Ot03Myw0u8Pknhx7OSnyYzBQbpx2j12dHfSeI/xulizGdukF10UIW6Xuv+sXxOw73yZeRJJxRNFYTFxPO7dE0FTBnpH+7UlP+311GsRa/37z7g== x-ms-exchange-antispam-messagedata: vEMaFFk166Y8ABslZEeUfD7U8W3UpHdXuL7GVBNej9gBo4FnJSWZOno6AyY4Ch+dJ6l1gZ62lNC+1tdQwa4y52vviGKFFzZOi66os8sNlCY3WRLLwurmcXtcq3fXI5ooF4i5cOT3fRNW9/L081caSA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_43E8C572943E4BA191CDD06B97AA0B52securekeycom_" MIME-Version: 1.0 X-OriginatorOrg: securekey.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb8c3889-83fc-43a0-efbc-08d7ae3adb95 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2020 15:06:51.1137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4PRQdi63F/BzyxDewEQwj8/un/LoDR+mkXbkn0IaPg+9XGo/k+mIQl+0hccaBwl/C2FaPonTFeD5M0hDfrSPKmj3GS1L4y2LFsyflKciw00= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1144 Archived-At: Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 15:06:57 -0000 --_000_43E8C572943E4BA191CDD06B97AA0B52securekeycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCldlIGFyZSByZWFsbHkgbG9va2luZyBmb3J3YXJkIHRvIHRoZSBkZXZlbG9wbWVudCBvZiB0 aGlzIHByb3RvY29sLCBhcyBpdCBoaXRzIHNvbWUga2V5IGFyZWFzIHRoYXQgb3VyIE9BdXRoIDIu MCAvIElPREMgLyBTQU1MIGJhc2VkIHNvbHV0aW9ucyBzdHJ1Z2dsZSB3aXRoLiBIYXZpbmcgYSBz dGFuZGFyZCBtZXRob2QgZm9yIGFkZHJlc3Npbmcgc2NlbmFyaW9zIGxpa2Ug4oCcYnJpbmcgeW91 ciBvd24gY2xpZW50IGFwcOKAnSBhbmQg4oCcYnJpbmcgeW91ciBvd24gSWRQc+KAnSB3aWxsIGJl IHZlcnkgdmFsdWFibGUgYW5kIFNlY3VyZUtleSBob3BlcyB0byBjb250cmlidXRlIHdoZXJlIHdl IGNhbi4NCg0KVGhhbmsteW91LA0KDQpNVg0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+ DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDcsIDIwMjAgYXQgMTA6NDIgUE0NClRvOiBKdXN0aW4g UmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpDYzogInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBVcGRhdGVkIFByb3Bvc2VkIFR4QXV0aCBD aGFydGVyDQoNCisxDQoNCk9uIEZyaSwgRmViIDcsIDIwMjAgYXQgODo1OCBBTSBKdXN0aW4gUmlj aGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KSeKA mXZlIHVwZGF0ZWQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBiYXNlZCBvbiBmZWVkYmFjayBh bmQgY29udmVyc2F0aW9uIGhlcmUgb24gdGhlIGxpc3Q6DQoNCg0KVGhpcyBncm91cCBpcyBjaGFy dGVyZWQgdG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5lZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBh dXRob3JpemF0aW9uLCBpZGVudGl0eSwgYW5kIEFQSSBhY2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2ls bCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0byBkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50 IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEl0IHdpbGwgZXhwYW5k IHVwb24gdGhlIHVzZXMgY2FzZXMgY3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLi4wIGFu ZCBPcGVuSUQgQ29ubmVjdCAoaXRzZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1 cHBvcnQgYXV0aG9yaXphdGlvbnMgc2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRyYW5z YWN0aW9uLCBwcm92aWRlIGEgY2xlYXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9uZyBh bGwgcGFydGllcyBpbnZvbHZlZCBpbiB0aGUgcHJvdG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1bm5l Y2Vzc2FyeSBkZXBlbmRlbmNlIG9uIGEgYnJvd3NlciBvciB1c2VyLWFnZW50IGZvciBjb29yZGlu YXRpbmcgaW50ZXJhY3Rpb25zLg0KDQpUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0 ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3Jt aW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVy YWN0aW9uIGNoYW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0 aGUgZGVsZWdhdGlvbiBjaGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhl IGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9B dXRoIDIuMCB3aGljaCBpcyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUg dXNlcuKAmXMgYnJvd3NlcikuIFRoZSBjbGllbnQgYW5kIEFTIHdpbGwgaW52b2x2ZSBhIHVzZXIg dG8gbWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGlu dGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4gVGhpcyBkZWNv dXBsaW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2Fs IGNoYWxsZW5nZXMgb2YgT0F1dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRo IGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBj aGFubmVscy4NCg0KQWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxs b3cgZm9yOg0KDQotIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIGFjY2Vzcw0KLSBBcHBy b3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0eSBjbGFpbXMNCi0gQXBwcm92YWwgb2Yg YWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBhbmQgQVBJcyBpbiBhIHNpbmdsZSBpbnRlcmFj dGlvbg0KLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBhcnR5IGF1dGhvcml6aW5nIGFjY2VzcyBh bmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xpZW50IHJlcXVlc3RpbmcgYWNjZXNzDQotIEEg dmFyaWV0eSBvZiBjbGllbnQgYXBwbGljYXRpb25zLCBpbmNsdWRpbmcgV2ViLCBtb2JpbGUsIHNp bmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24tY29uc3RyYWluZWQgYXBwbGljYXRpb25zDQoNClRo ZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29sIHRv IGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRpbmc6DQoNCi0gQ3J5cHRvZ3Jh cGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBw b3NzZXNzaW9uDQotIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFu ZCBub24td2ViIG1ldGhvZHMNCi0gTWVjaGFuaXNtIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdh cmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB1c2VkIGlu IGF1dGhvcml6YXRpb24gZGVjaXNpb25zDQotIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9r ZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMgdG8g dG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5cw0KLSBPcHRpbWl6ZWQgaW5j bHVzaW9uIG9mIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBw cm9jZXNzIChpbmNsdWRpbmcgaWRlbnRpdHkpDQoNCkFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdp bGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZl Y3ljbGUgaW5jbHVkaW5nOg0KDQotIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXINCi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zDQotIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0 cyBieSByZXNvdXJjZSBzZXJ2ZXJzDQoNCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMg d29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRp YmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBhdHRl bXB0IHRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5l Y3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJsZS4NCg0KVGhpcyBncm91cCBpcyBu b3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAsIGFuZCBhcyBz dWNoIHdpbGwgZm9jdXMgb24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5vdCBuZWNlc3Nh cmlseSBjb21wYXRpYmxlIHdpdGggT0F1dGggMi4wLi4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxk cyBkaXJlY3RseSBvbiBPQXV0aCAyLjAgd2lsbCBiZSBkZXZlbG9wZWQgaW4gdGhlIE9BdXRoIFdv cmtpbmcgR3JvdXAsIGluY2x1ZGluZyBmdW5jdGlvbmFsaXR5IGJhY2sgcG9ydGVkIGZyb20gVHhB dXRoIHRvIE9BdXRoIDIuMC4NCg0KVGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1l Y2hhbmlzbXMgZm9yIGFwcGx5aW5nIGNyeXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBhcyBKT1NF IGFuZCBDT1NFLCB0byB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlzIG5vdCBj aGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2RzLg0KDQpUaGUgaW5p dGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3 ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFu dGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMgb2YgSFRUUDIgYW5kIEhUVFAzIHdoZXJlIHBv c3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBsZSBtYXBwaW5nIHRvIG90aGVy IHByb3RvY29scyBzdWNoIGFzIENPQVAgd2hlbiBkb2luZyBzbyBkb2VzIG5vdCBjb25mbGljdCB3 aXRoIHRoZSBwcmltYXJ5IGZvY3VzLg0KDQpNaWxlc3RvbmVzIHRvIGluY2x1ZGU6DQogLSBDb3Jl IGRlbGVnYXRpb24gcHJvdG9jb2wNCiAtIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRp bmdzIHRvIHRoZSBjb3JlIHByb3RvY29sIGZvciBUTFMsIGRldGFjaGVkIEhUVFAgc2lnbmF0dXJl LCBhbmQgZW1iZWRkZWQgSFRUUCBzaWduYXR1cmVzDQogLSBJZGVudGl0eSBhbmQgYXV0aGVudGlj YXRpb24gY29udmV5YW5jZSBtZWNoYW5pc21zDQogLSBHdWlkZWxpbmVzIGZvciBleHRlbnNpb24g cG9pbnRzDQoNCg0KDQoNCldl4oCZdmUgc2NoZWR1bGVkIGEgQm9GIGZvciBWYW5jb3V2ZXIsIGFu ZCB0aGVyZeKAmXMgYSBjaGFuY2Ugd2UgY2FuIG1heWJlIGdldCBhIGNoYXJ0ZXIgYXBwcm92ZWQg YW5kIFdHIHNwdW4gdXAgaW4gdGltZSB0byBoYXZlIGFuIG9mZmljaWFsIG1lZXRpbmcuIEVpdGhl ciB3YXksIHdl4oCZbGwgYmUgbWVldGluZyB0byBkaXNjdXNzIFR4QXV0aC4NCg0KIOKAlCBKdXN0 aW4NCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRo DQoNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50cyBhbmQgbWF5IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCBvciBvdGhlcndpc2UgZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBsYXcuIEFueSBk aXN0cmlidXRpb24sIHByaW50aW5nIG9yIG90aGVyIHVzZSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMuDQo= --_000_43E8C572943E4BA191CDD06B97AA0B52securekeycom_ Content-Type: text/html; charset="utf-8" Content-ID: <6A93B8FD72DAAD418369D6961D5E916E@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0Ei IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2UgYXJlIHJlYWxseSBsb29raW5nIGZvcndhcmQgdG8gdGhlIGRldmVsb3BtZW50 IG9mIHRoaXMgcHJvdG9jb2wsIGFzIGl0IGhpdHMgc29tZSBrZXkgYXJlYXMgdGhhdCBvdXIgT0F1 dGggMi4wIC8gSU9EQyAvIFNBTUwgYmFzZWQgc29sdXRpb25zIHN0cnVnZ2xlIHdpdGguIEhhdmlu ZyBhIHN0YW5kYXJkIG1ldGhvZCBmb3IgYWRkcmVzc2luZyBzY2VuYXJpb3MgbGlrZSDigJxicmlu ZyB5b3VyIG93biBjbGllbnQgYXBw4oCdDQogYW5kIOKAnGJyaW5nIHlvdXIgb3duIElkUHPigJ0g d2lsbCBiZSB2ZXJ5IHZhbHVhYmxlIGFuZCBTZWN1cmVLZXkgaG9wZXMgdG8gY29udHJpYnV0ZSB3 aGVyZSB3ZSBjYW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rLXlvdSw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TVYgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VHhhdXRoICZsdDt0 eGF1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgJmx0O2Rp Y2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5 IDcsIDIwMjAgYXQgMTA6NDIgUE08YnI+DQo8Yj5UbzogPC9iPkp1c3RpbiBSaWNoZXIgJmx0O2py aWNoZXJAbWl0LmVkdSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZx dW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4 YXV0aF0gVXBkYXRlZCBQcm9wb3NlZCBUeEF1dGggQ2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+JiM0MzsxPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGcmksIEZlYiA3LCAyMDIwIGF0IDg6 NTggQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+ anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+SeKAmXZlIHVwZGF0ZWQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBiYXNlZCBv biBmZWVkYmFjayBhbmQgY29udmVyc2F0aW9uIGhlcmUgb24gdGhlIGxpc3Q6DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBh IGZpbmUtZ3JhaW5lZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBhdXRob3JpemF0aW9uLCBpZGVu dGl0eSwgYW5kIEFQSSBhY2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2lsbCBhbGxvdyBhbiBhdXRob3Jp emluZyBwYXJ0eSB0byBkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2gg YW4NCiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNlcyBj YXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuLjAgYW5kIE9wZW5JRCBDb25uZWN0 IChpdHNlbGYgYW4gZXh0ZW5zaW9uIG9mIE9BdXRoIDIuMCkgdG8gc3VwcG9ydCBhdXRob3JpemF0 aW9ucyBzY29wZWQgYXMgbmFycm93bHkgYXMgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHByb3ZpZGUg YSBjbGVhciBmcmFtZXdvcmsgZm9yIGludGVyYWN0aW9uDQogYW1vbmcgYWxsIHBhcnRpZXMgaW52 b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3NhcnkgZGVwZW5k ZW5jZSBvbiBhIGJyb3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0 aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVsdGlw bGUgcGFydGllcyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmljIHJv bGUuIFRoZSBwcm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVscywg c3VjaCBhcyB0aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24NCiBj aGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9BdXRoIDIuMCB3aGljaCBp cyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3Nl cikuIFRoZSBjbGllbnQgYW5kIEFTIHdpbGwgaW52b2x2ZSBhIHVzZXIgdG8gbWFrZSBhbiBhdXRo b3JpemF0aW9uIGRlY2lzaW9uIGFzIG5lY2Vzc2FyeQ0KIHRocm91Z2ggaW50ZXJhY3Rpb24gbWVj aGFuaXNtcyBpbmRpY2F0ZWQgYnkgdGhlIHByb3RvY29sLiBUaGlzIGRlY291cGxpbmcgYXZvaWRz IG1hbnkgb2YgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwgY2hhbGxlbmdlcyBv ZiBPQXV0aCAyLjAgYW5kIHByb3ZpZGVzIGEgbm9uLWludmFzaXZlIHBhdGggZm9yIHN1cHBvcnRp bmcgZnV0dXJlIHR5cGVzIG9mIGNsaWVudHMgYW5kIGludGVyYWN0aW9uIGNoYW5uZWxzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5BZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mg d2lsbCBhbGxvdyBmb3I6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gRmluZS1ncmFpbmVkIHNw ZWNpZmljYXRpb24gb2YgYWNjZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tIEFwcHJvdmFsIG9mIEFTIGF0dGVzdGF0aW9uIHRvIGlkZW50aXR5IGNsYWltczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+LSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2Vz IGFuZCBBUElzIGluIGEgc2luZ2xlIGludGVyYWN0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4tIFNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcGFydHkgYXV0aG9yaXppbmcg YWNjZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZSBjbGllbnQgcmVxdWVzdGluZyBhY2Nl c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gQSB2YXJpZXR5IG9mIGNs aWVudCBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFu ZCBpbnRlcmFjdGlvbi1jb25zdHJhaW5lZCBhcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJv dG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+LSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3Nh Z2Ugc2lnbmF0dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGlu Y2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+LSBNZWNoYW5pc20gZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3Jn YW5pemF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9y aXphdGlvbiBkZWNpc2lvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0g TWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVycyBhbmQg YmluZGluZyByZXNvdXJjZSByZXF1ZXN0cyB0byB0b2tlbnMgYW5kIGFzc29jaWF0ZWQgY3J5cHRv Z3JhcGhpYyBrZXlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIE9wdGltaXplZCBpbmNsdXNpb24g b2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdoIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mg KGluY2x1ZGluZyBpZGVudGl0eSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWRkaXRpb25hbGx5 LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhl IHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0g RGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+LSBSZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbnM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gUXVlcnkgb2YgdG9rZW4gcmlnaHRzIGJ5IHJl c291cmNlIHNlcnZlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWx0aG91Z2ggdGhlIGFydGlm YWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFj a3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZSBn cm91cCB3aWxsJm5ic3A7YXR0ZW1wdCB0byBzaW1wbGlmeSBtaWdyYXRpbmcgZnJvbSBPQXV0aCAy LjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvDQogdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJs ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0 ZXJlZCB0byBkZXZlbG9wIGV4dGVuc2lvbnMgdG8gT0F1dGggMi4wLCBhbmQgYXMgc3VjaCB3aWxs IGZvY3VzIG9uIG5ldyB0ZWNobm9sb2dpY2FsIHNvbHV0aW9ucyBub3QgbmVjZXNzYXJpbHkgY29t cGF0aWJsZSB3aXRoIE9BdXRoIDIuMC4uIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0 bHkgb24gT0F1dGggMi4wDQogd2lsbCBiZSBkZXZlbG9wZWQgaW4gdGhlIE9BdXRoIFdvcmtpbmcg R3JvdXAsIGluY2x1ZGluZyBmdW5jdGlvbmFsaXR5IGJhY2sgcG9ydGVkIGZyb20gVHhBdXRoIHRv IE9BdXRoIDIuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGFw cGx5aW5nIGNyeXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBhcyBKT1NFIGFuZCBDT1NFLCB0byB0 aGUgZGVsZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2 ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2RzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRo ZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1cyBvbiB1c2luZyBIVFRQIGZvciBjb21tdW5pY2F0aW9u IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0YWtpbmcg YWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBIVFRQMiBhbmQgSFRUUDMmbmJz cDt3aGVyZSBwb3NzaWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJsZQ0KIHNpbXBsZSBtYXBw aW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVAgd2hlbiBkb2luZyBzbyBkb2VzIG5v dCBjb25mbGljdCB3aXRoIHRoZSBwcmltYXJ5IGZvY3VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5NaWxlc3RvbmVzIHRvIGluY2x1ZGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDstIENvcmUgZGVsZWdhdGlvbiBwcm90b2NvbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7LSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5n cyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwg YW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 LSBJZGVudGl0eSBhbmQgYXV0aGVudGljYXRpb24gY29udmV5YW5jZSBtZWNoYW5pc21zPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDstIEd1aWRlbGluZXMgZm9yIGV4dGVuc2lvbiBwb2ludHM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldl 4oCZdmUgc2NoZWR1bGVkIGEgQm9GIGZvciBWYW5jb3V2ZXIsIGFuZCB0aGVyZeKAmXMgYSBjaGFu Y2Ugd2UgY2FuIG1heWJlIGdldCBhIGNoYXJ0ZXIgYXBwcm92ZWQgYW5kIFdHIHNwdW4gdXAgaW4g dGltZSB0byBoYXZlIGFuIG9mZmljaWFsIG1lZXRpbmcuIEVpdGhlciB3YXksIHdl4oCZbGwgYmUg bWVldGluZyB0byBkaXNjdXNzIFR4QXV0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPi0tIDxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhh dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGlkPSJib2R5IiBzdHlsZT0iZm9udC1zaXplOjcuNXB0OyBjb2xvcjpkYXJrZ3JheTsgbGlu ZS1oZWlnaHQ6MTBwdDsgZm9udC1mYW1pbHk6ICdBcmlhbCcsJ3RpbWVzIHJvbWFuJyxzZXJpZjsi Pg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnRzIGFuZCBtYXkgYmUgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsIG9yIG90aGVyd2lzZSBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIGxhdy4gQW55IGRp c3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3Igb3RoZXIgdXNlIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4NCiBJZiB5b3UgYXJlIG5vdCBhbiBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHks IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzLjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_43E8C572943E4BA191CDD06B97AA0B52securekeycom_-- From nobody Mon Feb 10 09:25:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7645120077 for ; Sun, 9 Feb 2020 23:10:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coil.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYFRcTQNKbzc for ; Sun, 9 Feb 2020 23:10:47 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 5A99112008D for ; Sun, 9 Feb 2020 23:10:47 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id r18so7480621edl.1 for ; Sun, 09 Feb 2020 23:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NdZsnrdDsrrmDPFVXcoeRBpLqh151TGuf8AMoROTaU8=; b=QLY7JlIWpk3y+RLSfo2AzNVLwQWEVRXJm3mUMSfopusxJU/en7TEfkgAJJkaEyACvQ lnHhTKpzGGJmAOpaSqQQqUtr3WW6bA+hAzg3kUeSJh3w/0VGbWMNr2Bx0ggZc1MEftDD NWslr/TxixfRTPPhp4gtc18aYfm1BkdsHaBjRT3bmM6OJxaKPFsfpiKCnjEc2Fy5JVPi 0A5UVUcnWOlFOrATsgHpF/vbht6QLy35LkU9hZSTxSqgOF/BtJ/VL+aOMbD04KC/PhsQ +dEfv29nL/mbMfwHx+TFLd/VurzI4jjE9mfRM72KpZ7zq9TZZiFaBe0DMUVjWstob/+y mo+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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NdZsnrdDsrrmDPFVXcoeRBpLqh151TGuf8AMoROTaU8=; b=IHNccBCuWd8ouSC28KPoJ0ac6ltYbfV2fnEPorx6+wB/7ueV0Lz8hMmD0TCEjyBfN/ 8sOZgm20aUPGWqoZDaAxRh5a1RjVVBsMavztWe/k983030a1qBZDbEESkzR3SGbnIZdj g6CVwcwFeBYNLtwktB3/TH0Bz8trlrPZGmtTka248jPDlJ1Fu4dim8Yc+qaGVPhYSRcC 1+wlUq2h0SGL1q9NyxlZQxJJUaGa6pqhkRDdHIzyjAFODIFbwtZsOfP7trIBJ/K9Q006 Tjk5OFtiugZcuDnl0WYihUyHGHfBTCMv8WnKcN26nLaJ7gYnCPCvcGgmoVvtYUYNIktI qJ4A== X-Gm-Message-State: APjAAAUlqVb0LOxDXyPYtnH3rqrApgI2iYDgv3LwOOpt0k6R3xH7LOHN 0qjrDf5venDqLOAalSUFsM99jnFFX7FpezqVfqfg/Q== X-Google-Smtp-Source: APXvYqyvg+c4hQ7pZg7uusimIockAOtcmUGoeSmFLrOIv0gN8bwcNGib0m6Vgr6p9Go/7ANexcdSvKZMdlc9oUPaOq4= X-Received: by 2002:a50:f318:: with SMTP id p24mr5898edm.237.1581318645803; Sun, 09 Feb 2020 23:10:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Matthew De Haast Date: Mon, 10 Feb 2020 09:10:34 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002902a0059e337065" Archived-At: X-Mailman-Approved-At: Mon, 10 Feb 2020 09:25:23 -0800 Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 07:10:50 -0000 --0000000000002902a0059e337065 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable + 1 On Sat, Feb 8, 2020 at 5:42 AM Dick Hardt wrote: > +1 > > On Fri, Feb 7, 2020 at 8:58 AM Justin Richer wrote: > >> I=E2=80=99ve updated the proposed charter text based on feedback and con= versation >> here on the list: >> >> >> This group is chartered to develop a fine-grained delegation protocol fo= r >> authorization, identity, and API access. This protocol will allow an >> authorizing party to delegate access to client software through an >> authorization server. It will expand upon the uses cases currently >> supported by OAuth 2..0 and OpenID Connect (itself an extension of OAuth >> 2.0) to support authorizations scoped as narrowly as a single transactio= n, >> provide a clear framework for interaction among all parties involved in = the >> protocol flow, and remove unnecessary dependence on a browser or user-ag= ent >> for coordinating interactions. >> >> The delegation process will be acted upon by multiple parties in the >> protocol, each performing a specific role. The protocol will decouple th= e >> interaction channels, such as the end user=E2=80=99s browser, from the d= elegation >> channel, which happens directly between the client and the authorization >> server (in contrast with OAuth 2.0 which is initiated by the client >> redirecting the user=E2=80=99s browser). The client and AS will involve = a user to >> make an authorization decision as necessary through interaction mechanis= ms >> indicated by the protocol. This decoupling avoids many of the security >> concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve >> path for supporting future types of clients and interaction channels. >> >> Additionally, the delegation process will allow for: >> >> - Fine-grained specification of access >> - Approval of AS attestation to identity claims >> - Approval of access to multiple resources and APIs in a single >> interaction >> - Separation between the party authorizing access and the party operatin= g >> the client requesting access >> - A variety of client applications, including Web, mobile, single-page, >> and interaction-constrained applications >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> - User interaction mechanisms including web and non-web methods >> - Mechanism for conveying user, software, organization, and other pieces >> of information used in authorization decisions >> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >> - Optimized inclusion of additional information through the delegation >> process (including identity) >> >> Additionally, the group will provide mechanisms for management of the >> protocol lifecycle including: >> >> - Discovery of the authorization server >> - Revocation of active tokens >> - Query of token rights by resource servers >> >> Although the artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 or OpenID Connect, the group >> will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the >> new protocol where possible. >> >> This group is not chartered to develop extensions to OAuth 2.0, and as >> such will focus on new technological solutions not necessarily compatibl= e >> with OAuth 2.0.. Functionality that builds directly on OAuth 2.0 will be >> developed in the OAuth Working Group, including functionality back porte= d >> from TxAuth to OAuth 2.0. >> >> The group is chartered to develop mechanisms for applying cryptographic >> methods, such as JOSE and COSE, to the delegation process. This group is >> not chartered to develop new cryptographic methods. >> >> The initial work will focus on using HTTP for communication between the >> client and the authorization server, taking advantage of optimization >> features of HTTP2 and HTTP3 where possible, and will strive to enable >> simple mapping to other protocols such as COAP when doing so does not >> conflict with the primary focus. >> >> Milestones to include: >> - Core delegation protocol >> - Key presentation mechanism bindings to the core protocol for TLS, >> detached HTTP signature, and embedded HTTP signatures >> - Identity and authentication conveyance mechanisms >> - Guidelines for extension points >> >> >> >> >> We=E2=80=99ve scheduled a BoF for Vancouver, and there=E2=80=99s a chanc= e we can maybe >> get a charter approved and WG spun up in time to have an official meetin= g. >> Either way, we=E2=80=99ll be meeting to discuss TxAuth. >> >> =E2=80=94 Justin >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000002902a0059e337065 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+ 1

On Sat, Feb 8, 2020 at 5:42 AM Dick Hardt <dick.hardt@gmail.com> wrote:
<= /div>
+1<= br>

On Fri, Feb 7, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve updated the = proposed charter text based on feedback and conversation here on the list:<= div>

This group is chartered to de= velop a fine-grained delegation protocol for authorization, identity, and A= PI access. This protocol will allow an authorizing party to delegate access= to client software through an authorization server. It will expand upon th= e uses cases currently supported by OAuth 2..0 and OpenID Connect (itself a= n extension of OAuth 2.0) to support authorizations scoped as narrowly as a= single transaction, provide a clear framework for interaction among all pa= rties involved in the protocol flow, and remove unnecessary dependence on a= browser or user-agent for coordinating interactions.=C2=A0

<= /div>
The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will decouple t= he interaction channels, such as the end user=E2=80=99s browser, from the d= elegation channel, which happens directly between the client and the author= ization server (in contrast with OAuth 2.0 which is initiated by the client= redirecting the user=E2=80=99s browser). The client and AS will involve a = user to make an authorization decision as necessary through interaction mec= hanisms indicated by the protocol. This decoupling avoids many of the secur= ity concerns and technical challenges of OAuth 2.0 and provides a non-invas= ive path for supporting future types of clients and interaction channels.

Additionally, the delegation = process will allow for:

- Fi= ne-grained specification of access
- Approval of AS at= testation to identity claims
- Approval of access to multiple res= ources and APIs in a single interaction
- Separation b= etween the party authorizing access and the party operating the client requ= esting access
- A variety of client applications, incl= uding Web, mobile, single-page, and interaction-constrained applications

The group will define extensio= n points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for key= s, message signatures, and proof of possession=C2=A0
-= User interaction mechanisms including web and non-web methods
<= div>
- Mechanism for conveying user, software, organization, and other = pieces of information used in authorization decisions
= - Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys
- Optimized= inclusion of additional information through the delegation process (includ= ing identity)

Additionally, = the group will provide mechanisms for management of the protocol lifecycle = including:

- Discovery of th= e authorization server
- Revocation of active tokens
- Query of token rights by resource servers
=

Although the artifacts for this work ar= e not intended or expected to be backwards-compatible with OAuth 2.0 or Ope= nID Connect, the group will=C2=A0attempt to simplify migrating from OAuth 2= .0 and OpenID Connect to the new protocol where possible.
<= div>
This group is not chartered to develop e= xtensions to OAuth 2.0, and as such will focus on new technological solutio= ns not necessarily compatible with OAuth 2.0.. Functionality that builds di= rectly on OAuth 2.0 will be developed in the OAuth Working Group, including= functionality back ported from TxAuth to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic = methods, such as JOSE and COSE, to the delegation process. This group is no= t chartered to develop new cryptographic methods.=C2=A0

The initial work will focus on using HTTP= for communication between the client and the authorization server, taking = advantage of optimization features of HTTP2 and HTTP3=C2=A0where possible, = and will strive to enable simple mapping to other protocols such as COAP wh= en doing so does not conflict with the primary focus.

<= div>Milestones to include:
=C2=A0- Core delegation protocol
=
=C2=A0- Key presentation mechanism bindings to the core protocol for T= LS, detached HTTP signature, and embedded HTTP signatures
=C2=A0-= Identity and authentication conveyance mechanisms
=C2=A0- Guidel= ines for extension points




We=E2=80=99ve scheduled a BoF= for Vancouver, and there=E2=80=99s a chance we can maybe get a charter app= roved and WG spun up in time to have an official meeting. Either way, we=E2= =80=99ll be meeting to discuss TxAuth.

=C2=A0=E2= =80=94 Justin
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000002902a0059e337065-- From nobody Mon Feb 10 12:48:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67F312084D for ; Mon, 10 Feb 2020 12:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 BGq73EOg4r4M for ; Mon, 10 Feb 2020 12:48:25 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (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 490B6120847 for ; Mon, 10 Feb 2020 12:48: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=1581367705; x=1612903705; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Alg/JP9Shf819FQFnqO2/8pP4M5/sOazeKSa11PSw3g=; b=RWJP/7yhkf1YUmiGe71VPxHGFP8QkBgHUAQ0SlbBQMhwKgbrHg4viKtP USBJVbH7g+4NyHuOHRIe+ZNxnEIOLuDMKC93RnN1FkTsJ8YfiaDzeRv1F FUG8LnFB6DmAWNX5CBBpDqlnSUh/g68Tx1vRo+zcOwbi4ssYvEOz4m828 8=; IronPort-SDR: myfEBhtV2ve2gAGxWiwmtQZL9rs1LkyiFCDcVMud9XG3lTiEt35M/kA0SSDbzl9KWG782Onl63 PphZA7VKI9fA== X-IronPort-AV: E=Sophos; i="5.70,426,1574121600"; d="scan'208,217"; a="16455910" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-87a10be6.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 10 Feb 2020 20:48:23 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-87a10be6.us-west-2.amazon.com (Postfix) with ESMTPS id 90B95A1923; Mon, 10 Feb 2020 20:48:22 +0000 (UTC) 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, 10 Feb 2020 20:48:22 +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, 10 Feb 2020 20:48:21 +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, 10 Feb 2020 20:48:21 +0000 From: "Richard Backman, Annabelle" To: Matthew De Haast , Dick Hardt CC: "txauth@ietf.org" , Justin Richer Thread-Topic: [Txauth] Updated Proposed TxAuth Charter Thread-Index: AQHV3dfRq/jD8BWU7E2l3tnJ/AZkE6gQp8IAgANe7QCAAF5hgA== Date: Mon, 10 Feb 2020 20:48:21 +0000 Message-ID: <0B2D3EDB-05CB-4427-8D90-46F01E9A7F99@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.180] Content-Type: multipart/alternative; boundary="_000_0B2D3EDB05CB44278D9046F01E9A7F99amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 20:48:28 -0000 --_000_0B2D3EDB05CB44278D9046F01E9A7F99amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0K4oCTDQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0eQ0KaHR0 cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWF0dGhldyBEZSBIYWFzdCA8bWF0dC5kZWhh YXN0PTQwY29pbC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBNb25kYXksIEZlYnJ1YXJ5IDEw LCAyMDIwIGF0IDk6MjcgQU0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4N CkNjOiAidHhhdXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPiwgSnVzdGluIFJpY2hlciA8 anJpY2hlckBtaXQuZWR1Pg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFVwZGF0ZWQgUHJvcG9zZWQg VHhBdXRoIENoYXJ0ZXINCg0KKyAxDQoNCk9uIFNhdCwgRmViIDgsIDIwMjAgYXQgNTo0MiBBTSBE aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20+PiB3cm90ZToNCisxDQoNCk9uIEZyaSwgRmViIDcsIDIwMjAgYXQgODo1OCBBTSBKdXN0aW4g UmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0K SeKAmXZlIHVwZGF0ZWQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBiYXNlZCBvbiBmZWVkYmFj ayBhbmQgY29udmVyc2F0aW9uIGhlcmUgb24gdGhlIGxpc3Q6DQoNCg0KVGhpcyBncm91cCBpcyBj aGFydGVyZWQgdG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5lZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZv ciBhdXRob3JpemF0aW9uLCBpZGVudGl0eSwgYW5kIEFQSSBhY2Nlc3MuIFRoaXMgcHJvdG9jb2wg d2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0byBkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xp ZW50IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEl0IHdpbGwgZXhw YW5kIHVwb24gdGhlIHVzZXMgY2FzZXMgY3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLi4w IGFuZCBPcGVuSUQgQ29ubmVjdCAoaXRzZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRv IHN1cHBvcnQgYXV0aG9yaXphdGlvbnMgc2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRy YW5zYWN0aW9uLCBwcm92aWRlIGEgY2xlYXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9u ZyBhbGwgcGFydGllcyBpbnZvbHZlZCBpbiB0aGUgcHJvdG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1 bm5lY2Vzc2FyeSBkZXBlbmRlbmNlIG9uIGEgYnJvd3NlciBvciB1c2VyLWFnZW50IGZvciBjb29y ZGluYXRpbmcgaW50ZXJhY3Rpb25zLg0KDQpUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUg YWN0ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJm b3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGlu dGVyYWN0aW9uIGNoYW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJv bSB0aGUgZGVsZWdhdGlvbiBjaGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4g dGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRo IE9BdXRoIDIuMCB3aGljaCBpcyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0 aGUgdXNlcuKAmXMgYnJvd3NlcikuIFRoZSBjbGllbnQgYW5kIEFTIHdpbGwgaW52b2x2ZSBhIHVz ZXIgdG8gbWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGFzIG5lY2Vzc2FyeSB0aHJvdWdo IGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4gVGhpcyBk ZWNvdXBsaW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5p Y2FsIGNoYWxsZW5nZXMgb2YgT0F1dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBw YXRoIGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlv biBjaGFubmVscy4NCg0KQWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwg YWxsb3cgZm9yOg0KDQotIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIGFjY2Vzcw0KLSBB cHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0eSBjbGFpbXMNCi0gQXBwcm92YWwg b2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBhbmQgQVBJcyBpbiBhIHNpbmdsZSBpbnRl cmFjdGlvbg0KLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBhcnR5IGF1dGhvcml6aW5nIGFjY2Vz cyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xpZW50IHJlcXVlc3RpbmcgYWNjZXNzDQot IEEgdmFyaWV0eSBvZiBjbGllbnQgYXBwbGljYXRpb25zLCBpbmNsdWRpbmcgV2ViLCBtb2JpbGUs IHNpbmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24tY29uc3RyYWluZWQgYXBwbGljYXRpb25zDQoN ClRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29s IHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRpbmc6DQoNCi0gQ3J5cHRv Z3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBv ZiBwb3NzZXNzaW9uDQotIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2Vi IGFuZCBub24td2ViIG1ldGhvZHMNCi0gTWVjaGFuaXNtIGZvciBjb252ZXlpbmcgdXNlciwgc29m dHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB1c2Vk IGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zDQotIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcg dG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMg dG8gdG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5cw0KLSBPcHRpbWl6ZWQg aW5jbHVzaW9uIG9mIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlv biBwcm9jZXNzIChpbmNsdWRpbmcgaWRlbnRpdHkpDQoNCkFkZGl0aW9uYWxseSwgdGhlIGdyb3Vw IHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBs aWZlY3ljbGUgaW5jbHVkaW5nOg0KDQotIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXINCi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zDQotIFF1ZXJ5IG9mIHRva2VuIHJp Z2h0cyBieSByZXNvdXJjZSBzZXJ2ZXJzDQoNCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRo aXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21w YXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBh dHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuLjAgYW5kIE9wZW5JRCBD b25uZWN0IHRvIHRoZSBuZXcgcHJvdG9jb2wgd2hlcmUgcG9zc2libGUuDQoNClRoaXMgZ3JvdXAg aXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGV4dGVuc2lvbnMgdG8gT0F1dGggMi4wLCBhbmQg YXMgc3VjaCB3aWxsIGZvY3VzIG9uIG5ldyB0ZWNobm9sb2dpY2FsIHNvbHV0aW9ucyBub3QgbmVj ZXNzYXJpbHkgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMC4uIEZ1bmN0aW9uYWxpdHkgdGhhdCBi dWlsZHMgZGlyZWN0bHkgb24gT0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0 aCBXb3JraW5nIEdyb3VwLCBpbmNsdWRpbmcgZnVuY3Rpb25hbGl0eSBiYWNrIHBvcnRlZCBmcm9t IFR4QXV0aCB0byBPQXV0aCAyLjAuDQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxv cCBtZWNoYW5pc21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1Y2ggYXMg Sk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91cCBpcyBu b3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy4NCg0KVGhl IGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRpb24g YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRha2luZyBh ZHZhbnRhZ2Ugb2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIG9mIEhUVFAyIGFuZCBIVFRQMyB3aGVy ZSBwb3NzaWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJsZSBzaW1wbGUgbWFwcGluZyB0byBv dGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQIHdoZW4gZG9pbmcgc28gZG9lcyBub3QgY29uZmxp Y3Qgd2l0aCB0aGUgcHJpbWFyeSBmb2N1cy4NCg0KTWlsZXN0b25lcyB0byBpbmNsdWRlOg0KIC0g Q29yZSBkZWxlZ2F0aW9uIHByb3RvY29sDQogLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBi aW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25h dHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KIC0gSWRlbnRpdHkgYW5kIGF1dGhl bnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtcw0KIC0gR3VpZGVsaW5lcyBmb3IgZXh0ZW5z aW9uIHBvaW50cw0KDQoNCg0KDQpXZeKAmXZlIHNjaGVkdWxlZCBhIEJvRiBmb3IgVmFuY291dmVy LCBhbmQgdGhlcmXigJlzIGEgY2hhbmNlIHdlIGNhbiBtYXliZSBnZXQgYSBjaGFydGVyIGFwcHJv dmVkIGFuZCBXRyBzcHVuIHVwIGluIHRpbWUgdG8gaGF2ZSBhbiBvZmZpY2lhbCBtZWV0aW5nLiBF aXRoZXIgd2F5LCB3ZeKAmWxsIGJlIG1lZXRpbmcgdG8gZGlzY3VzcyBUeEF1dGguDQoNCiDigJQg SnVzdGluDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpU eGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4 YXV0aA0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhh dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGgNCg== --_000_0B2D3EDB05CB44278D9046F01E9A7F99amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7BB5648ACF9476459BA9F9CF9008349D@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPuKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0 dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjND MSI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS88L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBN YXR0aGV3IERlIEhhYXN0ICZsdDttYXR0LmRlaGFhc3Q9NDBjb2lsLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBGZWJydWFyeSAxMCwgMjAyMCBhdCA5OjI3 IEFNPGJyPg0KPGI+VG86IDwvYj5EaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRo QGlldGYub3JnJmd0OywgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gVXBkYXRlZCBQcm9wb3NlZCBUeEF1dGggQ2hh cnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mIzQzOyAxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIFNhdCwg RmViIDgsIDIwMjAgYXQgNTo0MiBBTSBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5PbiBGcmksIEZlYiA3LCAyMDIwIGF0IDg6NTggQU0gSnVzdGlu IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxh bmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5J4oCZdmUgdXBkYXRlZCB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IGJhc2Vk IG9uIGZlZWRiYWNrIGFuZCBjb252ZXJzYXRpb24gaGVyZSBvbiB0aGUgbGlzdDoNCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmlu ZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24sIGlkZW50aXR5 LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5n IHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBh dXRob3JpemF0aW9uDQogc2VydmVyLiBJdCB3aWxsIGV4cGFuZCB1cG9uIHRoZSB1c2VzIGNhc2Vz IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4uMCBhbmQgT3BlbklEIENvbm5lY3QgKGl0 c2VsZiBhbiBleHRlbnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25z IHNjb3BlZCBhcyBuYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBhIGNs ZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMNCiBpbnZvbHZl ZCBpbiB0aGUgcHJvdG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1bm5lY2Vzc2FyeSBkZXBlbmRlbmNl IG9uIGEgYnJvd3NlciBvciB1c2VyLWFnZW50IGZvciBjb29yZGluYXRpbmcgaW50ZXJhY3Rpb25z LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRo ZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRp ZXMgaW4gdGhlIHByb3RvY29sLCBlYWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUg cHJvdG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50ZXJhY3Rpb24gY2hhbm5lbHMsIHN1Y2ggYXMg dGhlIGVuZCB1c2Vy4oCZcyBicm93c2VyLCBmcm9tIHRoZSBkZWxlZ2F0aW9uDQogY2hhbm5lbCwg d2hpY2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2ggaXMgaW5pdGlh dGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUg Y2xpZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlv biBkZWNpc2lvbiBhcyBuZWNlc3NhcnkNCiB0aHJvdWdoIGludGVyYWN0aW9uIG1lY2hhbmlzbXMg aW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4gVGhpcyBkZWNvdXBsaW5nIGF2b2lkcyBtYW55IG9m IHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2FsIGNoYWxsZW5nZXMgb2YgT0F1dGgg Mi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRoIGZvciBzdXBwb3J0aW5nIGZ1dHVy ZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBjaGFubmVscy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5BZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxvdyBm b3I6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBh Y2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIEFwcHJvdmFsIG9mIEFT IGF0dGVzdGF0aW9uIHRvIGlkZW50aXR5IGNsYWltczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gQXBw cm92YWwgb2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBhbmQgQVBJcyBpbiBhIHNpbmds ZSBpbnRlcmFjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gU2VwYXJh dGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBv cGVyYXRpbmcgdGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPi0gQSB2YXJpZXR5IG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGluY2x1 ZGluZyBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBpbnRlcmFjdGlvbi1jb25zdHJhaW5l ZCBhcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgZ3JvdXAgd2lsbCBkZWZpbmUg ZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxp dHkgaW4gYXJlYXMgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gQ3J5cHRvZ3JhcGhp YyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3Nz ZXNzaW9uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LSBVc2VyIGlu dGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LSBNZWNoYW5pc20gZm9yIGNvbnZleWlu ZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9y bWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4tIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9rZW5zIHRvIHJl c291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMgdG8gdG9rZW5zIGFu ZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gT3B0 aW1pemVkIGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRocm91Z2ggdGhlIGRl bGVnYXRpb24gcHJvY2VzcyAoaW5jbHVkaW5nIGlkZW50aXR5KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5h Z2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPi0gRGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LSBRdWVyeSBvZiB0b2tlbiByaWdodHMg YnkgcmVzb3VyY2Ugc2VydmVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFsdGhvdWdoIHRoZSBhcnRp ZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJh Y2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUg Z3JvdXAgd2lsbCZuYnNwO2F0dGVtcHQgdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGgg Mi4uMCBhbmQgT3BlbklEIENvbm5lY3QgdG8gdGhlDQogbmV3IHByb3RvY29sIHdoZXJlIHBvc3Np YmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVy ZWQgdG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBm b2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBh dGlibGUgd2l0aCBPQXV0aCAyLjAuLiBGdW5jdGlvbmFsaXR5IHRoYXQgYnVpbGRzIGRpcmVjdGx5 IG9uIE9BdXRoIDIuMCB3aWxsDQogYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0aCBXb3JraW5nIEdy b3VwLCBpbmNsdWRpbmcgZnVuY3Rpb25hbGl0eSBiYWNrIHBvcnRlZCBmcm9tIFR4QXV0aCB0byBP QXV0aCAyLjAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGFwcGx5aW5n IGNyeXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBhcyBKT1NFIGFuZCBDT1NFLCB0byB0aGUgZGVs ZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBu ZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2RzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGluaXRpYWwg d29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0 aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRha2luZyBhZHZhbnRhZ2Ug b2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIG9mIEhUVFAyIGFuZCBIVFRQMyZuYnNwO3doZXJlIHBv c3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlDQogc2ltcGxlIG1hcHBpbmcgdG8gb3Ro ZXIgcHJvdG9jb2xzIHN1Y2ggYXMgQ09BUCB3aGVuIGRvaW5nIHNvIGRvZXMgbm90IGNvbmZsaWN0 IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+TWlsZXN0b25lcyB0byBpbmNsdWRlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOy0gQ29yZSBkZWxlZ2F0aW9uIHByb3RvY29sPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7LSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90 b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAg c2lnbmF0dXJlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOy0gSWRlbnRpdHkgYW5kIGF1dGhl bnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw Oy0gR3VpZGVsaW5lcyBmb3IgZXh0ZW5zaW9uIHBvaW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5XZeKAmXZlIHNjaGVkdWxlZCBhIEJvRiBmb3IgVmFuY291 dmVyLCBhbmQgdGhlcmXigJlzIGEgY2hhbmNlIHdlIGNhbiBtYXliZSBnZXQgYSBjaGFydGVyIGFw cHJvdmVkIGFuZCBXRyBzcHVuIHVwIGluIHRpbWUgdG8gaGF2ZSBhbiBvZmZpY2lhbCBtZWV0aW5n LiBFaXRoZXIgd2F5LCB3ZeKAmWxsIGJlIG1lZXRpbmcgdG8gZGlzY3VzcyBUeEF1dGguPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A74oCUIEp1c3Rp bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLSA8YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LS0gPGJy Pg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_0B2D3EDB05CB44278D9046F01E9A7F99amazoncom_-- From nobody Mon Feb 10 15:38:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6309120873 for ; Mon, 10 Feb 2020 15:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 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_HELO_NONE=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 D6mGvjAyPuyB for ; Mon, 10 Feb 2020 15:38:41 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 7B0C512088E for ; Mon, 10 Feb 2020 15:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1581377922; x=1612913922; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=IndyHdqJphPXCkzQaNRq5PT22PrwwcDJU+5rxj8UIpw=; b=SaV2zcYlwowgImvFiSkNMfgDC5SMpG2Z0k5KyzpgM/T2uTEFU44KYRLa AWmUh4rM1Kve/t4zrvWV2IB2PA9rwzy9PmP7yTs6IGq2m0semVbewiqru iF1+oYHUUAD0GU209Gq3Ro0KOi2APmZHpnzpOMz/b60krGO63LYbE3vjZ E=; IronPort-SDR: 2jBH6Jds2n+FJYhiIeXkU3GIuCDJC/X/9tXmhUHQ8qS32ProflcG9B8Dx7bCKz+2/TBhnjhtlZ 2kDiXH0jKKoQ== X-IronPort-AV: E=Sophos; i="5.70,426,1574121600"; d="scan'208,217"; a="25567458" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-98acfc19.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 10 Feb 2020 22:58:27 +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-98acfc19.us-east-1.amazon.com (Postfix) with ESMTPS id 4916CA25B4; Mon, 10 Feb 2020 22:58:23 +0000 (UTC) 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, 10 Feb 2020 22:58:23 +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, 10 Feb 2020 22:58:23 +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, 10 Feb 2020 22:58:22 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , "txauth@ietf.org" Thread-Topic: [Txauth] XAuth -02 Thread-Index: AQHV3jRcCsQaXzP9e0Gex6TsPtSqQKgUiKoA Date: Mon, 10 Feb 2020 22:58:22 +0000 Message-ID: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.214] Content-Type: multipart/alternative; boundary="_000_58F0F4E4E9AE45E092F160B993B75A34amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 23:38:44 -0000 --_000_58F0F4E4E9AE45E092F160B993B75A34amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW50ZXJlc3Rpbmcgd29yay4gSSBhbSBlbmpveWluZyB0aGUgZmFjdCB0aGF0IHdlIGhhdmUgdHdv IGRpZmZlcmVudCB0YWtlcyBvbiB0aGUgc2FtZSBwcm9ibGVtLiBUaGUgY29tcGFyaXNvbnMgYW5k IGRpc2N1c3Npb25zIHdpbGwgbGVhZCB1cyB0byBhIGJldHRlciBvdmVyYWxsIHNvbHV0aW9uLg0K DQpIZXJlIGFyZSBteSBjb21tZW50cyBvbiBYQXV0aC0wMjoNCg0KU2VjdGlvbiAyLjE6DQogICAq ICAqUmVzb3VyY2UgT3duZXIqIChSTykgLSBvd25zIHRoZSBSUywgYW5kIGhhcyBkZWxlZ2F0ZWQg UlMgYWNjZXNzDQogICAgICBtYW5hZ2VtZW50IHRvIHRoZSBHUy4gIFRoZSBSTyBtYXkgYmUgdGhl IHNhbWUgZW50aXR5IGFzIHRoZSBVc2VyLCAuLi4NCg0KSeKAmW0gcmF0aGVyIGJhZmZsZWQgYnkg dGhpcyBkZWZpbml0aW9uLCBhbmQgd29uZGVyaW5nIGlmIGl04oCZcyBhIG1pc3Rha2Ugb3IgaWYg SeKAmW0gbWlzaW50ZXJwcmV0aW5nIGl0LiBJcyB0aGlzIGFuIGludGVudGlvbmFsIGRlcGFydHVy ZSBmcm9tIGhvdyDigJxST+KAnSBpcyB0eXBpY2FsbHkgdXNlZCB3aXRoaW4gdGhlIE9BdXRoIDIu MCBzcGFjZT8gVXN1YWxseSB0aGUgdGVybSBSTyByZWZlcnMgdG8gdGhlIGVudGl0eSB0aGF0IG93 bnMgdGhlIHNwZWNpZmljIHJlc291cmNlcyB0aGUgY2xpZW50IGlzIHJlcXVlc3RpbmcgYXV0aG9y aXphdGlvbiBmb3IuIFRoZSBSTyBkb2VzIG5vdCB0eXBpY2FsbHkgb3duIHRoZSBSUyBpdHNlbGYu DQoNClNlY3Rpb24gNS41LjI6DQoNCiAgIFRoZSBpbnRlcmFjdGlvbiBvYmplY3QgY29udGFpbnMg dGhlIHR5cGUgb2YgaW50ZXJhY3Rpb24gdGhlIENsaWVudA0KDQogICB3aWxsIHByb3ZpZGUgdGhl IFVzZXIuICBPdGhlciBhdHRyaWJ1dGVzDQoNCjxzbmlwPg0KDQogICAgICAgIC0gICp0eXBlKiAt IGNvbnRhaW5zIG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczogInBvcHVwIiwNCg0KICAgICAg ICAgICAicmVkaXJlY3QiLCBvciAicXJjb2RlIi4uLi4NCg0KMyBpc3N1ZXMgd2l0aCB0aGlzOg0K DQogIDEuICBIb3cgd291bGQgSSBkbyBhIHVzZXIgY29kZS1iYXNlZCBpbnRlcmFjdGlvbj8NCiAg Mi4gIENsaWVudHMgc3VwcG9ydCBtdWx0aXBsZSBpbnRlcmFjdGlvbiBtb2RlcyBhbmQgbWF5IG5v dCBhbHdheXMga25vdyB3aGF0IHRoZSBHUyBzdXBwb3J0cyAoYW5kIHZpY2UtdmVyc2EpLiBGb3Ig YSBtdWx0aS10ZW5hbnQgR1MsIGl0IG1heSB2YXJ5IGJ5IHRlbmFudCBjb25maWd1cmF0aW9uLiBD bGllbnRzIHNob3VsZCBiZSBhYmxlIHRvIHNheSB3aGF0IHRoZXkgY2FuIGRvLCBhbmQgdGhlIEdT IHNob3VsZCBiZSBhYmxlIHRvIHRlbGwgdGhlbSB3aGljaCBvbmUgdG8gdXNlLiBJdOKAmXMgYSB2 ZXJ5IHNpbXBsZSBidXQgcG93ZXJmdWwgaW5saW5lIG5lZ290aWF0aW9uLg0KICAzLiAgSSBkb27i gJl0IHNlZSB0aGUgdmFsdWUgb2YgdGhlIOKAnHBvcHVw4oCdIGludGVyYWN0aW9uIG1vZGUuIENs aWVudHMgY2FuIHVzZSDigJxyZWRpcmVjdOKAnSBtb2RlIHdpdGhpbiBwb3B1cHMuIEhvd2V2ZXIs IHNwZWFraW5nIGFzIHNvbWVvbmUgd2hvIGhhcyBkb25lIHRoYXQsIEkgcmVhbGx5IGRvbuKAmXQg cmVjb21tZW5kIGl0LiBQb3B1cHMgYXJlIGluY3JlYXNpbmdseSB1bnN1cHBvcnRlZCwgYW5kIHBy b25lIHRvIHdlaXJkIGJlaGF2aW9yYWwgaXNzdWVzLiBJbi1hcHAgYnJvd3NlcnMgaW4gRmFjZWJv b2ssIFR3aXR0ZXIsIGV0Yy4gdGVuZCB0byBoYXZlIHBvcHVwcyBkaXNhYmxlZC4gVGhlIGxhc3Qg dmVyc2lvbnMgb2YgSUUgTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwgKHRoZSBw b3BwZWQgdXAgcGFnZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVudCB3aW5k b3cpLg0KDQpTZWN0aW9uIDEyLjY6DQoNCiAgICAgICAgW0VkaXRvcjogaXMgdGhlcmUgc29tZSBv dGhlciByZWFzb24gdG8gaGF2ZSB0aGUgVXNlckluZm8NCg0KICAgICAgICBlbmRwb2ludD9dDQoN CkkgbWF5IHdhbnQgdG8gaG9zdCBteSBVc2VySW5mbyBlbmRwb2ludCBvbiBhIHNlcGFyYXRlIG1p Y3Jvc2VydmljZSBmcm9tIG15IHRva2VuIGVuZHBvaW50IChpbiBPQXV0aCAyLjAvT0lEQyB0ZXJt cykuIFRoZSBmb3JtZXIgbWlnaHQgYmUgcGFydCBvZiBteSB1c2VyIHByb2ZpbGUvZGlyZWN0b3J5 IHN0YWNrLCB3aGlsZSB0aGUgbGF0dGVyIGlzIHBhcnQgb2YgdGhlIGhpZ2hseSBwcml2aWxlZ2Vk IGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24gc3RhY2suDQoNClNlY3Rpb24gMTIuODoNCg0K ICAgICAgICAqV2h5IGhhdmUgYm90aCBjbGFpbXMgYW5kIGF1dGhvcml6YXRpb25zPyoNCg0KDQoN CiAgICAgICAgVGhlcmUgYXJlIHVzZSBjYXNlcyBmb3IgZWFjaCB0aGF0IGFyZSBpbmRlcGVuZGVu dDoNCg0KICAgICAgICBhdXRoZW50aWNhdGluZyBhIHVzZXIgdnMgZ3JhbnRpbmcgYWNjZXNzIHRv IGEgcmVzb3VyY2UuICBBDQoNCiAgICAgICAgcmVxdWVzdCBmb3IgYW4gYXV0aG9yaXphdGlvbiBy ZXR1cm5zIGFuIGFjY2VzcyB0b2tlbiBvciBoYW5kbGUsDQoNCiAgICAgICAgd2hpbGUgYSByZXF1 ZXN0IGZvciBhIGNsYWltIHJldHVybnMgdGhlIGNsYWltLg0KDQpJIGRvbuKAmXQgYWdyZWUgdGhh dCB0aGUgdXNlIGNhc2VzIGFyZSBkaXN0aW5jdC4gVGhlIG9ubHkgY2xhaW0gdGhhdCBpcyBzdHJp Y3RseSBuZWNlc3NhcnkgZm9yIGF1dGhlbnRpY2F0aW9uIGlzIHRoZSB1c2VyIGlkZW50aWZpZXIu IE90aGVyIGNsYWltcyBsaWtlIGVtYWlsIGFuZCBwaG9uZV9udW1iZXIgYXJlIG9mdGVuIHVzZWQg dG8gYWlkIGluIGxvY2FsIGFjY291bnQgaWRlbnRpZmljYXRpb24gKGkuZS4sIGFjY291bnQgbGlu a2luZyksIGJ1dCBhcmUgdXNlZnVsIGFuZCBpbnRlcmVzdGluZyBiZXlvbmQgdGhpcyB1c2UgY2Fz ZS4gT3RoZXIgY2xhaW1zIHN1Y2ggYXMgbmFtZSwgcHJlZmVycmVkX3VzZXJuYW1lLCBhbmQgYmly dGhkYXRlIGNvdWxkIGJlIHVzZWQgaW4gYSBzaW1pbGFyIGZhc2hpb24sIHRob3VnaCB0aGV5IGZy ZXF1ZW50bHkgYXJlbuKAmXQuIFRoZSBzYW1lIGlzIHRydWUgZm9yIG90aGVyIHJlc291cmNlcyBu b3QgY3VycmVudGx5IGRlZmluZWQgYXMgY2xhaW1zIChlLmcuLCB0aGUgZXh0ZXJuYWxJZCBlc3Rh Ymxpc2hlZCB3aGVuIHRoZSB1c2VyIHdhcyBpbXBvcnRlZCB0aHJvdWdoIFNDSU0pLg0KDQpDbGFp bXMgYXJlIGp1c3QgcmVzb3VyY2VzIHRoYXQgT0lEQyBwcm92aWRlcyBhIG5hbWUgcmVnaXN0cnkg YW5kIHNvbWUgZXh0cmEgZmVhdHVyZXMgZm9yOg0KDQogICogICBPcHRpb25hbGx5IGdldCB0aGUg dmFsdWUgYnVuZGxlZCB3aXRoIHRoZSBhdXRoZW50aWNhdGlvbiByZXNwb25zZSwgd2l0aG91dCBu ZWVkaW5nIHRvIGNhbGwgYSBzZXBhcmF0ZSBlbmRwb2ludC4NCiAgKiAgIE9wdGlvbmFsbHkgZ2V0 IHRoZSB2YWx1ZSBpbiBhIHNpZ25lZCBvciBlbmNyeXB0ZWQgYmxvYi4NCiAgKiAgIE9wdGlvbmFs bHkgcHJvdmlkZSBzb21lIHN0cnVjdHVyZWQgbWV0YWRhdGEgZGVzY3JpYmluZyB0aGUgcmVzb3Vy Y2UgYW5kL29yIHJlcXVlc3RlZCBhdXRob3JpemF0aW9uLg0KDQpJdOKAmXMgdGVsbGluZyB0aGF0 IGFsbCBvZiB0aGVzZSBhcmUgb3B0aW9uYWwuIElmIHdlIHRoaW5rIHRoZXNlIGFyZSBmZWF0dXJl cyB3b3J0aCBicmluZ2luZyBmb3J3YXJkIGludG8gd2hhdGV2ZXIgcHJvdG9jb2wgd2UgcHJvZHVj ZSB0aHJvdWdoIFR4QXV0aCwgd2Ugc2hvdWxkIGxvb2sgYXQgdGhlbSBpbmRlcGVuZGVudGx5IG9m IHRoZSBjbGFpbS9yZXNvdXJjZSBkaWNob3RvbXkuDQoNClNlY3Rpb24gMTIuMTI6DQoNCiAgICAg ICAgKldoeSBjb21wbGljYXRlIHRoZSBzZXF1ZW5jZSB3aXRoICJpbnRlcmFjdGlvbiIuImtlZXAi PyoNCg0KSSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3XigJlyZSB0cnlpbmcgdG8gc3VwcG9y dCBoZXJlLCBidXQgSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdG9vIGNvbXBsaWNhdGVkIHRvIGlt cGxlbWVudC4gRnJvbSB0aGUgc2VxdWVuY2VzLCBpdCBsb29rcyBsaWtlIHRoZSBDbGllbnQgaXMg ZXhwZWN0ZWQgdG8gaXNzdWUgYSBSZWFkIEdyYW50IHJlcXVlc3QsIGFuZCB0aGF0IGNvbm5lY3Rp b24gd2lsbCBiZSBrZXB0IG9wZW4gd2hpbGUgdGhlIFVzZXIgaXMgcmVkaXJlY3RlZCB0byB0aGUg R1MgYW5kIGdvZXMgdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gd29ya2Zsb3cgKGFuZCBwb3Nz aWJseSBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHdvcmtmbG93KS4gT25seSB0aGVuIHdvdWxk IHRoZSBHUyByZXR1cm4gdGhlIFJlYWQgR3JhbnQgcmVzcG9uc2UuIElzIHRoaXMgY29ycmVjdD8N Cg0KVG8gaW1wbGVtZW50IHRoaXMsIHRoZSBDbGllbnQgaGFzIHRvIGxhdW5jaCBhbiBhc3luY2hy b25vdXMgdGhyZWFkIHRvIGV4ZWN1dGUgdGhhdCByZXF1ZXN0IGFuZCBhd2FpdGluZyB0aGUgcmVz cG9uc2UuIFBvc3NpYmxlLCBidXQgc3VzY2VwdGlibGUgdG8gZmFpbHVyZXMuIFdoYXQgaGFwcGVu cyBpZiB0aGF0IHRocmVhZCBjcmFzaGVzPyBPciBmYWlscyB0byBzZW5kIHRoZSBVcGRhdGUgR3Jh bnQgcmVxdWVzdCB0byBmbGlwIGludGVyYWN0aW9uLmtlZXAgdG8gZmFsc2U/IFdoYXQgaXMgdGhl IEdTIGRvaW5nIGluIHRoZSBtZWFudGltZT8gSXMgaXQganVzdCBzaG93aW5nIHRoZSBVc2VyIGEg 4oCcbG9hZGluZ+KAnSB3aWRnZXQgYXMgaXQgd2FpdHMgZm9yIHRoZSBDbGllbnQgdG8gdXBkYXRl IHRoZSBncmFudD8gSG93IGxvbmcgZG9lcyBpdCB3YWl0IGZvcj8gRm9yIG1vYmlsZSBhcHBzLCB0 aGF0IGJhY2tncm91bmQgdGhyZWFkIG1heSBnZXQga2lsbGVkIG9yIGxvc2UgbmV0d29yayBjb25u ZWN0aXZpdHkgYXMgc29vbiBhcyB0aGUgdXNlciBnZXRzIHN3aXRjaGVkIG92ZXIgdG8gdGhlIHN5 c3RlbSBicm93c2VyIHRvIGxvYWQgdGhlIEdTIHNpZ24gaW4gcGFnZS4gRm9yIGEgcHVyZS1KUyBh cHAgdGhhdCByZWRpcmVjdHMsIEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHBvc3NpYmxlIGF0IGFs bC4gKHVubGVzcyB3ZWIgd29ya2VycyBjYW4gc3Vydml2ZSBwYWdlIHVubG9hZHM/KQ0KDQpUaGlz IGlzIGFuIGludGVyZXN0aW5nIHVzZSBjYXNlIGZvciB1cyB0byB0aGluayBhYm91dCwgYnV0IGl0 IG5lZWRzIGEgbG90IG9mIHdvcmsgYW5kIG1heSBub3QgYmUgc29tZXRoaW5nIHdlIHNob3VsZCB0 cnkgdG8gYmFrZSBpbnRvIHRoZSBjb3JlIHByb3RvY29sIGlmIHdlIGRvbuKAmXQgbmVlZCB0by4N Cg0KU2VjdGlvbiAxMi4xNDoNCg0KICAgICAgICAqV2h5IHVzZSBVUklzIHRvIGluc3RlYWQgb2Yg aGFuZGxlcyBmb3IgdGhlIEdyYW50IGFuZA0KDQogICAgICAgIEF1dGhvcml6YXRpb24/Kg0KDQpJ IGRpZG7igJl0IGxpa2UgdGhpcyB1bnRpbCBJIHJlYWxpemVkIHRoYXQgeW914oCZcmUgZGlzdGlu Z3Vpc2hpbmcgYmV0d2VlbiBoYW5kbGVzL1VSSXMgYW5kIHRva2Vucy4gTm93IHRoYXQgSeKAmXZl IHRob3VnaHQgYWJvdXQgaXQgbW9yZSwgSSBsaWtlIHRoaXMgZnJvbSB0aGUgc3RhbmRwb2ludCB0 aGF0IGl0IHVuZGVyc2NvcmVzIHRoZSBpZGVhIG9mIEdyYW50cyBhbmQgQXV0aG9yaXphdGlvbnMg YmVpbmcgcGVyc2lzdGVudCBvYmplY3RzIHdpdGhpbiB0aGUgcHJvdG9jb2wuIEFuZCBpdOKAmXMg cmVhbGx5IGp1c3QgbWFraW5nIHB1YmxpYyBzb21ldGhpbmcgdGhhdCB0aGUgR1MgaXMgcHJvYmFi bHkgZ29pbmcgdG8gYmUgZG9pbmcgdW5kZXIgdGhlIGhvb2QgYW55d2F5LiBIb3dldmVyLCB3ZSBo YXZlIHRvIGJlIGNhcmVmdWwgdGhhdCB3ZSBkb27igJl0IGFjY2lkZW50YWxseSBlbmNvdXJhZ2Ug aW1wbGVtZW50ZXJzIHRvIHN0YXJ0IHNob3ZpbmcgdGhpbmdzIGludG8gdGhlc2UgVVJJcy4NCg0K 4oCTDQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0eQ0KaHR0cHM6Ly9h d3MuYW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+ DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDcsIDIwMjAgYXQgODowMCBQTQ0KVG86ICJ0eGF1dGhA aWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVHhhdXRoXSBYQXV0aCAtMDIN Cg0KSSd2ZSBoZWF2aWx5IHJldmlzZWQgWEF1dGggYWdhaW4uDQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMg0KDQpBIG51bWJlciBvZiBu ZXcgaWRlYXMgdG8gYm91bmNlIGFyb3VuZDoNCg0KSSBoYXZlIGluY2x1ZGVkIGEgYnVuY2ggb2Yg c2VxdWVuY2VzIHRvIHNob3cgZGlmZmVyZW50IHVzZSBjYXNlcyBwb3NzaWJsZS4NCg0KUmF0aGVy IHRoYW4gYSB0cmFuc2FjdGlvbiwgSSB1c2UgYSBHcmFudCBhcyB0aGUgY2VudHJhbCBvYmplY3Qu DQoNClRoZSBpbnRlcmZhY2UgaXMgdmVyeSBSRVNUZnVsLg0KDQpUaGUgQVMgaXMgbm93IGEgR3Jh bnQgU2VydmVyIChHUykNCg0KVGhpcyBhbHNvIHNlZW1lZCBhcHByb3ByaWF0ZSBhdCBpdCBpcyBi b3RoIGFuIE9BdXRoIEFTLCBhbmQgYW4gT0lEQyBPUC4NCg0KUmF0aGVyIHRoYW4gYSBoYW5kbGUs IHRoZSBHcmFudCBoYXMgYSBVUkkuDQoNClRoZSBlbmRwb2ludCBVUkkgZm9yIHRoZSBHUyBpcyB0 aGUgR1MgVVJJLCBhbmQgaXMgdGhlIEdTIGlkZW50aWZpZXIuDQoNCkFuIGFjY2VzcyB0b2tlbiwg cmVmcmVzaCB0b2tlbiBldGMuIGFyZSBhbGwgYW4gQXV0aG9yaXphdGlvbi4gQW4gQXV0aG9yaXph dGlvbiBoYXMgYW4gQXV0aFogVVJJLi4NCg0KVGhlIEdyYW50IFVSSSBhbmQgQXV0aFogVVJJIGFs bCBzdGFydCB3aXRoIHRoZSBHUyBVUkkuDQoNCkEgR3JhbnQgaXMgY3JlYXRlZCBieSBkb2luZyBh IFBPU1QgdG8gdGhlIEdTIFVSSSwgcmV0dXJuaW5nIGEgR3JhbnQgVVJJLg0KDQpNZXRhZGF0YSBm b3IgdGhlIEdTIGlzIGRvbmUgd2l0aCBhbiBPUFRJT05TIHRvIHRoZSBHUyBVUkkuDQoNClRoZSBD bGllbnQgY2FuIGRvIEdFVCwgVVBEQVRFLCBhbmQgREVMRVRFIGFnYWluc3QgYSBHcmFudCBVUkku DQoNCkFuIGFjY2VzcyB0b2tlbiByZWZyZXNoIGlzIGEgR0VUIG9uIHRoZSBBdXRoWiBVUkkuDQoN CkFkZGluZyBpbiBSZWNpcHJvY2FsIE9BdXRoIGZ1bmN0aW9uYWxpdHkgd2FzIG1vcmUgc3RyYWln aHRmb3J3YXJkIHRoYW4gaW4gT0F1dGggMi4wIC0tIGJ1dCBub3QgYXMgc3RyYWlnaHQgZm9yd2Fy ZCBhcyBJIHdvdWxkIGxpa2UgLS0gYnV0IG5vdCBjbGVhciBob3cgdG8gbWFrZSBpdCBiZXR0ZXIg YW5kIHN0YXJ0IGZyb20gdGhlIENsaWVudCBhbmQgR1MgaGF2aW5nIGNvbnRleHQgb2Ygb25lIGF1 dGhvcml6YXRpb24gYmVmb3JlIHN3YXBwaW5nIHJvbGVzLg0KDQpQZXIgbXkgbGFzdCBlbWFpbHMs IG5hbWluZyBpcyBoYXJkLCB0aGVyZSBhcmUgbGlrZWx5IGxvdHMgb2YgbWlzdGFrZXMsIGFuZCBs b3RzIG9mIGFzcGVjdHMgdGhhdCBuZWVkIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSG9wZWZ1bGx5IHRo ZSBjb25jZXB0cyBjb21lIHRocm91Z2ghDQoNCi9EaWNrDQo= --_000_58F0F4E4E9AE45E092F160B993B75A34amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3 ODc1MDUyNzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjkyMTQ1OTY1MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoxODQ1OTc3MDk1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMzk3NjQ5NzgwIC0xNDM5NjY1ODUwIDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTI7DQoJbXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseToiTVMgTWluY2hvIjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkludGVyZXN0 aW5nIHdvcmsuIEkgYW0gZW5qb3lpbmcgdGhlIGZhY3QgdGhhdCB3ZSBoYXZlIHR3byBkaWZmZXJl bnQgdGFrZXMgb24gdGhlIHNhbWUgcHJvYmxlbS4gVGhlIGNvbXBhcmlzb25zIGFuZCBkaXNjdXNz aW9ucyB3aWxsIGxlYWQgdXMgdG8gYSBiZXR0ZXIgb3ZlcmFsbCBzb2x1dGlvbi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGVyZSBhcmUgbXkgY29tbWVudHMgb24gWEF1dGgtMDI6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMi4xOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAqJm5ic3A7ICpSZXNv dXJjZSBPd25lciogKFJPKSAtIG93bnMgdGhlIFJTLCBhbmQgaGFzIGRlbGVnYXRlZCBSUyBhY2Nl c3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmFnZW1lbnQgdG8g dGhlIEdTLiAmbmJzcDtUaGUgUk8gbWF5IGJlIHRoZSBzYW1lIGVudGl0eSBhcyB0aGUgVXNlciwg Li4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIHJhdGhlciBiYWZmbGVk IGJ5IHRoaXMgZGVmaW5pdGlvbiwgYW5kIHdvbmRlcmluZyBpZiBpdOKAmXMgYSBtaXN0YWtlIG9y IGlmIEnigJltIG1pc2ludGVycHJldGluZyBpdC4gSXMgdGhpcyBhbiBpbnRlbnRpb25hbCBkZXBh cnR1cmUgZnJvbSBob3cg4oCcUk/igJ0gaXMgdHlwaWNhbGx5IHVzZWQgd2l0aGluIHRoZSBPQXV0 aCAyLjAgc3BhY2U/IFVzdWFsbHkgdGhlIHRlcm0gUk8gcmVmZXJzIHRvIHRoZSBlbnRpdHkgdGhh dA0KIG93bnMgdGhlIHNwZWNpZmljIHJlc291cmNlcyB0aGUgY2xpZW50IGlzIHJlcXVlc3Rpbmcg YXV0aG9yaXphdGlvbiBmb3IuIFRoZSBSTyBkb2VzIG5vdCB0eXBpY2FsbHkgb3duIHRoZSBSUyBp dHNlbGYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gNS41LjI6PG86cD48L286cD48 L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBpbnRl cmFjdGlvbiBvYmplY3QgY29udGFpbnMgdGhlIHR5cGUgb2YgaW50ZXJhY3Rpb24gdGhlIENsaWVu dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyB3aWxsIHByb3ZpZGUgdGhlIFVzZXIuJm5ic3A7IE90aGVyIGF0dHJpYnV0 ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0mbmJzcDsgKnR5cGUqIC0gY29udGFpbnMgb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFs dWVzOiAmcXVvdDtwb3B1cCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7cmVkaXJlY3QmcXVvdDssIG9yICZxdW90 O3FyY29kZSZxdW90Oy4uLi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MyBpc3N1 ZXMgd2l0aCB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg c3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5Ib3cgd291bGQgSSBkbyBh IHVzZXIgY29kZS1iYXNlZCBpbnRlcmFjdGlvbj88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8yIj5DbGllbnRzIHN1cHBvcnQgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZXMgYW5kIG1h eSBub3QgYWx3YXlzIGtub3cgd2hhdCB0aGUgR1Mgc3VwcG9ydHMgKGFuZCB2aWNlLXZlcnNhKS4g Rm9yIGEgbXVsdGktdGVuYW50IEdTLCBpdCBtYXkgdmFyeSBieSB0ZW5hbnQgY29uZmlndXJhdGlv bi4gQ2xpZW50cyBzaG91bGQNCiBiZSBhYmxlIHRvIHNheSB3aGF0IHRoZXkgY2FuIGRvLCBhbmQg dGhlIEdTIHNob3VsZCBiZSBhYmxlIHRvIHRlbGwgdGhlbSB3aGljaCBvbmUgdG8gdXNlLiBJdOKA mXMgYSB2ZXJ5IHNpbXBsZSBidXQgcG93ZXJmdWwgaW5saW5lIG5lZ290aWF0aW9uLjxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPkkgZG9u4oCZdCBzZWUgdGhlIHZhbHVlIG9mIHRo ZSDigJxwb3B1cOKAnSBpbnRlcmFjdGlvbiBtb2RlLiBDbGllbnRzIGNhbiB1c2Ug4oCccmVkaXJl Y3TigJ0gbW9kZSB3aXRoaW4gcG9wdXBzLiBIb3dldmVyLCBzcGVha2luZyBhcyBzb21lb25lIHdo byBoYXMgZG9uZSB0aGF0LCBJIHJlYWxseSBkb27igJl0IHJlY29tbWVuZCBpdC4gUG9wdXBzDQog YXJlIGluY3JlYXNpbmdseSB1bnN1cHBvcnRlZCwgYW5kIHByb25lIHRvIHdlaXJkIGJlaGF2aW9y YWwgaXNzdWVzLiBJbi1hcHAgYnJvd3NlcnMgaW4gRmFjZWJvb2ssIFR3aXR0ZXIsIGV0Yy4gdGVu ZCB0byBoYXZlIHBvcHVwcyBkaXNhYmxlZC4gVGhlIGxhc3QgdmVyc2lvbnMgb2YgSUUgTW9iaWxl IGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwgKHRoZSBwb3BwZWQgdXAgcGFnZSBiYXNpY2Fs bHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVudA0KIHdpbmRvdykuIDxvOnA+PC9vOnA+PC9s aT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDEyLjY6PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwO1tFZGl0b3I6IGlzIHRoZXJlIHNvbWUgb3RoZXIgcmVhc29uIHRvIGhhdmUgdGhlIFVz ZXJJbmZvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50 P108bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBtYXkgd2FudCB0byBob3N0IG15 IFVzZXJJbmZvIGVuZHBvaW50IG9uIGEgc2VwYXJhdGUgbWljcm9zZXJ2aWNlIGZyb20gbXkgdG9r ZW4gZW5kcG9pbnQgKGluIE9BdXRoIDIuMC9PSURDIHRlcm1zKS4gVGhlIGZvcm1lciBtaWdodCBi ZSBwYXJ0IG9mIG15IHVzZXIgcHJvZmlsZS9kaXJlY3Rvcnkgc3RhY2ssIHdoaWxlIHRoZSBsYXR0 ZXIgaXMgcGFydCBvZiB0aGUgaGlnaGx5IHByaXZpbGVnZWQgYXV0aGVudGljYXRpb24vYXV0aG9y aXphdGlvbg0KIHN0YWNrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDEyLjg6PG86 cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpXaHkgaGF2ZSBib3RoIGNsYWltcyBhbmQg YXV0aG9yaXphdGlvbnM/KjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaGVyZSBhcmUgdXNlIGNhc2VzIGZvciBlYWNoIHRoYXQgYXJlIGluZGVwZW5kZW50 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdGlu ZyBhIHVzZXIgdnMgZ3JhbnRpbmcgYWNjZXNzIHRvIGEgcmVzb3VyY2UuJm5ic3A7IEE8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdCBmb3IgYW4gYXV0aG9y aXphdGlvbiByZXR1cm5zIGFuIGFjY2VzcyB0b2tlbiBvciBoYW5kbGUsPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWxlIGEgcmVxdWVzdCBmb3IgYSBjbGFpbSBy ZXR1cm5zIHRoZSBjbGFpbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27i gJl0IGFncmVlIHRoYXQgdGhlIHVzZSBjYXNlcyBhcmUgZGlzdGluY3QuIFRoZSBvbmx5IGNsYWlt IHRoYXQgaXMgc3RyaWN0bHkgbmVjZXNzYXJ5IGZvciBhdXRoZW50aWNhdGlvbiBpcyB0aGUgdXNl ciBpZGVudGlmaWVyLiBPdGhlciBjbGFpbXMgbGlrZSBlbWFpbCBhbmQgcGhvbmVfbnVtYmVyIGFy ZSBvZnRlbiB1c2VkIHRvIGFpZCBpbiBsb2NhbCBhY2NvdW50IGlkZW50aWZpY2F0aW9uIChpLmUu LCBhY2NvdW50DQogbGlua2luZyksIGJ1dCBhcmUgdXNlZnVsIGFuZCBpbnRlcmVzdGluZyBiZXlv bmQgdGhpcyB1c2UgY2FzZS4gT3RoZXIgY2xhaW1zIHN1Y2ggYXMgbmFtZSwgcHJlZmVycmVkX3Vz ZXJuYW1lLCBhbmQgYmlydGhkYXRlIGNvdWxkIGJlIHVzZWQgaW4gYSBzaW1pbGFyIGZhc2hpb24s IHRob3VnaCB0aGV5IGZyZXF1ZW50bHkgYXJlbuKAmXQuIFRoZSBzYW1lIGlzIHRydWUgZm9yIG90 aGVyIHJlc291cmNlcyBub3QgY3VycmVudGx5IGRlZmluZWQgYXMgY2xhaW1zDQogKGUuZy4sIHRo ZSBleHRlcm5hbElkIGVzdGFibGlzaGVkIHdoZW4gdGhlIHVzZXIgd2FzIGltcG9ydGVkIHRocm91 Z2ggU0NJTSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNsYWltcyBhcmUganVzdCByZXNvdXJj ZXMgdGhhdCBPSURDIHByb3ZpZGVzIGEgbmFtZSByZWdpc3RyeSBhbmQgc29tZSBleHRyYSBmZWF0 dXJlcyBmb3I6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+T3B0aW9uYWxseSBnZXQgdGhlIHZhbHVlIGJ1 bmRsZWQgd2l0aCB0aGUgYXV0aGVudGljYXRpb24gcmVzcG9uc2UsIHdpdGhvdXQgbmVlZGluZyB0 byBjYWxsIGEgc2VwYXJhdGUgZW5kcG9pbnQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvMSI+T3B0aW9uYWxseSBnZXQgdGhlIHZhbHVlIGluIGEgc2lnbmVkIG9yIGVuY3J5cHRlZCBi bG9iLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPk9wdGlvbmFsbHkgcHJvdmlk ZSBzb21lIHN0cnVjdHVyZWQgbWV0YWRhdGEgZGVzY3JpYmluZyB0aGUgcmVzb3VyY2UgYW5kL29y IHJlcXVlc3RlZCBhdXRob3JpemF0aW9uLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dOKAmXMgdGVsbGluZyB0aGF0IGFsbCBvZiB0aGVzZSBhcmUgb3B0aW9uYWwuIElmIHdlIHRoaW5r IHRoZXNlIGFyZSBmZWF0dXJlcyB3b3J0aCBicmluZ2luZyBmb3J3YXJkIGludG8gd2hhdGV2ZXIg cHJvdG9jb2wgd2UgcHJvZHVjZSB0aHJvdWdoIFR4QXV0aCwgd2Ugc2hvdWxkIGxvb2sgYXQgdGhl bSBpbmRlcGVuZGVudGx5IG9mIHRoZSBjbGFpbS9yZXNvdXJjZSBkaWNob3RvbXkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMTIuMTI6PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICpXaHkgY29tcGxpY2F0ZSB0aGUgc2VxdWVuY2Ugd2l0aCAmcXVvdDtpbnRlcmFjdGlv biZxdW90Oy4mcXVvdDtrZWVwJnF1b3Q7Pyo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3XigJlyZSB0cnlpbmcgdG8gc3VwcG9ydCBo ZXJlLCBidXQgSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdG9vIGNvbXBsaWNhdGVkIHRvIGltcGxl bWVudC4gRnJvbSB0aGUgc2VxdWVuY2VzLCBpdCBsb29rcyBsaWtlIHRoZSBDbGllbnQgaXMgZXhw ZWN0ZWQgdG8gaXNzdWUgYSBSZWFkIEdyYW50IHJlcXVlc3QsIGFuZCB0aGF0IGNvbm5lY3Rpb24g d2lsbCBiZSBrZXB0DQogb3BlbiB3aGlsZSB0aGUgVXNlciBpcyByZWRpcmVjdGVkIHRvIHRoZSBH UyBhbmQgZ29lcyB0aHJvdWdoIHRoZSBhdXRoZW50aWNhdGlvbiB3b3JrZmxvdyAoYW5kIHBvc3Np Ymx5IHBhcnQgb2YgdGhlIGF1dGhvcml6YXRpb24gd29ya2Zsb3cpLiBPbmx5IHRoZW4gd291bGQg dGhlIEdTIHJldHVybiB0aGUgUmVhZCBHcmFudCByZXNwb25zZS4gSXMgdGhpcyBjb3JyZWN0Pzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBpbXBsZW1lbnQgdGhpcywgdGhlIENsaWVudCBoYXMg dG8gbGF1bmNoIGFuIGFzeW5jaHJvbm91cyB0aHJlYWQgdG8gZXhlY3V0ZSB0aGF0IHJlcXVlc3Qg YW5kIGF3YWl0aW5nIHRoZSByZXNwb25zZS4gUG9zc2libGUsIGJ1dCBzdXNjZXB0aWJsZSB0byBm YWlsdXJlcy4gV2hhdCBoYXBwZW5zIGlmIHRoYXQgdGhyZWFkIGNyYXNoZXM/IE9yIGZhaWxzIHRv IHNlbmQgdGhlIFVwZGF0ZSBHcmFudCByZXF1ZXN0DQogdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVw IHRvIGZhbHNlPyBXaGF0IGlzIHRoZSBHUyBkb2luZyBpbiB0aGUgbWVhbnRpbWU/IElzIGl0IGp1 c3Qgc2hvd2luZyB0aGUgVXNlciBhIOKAnGxvYWRpbmfigJ0gd2lkZ2V0IGFzIGl0IHdhaXRzIGZv ciB0aGUgQ2xpZW50IHRvIHVwZGF0ZSB0aGUgZ3JhbnQ/IEhvdyBsb25nIGRvZXMgaXQgd2FpdCBm b3I/IEZvciBtb2JpbGUgYXBwcywgdGhhdCBiYWNrZ3JvdW5kIHRocmVhZCBtYXkgZ2V0IGtpbGxl ZCBvciBsb3NlDQogbmV0d29yayBjb25uZWN0aXZpdHkgYXMgc29vbiBhcyB0aGUgdXNlciBnZXRz IHN3aXRjaGVkIG92ZXIgdG8gdGhlIHN5c3RlbSBicm93c2VyIHRvIGxvYWQgdGhlIEdTIHNpZ24g aW4gcGFnZS4gRm9yIGEgcHVyZS1KUyBhcHAgdGhhdCByZWRpcmVjdHMsIEkgZG9u4oCZdCB0aGlu ayB0aGlzIGlzIHBvc3NpYmxlIGF0IGFsbC4gKHVubGVzcyB3ZWIgd29ya2VycyBjYW4gc3Vydml2 ZSBwYWdlIHVubG9hZHM/KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFuIGludGVy ZXN0aW5nIHVzZSBjYXNlIGZvciB1cyB0byB0aGluayBhYm91dCwgYnV0IGl0IG5lZWRzIGEgbG90 IG9mIHdvcmsgYW5kIG1heSBub3QgYmUgc29tZXRoaW5nIHdlIHNob3VsZCB0cnkgdG8gYmFrZSBp bnRvIHRoZSBjb3JlIHByb3RvY29sIGlmIHdlIGRvbuKAmXQgbmVlZCB0by48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2VjdGlvbiAxMi4xNDo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKldoeSB1c2UgVVJJcyB0byBpbnN0ZWFkIG9mIGhhbmRsZXMgZm9yIHRoZSBHcmFudCBhbmQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbj8q PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbuKAmXQgbGlrZSB0aGlzIHVu dGlsIEkgcmVhbGl6ZWQgdGhhdCB5b3XigJlyZSBkaXN0aW5ndWlzaGluZyBiZXR3ZWVuIGhhbmRs ZXMvVVJJcyBhbmQgdG9rZW5zLiBOb3cgdGhhdCBJ4oCZdmUgdGhvdWdodCBhYm91dCBpdCBtb3Jl LCBJIGxpa2UgdGhpcyBmcm9tIHRoZSBzdGFuZHBvaW50IHRoYXQgaXQgdW5kZXJzY29yZXMgdGhl IGlkZWEgb2YgR3JhbnRzIGFuZCBBdXRob3JpemF0aW9ucyBiZWluZyBwZXJzaXN0ZW50DQogb2Jq ZWN0cyB3aXRoaW4gdGhlIHByb3RvY29sLiBBbmQgaXTigJlzIHJlYWxseSBqdXN0IG1ha2luZyBw dWJsaWMgc29tZXRoaW5nIHRoYXQgdGhlIEdTIGlzIHByb2JhYmx5IGdvaW5nIHRvIGJlIGRvaW5n IHVuZGVyIHRoZSBob29kIGFueXdheS4gSG93ZXZlciwgd2UgaGF2ZSB0byBiZSBjYXJlZnVsIHRo YXQgd2UgZG9u4oCZdCBhY2NpZGVudGFsbHkgZW5jb3VyYWdlIGltcGxlbWVudGVycyB0byBzdGFy dCBzaG92aW5nIHRoaW5ncyBpbnRvIHRoZXNlIFVSSXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRl bnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9p ZGVudGl0eS8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24u Y29tL2lkZW50aXR5Lzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VHhhdXRoICZsdDt0eGF1dGgt Ym91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgJmx0O2RpY2suaGFy ZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDcsIDIw MjAgYXQgODowMCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7 ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltUeGF1dGhdIFhB dXRoIC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SSd2ZSBoZWF2aWx5IHJldmlzZWQgWEF1dGggYWdhaW4uIDxvOnA+DQo8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAyPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BIG51bWJlciBvZiBuZXcgaWRlYXMgdG8gYm91 bmNlIGFyb3VuZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JIGhhdmUgaW5jbHVkZWQgYSBidW5jaCBvZiBzZXF1ZW5jZXMgdG8gc2hvdyBkaWZmZXJlbnQg dXNlIGNhc2VzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlJhdGhlciB0aGFuIGEgdHJhbnNhY3Rpb24sIEkgdXNlIGEgR3JhbnQgYXMgdGhl IGNlbnRyYWwgb2JqZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlRoZSBpbnRlcmZhY2UgaXMgdmVyeSBSRVNUZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBBUyBpcyBub3cgYSBHcmFudCBTZXJ2ZXIg KEdTKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoaXMg YWxzbyBzZWVtZWQgYXBwcm9wcmlhdGUgYXQgaXQgaXMgYm90aCBhbiBPQXV0aCBBUywgYW5kIGFu IE9JREMgT1AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ UmF0aGVyIHRoYW4gYSBoYW5kbGUsIHRoZSBHcmFudCBoYXMgYSBVUkkuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGVuZHBvaW50IFVSSSBm b3IgdGhlIEdTIGlzIHRoZSBHUyBVUkksIGFuZCBpcyB0aGUgR1MgaWRlbnRpZmllci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbiBhY2Nlc3MgdG9rZW4s IHJlZnJlc2ggdG9rZW4gZXRjLiBhcmUgYWxsIGFuIEF1dGhvcml6YXRpb24uIEFuIEF1dGhvcml6 YXRpb24gaGFzIGFuIEF1dGhaIFVSSS4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlIEdyYW50IFVSSSBhbmQgQXV0aFogVVJJIGFsbCBzdGFydCB3aXRo IHRoZSBHUyBVUkkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+QSBHcmFudCBpcyBjcmVhdGVkIGJ5IGRvaW5nIGEgUE9TVCB0byB0aGUgR1MgVVJJLCByZXR1 cm5pbmcgYSBHcmFudCBVUkkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+TWV0YWRhdGEgZm9yIHRoZSBHUyBpcyBkb25lIHdpdGggYW4gT1BUSU9OUyB0byB0 aGUgR1MgVVJJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlRoZSBDbGllbnQgY2FuIGRvIEdFVCwgVVBEQVRFLCBhbmQgREVMRVRFIGFnYWluc3QgYSBHcmFu dCBVUkkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4g YWNjZXNzIHRva2VuIHJlZnJlc2ggaXMgYSBHRVQgb24gdGhlIEF1dGhaIFVSSS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFkZGluZyBpbiBS ZWNpcHJvY2FsIE9BdXRoIGZ1bmN0aW9uYWxpdHkgd2FzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRo YW4gaW4gT0F1dGggMi4wIC0tIGJ1dCBub3QgYXMgc3RyYWlnaHQgZm9yd2FyZCBhcyBJIHdvdWxk IGxpa2UgLS0gYnV0IG5vdCBjbGVhciBob3cgdG8gbWFrZSBpdCBiZXR0ZXIgYW5kIHN0YXJ0IGZy b20gdGhlIENsaWVudCBhbmQgR1MgaGF2aW5nIGNvbnRleHQNCiBvZiBvbmUgYXV0aG9yaXphdGlv biBiZWZvcmUgc3dhcHBpbmcgcm9sZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+UGVyIG15IGxhc3QgZW1haWxzLCBuYW1pbmcgaXMgaGFyZCwgdGhlcmUg YXJlIGxpa2VseSBsb3RzIG9mIG1pc3Rha2VzLCBhbmQgbG90cyBvZiBhc3BlY3RzIHRoYXQgbmVl ZCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEhvcGVmdWxseSB0aGUgY29uY2VwdHMgY29tZSB0aHJvdWdo ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi9EaWNrPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_58F0F4E4E9AE45E092F160B993B75A34amazoncom_-- From nobody Tue Feb 11 11:43:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60712081A for ; Tue, 11 Feb 2020 11:43:18 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 T3clT1ebmr9P for ; Tue, 11 Feb 2020 11:43:13 -0800 (PST) Received: from sonic317-32.consmr.mail.ne1.yahoo.com (sonic317-32.consmr.mail.ne1.yahoo.com [66.163.184.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 9EC0312081C for ; Tue, 11 Feb 2020 11:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1581450191; bh=IFMZcAh3gdqdm9rxxl/m8kkWPfpEn/yuYbBDtetuQAM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=uSbDVeLKY1U3hvBQ1UM5CKh3JoyYY6cO1RLJxzhQQuEjnn8IeTWA+dOacLVJ4qlwWUIbi7X/GLmthBXbEY2dwKKU+lZHqCEGkj1s7GFOGV7JDkHrQoK7cvhdKsR7vMc59SOGEFtVNdPIdY5qe1d5iJ8rBS/0plktFkR4OSh6OgXZrf/uUyoX1OmsUhtTknZmx9CpjkEgVfVasQGOFEhXHvMRRJ1VQMGbVYWYMvO/Zk+Um9OGATH0darb83daIKsvJP3xG3b769viKrEmoIbf5ClKe3B+B74esEHA4bypW1ASCNfT1SLIBPXMbWjdZczDyBeEEHCUhSQm9TPF35aVkQ== X-YMail-OSG: vUsuaMoVM1mFOadqKDMD09iBv8MrUZq45Llt_U.F6baYEMla8GNUjvFyhN.qBN5 ETL_dMgwcOFLgrYUv7EChn.fYLdKcxhTVdmBc9bFYveYLwtHCBeECd0V_mg5gCnMzswXR68QEII6 zRDavvR_R9fBnfYOOIDsryaoEp31xRanphBHR4R3a2K2t5PBuyjaopm_HEGXPvJnY8eXseHqDPub mLobMXdVaUmyzAEbg7VComPasfj9YEHbdpbyXzm6URReghC.FW.zHDrRdIaQFoy0m2rqKGg9ysY1 I9cAfYhtwA5nRL60kXdhzIBShfxv2qmaM91ghXsFY8UkvW8OoUMkBt0Xl8WG74cIERroujduiC11 i6Eoxzg9zAqJGDkIP7R5ANKDbulKT.82WJr9nRA8iks0zQ.vKYV_45W9P1528EMO7l6MVsQbmh_B AX2MFh6HogU_WCU1ijKFLXeIq_dayKZX_2IkH0fyAaWB5y13iUjzsymwhW1J.GkDyZFW55_mm6JZ FaNGZtSdwaUJAKa5OPcUuehc3WpuXqOSf.j0vAY5VqdezROFnlcD259VSrj9Lc1Z4yk1keoet6Jz kDoEXFqTsKOFUPPnJKMnIbKAgYNyyhQuILq89Jcu2_O06iVmYKXlEUXDnVVI6amGaKID4yZum7dE dHRohgvP4klUc7AHfWkeYzAi14KXkb_9Dmq9lsM13OkYKY01v628ytqnvpMKqzm6fhuAH2.7oXLb 3EZ1I6Ta3veEqCeYxRUBm62GOIfgq6N0WR2nSflza3jhpQsyQjiicXMydb5_w6nX6h6O.KI19ilk R6BMks6b00Wm5IRdcal2LIiVbk0VSSfvtttYW232qrwlxoYRGt.ge_2m.W.rCEm96h95jArVLrsW 7CcbOG.Vq_H3UWemjHrR3rUMcqD10a2eY8026leVwbQCFeP3DhR63O50ZnPy.vAoj5Qw5I27GyHY NddEFjazmQSOFdcqNrFaydg1LGC6ZQdg_CfvxDQrvU7PzZ3CvxpHyANSFZYSt_VebeCwTHdX_QPI kqfuX_bIJ4HfRO12AO0jOXjptcp73vaYzh2Z5RfzcNzTICW8.s3Bdp3e7.nNccX4YRbwLQ5ROow. A43hiOEjWvQUyyhzYKk35DEAcJZHZSeV3XOfvKQCSiVegc8onJdS7VSYynr3fnveaSAqy8RqvUGo NGhTbNlJgHwFo.01vWwlIIIcXFhok1_SYdr_muW8vtyA.lh3GnXlth_DoZRDwrswy6kKA912Pvv3 50DDWw_v.9UNakD38mBPw8e6vzYIH0XmF2UEVJe_cxTLY9o11KdZ2cC6btFaixtulXJyB4DpqWBu .CuRoC_nxnXFYBsjqoxDdni4adun0eEGWARhhTu8YFXkRHe4fraFe7Fi47IUo0bi2AzOycokkyzH zqp6.iwF20JyFfstCkU2clIauVtM5AXAoG.g- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Tue, 11 Feb 2020 19:43:11 +0000 Received: by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7f3cc7feab28a0c6c997e43f39227d86; Tue, 11 Feb 2020 19:43:06 +0000 (UTC) To: Justin Richer , txauth@ietf.org References: From: George Fletcher Organization: AOL LLC Message-ID: <0e6f4439-684a-71be-d8f2-ce29effd65f2@aol.com> Date: Tue, 11 Feb 2020 14:43:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------350C4997998255ED3286A5CE" Content-Language: en-US X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Archived-At: Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 19:43:19 -0000 This is a multi-part message in MIME format. --------------350C4997998255ED3286A5CE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm also +1. I'm looking forward to the discussion in Vancouver! On 2/7/20 11:58 AM, Justin Richer wrote: > I’ve updated the proposed charter text based on feedback and > conversation here on the list: > > > This group is chartered to develop a fine-grained delegation > protocol for authorization, identity, and API access. This > protocol will allow an authorizing party to delegate access to > client software through an authorization server. It will expand > upon the uses cases currently supported by OAuth 2.0 and OpenID > Connect (itself an extension of OAuth 2.0) to support > authorizations scoped as narrowly as a single transaction, provide > a clear framework for interaction among all parties involved in > the protocol flow, and remove unnecessary dependence on a browser > or user-agent for coordinating interactions. > > The delegation process will be acted upon by multiple parties in > the protocol, each performing a specific role. The protocol will > decouple the interaction channels, such as the end user’s browser, > from the delegation channel, which happens directly between the > client and the authorization server (in contrast with OAuth 2.0 > which is initiated by the client redirecting the user’s browser). > The client and AS will involve a user to make an authorization > decision as necessary through interaction mechanisms indicated by > the protocol. This decoupling avoids many of the security concerns > and technical challenges of OAuth 2.0 and provides a non-invasive > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single > interaction > - Separation between the party authorizing access and the party > operating the client requesting access > - A variety of client applications, including Web, mobile, > single-page, and interaction-constrained applications > > The group will define extension points for this protocol to allow > for flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanism for conveying user, software, organization, and other > pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the > delegation process (including identity) > > Additionally, the group will provide mechanisms for management of > the protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected > to be backwards-compatible with OAuth 2.0 or OpenID Connect, the > group will attempt to simplify migrating from OAuth 2.0 and OpenID > Connect to the new protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, > and as such will focus on new technological solutions not > necessarily compatible with OAuth 2.0. Functionality that builds > directly on OAuth 2.0 will be developed in the OAuth Working > Group, including functionality back ported from TxAuth to OAuth 2.0. > > The group is chartered to develop mechanisms for applying > cryptographic methods, such as JOSE and COSE, to the delegation > process. This group is not chartered to develop new cryptographic > methods. > > The initial work will focus on using HTTP for communication > between the client and the authorization server, taking advantage > of optimization features of HTTP2 and HTTP3 where possible, and > will strive to enable simple mapping to other protocols such as > COAP when doing so does not conflict with the primary focus. > > Milestones to include: >  - Core delegation protocol >  - Key presentation mechanism bindings to the core protocol for > TLS, detached HTTP signature, and embedded HTTP signatures >  - Identity and authentication conveyance mechanisms >  - Guidelines for extension points > > > > > We’ve scheduled a BoF for Vancouver, and there’s a chance we can maybe > get a charter approved and WG spun up in time to have an official > meeting. Either way, we’ll be meeting to discuss TxAuth. > >  — Justin > --------------350C4997998255ED3286A5CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'm also +1. I'm looking forward to the discussion in Vancouver!

On 2/7/20 11:58 AM, Justin Richer wrote:
I’ve updated the proposed charter text based on feedback and conversation here on the list:


This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. 

The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which is initiated by the client redirecting the user’s browser). The client and AS will involve a user to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Separation between the party authorizing access and the party operating the client requesting access
- A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications

The group will define extension points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession 
- User interaction mechanisms including web and non-web methods
- Mechanism for conveying user, software, organization, and other pieces of information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation process (including identity)

Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back ported from TxAuth to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. 

The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus.

Milestones to include:
 - Core delegation protocol
 - Key presentation mechanism bindings to the core protocol for TLS, detached HTTP signature, and embedded HTTP signatures
 - Identity and authentication conveyance mechanisms
 - Guidelines for extension points




We’ve scheduled a BoF for Vancouver, and there’s a chance we can maybe get a charter approved and WG spun up in time to have an official meeting. Either way, we’ll be meeting to discuss TxAuth.

 — Justin


--------------350C4997998255ED3286A5CE-- From nobody Wed Feb 12 18:34:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E21E120044 for ; Wed, 12 Feb 2020 18:34:55 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqHe6UIiWhjz for ; Wed, 12 Feb 2020 18:34:52 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 9D158120043 for ; Wed, 12 Feb 2020 18:34:51 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id t23so3077555lfk.6 for ; Wed, 12 Feb 2020 18:34:51 -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=XBxck7BGi+TbFb8YBYcTR+uzVUNQC4owk4qXnHaKgvQ=; b=uoReipGkmS22WEPiwYQSpyVK2EenZ1aWJkBmVTNJz8lEH2HB0cfKxS9Xh/oIQ+CvOG Hk1mRoDeG0wPQJ5SfbsgH96oKGP7ycO8M3cPB/4f6RlZCm0u/08UJTuswLBVfZtP86BU hUkb2TOZdbt7EjUWRA8i7dFVlTcmCNym61m+bK4WCow8l6FYQd+Zs3AZfDP5SXXWt3Y6 F0F2lfCXAowiCNTlsYbQwNX9+UanmGtBLVbL6UFfBQYQfTja+PT87WF72X5FnBAjr5U5 jreCxunUGCv/p6krZMv1Jei+MOPY3rsdHwBaFyYjAla2sjNl+VFv+XOihXaf0+U1dK/x pUIg== 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=XBxck7BGi+TbFb8YBYcTR+uzVUNQC4owk4qXnHaKgvQ=; b=H68lWLK0auLjODx8CyWaUmCCwOieDBMRWoH3JBoVvtl1tgMXCGRS683TmBh3/421Q5 pPNUTcbyVLPEJyUy6u7bKssrsg8+esNXoF+j58E8DBBLoCSX2t9dSP+xws/qj+HcOJRv ydPDNzoLM6wnYPuQ0biaGjFKkmzrIfC02V5cj0IP9AZNcova4vJeMxg+sFBpT5GpKwkW tobClmPZnGRdkMDQAA74DeJJVBhGNjlART5b3byaAlAMiou1lBimfWEokZxxUsBu8t/c yvLxaT8f2GBwv/iVhpimgBzr7y5vyssozGmlcdrU2BDz97jT16YXaU+LTIPCDqG64Js4 G7rg== X-Gm-Message-State: APjAAAVA1Ud9YJkDbOw355RmUUh5FMJOqCFOYXICRCaDtdIt7WRe5LAY p5gkUNi7gH5yH0VnFSP+Y8dHGMOqExQXipElGdE= X-Google-Smtp-Source: APXvYqwT+3gD/IdS23ZklN7ZLpLt6MCAf5ZIbweDI3RMbQlheG0/CEbip5eLPlhNPCmwTfGbKYNmyZPBMwgKakYyvOM= X-Received: by 2002:ac2:531b:: with SMTP id c27mr8103020lfh.91.1581561289637; Wed, 12 Feb 2020 18:34:49 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> In-Reply-To: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> From: Dick Hardt Date: Wed, 12 Feb 2020 18:34:23 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dc0688059e6beea5" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 02:34:55 -0000 --000000000000dc0688059e6beea5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback Annabelle, sorry for the delay in responding. Comments and questions inserted: On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > Interesting work. I am enjoying the fact that we have two different takes > on the same problem. The comparisons and discussions will lead us to a > better overall solution. > That was my goal of publishing the draft! > > > Here are my comments on XAuth-02: > > > > Section 2.1: > > * *Resource Owner* (RO) - owns the RS, and has delegated RS access > > management to the GS. The RO may be the same entity as the User, > ... > > > > I=E2=80=99m rather baffled by this definition, and wondering if it=E2=80= =99s a mistake or > if I=E2=80=99m misinterpreting it. Is this an intentional departure from = how =E2=80=9CRO=E2=80=9D > is typically used within the OAuth 2.0 space? Usually the term RO refers = to > the entity that owns the specific resources the client is requesting > authorization for. The RO does not typically own the RS itself. > Mistake. Thanks for catching! > > > Section 5.5.2: > > The interaction object contains the type of interaction the Client > > will provide the User. Other attributes > > > > - *type* - contains one of the following values: "popup", > > "redirect", or "qrcode".... > > > > 3 issues with this: > > 1. How would I do a user code-based interaction? > > To clarify, the User is entering a code in the Client into the GS, or the User is entering a code into the Client? If the prior, the QR code also allows a message. I'm envisioning a User with a mobile phone can scan the QR code which contains a URL at the GS, and includes the code. The message would describe what to do and include the code. > > 1. > 2. Clients support multiple interaction modes and may not always know > what the GS supports (and vice-versa). For a multi-tenant GS, it may v= ary > by tenant configuration. Clients should be able to say what they can d= o, > and the GS should be able to tell them which one to use. It=E2=80=99s = a very simple > but powerful inline negotiation. > > That is what is in TxAuth. Would you elaborate on how the GS might be constrained? Why would the GS not be able to do all? I would think all constraints would be at the Client. Am I missing something? > > 1. > 2. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D intera= ction mode. Clients can > use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking a= s someone who has > done that, I really don=E2=80=99t recommend it. Popups are increasingl= y > unsupported, and prone to weird behavioral issues. In-app browsers in > Facebook, Twitter, etc. tend to have popups disabled. The last version= s of > IE Mobile didn=E2=80=99t support them at all (the popped up page basic= ally just > loaded into the current window). in > > Popups are really useful in single-page apps as you want to keep the context and not reload the page. Agree that popups don't make sense in mobile. A full redirect does of course. A single-page app on mobile would open a new tab which would be a separate context rather than a redirect. > > 1. > > > > Section 12.6: > > [Editor: is there some other reason to have the UserInfo > > endpoint?] > > > > I may want to host my UserInfo endpoint on a separate microservice from m= y > token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my > user profile/directory stack, while the latter is part of the highly > privileged authentication/authorization stack. > The token endpoint has the access token anyway, so it can fetch the data from the other endpoint itself if it wanted to. IE, there is no separation of duties. What are the advantages of the UserInfo endpoint to the User or Client? The UserInfo endpoint seems to just add more complexity, with no ability to start a User interaction if additional consent is needed. > > > Section 12.8: > > *Why have both claims and authorizations?* > > > > There are use cases for each that are independent: > > authenticating a user vs granting access to a resource. A > > request for an authorization returns an access token or handle, > > while a request for a claim returns the claim. > > > > I don=E2=80=99t agree that the use cases are distinct. The only claim tha= t is > strictly necessary for authentication is the user identifier. Other claim= s > like email and phone_number are often used to aid in local account > identification (i.e., account linking), but are useful and interesting > beyond this use case. > Some Clients use email and phone_number as the identifier and don't pay attention to the directed identifier. Not the best practice, but it is what people do. > Other claims such as name, preferred_username, and birthdate could be use= d > in a similar fashion, though they frequently aren=E2=80=99t. The same is = true for > other resources not currently defined as claims (e.g., the externalId > established when the user was imported through SCIM). > > > > Claims are just resources that OIDC provides a name registry and some > extra features for: > > - Optionally get the value bundled with the authentication response, > without needing to call a separate endpoint. > > In my opinion, all the different ways to get claims in OIDC is a bug, no= t a feature. With the optionality at the OP, a generic Client has to support both. > > - > - Optionally get the value in a signed or encrypted blob. > > This optionality is useful to the Client, as it can decide what claims should be in the signed blob which may be used differently than other claims. > - > - Optionally provide some structured metadata describing the resource > and/or requested authorization. > > > > - > > > > It=E2=80=99s telling that all of these are optional. If we think these ar= e > features worth bringing forward into whatever protocol we produce through > TxAuth, we should look at them independently of the claim/resource > dichotomy. > I agree that these features are orthogonal to the "are claims and resources the same thing" debate. I strongly think it is a disservice to our audience to conflate claims and resources. Claims are statements about the User and read-only. Resources are independent of the GS. The Client may be able to do all of CRUD on the resource. While there is overlap with the UserInfo endpoint that it could be considered a resource, I don't think that helps the audience. The language in XAuth can definitely use improvement to provide more clarity here. > > > Section 12.12: > > *Why complicate the sequence with "interaction"."keep"?* > > > > I understand the use case you=E2=80=99re trying to support here, but I th= ink the > proposal is too complicated to implement. From the sequences, it looks li= ke > the Client is expected to issue a Read Grant request, and that connection > will be kept open while the User is redirected to the GS and goes through > the authentication workflow (and possibly part of the authorization > workflow). Only then would the GS return the Read Grant response. Is this > correct? > > > > To implement this, the Client has to launch an asynchronous thread to > execute that request and awaiting the response. > Possible, but susceptible to failures. What happens if that thread crashes? > Or fails to send the Update Grant request to flip interaction.keep to > false? What is the GS doing in the meantime? Is it just showing the User = a > =E2=80=9Cloading=E2=80=9D widget as it waits for the Client to update the= grant? How long > does it wait for? For mobile apps, that background thread may get killed = or > lose network connectivity as soon as the user gets switched over to the > system browser to load the GS sign in page. For a pure-JS app that > redirects, I don=E2=80=99t think this is possible at all. (unless web wor= kers can > survive page unloads?) > > > > This is an interesting use case for us to think about, but it needs a lot > of work and may not be something we should try to bake into the core > protocol if we don=E2=80=99t need to. > It might not have been obvious, but the Client calling the GS to get a result while the interaction is happening is what happens in any flow with an interaction started by the Client. It is not unique to "interaction"."keep" -- we are just adding additional back and forths between the Client and GS. A QR Code example HAS to work this way, as there is no other way for the Client to know the interaction has completed. Google and Microsoft both have a similar user experience. The User wants to log into an app -- they are instructed to go to the respective mobile app to approve the authentication -- and then the User returns to the app which changes to a logged in state. An authentication only flow using XAuth would work the same way. > > > Section 12.14: > > *Why use URIs to instead of handles for the Grant and > > Authorization?* > > > > I didn=E2=80=99t like this until I realized that you=E2=80=99re distingui= shing between > handles/URIs and tokens. Now that I=E2=80=99ve thought about it more, I l= ike this > from the standpoint that it underscores the idea of Grants and > Authorizations being persistent objects within the protocol. > :) > And it=E2=80=99s really just making public something that the GS is proba= bly going > to be doing under the hood anyway. However, we have to be careful that we > don=E2=80=99t accidentally encourage implementers to start shoving things= into > these URIs. > The URI content is intended to be opaque. There would be security considerations would keep people from putting visible stuff in there they shouldn't. I would expect implementations to use a random value with a checksum, or a JWT. > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, February 7, 2020 at 8:00 PM > *To: *"txauth@ietf.org" > *Subject: *[Txauth] XAuth -02 > > > > I've heavily revised XAuth again. > > > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02 > > > > A number of new ideas to bounce around: > > > > I have included a bunch of sequences to show different use cases possible= . > > > > Rather than a transaction, I use a Grant as the central object. > > > > The interface is very RESTful. > > > > The AS is now a Grant Server (GS) > > > > This also seemed appropriate at it is both an OAuth AS, and an OIDC OP. > > > > Rather than a handle, the Grant has a URI. > > > > The endpoint URI for the GS is the GS URI, and is the GS identifier. > > > > An access token, refresh token etc. are all an Authorization. An > Authorization has an AuthZ URI.. > > > > The Grant URI and AuthZ URI all start with the GS URI. > > > > A Grant is created by doing a POST to the GS URI, returning a Grant URI. > > > > Metadata for the GS is done with an OPTIONS to the GS URI. > > > > The Client can do GET, UPDATE, and DELETE against a Grant URI. > > > > An access token refresh is a GET on the AuthZ URI. > > > > Adding in Reciprocal OAuth functionality was more straightforward than in > OAuth 2.0 -- but not as straight forward as I would like -- but not clear > how to make it better and start from the Client and GS having context of > one authorization before swapping roles. > > > > Per my last emails, naming is hard, there are likely lots of mistakes, an= d > lots of aspects that need normative language. Hopefully the concepts come > through! > > > > /Dick > =E1=90=A7 --000000000000dc0688059e6beea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback Annabelle, sorry for the dela= y in responding.

Comments and questions inserted:<= /div>
O= n Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle <richanna@amazon.com> wro= te:

Interesting work. I am enjoying the fact that we hav= e two different takes on the same problem. The comparisons and discussions = will lead us to a better overall solution.


That was my goal of publishing the draft!
=C2=A0<= /div>
=

=C2=A0

Here are my comments on XAuth-02:

=C2=A0

Section 2.1:

=C2=A0=C2=A0 *=C2=A0 *Resource Owner* (RO) - own= s the RS, and has delegated RS access

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 management to the= GS.=C2=A0 The RO may be the same entity as the User, ...

=C2=A0

I=E2=80=99m rather baffled by this definition, and w= ondering if it=E2=80=99s a mistake or if I=E2=80=99m misinterpreting it. Is= this an intentional departure from how =E2=80=9CRO=E2=80=9D is typically u= sed within the OAuth 2.0 space? Usually the term RO refers to the entity th= at owns the specific resources the client is requesting authorization for. Th= e RO does not typically own the RS itself.


Mistake. Thanks for catching!
=C2=A0

=C2=A0

Section 5.5.2:

=C2=A0=C2=A0 The interaction object contai=
ns the type of interaction the Client
=C2=A0=C2=A0 will provide the User.=C2=A0 =
Other attributes
<snip>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 -=C2=A0 *type* - contains one of the following values: "popup",<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =C2=A0=C2=A0=C2=A0"redirect", or "qrcode"....

=C2=A0

3 issues with this:

  1. How would I do a user code-based interaction?=
To clarify, the User is entering a = code in the Client into the GS, or the User is entering a code into the Cli= ent?=C2=A0

If the prior, the QR code also allows a= message. I'm envisioning a User with a mobile phone can scan the QR co= de which contains a URL at the GS, and includes the code.=C2=A0
<= br>
The message would describe what to do and include the code.
=C2=A0
  1. Clients support multiple interaction modes and may not always know what t= he GS supports (and vice-versa). For a multi-tenant GS, it may vary by tena= nt configuration. Clients should be able to say what they can do, and the GS should be able to tell them wh= ich one to use. It=E2=80=99s a very simple but powerful inline negotiation.=

That is what is in T= xAuth. Would you elaborate on how the GS might be constrained? Why would th= e GS not be able to do all?

I would think all cons= traints would be at the Client. Am I missing something?
=C2=A0
  2. I don=E2=80= =99t see the value of the =E2=80=9Cpopup=E2=80=9D interaction mode. Clients= can use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking a= s someone who has done that, I really don=E2=80=99t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app= browsers in Facebook, Twitter, etc. tend to have popups disabled. The last= versions of IE Mobile didn=E2=80=99t support them at all (the popped up pa= ge basically just loaded into the current window). in=C2=A0

Po= pups are really useful in single-page apps as you want to keep the context = and not reload the page.

Agree that popups don'= ;t make sense in mobile. A full redirect does of course. A single-page app = on mobile would open a new tab which would be a separate context rather tha= n a redirect.
=C2=A0

=C2=A0

Section 12.6:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0[Editor: is there some other reason to have the UserInfo
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 endpoint?]

=C2=A0

I may want to host my UserInfo endpoint on a separat= e microservice from my token endpoint (in OAuth 2.0/OIDC terms). The former= might be part of my user profile/directory stack, while the latter is part= of the highly privileged authentication/authorization stack.



The = token endpoint has the access token anyway, so it can fetch the data from t= he other endpoint itself if it wanted to. IE, there is no separation of dut= ies.

What are the advantages of the UserInfo endpo= int to the User or Client?=C2=A0

The UserInfo endp= oint seems to just add more complexity, with no ability to start a User int= eraction if additional consent is needed.

=C2=A0
<= div>

=C2=A0

Section 12.8:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 *Why have both claims and authorizations?*
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 There are use cases for each that are independent:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 authenticating a user vs granting access to a resource.=C2=A0 A<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 request for an authorization returns an access token or handle,<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 while a request for a claim returns the claim.


=C2=A0


I don=E2=80=99t agree that the use cases are distinc=
t. The only claim that is strictly necessary for authentication is the user=
 identifier. Other claims like email and phone_number are often used to aid=
 in local account identification (i.e., account
 linking), but are useful and interesting beyond this use case.

Some Clients use email and phone_numbe= r as the identifier and don't pay attention to the directed identifier.= Not the best practice, but it is what people do.
=C2=A0

Other claims such as name, preferred_username, and bir= thdate could be used in a similar fashion, though they frequently aren=E2= =80=99t. The same is true for other resources not currently defined as clai= ms (e.g., the externalId established when the user was imported through SCIM)= .

=C2=A0

Claims are just resources that OIDC provides a name = registry and some extra features for:

  • Optionally get the value bundled with the aut= hentication response, without needing to call a separate endpoint.
=C2=A0In my opinion, all the different ways = to get claims in OIDC is a bug, not a feature. With the optionality at the = OP,=C2=A0 a generic Client has to support both.

=C2=A0
  • Optio= nally get the value in a signed or encrypted blob.
This optionality is useful to the Client, as it can decide w= hat claims should be in the signed blob which may be used differently than = other claims.

  • Optionally provide some structured metadata describing the resource= and/or requested authorization.
=C2=A0
<= div lang=3D"EN-US">

=C2=A0

It=E2=80=99s telling that all of these are optional.= If we think these are features worth bringing forward into whatever protoc= ol we produce through TxAuth, we should look at them independently of the c= laim/resource dichotomy.


I = agree that these features are orthogonal to the "are claims and resour= ces the same thing" debate.=C2=A0

I strongly = think it is a disservice to our audience to conflate claims and resources. = Claims are statements about the User and read-only.

Resources are independent of the GS. The Client may be able to do all of = CRUD on the resource.=C2=A0

While there is overlap= with the UserInfo endpoint that it could be considered a resource, I don&#= 39;t think that helps the audience.

The language i= n XAuth can definitely use improvement to provide more clarity here.
<= div>
=C2=A0

=C2=A0

Section 12.12:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 *Why complicate the sequence with "interaction"."keep"=
?*

=C2=A0

I understand the use case you=E2=80=99re trying to s= upport here, but I think the proposal is too complicated to implement. From= the sequences, it looks like the Client is expected to issue a Read Grant = request, and that connection will be kept open while the User is redirected to the GS and goes through the authentic= ation workflow (and possibly part of the authorization workflow). Only then= would the GS return the Read Grant response. Is this correct?

=C2=A0

To implement this, the Client has to launch an async= hronous thread to execute that request and awaiting the response.

=

Possible, but susceptible to fail= ures. What happens if that thread crashes? Or fails to send the Update Gran= t request to flip interaction.keep to false? What is the GS doing in the meantime? I= s it just showing the User a =E2=80=9Cloading=E2=80=9D widget as it waits f= or the Client to update the grant? How long does it wait for? For mobile ap= ps, that background thread may get killed or lose network connectivity as soon as the user gets switched over to the system = browser to load the GS sign in page. For a pure-JS app that redirects, I do= n=E2=80=99t think this is possible at all. (unless web workers can survive = page unloads?)

=C2=A0

This is an interesting use case for us to think abou= t, but it needs a lot of work and may not be something we should try to bak= e into the core protocol if we don=E2=80=99t need to.


It might not have been obvious, but the Client c= alling the GS to get a result while the interaction is happening is what ha= ppens in any flow with an interaction started by the Client. It is not uniq= ue to "interaction"."keep" -- we are just adding additi= onal back and forths between the Client and GS.

A = QR Code example HAS to work this way, as there is no other way for the Clie= nt to know the interaction has completed.

Google a= nd Microsoft both have a similar user experience. The User wants to log int= o an app -- they are instructed to go to the respective mobile app to appro= ve the authentication -- and then the User returns to the app which changes= to a logged in state.=C2=A0 An authentication only flow using XAuth would = work the same way.

=C2=A0

=C2=A0

Section 12.14:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 *Why use URIs to instead of handles for the Grant and=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Authorization?*

=C2=A0

I didn=E2=80=99t like this until I realized that you= =E2=80=99re distinguishing between handles/URIs and tokens. Now that I=E2= =80=99ve thought about it more, I like this from the standpoint that it und= erscores the idea of Grants and Authorizations being persistent objects within the protocol.


<= div>:)
=C2=A0

And it=E2=80=99s really= just making public something that the GS is probably going to be doing und= er the hood anyway. However, we have to be careful that we don=E2=80=99t ac= cidentally encourage implementers to start shoving things into these URIs.<= /p>


The URI content is intended= to be opaque. There would be security considerations would keep people fro= m putting visible stuff in there they shouldn't.

I would expect implementations to use a random value with a checksum, or= a JWT.
=C2=A0

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 7, 2020 at 8:00 PM
To: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: [Txauth] XAuth -02

=C2=A0

I've heavily revised= XAuth again.

=C2=A0

https://too= ls.ietf.org/html/draft-hardt-xauth-protocol-02

=C2=A0

A number of new ideas to= bounce around:

=C2=A0

I have included a bunch = of sequences to show different use cases possible.

=C2=A0

Rather than a transactio= n, I use a Grant as the central object.

=C2=A0

The interface is very RE= STful.

=C2=A0

The AS is now a Grant Se= rver (GS)

=C2=A0

This also seemed appropr= iate at it is both an OAuth AS, and an OIDC OP.

=C2=A0

Rather than a handle, th= e Grant has a URI.=C2=A0

=C2=A0

The endpoint URI for the= GS is the GS URI, and is the GS identifier.

=C2=A0

An access token, refresh= token etc. are all an Authorization. An Authorization has an AuthZ URI..

=C2=A0

The Grant URI and AuthZ = URI all start with the GS URI.

=C2=A0

A Grant is created by do= ing a POST to the GS URI, returning a Grant URI.

=C2=A0

Metadata for the GS is d= one with an OPTIONS to the GS URI.

=C2=A0

The Client can do GET, U= PDATE, and DELETE against a Grant URI.

=C2=A0

An access token refresh = is a GET on the AuthZ URI.

=C2=A0

Adding in Reciprocal OAu= th functionality was more straightforward than in OAuth 2.0 -- but not as s= traight forward as I would like -- but not clear how to make it better and = start from the Client and GS having context of one authorization before swapping roles.

=C2=A0

Per my last emails, nami= ng is hard, there are likely lots of mistakes, and lots of aspects that nee= d normative language. Hopefully the concepts come through!

=C2=A0

/Dick

3D""= =E1=90=A7
--000000000000dc0688059e6beea5-- From nobody Thu Feb 13 00:57:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207D41200C7 for ; Thu, 13 Feb 2020 00:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swissre.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJOm5_X-pt8I for ; Thu, 13 Feb 2020 00:57:37 -0800 (PST) Received: from esa6.hc1106-67.c3s2.iphmx.com (esa6.hc1106-67.c3s2.iphmx.com [139.138.36.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D82120045 for ; Thu, 13 Feb 2020 00:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1581584257; x=1613120257; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5fJZSxWAE6PZRu/T/cVr8C+2sLM4JbK4KsRxdDfNGFY=; b=S+50Yz3dGM85LjmWKU8xgtg70bIbfs7/SY3nmjYobzhe/li3TVpsLCwQ irH/UHjEM/JsJo98MW4jUdSOGqhKYLB/8WFkal4CKJB8QPqdKjaEHokbD +XNYNnXN5dKGSevyR9qwZDrqfgcDK/hnJiI9PaCGhLUoVoRU5Utd8nyo/ Fesl7B/c0y+2lz81MBLH7/TKb7F+BQAUeChwXW7QilkHdgnkyQ1+hDxiM LJqYX8PIIJTTnqx8KAQAtDC4tKfN8XerZjB1d2a3gUCIX4xXNSAGW2lcZ Qze2pEhweVVkr57ffETOQh7ial21S6bd4T7Lxl5xWIi6dEYLG9oJHK7sj w==; IronPort-SDR: ExxUErr36LZnhzLl5qhhB+B2xBextiwRaAtgktm5AN7tAwL+Z/631CdJwsRbtss2trJI44TRWU Yf1R1AC8frYfcmITns1h10LavSdShuAPZR6nVjN3ERyL/4aIsWDG5EKd3yWPNwk+IL3KFqdgG/ t6/973W7Jx9y0IHfWY6ig4kzn2HQKTNq4RvOgTUZiFxauaGcbtNmq4VF9qmH4hMHPPC3mDk689 rvOsfKyv+ETqv15FT/RzF8cMMnWQZv/QxJ5NmkLsblRnF307EiA336eB9mZH3y/s0qmBQ1tE/c Sds= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.103]) by esa6.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 13 Feb 2020 08:57:34 +0000 Received: from CHRP5015.corp.gwpnet.com (10.53.1.47) by edge.swissre.com (193.246.239.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Feb 2020 09:57:33 +0100 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5015.corp.gwpnet.com (10.53.1.47) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Feb 2020 09:57:31 +0100 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.000; Thu, 13 Feb 2020 09:57:31 +0100 From: Lee McGovern To: Dick Hardt , "Richard Backman, Annabelle" CC: "txauth@ietf.org" Thread-Topic: [Txauth] XAuth -02 Thread-Index: AQHV4hY2vRTdwp1ZM0C4ZJEDoPnnE6gY0Mvg Date: Thu, 13 Feb 2020 08:57:31 +0000 Message-ID: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2020-02-13T08:57:30.1918979Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.10] x-rcom-deduphash: e0500a76-cf4a-4a9d-a47b-9bdbc6139285 Content-Type: multipart/alternative; boundary="_000_83d2e96f06e94a9d86d5e459dfa3584fCHRP5009corpgwpnetcom_" MIME-Version: 1.0 X-GBS-PROC: NlZb6SSb3rIQOquSs+1yeWTE4QMwjkvyDfXDmwXb9Rg= Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 08:57:42 -0000 --_000_83d2e96f06e94a9d86d5e459dfa3584fCHRP5009corpgwpnetcom_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SXMgYW4gYWx0ZXJuYXRpdmUgdG8gSk9TRSBiZWluZyBjb25zaWRlcmVkIGZvciBleGFtcGxlIFBB U0VUTz8NCg0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NClNlbnQ6 IERvbm5lcnN0YWcsIDEzLiBGZWJydWFyIDIwMjAgMDM6MzQNClRvOiBSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbT4NCkNjOiB0eGF1dGhAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbVHhhdXRoXSBYQXV0aCAtMDINCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sg QW5uYWJlbGxlLCBzb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuDQoNCkNvbW1lbnRz IGFuZCBxdWVzdGlvbnMgaW5zZXJ0ZWQ6DQoNCk9uIE1vbiwgRmViIDEwLCAyMDIwIGF0IDM6Mzgg UE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCkludGVyZXN0aW5nIHdvcmsuIEkgYW0gZW5q b3lpbmcgdGhlIGZhY3QgdGhhdCB3ZSBoYXZlIHR3byBkaWZmZXJlbnQgdGFrZXMgb24gdGhlIHNh bWUgcHJvYmxlbS4gVGhlIGNvbXBhcmlzb25zIGFuZCBkaXNjdXNzaW9ucyB3aWxsIGxlYWQgdXMg dG8gYSBiZXR0ZXIgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KVGhhdCB3YXMgbXkgZ29hbCBvZiBwdWJs aXNoaW5nIHRoZSBkcmFmdCENCg0KDQpIZXJlIGFyZSBteSBjb21tZW50cyBvbiBYQXV0aC0wMjoN Cg0KU2VjdGlvbiAyLjE6DQogICAqICAqUmVzb3VyY2UgT3duZXIqIChSTykgLSBvd25zIHRoZSBS UywgYW5kIGhhcyBkZWxlZ2F0ZWQgUlMgYWNjZXNzDQogICAgICBtYW5hZ2VtZW50IHRvIHRoZSBH Uy4gIFRoZSBSTyBtYXkgYmUgdGhlIHNhbWUgZW50aXR5IGFzIHRoZSBVc2VyLCAuLi4NCg0KSeKA mW0gcmF0aGVyIGJhZmZsZWQgYnkgdGhpcyBkZWZpbml0aW9uLCBhbmQgd29uZGVyaW5nIGlmIGl0 4oCZcyBhIG1pc3Rha2Ugb3IgaWYgSeKAmW0gbWlzaW50ZXJwcmV0aW5nIGl0LiBJcyB0aGlzIGFu IGludGVudGlvbmFsIGRlcGFydHVyZSBmcm9tIGhvdyDigJxST+KAnSBpcyB0eXBpY2FsbHkgdXNl ZCB3aXRoaW4gdGhlIE9BdXRoIDIuMCBzcGFjZT8gVXN1YWxseSB0aGUgdGVybSBSTyByZWZlcnMg dG8gdGhlIGVudGl0eSB0aGF0IG93bnMgdGhlIHNwZWNpZmljIHJlc291cmNlcyB0aGUgY2xpZW50 IGlzIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiBmb3IuIFRoZSBSTyBkb2VzIG5vdCB0eXBpY2Fs bHkgb3duIHRoZSBSUyBpdHNlbGYuDQoNCk1pc3Rha2UuIFRoYW5rcyBmb3IgY2F0Y2hpbmchDQoN Cg0KU2VjdGlvbiA1LjUuMjoNCg0KICAgVGhlIGludGVyYWN0aW9uIG9iamVjdCBjb250YWlucyB0 aGUgdHlwZSBvZiBpbnRlcmFjdGlvbiB0aGUgQ2xpZW50DQoNCiAgIHdpbGwgcHJvdmlkZSB0aGUg VXNlci4gIE90aGVyIGF0dHJpYnV0ZXMNCg0KPHNuaXA+DQoNCiAgICAgICAgLSAgKnR5cGUqIC0g Y29udGFpbnMgb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzOiAicG9wdXAiLA0KDQogICAgICAg ICAgICJyZWRpcmVjdCIsIG9yICJxcmNvZGUiLi4uLg0KDQozIGlzc3VlcyB3aXRoIHRoaXM6DQoN CiAgMS4gIEhvdyB3b3VsZCBJIGRvIGEgdXNlciBjb2RlLWJhc2VkIGludGVyYWN0aW9uPw0KVG8g Y2xhcmlmeSwgdGhlIFVzZXIgaXMgZW50ZXJpbmcgYSBjb2RlIGluIHRoZSBDbGllbnQgaW50byB0 aGUgR1MsIG9yIHRoZSBVc2VyIGlzIGVudGVyaW5nIGEgY29kZSBpbnRvIHRoZSBDbGllbnQ/DQoN CklmIHRoZSBwcmlvciwgdGhlIFFSIGNvZGUgYWxzbyBhbGxvd3MgYSBtZXNzYWdlLiBJJ20gZW52 aXNpb25pbmcgYSBVc2VyIHdpdGggYSBtb2JpbGUgcGhvbmUgY2FuIHNjYW4gdGhlIFFSIGNvZGUg d2hpY2ggY29udGFpbnMgYSBVUkwgYXQgdGhlIEdTLCBhbmQgaW5jbHVkZXMgdGhlIGNvZGUuDQoN ClRoZSBtZXNzYWdlIHdvdWxkIGRlc2NyaWJlIHdoYXQgdG8gZG8gYW5kIGluY2x1ZGUgdGhlIGNv ZGUuDQoNCg0KICAxLg0KICAyLiAgQ2xpZW50cyBzdXBwb3J0IG11bHRpcGxlIGludGVyYWN0aW9u IG1vZGVzIGFuZCBtYXkgbm90IGFsd2F5cyBrbm93IHdoYXQgdGhlIEdTIHN1cHBvcnRzIChhbmQg dmljZS12ZXJzYSkuIEZvciBhIG11bHRpLXRlbmFudCBHUywgaXQgbWF5IHZhcnkgYnkgdGVuYW50 IGNvbmZpZ3VyYXRpb24uIENsaWVudHMgc2hvdWxkIGJlIGFibGUgdG8gc2F5IHdoYXQgdGhleSBj YW4gZG8sIGFuZCB0aGUgR1Mgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCB0aGVtIHdoaWNoIG9uZSB0 byB1c2UuIEl04oCZcyBhIHZlcnkgc2ltcGxlIGJ1dCBwb3dlcmZ1bCBpbmxpbmUgbmVnb3RpYXRp b24uDQoNClRoYXQgaXMgd2hhdCBpcyBpbiBUeEF1dGguIFdvdWxkIHlvdSBlbGFib3JhdGUgb24g aG93IHRoZSBHUyBtaWdodCBiZSBjb25zdHJhaW5lZD8gV2h5IHdvdWxkIHRoZSBHUyBub3QgYmUg YWJsZSB0byBkbyBhbGw/DQoNCkkgd291bGQgdGhpbmsgYWxsIGNvbnN0cmFpbnRzIHdvdWxkIGJl IGF0IHRoZSBDbGllbnQuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCg0KICAxLg0KICAyLiAg SSBkb27igJl0IHNlZSB0aGUgdmFsdWUgb2YgdGhlIOKAnHBvcHVw4oCdIGludGVyYWN0aW9uIG1v ZGUuIENsaWVudHMgY2FuIHVzZSDigJxyZWRpcmVjdOKAnSBtb2RlIHdpdGhpbiBwb3B1cHMuIEhv d2V2ZXIsIHNwZWFraW5nIGFzIHNvbWVvbmUgd2hvIGhhcyBkb25lIHRoYXQsIEkgcmVhbGx5IGRv buKAmXQgcmVjb21tZW5kIGl0LiBQb3B1cHMgYXJlIGluY3JlYXNpbmdseSB1bnN1cHBvcnRlZCwg YW5kIHByb25lIHRvIHdlaXJkIGJlaGF2aW9yYWwgaXNzdWVzLiBJbi1hcHAgYnJvd3NlcnMgaW4g RmFjZWJvb2ssIFR3aXR0ZXIsIGV0Yy4gdGVuZCB0byBoYXZlIHBvcHVwcyBkaXNhYmxlZC4gVGhl IGxhc3QgdmVyc2lvbnMgb2YgSUUgTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwg KHRoZSBwb3BwZWQgdXAgcGFnZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVu dCB3aW5kb3cpLiBpbg0KDQpQb3B1cHMgYXJlIHJlYWxseSB1c2VmdWwgaW4gc2luZ2xlLXBhZ2Ug YXBwcyBhcyB5b3Ugd2FudCB0byBrZWVwIHRoZSBjb250ZXh0IGFuZCBub3QgcmVsb2FkIHRoZSBw YWdlLg0KDQpBZ3JlZSB0aGF0IHBvcHVwcyBkb24ndCBtYWtlIHNlbnNlIGluIG1vYmlsZS4gQSBm dWxsIHJlZGlyZWN0IGRvZXMgb2YgY291cnNlLiBBIHNpbmdsZS1wYWdlIGFwcCBvbiBtb2JpbGUg d291bGQgb3BlbiBhIG5ldyB0YWIgd2hpY2ggd291bGQgYmUgYSBzZXBhcmF0ZSBjb250ZXh0IHJh dGhlciB0aGFuIGEgcmVkaXJlY3QuDQoNCg0KICAxLg0KDQpTZWN0aW9uIDEyLjY6DQoNCiAgICAg ICAgW0VkaXRvcjogaXMgdGhlcmUgc29tZSBvdGhlciByZWFzb24gdG8gaGF2ZSB0aGUgVXNlcklu Zm8NCg0KICAgICAgICBlbmRwb2ludD9dDQoNCkkgbWF5IHdhbnQgdG8gaG9zdCBteSBVc2VySW5m byBlbmRwb2ludCBvbiBhIHNlcGFyYXRlIG1pY3Jvc2VydmljZSBmcm9tIG15IHRva2VuIGVuZHBv aW50IChpbiBPQXV0aCAyLjAvT0lEQyB0ZXJtcykuIFRoZSBmb3JtZXIgbWlnaHQgYmUgcGFydCBv ZiBteSB1c2VyIHByb2ZpbGUvZGlyZWN0b3J5IHN0YWNrLCB3aGlsZSB0aGUgbGF0dGVyIGlzIHBh cnQgb2YgdGhlIGhpZ2hseSBwcml2aWxlZ2VkIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24g c3RhY2suDQoNCg0KVGhlIHRva2VuIGVuZHBvaW50IGhhcyB0aGUgYWNjZXNzIHRva2VuIGFueXdh eSwgc28gaXQgY2FuIGZldGNoIHRoZSBkYXRhIGZyb20gdGhlIG90aGVyIGVuZHBvaW50IGl0c2Vs ZiBpZiBpdCB3YW50ZWQgdG8uIElFLCB0aGVyZSBpcyBubyBzZXBhcmF0aW9uIG9mIGR1dGllcy4N Cg0KV2hhdCBhcmUgdGhlIGFkdmFudGFnZXMgb2YgdGhlIFVzZXJJbmZvIGVuZHBvaW50IHRvIHRo ZSBVc2VyIG9yIENsaWVudD8NCg0KVGhlIFVzZXJJbmZvIGVuZHBvaW50IHNlZW1zIHRvIGp1c3Qg YWRkIG1vcmUgY29tcGxleGl0eSwgd2l0aCBubyBhYmlsaXR5IHRvIHN0YXJ0IGEgVXNlciBpbnRl cmFjdGlvbiBpZiBhZGRpdGlvbmFsIGNvbnNlbnQgaXMgbmVlZGVkLg0KDQoNCg0KU2VjdGlvbiAx Mi44Og0KDQogICAgICAgICpXaHkgaGF2ZSBib3RoIGNsYWltcyBhbmQgYXV0aG9yaXphdGlvbnM/ Kg0KDQoNCg0KICAgICAgICBUaGVyZSBhcmUgdXNlIGNhc2VzIGZvciBlYWNoIHRoYXQgYXJlIGlu ZGVwZW5kZW50Og0KDQogICAgICAgIGF1dGhlbnRpY2F0aW5nIGEgdXNlciB2cyBncmFudGluZyBh Y2Nlc3MgdG8gYSByZXNvdXJjZS4gIEENCg0KICAgICAgICByZXF1ZXN0IGZvciBhbiBhdXRob3Jp emF0aW9uIHJldHVybnMgYW4gYWNjZXNzIHRva2VuIG9yIGhhbmRsZSwNCg0KICAgICAgICB3aGls ZSBhIHJlcXVlc3QgZm9yIGEgY2xhaW0gcmV0dXJucyB0aGUgY2xhaW0uDQoNCkkgZG9u4oCZdCBh Z3JlZSB0aGF0IHRoZSB1c2UgY2FzZXMgYXJlIGRpc3RpbmN0LiBUaGUgb25seSBjbGFpbSB0aGF0 IGlzIHN0cmljdGx5IG5lY2Vzc2FyeSBmb3IgYXV0aGVudGljYXRpb24gaXMgdGhlIHVzZXIgaWRl bnRpZmllci4gT3RoZXIgY2xhaW1zIGxpa2UgZW1haWwgYW5kIHBob25lX251bWJlciBhcmUgb2Z0 ZW4gdXNlZCB0byBhaWQgaW4gbG9jYWwgYWNjb3VudCBpZGVudGlmaWNhdGlvbiAoaS5lLiwgYWNj b3VudCBsaW5raW5nKSwgYnV0IGFyZSB1c2VmdWwgYW5kIGludGVyZXN0aW5nIGJleW9uZCB0aGlz IHVzZSBjYXNlLg0KDQpTb21lIENsaWVudHMgdXNlIGVtYWlsIGFuZCBwaG9uZV9udW1iZXIgYXMg dGhlIGlkZW50aWZpZXIgYW5kIGRvbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIGRpcmVjdGVkIGlk ZW50aWZpZXIuIE5vdCB0aGUgYmVzdCBwcmFjdGljZSwgYnV0IGl0IGlzIHdoYXQgcGVvcGxlIGRv Lg0KDQpPdGhlciBjbGFpbXMgc3VjaCBhcyBuYW1lLCBwcmVmZXJyZWRfdXNlcm5hbWUsIGFuZCBi aXJ0aGRhdGUgY291bGQgYmUgdXNlZCBpbiBhIHNpbWlsYXIgZmFzaGlvbiwgdGhvdWdoIHRoZXkg ZnJlcXVlbnRseSBhcmVu4oCZdC4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3Igb3RoZXIgcmVzb3VyY2Vz IG5vdCBjdXJyZW50bHkgZGVmaW5lZCBhcyBjbGFpbXMgKGUuZy4sIHRoZSBleHRlcm5hbElkIGVz dGFibGlzaGVkIHdoZW4gdGhlIHVzZXIgd2FzIGltcG9ydGVkIHRocm91Z2ggU0NJTSkuLg0KDQpD bGFpbXMgYXJlIGp1c3QgcmVzb3VyY2VzIHRoYXQgT0lEQyBwcm92aWRlcyBhIG5hbWUgcmVnaXN0 cnkgYW5kIHNvbWUgZXh0cmEgZmVhdHVyZXMgZm9yOg0KDQogICogICBPcHRpb25hbGx5IGdldCB0 aGUgdmFsdWUgYnVuZGxlZCB3aXRoIHRoZSBhdXRoZW50aWNhdGlvbiByZXNwb25zZSwgd2l0aG91 dCBuZWVkaW5nIHRvIGNhbGwgYSBzZXBhcmF0ZSBlbmRwb2ludC4NCiBJbiBteSBvcGluaW9uLCBh bGwgdGhlIGRpZmZlcmVudCB3YXlzIHRvIGdldCBjbGFpbXMgaW4gT0lEQyBpcyBhIGJ1Zywgbm90 IGEgZmVhdHVyZS4gV2l0aCB0aGUgb3B0aW9uYWxpdHkgYXQgdGhlIE9QLCAgYSBnZW5lcmljIENs aWVudCBoYXMgdG8gc3VwcG9ydCBib3RoLg0KDQoNCg0KICAqDQogICogICBPcHRpb25hbGx5IGdl dCB0aGUgdmFsdWUgaW4gYSBzaWduZWQgb3IgZW5jcnlwdGVkIGJsb2IuDQpUaGlzIG9wdGlvbmFs aXR5IGlzIHVzZWZ1bCB0byB0aGUgQ2xpZW50LCBhcyBpdCBjYW4gZGVjaWRlIHdoYXQgY2xhaW1z IHNob3VsZCBiZSBpbiB0aGUgc2lnbmVkIGJsb2Igd2hpY2ggbWF5IGJlIHVzZWQgZGlmZmVyZW50 bHkgdGhhbiBvdGhlciBjbGFpbXMuDQoNCg0KICAqDQogICogICBPcHRpb25hbGx5IHByb3ZpZGUg c29tZSBzdHJ1Y3R1cmVkIG1ldGFkYXRhIGRlc2NyaWJpbmcgdGhlIHJlc291cmNlIGFuZC9vciBy ZXF1ZXN0ZWQgYXV0aG9yaXphdGlvbi4NCg0KDQoNCiAgKg0KDQpJdOKAmXMgdGVsbGluZyB0aGF0 IGFsbCBvZiB0aGVzZSBhcmUgb3B0aW9uYWwuIElmIHdlIHRoaW5rIHRoZXNlIGFyZSBmZWF0dXJl cyB3b3J0aCBicmluZ2luZyBmb3J3YXJkIGludG8gd2hhdGV2ZXIgcHJvdG9jb2wgd2UgcHJvZHVj ZSB0aHJvdWdoIFR4QXV0aCwgd2Ugc2hvdWxkIGxvb2sgYXQgdGhlbSBpbmRlcGVuZGVudGx5IG9m IHRoZSBjbGFpbS9yZXNvdXJjZSBkaWNob3RvbXkuDQoNCkkgYWdyZWUgdGhhdCB0aGVzZSBmZWF0 dXJlcyBhcmUgb3J0aG9nb25hbCB0byB0aGUgImFyZSBjbGFpbXMgYW5kIHJlc291cmNlcyB0aGUg c2FtZSB0aGluZyIgZGViYXRlLg0KDQpJIHN0cm9uZ2x5IHRoaW5rIGl0IGlzIGEgZGlzc2Vydmlj ZSB0byBvdXIgYXVkaWVuY2UgdG8gY29uZmxhdGUgY2xhaW1zIGFuZCByZXNvdXJjZXMuIENsYWlt cyBhcmUgc3RhdGVtZW50cyBhYm91dCB0aGUgVXNlciBhbmQgcmVhZC1vbmx5Lg0KDQpSZXNvdXJj ZXMgYXJlIGluZGVwZW5kZW50IG9mIHRoZSBHUy4gVGhlIENsaWVudCBtYXkgYmUgYWJsZSB0byBk byBhbGwgb2YgQ1JVRCBvbiB0aGUgcmVzb3VyY2UuDQoNCldoaWxlIHRoZXJlIGlzIG92ZXJsYXAg d2l0aCB0aGUgVXNlckluZm8gZW5kcG9pbnQgdGhhdCBpdCBjb3VsZCBiZSBjb25zaWRlcmVkIGEg cmVzb3VyY2UsIEkgZG9uJ3QgdGhpbmsgdGhhdCBoZWxwcyB0aGUgYXVkaWVuY2UuDQoNClRoZSBs YW5ndWFnZSBpbiBYQXV0aCBjYW4gZGVmaW5pdGVseSB1c2UgaW1wcm92ZW1lbnQgdG8gcHJvdmlk ZSBtb3JlIGNsYXJpdHkgaGVyZS4NCg0KDQoNClNlY3Rpb24gMTIuMTI6DQoNCiAgICAgICAgKldo eSBjb21wbGljYXRlIHRoZSBzZXF1ZW5jZSB3aXRoICJpbnRlcmFjdGlvbiIuImtlZXAiPyoNCg0K SSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3XigJlyZSB0cnlpbmcgdG8gc3VwcG9ydCBoZXJl LCBidXQgSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdG9vIGNvbXBsaWNhdGVkIHRvIGltcGxlbWVu dC4gRnJvbSB0aGUgc2VxdWVuY2VzLCBpdCBsb29rcyBsaWtlIHRoZSBDbGllbnQgaXMgZXhwZWN0 ZWQgdG8gaXNzdWUgYSBSZWFkIEdyYW50IHJlcXVlc3QsIGFuZCB0aGF0IGNvbm5lY3Rpb24gd2ls bCBiZSBrZXB0IG9wZW4gd2hpbGUgdGhlIFVzZXIgaXMgcmVkaXJlY3RlZCB0byB0aGUgR1MgYW5k IGdvZXMgdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gd29ya2Zsb3cgKGFuZCBwb3NzaWJseSBw YXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHdvcmtmbG93KS4gT25seSB0aGVuIHdvdWxkIHRoZSBH UyByZXR1cm4gdGhlIFJlYWQgR3JhbnQgcmVzcG9uc2UuIElzIHRoaXMgY29ycmVjdD8NCg0KVG8g aW1wbGVtZW50IHRoaXMsIHRoZSBDbGllbnQgaGFzIHRvIGxhdW5jaCBhbiBhc3luY2hyb25vdXMg dGhyZWFkIHRvIGV4ZWN1dGUgdGhhdCByZXF1ZXN0IGFuZCBhd2FpdGluZyB0aGUgcmVzcG9uc2Uu DQpQb3NzaWJsZSwgYnV0IHN1c2NlcHRpYmxlIHRvIGZhaWx1cmVzLiBXaGF0IGhhcHBlbnMgaWYg dGhhdCB0aHJlYWQgY3Jhc2hlcz8gT3IgZmFpbHMgdG8gc2VuZCB0aGUgVXBkYXRlIEdyYW50IHJl cXVlc3QgdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVwIHRvIGZhbHNlPyBXaGF0IGlzIHRoZSBHUyBk b2luZyBpbiB0aGUgbWVhbnRpbWU/IElzIGl0IGp1c3Qgc2hvd2luZyB0aGUgVXNlciBhIOKAnGxv YWRpbmfigJ0gd2lkZ2V0IGFzIGl0IHdhaXRzIGZvciB0aGUgQ2xpZW50IHRvIHVwZGF0ZSB0aGUg Z3JhbnQ/IEhvdyBsb25nIGRvZXMgaXQgd2FpdCBmb3I/IEZvciBtb2JpbGUgYXBwcywgdGhhdCBi YWNrZ3JvdW5kIHRocmVhZCBtYXkgZ2V0IGtpbGxlZCBvciBsb3NlIG5ldHdvcmsgY29ubmVjdGl2 aXR5IGFzIHNvb24gYXMgdGhlIHVzZXIgZ2V0cyBzd2l0Y2hlZCBvdmVyIHRvIHRoZSBzeXN0ZW0g YnJvd3NlciB0byBsb2FkIHRoZSBHUyBzaWduIGluIHBhZ2UuIEZvciBhIHB1cmUtSlMgYXBwIHRo YXQgcmVkaXJlY3RzLCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBwb3NzaWJsZSBhdCBhbGwuICh1 bmxlc3Mgd2ViIHdvcmtlcnMgY2FuIHN1cnZpdmUgcGFnZSB1bmxvYWRzPykNCg0KVGhpcyBpcyBh biBpbnRlcmVzdGluZyB1c2UgY2FzZSBmb3IgdXMgdG8gdGhpbmsgYWJvdXQsIGJ1dCBpdCBuZWVk cyBhIGxvdCBvZiB3b3JrIGFuZCBtYXkgbm90IGJlIHNvbWV0aGluZyB3ZSBzaG91bGQgdHJ5IHRv IGJha2UgaW50byB0aGUgY29yZSBwcm90b2NvbCBpZiB3ZSBkb27igJl0IG5lZWQgdG8uDQoNCkl0 IG1pZ2h0IG5vdCBoYXZlIGJlZW4gb2J2aW91cywgYnV0IHRoZSBDbGllbnQgY2FsbGluZyB0aGUg R1MgdG8gZ2V0IGEgcmVzdWx0IHdoaWxlIHRoZSBpbnRlcmFjdGlvbiBpcyBoYXBwZW5pbmcgaXMg d2hhdCBoYXBwZW5zIGluIGFueSBmbG93IHdpdGggYW4gaW50ZXJhY3Rpb24gc3RhcnRlZCBieSB0 aGUgQ2xpZW50LiBJdCBpcyBub3QgdW5pcXVlIHRvICJpbnRlcmFjdGlvbiIuImtlZXAiIC0tIHdl IGFyZSBqdXN0IGFkZGluZyBhZGRpdGlvbmFsIGJhY2sgYW5kIGZvcnRocyBiZXR3ZWVuIHRoZSBD bGllbnQgYW5kIEdTLg0KDQpBIFFSIENvZGUgZXhhbXBsZSBIQVMgdG8gd29yayB0aGlzIHdheSwg YXMgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciB0aGUgQ2xpZW50IHRvIGtub3cgdGhlIGludGVy YWN0aW9uIGhhcyBjb21wbGV0ZWQuDQoNCkdvb2dsZSBhbmQgTWljcm9zb2Z0IGJvdGggaGF2ZSBh IHNpbWlsYXIgdXNlciBleHBlcmllbmNlLiBUaGUgVXNlciB3YW50cyB0byBsb2cgaW50byBhbiBh cHAgLS0gdGhleSBhcmUgaW5zdHJ1Y3RlZCB0byBnbyB0byB0aGUgcmVzcGVjdGl2ZSBtb2JpbGUg YXBwIHRvIGFwcHJvdmUgdGhlIGF1dGhlbnRpY2F0aW9uIC0tIGFuZCB0aGVuIHRoZSBVc2VyIHJl dHVybnMgdG8gdGhlIGFwcCB3aGljaCBjaGFuZ2VzIHRvIGEgbG9nZ2VkIGluIHN0YXRlLiAgQW4g YXV0aGVudGljYXRpb24gb25seSBmbG93IHVzaW5nIFhBdXRoIHdvdWxkIHdvcmsgdGhlIHNhbWUg d2F5Lg0KDQoNCg0KU2VjdGlvbiAxMi4xNDoNCg0KICAgICAgICAqV2h5IHVzZSBVUklzIHRvIGlu c3RlYWQgb2YgaGFuZGxlcyBmb3IgdGhlIEdyYW50IGFuZA0KDQogICAgICAgIEF1dGhvcml6YXRp b24/Kg0KDQpJIGRpZG7igJl0IGxpa2UgdGhpcyB1bnRpbCBJIHJlYWxpemVkIHRoYXQgeW914oCZ cmUgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBoYW5kbGVzL1VSSXMgYW5kIHRva2Vucy4gTm93IHRo YXQgSeKAmXZlIHRob3VnaHQgYWJvdXQgaXQgbW9yZSwgSSBsaWtlIHRoaXMgZnJvbSB0aGUgc3Rh bmRwb2ludCB0aGF0IGl0IHVuZGVyc2NvcmVzIHRoZSBpZGVhIG9mIEdyYW50cyBhbmQgQXV0aG9y aXphdGlvbnMgYmVpbmcgcGVyc2lzdGVudCBvYmplY3RzIHdpdGhpbiB0aGUgcHJvdG9jb2wuDQoN CjopDQoNCkFuZCBpdOKAmXMgcmVhbGx5IGp1c3QgbWFraW5nIHB1YmxpYyBzb21ldGhpbmcgdGhh dCB0aGUgR1MgaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgZG9pbmcgdW5kZXIgdGhlIGhvb2QgYW55 d2F5LiBIb3dldmVyLCB3ZSBoYXZlIHRvIGJlIGNhcmVmdWwgdGhhdCB3ZSBkb27igJl0IGFjY2lk ZW50YWxseSBlbmNvdXJhZ2UgaW1wbGVtZW50ZXJzIHRvIHN0YXJ0IHNob3ZpbmcgdGhpbmdzIGlu dG8gdGhlc2UgVVJJcy4NCg0KVGhlIFVSSSBjb250ZW50IGlzIGludGVuZGVkIHRvIGJlIG9wYXF1 ZS4gVGhlcmUgd291bGQgYmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQga2VlcCBwZW9w bGUgZnJvbSBwdXR0aW5nIHZpc2libGUgc3R1ZmYgaW4gdGhlcmUgdGhleSBzaG91bGRuJ3QuDQoN Ckkgd291bGQgZXhwZWN0IGltcGxlbWVudGF0aW9ucyB0byB1c2UgYSByYW5kb20gdmFsdWUgd2l0 aCBhIGNoZWNrc3VtLCBvciBhIEpXVC4NCg0KDQrigJMNCkFubmFiZWxsZSBCYWNrbWFuIChzaGUv aGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lw0KDQoN CkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3Vu Y2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5 IDcsIDIwMjAgYXQgODowMCBQTQ0KVG86ICJ0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBp ZXRmLm9yZz4iIDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBbVHhhdXRoXSBYQXV0aCAtMDINCg0KSSd2ZSBoZWF2aWx5IHJldmlzZWQgWEF1dGggYWdh aW4uDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90 b2NvbC0wMjxodHRwczovL3Rvb2xzLi5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXBy b3RvY29sLTAyPg0KDQpBIG51bWJlciBvZiBuZXcgaWRlYXMgdG8gYm91bmNlIGFyb3VuZDoNCg0K SSBoYXZlIGluY2x1ZGVkIGEgYnVuY2ggb2Ygc2VxdWVuY2VzIHRvIHNob3cgZGlmZmVyZW50IHVz ZSBjYXNlcyBwb3NzaWJsZS4NCg0KUmF0aGVyIHRoYW4gYSB0cmFuc2FjdGlvbiwgSSB1c2UgYSBH cmFudCBhcyB0aGUgY2VudHJhbCBvYmplY3QuDQoNClRoZSBpbnRlcmZhY2UgaXMgdmVyeSBSRVNU ZnVsLg0KDQpUaGUgQVMgaXMgbm93IGEgR3JhbnQgU2VydmVyIChHUykNCg0KVGhpcyBhbHNvIHNl ZW1lZCBhcHByb3ByaWF0ZSBhdCBpdCBpcyBib3RoIGFuIE9BdXRoIEFTLCBhbmQgYW4gT0lEQyBP UC4NCg0KUmF0aGVyIHRoYW4gYSBoYW5kbGUsIHRoZSBHcmFudCBoYXMgYSBVUkkuDQoNClRoZSBl bmRwb2ludCBVUkkgZm9yIHRoZSBHUyBpcyB0aGUgR1MgVVJJLCBhbmQgaXMgdGhlIEdTIGlkZW50 aWZpZXIuDQoNCkFuIGFjY2VzcyB0b2tlbiwgcmVmcmVzaCB0b2tlbiBldGMuIGFyZSBhbGwgYW4g QXV0aG9yaXphdGlvbi4gQW4gQXV0aG9yaXphdGlvbiBoYXMgYW4gQXV0aFogVVJJLi4NCg0KVGhl IEdyYW50IFVSSSBhbmQgQXV0aFogVVJJIGFsbCBzdGFydCB3aXRoIHRoZSBHUyBVUkkuDQoNCkEg R3JhbnQgaXMgY3JlYXRlZCBieSBkb2luZyBhIFBPU1QgdG8gdGhlIEdTIFVSSSwgcmV0dXJuaW5n IGEgR3JhbnQgVVJJLg0KDQpNZXRhZGF0YSBmb3IgdGhlIEdTIGlzIGRvbmUgd2l0aCBhbiBPUFRJ T05TIHRvIHRoZSBHUyBVUkkuDQoNClRoZSBDbGllbnQgY2FuIGRvIEdFVCwgVVBEQVRFLCBhbmQg REVMRVRFIGFnYWluc3QgYSBHcmFudCBVUkkuDQoNCkFuIGFjY2VzcyB0b2tlbiByZWZyZXNoIGlz IGEgR0VUIG9uIHRoZSBBdXRoWiBVUkkuDQoNCkFkZGluZyBpbiBSZWNpcHJvY2FsIE9BdXRoIGZ1 bmN0aW9uYWxpdHkgd2FzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRoYW4gaW4gT0F1dGggMi4wIC0t IGJ1dCBub3QgYXMgc3RyYWlnaHQgZm9yd2FyZCBhcyBJIHdvdWxkIGxpa2UgLS0gYnV0IG5vdCBj bGVhciBob3cgdG8gbWFrZSBpdCBiZXR0ZXIgYW5kIHN0YXJ0IGZyb20gdGhlIENsaWVudCBhbmQg R1MgaGF2aW5nIGNvbnRleHQgb2Ygb25lIGF1dGhvcml6YXRpb24gYmVmb3JlIHN3YXBwaW5nIHJv bGVzLg0KDQpQZXIgbXkgbGFzdCBlbWFpbHMsIG5hbWluZyBpcyBoYXJkLCB0aGVyZSBhcmUgbGlr ZWx5IGxvdHMgb2YgbWlzdGFrZXMsIGFuZCBsb3RzIG9mIGFzcGVjdHMgdGhhdCBuZWVkIG5vcm1h dGl2ZSBsYW5ndWFnZS4gSG9wZWZ1bGx5IHRoZSBjb25jZXB0cyBjb21lIHRocm91Z2ghDQoNCi9E aWNrDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lY SmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTdjZDE4ZWE2LThjNTAt NDZkYy1iZTI1LWU5OWY2MTRkYWI4Ml3hkKcNCgoKVGhpcyBlLW1haWwsIGluY2x1ZGluZyBhdHRh Y2htZW50cywgaXMgaW50ZW5kZWQgZm9yIHRoZSBwZXJzb24ocykgb3IgY29tcGFueSBuYW1lZCBh bmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5IHByaXZpbGVnZWQgaW5m b3JtYXRpb24uCgpVbmF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZyBvciB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBtYXkgYmUgdW5sYXdmdWwgYW5kIGlzIHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBub3RpZnkgdGhlIHNlbmRlci4KQWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlLW1haWwg bWVzc2FnZXMgYXJlIHN0b3JlZCBpbiB0aGUgU3dpc3MgUmUgRWxlY3Ryb25pYyBNZXNzYWdlIFJl cG9zaXRvcnkuCklmIHlvdSBkbyBub3Qgd2lzaCB0aGUgcmV0ZW50aW9uIG9mIHBvdGVudGlhbGx5 IHByaXZhdGUgZS1tYWlscyBieSBTd2lzcyBSZSwgd2Ugc3Ryb25nbHkgYWR2aXNlIHlvdSBub3Qg dG8gdXNlIHRoZSBTd2lzcyBSZSBlLW1haWwgYWNjb3VudCBmb3IgYW55IHByaXZhdGUsIG5vbi1i dXNpbmVzcyByZWxhdGVkIGNvbW11bmljYXRpb25zLgo= --_000_83d2e96f06e94a9d86d5e459dfa3584fCHRP5009corpgwpnetcom_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpERS1DSDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6Mzc0MDE0MTY1Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczo2NDk4ODI5MzQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDczNTIxMzI1Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxMTMzMjg4NTYwO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk OjQ3NDgzNTczMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNDY4NjcyODI7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjU1MzIw NDYxNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNzk2MzU3MzI7fQ0KQGxpc3QgbDQNCgl7 bXNvLWxpc3QtaWQ6OTA3MzAwOTI0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ5Mzk0MDA3 ODt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxp c3QtaWQ6MTM5NjAxMTM3MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5Mjc2Mzc4MDA7fQ0K QGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1 OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlk OjE1NjM1NjEzODU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIxNDAxNTM1NDg7fQ0KQGxpc3Qg bDcNCgl7bXNvLWxpc3QtaWQ6MjAwNDg5NjI4ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEx MDYwODg1NjA7fQ0KQGxpc3QgbDc6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw3OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3 OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy ODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw3OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkRFLUNIIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JcyBhbiBhbHRlcm5hdGl2ZSB0byBK T1NFIGJlaW5nIGNvbnNpZGVyZWQgZm9yIGV4YW1wbGUgUEFTRVRPPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDsNCjxicj4N CjxiPlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAxMy4gRmVicnVhciAyMDIwIDAzOjM0PGJyPg0KPGI+ VG86PC9iPiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmFAYW1hem9uLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IHR4YXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1R4YXV0aF0gWEF1dGggLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIEFubmFiZWxsZSwgc29ycnkgZm9y IHRoZSBkZWxheSBpbiByZXNwb25kaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21tZW50cyBhbmQgcXVlc3Rpb25zIGluc2VydGVkOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIg MTAsIDIwMjAgYXQgMzozOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBh bWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPkludGVyZXN0aW5nIHdvcmsuIEkgYW0gZW5qb3lpbmcgdGhlIGZhY3QgdGhhdCB3ZSBoYXZl IHR3byBkaWZmZXJlbnQgdGFrZXMgb24gdGhlIHNhbWUgcHJvYmxlbS4gVGhlIGNvbXBhcmlzb25z IGFuZCBkaXNjdXNzaW9ucyB3aWxsIGxlYWQgdXMgdG8gYSBiZXR0ZXIgb3ZlcmFsbA0KIHNvbHV0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdhcyBteSBnb2FsIG9mIHB1Ymxp c2hpbmcgdGhlIGRyYWZ0ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPkhlcmUgYXJlIG15IGNvbW1lbnRzIG9uIFhBdXRoLTAyOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPlNlY3Rpb24gMi4xOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgKiZuYnNwOyAqUmVzb3VyY2UgT3duZXIqIChSTykgLSBvd25zIHRoZSBSUywgYW5kIGhh cyBkZWxlZ2F0ZWQgUlMgYWNjZXNzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmFnZW1lbnQg dG8gdGhlIEdTLiZuYnNwOyBUaGUgUk8gbWF5IGJlIHRoZSBzYW1lIGVudGl0eSBhcyB0aGUgVXNl ciwgLi4uDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PknigJltIHJhdGhlciBiYWZmbGVkIGJ5IHRoaXMgZGVmaW5pdGlvbiwgYW5kIHdvbmRlcmluZyBp ZiBpdOKAmXMgYSBtaXN0YWtlIG9yIGlmIEnigJltIG1pc2ludGVycHJldGluZyBpdC4gSXMgdGhp cyBhbiBpbnRlbnRpb25hbCBkZXBhcnR1cmUgZnJvbSBob3cg4oCcUk/igJ0gaXMgdHlwaWNhbGx5 DQogdXNlZCB3aXRoaW4gdGhlIE9BdXRoIDIuMCBzcGFjZT8gVXN1YWxseSB0aGUgdGVybSBSTyBy ZWZlcnMgdG8gdGhlIGVudGl0eSB0aGF0IG93bnMgdGhlIHNwZWNpZmljIHJlc291cmNlcyB0aGUg Y2xpZW50IGlzIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiBmb3IuIFRoZSBSTyBkb2VzIG5vdCB0 eXBpY2FsbHkgb3duIHRoZSBSUyBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1p c3Rha2UuIFRoYW5rcyBmb3IgY2F0Y2hpbmchPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlvbiA1LjUuMjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBUaGUgaW50ZXJhY3Rpb24gb2JqZWN0IGNvbnRhaW5zIHRoZSB0eXBlIG9mIGludGVyYWN0 aW9uIHRoZSBDbGllbnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgd2lsbCBwcm92aWRlIHRoZSBVc2VyLiZuYnNwOyBPdGhlciBhdHRyaWJ1dGVzPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZsdDtzbmlwJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtJm5ic3A7ICp0 eXBlKiAtIGNvbnRhaW5zIG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczogJnF1b3Q7cG9wdXAm cXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O3Jl ZGlyZWN0JnF1b3Q7LCBvciAmcXVvdDtxcmNvZGUmcXVvdDsuLi4uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjMgaXNzdWVzIHdpdGggdGhpczo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ SG93IHdvdWxkIEkgZG8gYSB1c2VyIGNvZGUtYmFzZWQgaW50ZXJhY3Rpb24/PG86cD48L286cD48 L3NwYW4+PC9saT48L29sPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBjbGFyaWZ5LCB0aGUgVXNlciBpcyBlbnRlcmluZyBhIGNv ZGUgaW4gdGhlIENsaWVudCBpbnRvIHRoZSBHUywgb3IgdGhlIFVzZXIgaXMgZW50ZXJpbmcgYSBj b2RlIGludG8gdGhlIENsaWVudD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHByaW9yLCB0aGUgUVIgY29kZSBhbHNvIGFs bG93cyBhIG1lc3NhZ2UuIEknbSBlbnZpc2lvbmluZyBhIFVzZXIgd2l0aCBhIG1vYmlsZSBwaG9u ZSBjYW4gc2NhbiB0aGUgUVIgY29kZSB3aGljaCBjb250YWlucyBhIFVSTCBhdCB0aGUgR1MsIGFu ZCBpbmNsdWRlcyB0aGUgY29kZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG1lc3NhZ2Ugd291bGQgZGVzY3JpYmUgd2hhdCB0 byBkbyBhbmQgaW5jbHVkZSB0aGUgY29kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNiBsZXZlbDEgbGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0Omw2IGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5DbGllbnRzIHN1cHBv cnQgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZXMgYW5kIG1heSBub3QgYWx3YXlzIGtub3cgd2hh dCB0aGUgR1Mgc3VwcG9ydHMgKGFuZCB2aWNlLXZlcnNhKS4gRm9yIGEgbXVsdGktdGVuYW50IEdT LCBpdCBtYXkgdmFyeSBieSB0ZW5hbnQgY29uZmlndXJhdGlvbi4gQ2xpZW50cyBzaG91bGQgYmUg YWJsZSB0byBzYXkgd2hhdCB0aGV5IGNhbiBkbywgYW5kIHRoZSBHUyBzaG91bGQgYmUgYWJsZQ0K IHRvIHRlbGwgdGhlbSB3aGljaCBvbmUgdG8gdXNlLiBJdOKAmXMgYSB2ZXJ5IHNpbXBsZSBidXQg cG93ZXJmdWwgaW5saW5lIG5lZ290aWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0IGlzIHdoYXQgaXMgaW4gVHhBdXRoLiBXb3VsZCB5b3UgZWxhYm9yYXRlIG9uIGhv dyB0aGUgR1MgbWlnaHQgYmUgY29uc3RyYWluZWQ/IFdoeSB3b3VsZCB0aGUgR1Mgbm90IGJlIGFi bGUgdG8gZG8gYWxsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdvdWxkIHRoaW5rIGFsbCBjb25zdHJhaW50cyB3b3VsZCBiZSBhdCB0aGUg Q2xpZW50LiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkkgZG9u4oCZ dCBzZWUgdGhlIHZhbHVlIG9mIHRoZSDigJxwb3B1cOKAnSBpbnRlcmFjdGlvbiBtb2RlLiBDbGll bnRzIGNhbiB1c2Ug4oCccmVkaXJlY3TigJ0gbW9kZSB3aXRoaW4gcG9wdXBzLiBIb3dldmVyLCBz cGVha2luZyBhcyBzb21lb25lIHdobyBoYXMgZG9uZSB0aGF0LCBJIHJlYWxseSBkb27igJl0IHJl Y29tbWVuZCBpdC4gUG9wdXBzIGFyZSBpbmNyZWFzaW5nbHkgdW5zdXBwb3J0ZWQsIGFuZCBwcm9u ZSB0byB3ZWlyZCBiZWhhdmlvcmFsDQogaXNzdWVzLiBJbi1hcHAgYnJvd3NlcnMgaW4gRmFjZWJv b2ssIFR3aXR0ZXIsIGV0Yy4gdGVuZCB0byBoYXZlIHBvcHVwcyBkaXNhYmxlZC4gVGhlIGxhc3Qg dmVyc2lvbnMgb2YgSUUgTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwgKHRoZSBw b3BwZWQgdXAgcGFnZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVudCB3aW5k b3cpLiBpbiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qb3B1cHMgYXJl IHJlYWxseSB1c2VmdWwgaW4gc2luZ2xlLXBhZ2UgYXBwcyBhcyB5b3Ugd2FudCB0byBrZWVwIHRo ZSBjb250ZXh0IGFuZCBub3QgcmVsb2FkIHRoZSBwYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZSB0aGF0IHBvcHVwcyBkb24ndCBt YWtlIHNlbnNlIGluIG1vYmlsZS4gQSBmdWxsIHJlZGlyZWN0IGRvZXMgb2YgY291cnNlLiBBIHNp bmdsZS1wYWdlIGFwcCBvbiBtb2JpbGUgd291bGQgb3BlbiBhIG5ldyB0YWIgd2hpY2ggd291bGQg YmUgYSBzZXBhcmF0ZSBjb250ZXh0IHJhdGhlciB0aGFuIGEgcmVkaXJlY3QuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0 eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PlNlY3Rpb24gMTIuNjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDtbRWRpdG9yOiBpcyB0aGVyZSBzb21lIG90aGVyIHJlYXNvbiB0byBoYXZlIHRo ZSBVc2VySW5mbzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludD9dPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgbWF5IHdhbnQgdG8gaG9z dCBteSBVc2VySW5mbyBlbmRwb2ludCBvbiBhIHNlcGFyYXRlIG1pY3Jvc2VydmljZSBmcm9tIG15 IHRva2VuIGVuZHBvaW50IChpbiBPQXV0aCAyLjAvT0lEQyB0ZXJtcykuIFRoZSBmb3JtZXIgbWln aHQgYmUgcGFydCBvZiBteSB1c2VyIHByb2ZpbGUvZGlyZWN0b3J5DQogc3RhY2ssIHdoaWxlIHRo ZSBsYXR0ZXIgaXMgcGFydCBvZiB0aGUgaGlnaGx5IHByaXZpbGVnZWQgYXV0aGVudGljYXRpb24v YXV0aG9yaXphdGlvbiBzdGFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdG9r ZW4gZW5kcG9pbnQgaGFzIHRoZSBhY2Nlc3MgdG9rZW4gYW55d2F5LCBzbyBpdCBjYW4gZmV0Y2gg dGhlIGRhdGEgZnJvbSB0aGUgb3RoZXIgZW5kcG9pbnQgaXRzZWxmIGlmIGl0IHdhbnRlZCB0by4g SUUsIHRoZXJlIGlzIG5vIHNlcGFyYXRpb24gb2YgZHV0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFyZSB0aGUgYWR2YW50YWdl cyBvZiB0aGUgVXNlckluZm8gZW5kcG9pbnQgdG8gdGhlIFVzZXIgb3IgQ2xpZW50PyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg VXNlckluZm8gZW5kcG9pbnQgc2VlbXMgdG8ganVzdCBhZGQgbW9yZSBjb21wbGV4aXR5LCB3aXRo IG5vIGFiaWxpdHkgdG8gc3RhcnQgYSBVc2VyIGludGVyYWN0aW9uIGlmIGFkZGl0aW9uYWwgY29u c2VudCBpcyBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5TZWN0aW9uIDEyLjg6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKldoeSBoYXZlIGJvdGggY2xhaW1zIGFuZCBhdXRob3Jp emF0aW9ucz8qPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIGVhY2ggdGhhdCBh cmUgaW5kZXBlbmRlbnQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0aW5nIGEg dXNlciB2cyBncmFudGluZyBhY2Nlc3MgdG8gYSByZXNvdXJjZS4mbmJzcDsgQTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyByZXF1ZXN0IGZvciBhbiBhdXRob3JpemF0aW9uIHJldHVybnMgYW4gYWNj ZXNzIHRva2VuIG9yIGhhbmRsZSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hpbGUgYSByZXF1 ZXN0IGZvciBhIGNsYWltIHJldHVybnMgdGhlIGNsYWltLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvbuKAmXQgYWdyZWUgdGhhdCB0aGUgdXNl IGNhc2VzIGFyZSBkaXN0aW5jdC4gVGhlIG9ubHkgY2xhaW0gdGhhdCBpcyBzdHJpY3RseSBuZWNl c3NhcnkgZm9yIGF1dGhlbnRpY2F0aW9uIGlzIHRoZSB1c2VyIGlkZW50aWZpZXIuIE90aGVyIGNs YWltcyBsaWtlIGVtYWlsIGFuZA0KIHBob25lX251bWJlciBhcmUgb2Z0ZW4gdXNlZCB0byBhaWQg aW4gbG9jYWwgYWNjb3VudCBpZGVudGlmaWNhdGlvbiAoaS5lLiwgYWNjb3VudCBsaW5raW5nKSwg YnV0IGFyZSB1c2VmdWwgYW5kIGludGVyZXN0aW5nIGJleW9uZCB0aGlzIHVzZSBjYXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIENsaWVudHMgdXNlIGVtYWlsIGFuZCBwaG9uZV9u dW1iZXIgYXMgdGhlIGlkZW50aWZpZXIgYW5kIGRvbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIGRp cmVjdGVkIGlkZW50aWZpZXIuIE5vdCB0aGUgYmVzdCBwcmFjdGljZSwgYnV0IGl0IGlzIHdoYXQg cGVvcGxlIGRvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVyIGNs YWltcyBzdWNoIGFzIG5hbWUsIHByZWZlcnJlZF91c2VybmFtZSwgYW5kIGJpcnRoZGF0ZSBjb3Vs ZCBiZSB1c2VkIGluIGEgc2ltaWxhciBmYXNoaW9uLCB0aG91Z2ggdGhleSBmcmVxdWVudGx5IGFy ZW7igJl0LiBUaGUgc2FtZSBpcyB0cnVlIGZvciBvdGhlciByZXNvdXJjZXMNCiBub3QgY3VycmVu dGx5IGRlZmluZWQgYXMgY2xhaW1zIChlLmcuLCB0aGUgZXh0ZXJuYWxJZCBlc3RhYmxpc2hlZCB3 aGVuIHRoZSB1c2VyIHdhcyBpbXBvcnRlZCB0aHJvdWdoIFNDSU0pLi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5DbGFpbXMgYXJlIGp1c3QgcmVzb3VyY2VzIHRoYXQgT0lEQyBwcm92aWRlcyBhIG5h bWUgcmVnaXN0cnkgYW5kIHNvbWUgZXh0cmEgZmVhdHVyZXMgZm9yOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPk9wdGlvbmFsbHkgZ2V0IHRoZSB2 YWx1ZSBidW5kbGVkIHdpdGggdGhlIGF1dGhlbnRpY2F0aW9uIHJlc3BvbnNlLCB3aXRob3V0IG5l ZWRpbmcgdG8gY2FsbCBhIHNlcGFyYXRlIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7SW4gbXkgb3BpbmlvbiwgYWxsIHRoZSBkaWZmZXJlbnQgd2F5cyB0byBn ZXQgY2xhaW1zIGluIE9JREMgaXMgYSBidWcsIG5vdCBhIGZlYXR1cmUuIFdpdGggdGhlIG9wdGlv bmFsaXR5IGF0IHRoZSBPUCwmbmJzcDsgYSBnZW5lcmljIENsaWVudCBoYXMgdG8gc3VwcG9ydCBi b3RoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNyBs ZXZlbDEgbGZvNiI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw3IGxldmVsMSBsZm82Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj5PcHRpb25hbGx5IGdldCB0aGUgdmFsdWUgaW4gYSBzaWduZWQgb3Ig ZW5jcnlwdGVkIGJsb2IuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG9wdGlv bmFsaXR5IGlzIHVzZWZ1bCB0byB0aGUgQ2xpZW50LCBhcyBpdCBjYW4gZGVjaWRlIHdoYXQgY2xh aW1zIHNob3VsZCBiZSBpbiB0aGUgc2lnbmVkIGJsb2Igd2hpY2ggbWF5IGJlIHVzZWQgZGlmZmVy ZW50bHkgdGhhbiBvdGhlciBjbGFpbXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsNSBsZXZlbDEgbGZvNyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw1 IGxldmVsMSBsZm83Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5PcHRpb25hbGx5IHByb3ZpZGUgc29t ZSBzdHJ1Y3R1cmVkIG1ldGFkYXRhIGRlc2NyaWJpbmcgdGhlIHJlc291cmNlIGFuZC9vciByZXF1 ZXN0ZWQgYXV0aG9yaXphdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvbGk+ PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkl04oCZcyB0ZWxsaW5nIHRoYXQgYWxsIG9mIHRoZXNlIGFyZSBvcHRpb25hbC4gSWYg d2UgdGhpbmsgdGhlc2UgYXJlIGZlYXR1cmVzIHdvcnRoIGJyaW5naW5nIGZvcndhcmQgaW50byB3 aGF0ZXZlciBwcm90b2NvbCB3ZSBwcm9kdWNlIHRocm91Z2ggVHhBdXRoLCB3ZSBzaG91bGQNCiBs b29rIGF0IHRoZW0gaW5kZXBlbmRlbnRseSBvZiB0aGUgY2xhaW0vcmVzb3VyY2UgZGljaG90b215 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlc2UgZmVhdHVyZXMg YXJlIG9ydGhvZ29uYWwgdG8gdGhlICZxdW90O2FyZSBjbGFpbXMgYW5kIHJlc291cmNlcyB0aGUg c2FtZSB0aGluZyZxdW90OyBkZWJhdGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3Ryb25nbHkgdGhpbmsgaXQgaXMgYSBkaXNz ZXJ2aWNlIHRvIG91ciBhdWRpZW5jZSB0byBjb25mbGF0ZSBjbGFpbXMgYW5kIHJlc291cmNlcy4g Q2xhaW1zIGFyZSBzdGF0ZW1lbnRzIGFib3V0IHRoZSBVc2VyIGFuZCByZWFkLW9ubHkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlc291cmNl cyBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlIEdTLiBUaGUgQ2xpZW50IG1heSBiZSBhYmxlIHRvIGRv IGFsbCBvZiBDUlVEIG9uIHRoZSByZXNvdXJjZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhlcmUgaXMgb3ZlcmxhcCB3 aXRoIHRoZSBVc2VySW5mbyBlbmRwb2ludCB0aGF0IGl0IGNvdWxkIGJlIGNvbnNpZGVyZWQgYSBy ZXNvdXJjZSwgSSBkb24ndCB0aGluayB0aGF0IGhlbHBzIHRoZSBhdWRpZW5jZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxhbmd1YWdl IGluIFhBdXRoIGNhbiBkZWZpbml0ZWx5IHVzZSBpbXByb3ZlbWVudCB0byBwcm92aWRlIG1vcmUg Y2xhcml0eSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+U2VjdGlvbiAxMi4xMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqV2h5IGNvbXBsaWNhdGUgdGhlIHNlcXVlbmNlIHdpdGgg JnF1b3Q7aW50ZXJhY3Rpb24mcXVvdDsuJnF1b3Q7a2VlcCZxdW90Oz8qPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdW5kZXJzdGFuZCB0aGUgdXNl IGNhc2UgeW914oCZcmUgdHJ5aW5nIHRvIHN1cHBvcnQgaGVyZSwgYnV0IEkgdGhpbmsgdGhlIHBy b3Bvc2FsIGlzIHRvbyBjb21wbGljYXRlZCB0byBpbXBsZW1lbnQuIEZyb20gdGhlIHNlcXVlbmNl cywgaXQgbG9va3MgbGlrZSB0aGUgQ2xpZW50DQogaXMgZXhwZWN0ZWQgdG8gaXNzdWUgYSBSZWFk IEdyYW50IHJlcXVlc3QsIGFuZCB0aGF0IGNvbm5lY3Rpb24gd2lsbCBiZSBrZXB0IG9wZW4gd2hp bGUgdGhlIFVzZXIgaXMgcmVkaXJlY3RlZCB0byB0aGUgR1MgYW5kIGdvZXMgdGhyb3VnaCB0aGUg YXV0aGVudGljYXRpb24gd29ya2Zsb3cgKGFuZCBwb3NzaWJseSBwYXJ0IG9mIHRoZSBhdXRob3Jp emF0aW9uIHdvcmtmbG93KS4gT25seSB0aGVuIHdvdWxkIHRoZSBHUyByZXR1cm4gdGhlIFJlYWQg R3JhbnQNCiByZXNwb25zZS4gSXMgdGhpcyBjb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PlRvIGltcGxlbWVudCB0aGlzLCB0aGUgQ2xpZW50IGhhcyB0byBsYXVuY2ggYW4gYXN5bmNocm9u b3VzIHRocmVhZCB0byBleGVjdXRlIHRoYXQgcmVxdWVzdCBhbmQgYXdhaXRpbmcgdGhlIHJlc3Bv bnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5Qb3NzaWJsZSwgYnV0IHN1c2NlcHRpYmxlIHRvIGZhaWx1cmVzLiBXaGF0 IGhhcHBlbnMgaWYgdGhhdCB0aHJlYWQgY3Jhc2hlcz8gT3IgZmFpbHMgdG8gc2VuZCB0aGUgVXBk YXRlIEdyYW50IHJlcXVlc3QgdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVwIHRvIGZhbHNlPyBXaGF0 DQogaXMgdGhlIEdTIGRvaW5nIGluIHRoZSBtZWFudGltZT8gSXMgaXQganVzdCBzaG93aW5nIHRo ZSBVc2VyIGEg4oCcbG9hZGluZ+KAnSB3aWRnZXQgYXMgaXQgd2FpdHMgZm9yIHRoZSBDbGllbnQg dG8gdXBkYXRlIHRoZSBncmFudD8gSG93IGxvbmcgZG9lcyBpdCB3YWl0IGZvcj8gRm9yIG1vYmls ZSBhcHBzLCB0aGF0IGJhY2tncm91bmQgdGhyZWFkIG1heSBnZXQga2lsbGVkIG9yIGxvc2UgbmV0 d29yayBjb25uZWN0aXZpdHkgYXMgc29vbiBhcyB0aGUgdXNlcg0KIGdldHMgc3dpdGNoZWQgb3Zl ciB0byB0aGUgc3lzdGVtIGJyb3dzZXIgdG8gbG9hZCB0aGUgR1Mgc2lnbiBpbiBwYWdlLiBGb3Ig YSBwdXJlLUpTIGFwcCB0aGF0IHJlZGlyZWN0cywgSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgcG9z c2libGUgYXQgYWxsLiAodW5sZXNzIHdlYiB3b3JrZXJzIGNhbiBzdXJ2aXZlIHBhZ2UgdW5sb2Fk cz8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBhbiBpbnRlcmVzdGluZyB1c2UgY2Fz ZSBmb3IgdXMgdG8gdGhpbmsgYWJvdXQsIGJ1dCBpdCBuZWVkcyBhIGxvdCBvZiB3b3JrIGFuZCBt YXkgbm90IGJlIHNvbWV0aGluZyB3ZSBzaG91bGQgdHJ5IHRvIGJha2UgaW50byB0aGUgY29yZSBw cm90b2NvbCBpZiB3ZQ0KIGRvbuKAmXQgbmVlZCB0by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQgbWlnaHQgbm90IGhhdmUgYmVlbiBvYnZpb3VzLCBidXQgdGhlIENsaWVudCBjYWxsaW5n IHRoZSBHUyB0byBnZXQgYSByZXN1bHQgd2hpbGUgdGhlIGludGVyYWN0aW9uIGlzIGhhcHBlbmlu ZyBpcyB3aGF0IGhhcHBlbnMgaW4gYW55IGZsb3cgd2l0aCBhbiBpbnRlcmFjdGlvbiBzdGFydGVk IGJ5IHRoZSBDbGllbnQuIEl0IGlzIG5vdCB1bmlxdWUgdG8gJnF1b3Q7aW50ZXJhY3Rpb24mcXVv dDsuJnF1b3Q7a2VlcCZxdW90OyAtLSB3ZSBhcmUganVzdA0KIGFkZGluZyBhZGRpdGlvbmFsIGJh Y2sgYW5kIGZvcnRocyBiZXR3ZWVuIHRoZSBDbGllbnQgYW5kIEdTLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIFFSIENvZGUgZXhhbXBsZSBI QVMgdG8gd29yayB0aGlzIHdheSwgYXMgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciB0aGUgQ2xp ZW50IHRvIGtub3cgdGhlIGludGVyYWN0aW9uIGhhcyBjb21wbGV0ZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2dsZSBhbmQgTWljcm9z b2Z0IGJvdGggaGF2ZSBhIHNpbWlsYXIgdXNlciBleHBlcmllbmNlLiBUaGUgVXNlciB3YW50cyB0 byBsb2cgaW50byBhbiBhcHAgLS0gdGhleSBhcmUgaW5zdHJ1Y3RlZCB0byBnbyB0byB0aGUgcmVz cGVjdGl2ZSBtb2JpbGUgYXBwIHRvIGFwcHJvdmUgdGhlIGF1dGhlbnRpY2F0aW9uIC0tIGFuZCB0 aGVuIHRoZSBVc2VyIHJldHVybnMgdG8gdGhlIGFwcCB3aGljaCBjaGFuZ2VzIHRvDQogYSBsb2dn ZWQgaW4gc3RhdGUuJm5ic3A7IEFuIGF1dGhlbnRpY2F0aW9uIG9ubHkgZmxvdyB1c2luZyBYQXV0 aCB3b3VsZCB3b3JrIHRoZSBzYW1lIHdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gMTIuMTQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKldoeSB1c2UgVVJJcyB0byBpbnN0 ZWFkIG9mIGhhbmRsZXMgZm9yIHRoZSBHcmFudCBhbmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QXV0aG9yaXphdGlvbj8qPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgZGlkbuKAmXQgbGlrZSB0aGlzIHVudGlsIEkgcmVhbGl6ZWQgdGhhdCB5b3Xi gJlyZSBkaXN0aW5ndWlzaGluZyBiZXR3ZWVuIGhhbmRsZXMvVVJJcyBhbmQgdG9rZW5zLiBOb3cg dGhhdCBJ4oCZdmUgdGhvdWdodCBhYm91dCBpdCBtb3JlLCBJIGxpa2UgdGhpcyBmcm9tIHRoZSBz dGFuZHBvaW50DQogdGhhdCBpdCB1bmRlcnNjb3JlcyB0aGUgaWRlYSBvZiBHcmFudHMgYW5kIEF1 dGhvcml6YXRpb25zIGJlaW5nIHBlcnNpc3RlbnQgb2JqZWN0cyB3aXRoaW4gdGhlIHByb3RvY29s Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjopPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+QW5kIGl04oCZcyByZWFsbHkganVzdCBtYWtpbmcgcHVibGljIHNvbWV0 aGluZyB0aGF0IHRoZSBHUyBpcyBwcm9iYWJseSBnb2luZyB0byBiZSBkb2luZyB1bmRlciB0aGUg aG9vZCBhbnl3YXkuIEhvd2V2ZXIsIHdlIGhhdmUgdG8gYmUgY2FyZWZ1bCB0aGF0IHdlIGRvbuKA mXQgYWNjaWRlbnRhbGx5DQogZW5jb3VyYWdlIGltcGxlbWVudGVycyB0byBzdGFydCBzaG92aW5n IHRoaW5ncyBpbnRvIHRoZXNlIFVSSXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBV UkkgY29udGVudCBpcyBpbnRlbmRlZCB0byBiZSBvcGFxdWUuIFRoZXJlIHdvdWxkIGJlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHdvdWxkIGtlZXAgcGVvcGxlIGZyb20gcHV0dGluZyB2aXNpYmxl IHN0dWZmIGluIHRoZXJlIHRoZXkgc2hvdWxkbid0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGV4cGVjdCBpbXBsZW1lbnRhdGlv bnMgdG8gdXNlIGEgcmFuZG9tIHZhbHVlIHdpdGggYSBjaGVja3N1bSwgb3IgYSBKV1QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5 LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3 cy5hbWF6b24uY29tL2lkZW50aXR5Lzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VHhhdXRoICZsdDs8YSBocmVm PSJtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGgt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBo cmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhh cmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgRmVicnVhcnkg NywgMjAyMCBhdCA4OjAwIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4 YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltUeGF1dGhdIFhBdXRo IC0wMjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPkkndmUgaGVhdmlseSByZXZpc2VkIFhBdXRoIGFnYWluLiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy4uaWV0Zi5v cmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QSBudW1iZXIgb2YgbmV3IGlkZWFzIHRv IGJvdW5jZSBhcm91bmQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSBo YXZlIGluY2x1ZGVkIGEgYnVuY2ggb2Ygc2VxdWVuY2VzIHRvIHNob3cgZGlmZmVyZW50IHVzZSBj YXNlcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5SYXRo ZXIgdGhhbiBhIHRyYW5zYWN0aW9uLCBJIHVzZSBhIEdyYW50IGFzIHRoZSBjZW50cmFsIG9iamVj dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgaW50ZXJmYWNlIGlz IHZlcnkgUkVTVGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg QVMgaXMgbm93IGEgR3JhbnQgU2VydmVyIChHUyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj5UaGlzIGFsc28gc2VlbWVkIGFwcHJvcHJpYXRlIGF0IGl0IGlzIGJvdGggYW4g T0F1dGggQVMsIGFuZCBhbiBPSURDIE9QLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPlJhdGhlciB0aGFuIGEgaGFuZGxlLCB0aGUgR3JhbnQgaGFzIGEgVVJJLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBlbmRwb2ludCBVUkkgZm9y IHRoZSBHUyBpcyB0aGUgR1MgVVJJLCBhbmQgaXMgdGhlIEdTIGlkZW50aWZpZXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QW4gYWNjZXNzIHRva2VuLCByZWZyZXNoIHRv a2VuIGV0Yy4gYXJlIGFsbCBhbiBBdXRob3JpemF0aW9uLiBBbiBBdXRob3JpemF0aW9uIGhhcyBh biBBdXRoWiBVUkkuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBH cmFudCBVUkkgYW5kIEF1dGhaIFVSSSBhbGwgc3RhcnQgd2l0aCB0aGUgR1MgVVJJLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkEgR3JhbnQgaXMgY3JlYXRlZCBieSBkb2lu ZyBhIFBPU1QgdG8gdGhlIEdTIFVSSSwgcmV0dXJuaW5nIGEgR3JhbnQgVVJJLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPk1ldGFkYXRhIGZvciB0aGUgR1MgaXMgZG9uZSB3 aXRoIGFuIE9QVElPTlMgdG8gdGhlIEdTIFVSSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgQ2xpZW50IGNhbiBkbyBHRVQsIFVQREFURSwgYW5kIERFTEVURSBhZ2Fp bnN0IGEgR3JhbnQgVVJJLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkFu IGFjY2VzcyB0b2tlbiByZWZyZXNoIGlzIGEgR0VUIG9uIHRoZSBBdXRoWiBVUkkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5BZGRpbmcgaW4gUmVjaXByb2Nh bCBPQXV0aCBmdW5jdGlvbmFsaXR5IHdhcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZCB0aGFuIGluIE9B dXRoIDIuMCAtLSBidXQgbm90IGFzIHN0cmFpZ2h0IGZvcndhcmQgYXMgSSB3b3VsZCBsaWtlIC0t IGJ1dCBub3QgY2xlYXIgaG93IHRvIG1ha2UgaXQgYmV0dGVyIGFuZCBzdGFydCBmcm9tIHRoZSBD bGllbnQgYW5kIEdTIGhhdmluZyBjb250ZXh0IG9mIG9uZSBhdXRob3JpemF0aW9uDQogYmVmb3Jl IHN3YXBwaW5nIHJvbGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlBl ciBteSBsYXN0IGVtYWlscywgbmFtaW5nIGlzIGhhcmQsIHRoZXJlIGFyZSBsaWtlbHkgbG90cyBv ZiBtaXN0YWtlcywgYW5kIGxvdHMgb2YgYXNwZWN0cyB0aGF0IG5lZWQgbm9ybWF0aXZlIGxhbmd1 YWdlLiBIb3BlZnVsbHkgdGhlIGNvbmNlcHRzIGNvbWUgdGhyb3VnaCE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4vRGljazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiBpZD0i X3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRl cj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFt cDtndWlkPTdjZDE4ZWE2LThjNTAtNDZkYy1iZTI1LWU5OWY2MTRkYWI4MiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N Cjxicj48ZGl2PlRoaXMgZS1tYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIGlzIGludGVuZGVk IGZvciB0aGUgcGVyc29uKHMpIG9yIGNvbXBhbnkgbmFtZWQgYW5kIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBhbmQvb3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLjwvZGl2PlVuYXV0 aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIG1h eSBiZSB1bmxhd2Z1bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIG5vdGlmeSB0aGUg c2VuZGVyLjxicj5BbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUtbWFpbCBtZXNzYWdlcyBhcmUg c3RvcmVkIGluIHRoZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3NhZ2UgUmVwb3NpdG9yeS48YnI+ SWYgeW91IGRvIG5vdCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50aWFsbHkgcHJpdmF0ZSBl LW1haWxzIGJ5IFN3aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91IG5vdCB0byB1c2UgdGhl IFN3aXNzIFJlIGUtbWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwgbm9uLWJ1c2luZXNzIHJl bGF0ZWQgY29tbXVuaWNhdGlvbnMuPC9ib2R5Pg0KPC9odG1sPg0K --_000_83d2e96f06e94a9d86d5e459dfa3584fCHRP5009corpgwpnetcom_-- From nobody Thu Feb 13 02:52:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB511200EF for ; Thu, 13 Feb 2020 02:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS5ZS5qJ_4zb for ; Thu, 13 Feb 2020 02:51:56 -0800 (PST) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4AF1200EC for ; Thu, 13 Feb 2020 02:51:56 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 781E7385BBB; Thu, 13 Feb 2020 10:51:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1581591113; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WtwsRBOY4CsYi7FWo0HeCqELfkeqNVC1ocf4oIlv7bA=; b=DhRSBnDNvK2ytAamMkjWBgA1mB6GlVemNRMK54of6cNu6WaJsqbJRJ8R4EBpjZbQs55z6O pA/MqfNstDF7NXJdc9MCruVoRkrDzXby9fwDo2RBHG20W0RQxsw1nB3nrfmfhveSLCvQ3O dnOn3XQ0PBx+OXXAX2z3l6YS2DpXVvQ= Content-Type: multipart/alternative; boundary=Apple-Mail-E7381976-5659-43DE-943B-2117EC5059AB Content-Transfer-Encoding: 7bit From: David Mime-Version: 1.0 Date: Thu, 13 Feb 2020 03:51:50 -0700 Message-Id: References: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> Cc: Dick Hardt , "Richard Backman, Annabelle" , "txauth@ietf.org" In-Reply-To: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> To: Lee McGovern ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1581591114; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WtwsRBOY4CsYi7FWo0HeCqELfkeqNVC1ocf4oIlv7bA=; b=jYQZd7ah2f9r+vyakXq8nRpIBMvhgO83RMOq8v36JVdktbcLF3MgBMfITBXv0OrlLfnfJs VY1m9ZWiyGCCm5cqwESQwOXUsee9m0hC/Tzc7K9ZfglaG+ArhR+yDXjbrLJJpr2Djta5wL u3/Kk+G9hnMF2h/lUuh0AxA9tjTlnHE= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1581591114; a=rsa-sha256; cv=none; b=jdJ52vOUWFpkUOYjN5bfx9x0hc6zTElw7w+pqdaZvmLLLjY7UFYn7MxILXctZSTlmbBPoH quTsC7UPLM5zGCbBCyIycdq6eYPGcBoQE2zL1yBTRtHDBfRIX/jWkpAFqx0RBnejmQSai8 zAX/uZkT94/DM9BQCz/tn9vjJ1EZluU= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 10:52:00 -0000 --Apple-Mail-E7381976-5659-43DE-943B-2117EC5059AB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In what context? I do not believe this draft mandates tokens in a particular= format.=20 That said - likely not for any standardized communication, since PASETO is a= non standardized vendor format.=20 -DW > On Feb 13, 2020, at 1:57 AM, Lee McGovern wrote= : >=20 > =EF=BB=BF > Is an alternative to JOSE being considered for example PASETO? > =20 > =20 > From: Dick Hardt =20 > Sent: Donnerstag, 13. Februar 2020 03:34 > To: Richard Backman, Annabelle > Cc: txauth@ietf.org > Subject: Re: [Txauth] XAuth -02 > =20 > Thanks for the feedback Annabelle, sorry for the delay in responding. > =20 > Comments and questions inserted: > =20 > On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle wrote: > Interesting work. I am enjoying the fact that we have two different takes o= n the same problem. The comparisons and discussions will lead us to a better= overall solution. > =20 > That was my goal of publishing the draft! > =20 > =20 > Here are my comments on XAuth-02: > =20 > Section 2.1: > * *Resource Owner* (RO) - owns the RS, and has delegated RS access > management to the GS. The RO may be the same entity as the User, ..= . > =20 > I=E2=80=99m rather baffled by this definition, and wondering if it=E2=80=99= s a mistake or if I=E2=80=99m misinterpreting it. Is this an intentional dep= arture from how =E2=80=9CRO=E2=80=9D is typically used within the OAuth 2.0 s= pace? Usually the term RO refers to the entity that owns the specific resour= ces the client is requesting authorization for. The RO does not typically ow= n the RS itself. > =20 > Mistake. Thanks for catching! > =20 > =20 > Section 5.5.2: > The interaction object contains the type of interaction the Client > will provide the User. Other attributes > > - *type* - contains one of the following values: "popup", > "redirect", or "qrcode".... > =20 > 3 issues with this: > How would I do a user code-based interaction? > To clarify, the User is entering a code in the Client into the GS, or the U= ser is entering a code into the Client?=20 > =20 > If the prior, the QR code also allows a message. I'm envisioning a User wi= th a mobile phone can scan the QR code which contains a URL at the GS, and i= ncludes the code.=20 > =20 > The message would describe what to do and include the code. > =20 > =20 > Clients support multiple interaction modes and may not always know what th= e GS supports (and vice-versa). For a multi-tenant GS, it may vary by tenant= configuration. Clients should be able to say what they can do, and the GS s= hould be able to tell them which one to use. It=E2=80=99s a very simple but p= owerful inline negotiation. > =20 > That is what is in TxAuth. Would you elaborate on how the GS might be cons= trained? Why would the GS not be able to do all? > =20 > I would think all constraints would be at the Client. Am I missing somethi= ng? > =20 > =20 > I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D interaction m= ode. Clients can use =E2=80=9Credirect=E2=80=9D mode within popups. However,= speaking as someone who has done that, I really don=E2=80=99t recommend it.= Popups are increasingly unsupported, and prone to weird behavioral issues. I= n-app browsers in Facebook, Twitter, etc. tend to have popups disabled. The l= ast versions of IE Mobile didn=E2=80=99t support them at all (the popped up p= age basically just loaded into the current window). in=20 > =20 > Popups are really useful in single-page apps as you want to keep the conte= xt and not reload the page. > =20 > Agree that popups don't make sense in mobile. A full redirect does of cour= se. A single-page app on mobile would open a new tab which would be a separa= te context rather than a redirect. > =20 > =20 > =20 > Section 12.6: > [Editor: is there some other reason to have the UserInfo > endpoint?] > =20 > I may want to host my UserInfo endpoint on a separate microservice from my= token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my us= er profile/directory stack, while the latter is part of the highly privilege= d authentication/authorization stack. > =20 > =20 > The token endpoint has the access token anyway, so it can fetch the data f= rom the other endpoint itself if it wanted to. IE, there is no separation of= duties. > =20 > What are the advantages of the UserInfo endpoint to the User or Client?=20= > =20 > The UserInfo endpoint seems to just add more complexity, with no ability t= o start a User interaction if additional consent is needed. > =20 > =20 > =20 > Section 12.8: > *Why have both claims and authorizations?* > =20 > There are use cases for each that are independent: > authenticating a user vs granting access to a resource. A > request for an authorization returns an access token or handle, > while a request for a claim returns the claim. > =20 > I don=E2=80=99t agree that the use cases are distinct. The only claim that= is strictly necessary for authentication is the user identifier. Other clai= ms like email and phone_number are often used to aid in local account identi= fication (i.e., account linking), but are useful and interesting beyond this= use case. > =20 > Some Clients use email and phone_number as the identifier and don't pay at= tention to the directed identifier. Not the best practice, but it is what pe= ople do. > =20 > Other claims such as name, preferred_username, and birthdate could be used= in a similar fashion, though they frequently aren=E2=80=99t. The same is tr= ue for other resources not currently defined as claims (e.g., the externalId= established when the user was imported through SCIM).. > =20 > Claims are just resources that OIDC provides a name registry and some extr= a features for: > Optionally get the value bundled with the authentication response, without= needing to call a separate endpoint. > In my opinion, all the different ways to get claims in OIDC is a bug, not= a feature. With the optionality at the OP, a generic Client has to support= both. > =20 > =20 > =20 > Optionally get the value in a signed or encrypted blob. > This optionality is useful to the Client, as it can decide what claims sho= uld be in the signed blob which may be used differently than other claims. > =20 > =20 > Optionally provide some structured metadata describing the resource and/or= requested authorization. > =20 > =20 > =20 > =20 > It=E2=80=99s telling that all of these are optional. If we think these are= features worth bringing forward into whatever protocol we produce through T= xAuth, we should look at them independently of the claim/resource dichotomy.= > =20 > I agree that these features are orthogonal to the "are claims and resource= s the same thing" debate.=20 > =20 > I strongly think it is a disservice to our audience to conflate claims and= resources. Claims are statements about the User and read-only. > =20 > Resources are independent of the GS. The Client may be able to do all of C= RUD on the resource.=20 > =20 > While there is overlap with the UserInfo endpoint that it could be conside= red a resource, I don't think that helps the audience. > =20 > The language in XAuth can definitely use improvement to provide more clari= ty here. > =20 > =20 > =20 > Section 12.12: > *Why complicate the sequence with "interaction"."keep"?* > =20 > I understand the use case you=E2=80=99re trying to support here, but I thi= nk the proposal is too complicated to implement. =46rom the sequences, it lo= oks like the Client is expected to issue a Read Grant request, and that conn= ection will be kept open while the User is redirected to the GS and goes thr= ough the authentication workflow (and possibly part of the authorization wor= kflow). Only then would the GS return the Read Grant response. Is this corre= ct? > =20 > To implement this, the Client has to launch an asynchronous thread to exec= ute that request and awaiting the response. > Possible, but susceptible to failures. What happens if that thread crashes= ? Or fails to send the Update Grant request to flip interaction.keep to fals= e? What is the GS doing in the meantime? Is it just showing the User a =E2=80= =9Cloading=E2=80=9D widget as it waits for the Client to update the grant? H= ow long does it wait for? For mobile apps, that background thread may get ki= lled or lose network connectivity as soon as the user gets switched over to t= he system browser to load the GS sign in page. For a pure-JS app that redire= cts, I don=E2=80=99t think this is possible at all. (unless web workers can s= urvive page unloads?) > =20 > This is an interesting use case for us to think about, but it needs a lot o= f work and may not be something we should try to bake into the core protocol= if we don=E2=80=99t need to. > =20 > It might not have been obvious, but the Client calling the GS to get a res= ult while the interaction is happening is what happens in any flow with an i= nteraction started by the Client. It is not unique to "interaction"."keep" -= - we are just adding additional back and forths between the Client and GS. > =20 > A QR Code example HAS to work this way, as there is no other way for the C= lient to know the interaction has completed. > =20 > Google and Microsoft both have a similar user experience. The User wants t= o log into an app -- they are instructed to go to the respective mobile app t= o approve the authentication -- and then the User returns to the app which c= hanges to a logged in state. An authentication only flow using XAuth would w= ork the same way. > =20 > =20 > =20 > Section 12.14: > *Why use URIs to instead of handles for the Grant and > Authorization?* > =20 > I didn=E2=80=99t like this until I realized that you=E2=80=99re distinguis= hing between handles/URIs and tokens. Now that I=E2=80=99ve thought about it= more, I like this from the standpoint that it underscores the idea of Grant= s and Authorizations being persistent objects within the protocol. > =20 > :) > =20 > And it=E2=80=99s really just making public something that the GS is probab= ly going to be doing under the hood anyway. However, we have to be careful t= hat we don=E2=80=99t accidentally encourage implementers to start shoving th= ings into these URIs. > =20 > The URI content is intended to be opaque. There would be security consider= ations would keep people from putting visible stuff in there they shouldn't.= > =20 > I would expect implementations to use a random value with a checksum, or a= JWT. > =20 > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth on behalf of Dick Hardt > Date: Friday, February 7, 2020 at 8:00 PM > To: "txauth@ietf.org" > Subject: [Txauth] XAuth -02 > =20 > I've heavily revised XAuth again. > =20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02 > =20 > A number of new ideas to bounce around: > =20 > I have included a bunch of sequences to show different use cases possible.= > =20 > Rather than a transaction, I use a Grant as the central object. > =20 > The interface is very RESTful. > =20 > The AS is now a Grant Server (GS) > =20 > This also seemed appropriate at it is both an OAuth AS, and an OIDC OP. > =20 > Rather than a handle, the Grant has a URI.=20 > =20 > The endpoint URI for the GS is the GS URI, and is the GS identifier. > =20 > An access token, refresh token etc. are all an Authorization. An Authoriza= tion has an AuthZ URI.. > =20 > The Grant URI and AuthZ URI all start with the GS URI. > =20 > A Grant is created by doing a POST to the GS URI, returning a Grant URI. > =20 > Metadata for the GS is done with an OPTIONS to the GS URI. > =20 > The Client can do GET, UPDATE, and DELETE against a Grant URI. > =20 > An access token refresh is a GET on the AuthZ URI. > =20 > Adding in Reciprocal OAuth functionality was more straightforward than in O= Auth 2.0 -- but not as straight forward as I would like -- but not clear how= to make it better and start from the Client and GS having context of one au= thorization before swapping roles. > =20 > Per my last emails, naming is hard, there are likely lots of mistakes, and= lots of aspects that need normative language. Hopefully the concepts come t= hrough! > =20 > /Dick > =E1=90=A7 >=20 > This e-mail, including attachments, is intended for the person(s) or compa= ny named and may contain confidential and/or legally privileged information.= > Unauthorized disclosure, copying or use of this information may be unlawfu= l and is prohibited. If you are not the intended recipient, please delete th= is message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re Elect= ronic Message Repository. > If you do not wish the retention of potentially private e-mails by Swiss R= e, we strongly advise you not to use the Swiss Re e-mail account for any pri= vate, non-business related communications. --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-E7381976-5659-43DE-943B-2117EC5059AB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable In what context? I do not believe this draf= t mandates tokens in a particular format. 

That said= - likely not for any standardized communication, since PASETO is a non stan= dardized vendor format. 

-DW
<= div dir=3D"ltr">
On Feb 13, 2020, at 1:57 AM, L= ee McGovern <Lee_McGovern@swissre.com> wrote:

=EF=BB=BF

Is an alternative to JOSE being considered for example PASETO?

 

 

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Donnerstag, 13. Februar 2020 03:34
To: Richard Backman, Annabelle <richanna@amazon.com>
Cc: txauth@ietf.org
Subject: Re: [Txauth] XAuth -02

 

Thanks for the feedback Annabelle, sorry for the dela= y in responding.

 

Comments and questions inserted:

 

On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Anna= belle <richanna@= amazon.com> wrote:

Interesting work. I am enjoying the fact that w= e have two different takes on the same problem. The comparisons and discussi= ons will lead us to a better overall solution.

 

That was my goal of publishing the draft!<= /p>

 

 

Here are my comments on XAuth-02:

 

Section 2.1:

   *  *Resource Owner* (RO) - own= s the RS, and has delegated RS access=

      management to the= GS.  The RO may be the same entity as the User, ...

 

I=E2=80=99m rather baffled by this definition, a= nd wondering if it=E2=80=99s a mistake or if I=E2=80=99m misinterpreting it.= Is this an intentional departure from how =E2=80=9CRO=E2=80=9D is typically= used within the OAuth 2.0 space? Usually the term RO refers to the entity t= hat owns the specific resources the client is requesting authorization for. T= he RO does not typically own the RS itself.

 

Mistake. Thanks for catching!

 

 

Section 5.5.2:

   The interaction=
 object contains the type of interaction the Client
   will provide th=
e User.  Other attributes=

<snip>
    &nbs=
p;   -  *type* - contains one of the following values: "popup=
",
    &nbs=
p;      "redirect", or "qrcode"....

 

3 issues with this:

  1. How would I do a user code-based interaction?

To clarify, the User is entering a code in the Client= into the GS, or the User is entering a code into the Client? 

 

If the prior, the QR code also allows a message. I'm e= nvisioning a User with a mobile phone can scan the QR code which contains a U= RL at the GS, and includes the code. 

 

The message would describe what to do and include the= code.

 

  1.  
  2. Clients support multiple interaction modes and may not a= lways know what the GS supports (and vice-versa). For a multi-tenant GS, it m= ay vary by tenant configuration. Clients should be able to say what they can= do, and the GS should be able to tell them which one to use. It=E2=80=99s a very simple but powerful inli= ne negotiation.

 

That is what is in TxAuth. Would you elaborate on how= the GS might be constrained? Why would the GS not be able to do all?

 

I would think all constraints would be at the Client.= Am I missing something?

 

  1.  
  2. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80= =9D interaction mode. Clients can use =E2=80=9Credirect=E2=80=9D mode within= popups. However, speaking as someone who has done that, I really don=E2=80=99= t recommend it. Popups are increasingly unsupported, and prone to weird beha= vioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups disa= bled. The last versions of IE Mobile didn=E2=80=99t support them at all (the= popped up page basically just loaded into the current window). in 

 

Popups are really useful in single-page apps as you w= ant to keep the context and not reload the page.

 

Agree that popups don't make sense in mobile. A full r= edirect does of course. A single-page app on mobile would open a new tab whi= ch would be a separate context rather than a redirect.

 

  1.  

 

Section 12.6:

    &nbs=
p;   [Editor: is there some other reason to have the UserInfo
    &nbs=
p;   endpoint?]

 


I may want to host my UserInfo endpoint on a se=
parate microservice from my token endpoint (in OAuth 2.0/OIDC terms). The fo=
rmer might be part of my user profile/directory
 stack, while the latter is part of the highly privileged authentication/aut=
horization stack.

 

 

The token endpoint has the access token anyway, so it= can fetch the data from the other endpoint itself if it wanted to. IE, ther= e is no separation of duties.

 

What are the advantages of the UserInfo endpoint to t= he User or Client? 

 

The UserInfo endpoint seems to just add more complexi= ty, with no ability to start a User interaction if additional consent is nee= ded.

 

 

 

Section 12.8:

    &nbs=
p;   *Why have both claims and authorizations?*
 
    &nbs=
p;   There are use cases for each that are independent:
    &nbs=
p;   authenticating a user vs granting access to a resource. =
 A
    &nbs=
p;   request for an authorization returns an access token or handl=
e,
    &nbs=
p;   while a request for a claim returns the claim.

 

I don=E2=80=99t agree that the use cases are di= stinct. The only claim that is strictly necessary for authentication is the u= ser identifier. Other claims like email and phone_number are often used to aid in local account identification (i.e., a= ccount linking), but are useful and interesting beyond this use case.

 

Some Clients use email and phone_number as the identi= fier and don't pay attention to the directed identifier. Not the best practi= ce, but it is what people do.

 

Other claims such as name, preferred_username, a= nd birthdate could be used in a similar fashion, though they frequently aren= =E2=80=99t. The same is true for other resources not currently defined as claims (e.g., the externalId established when the u= ser was imported through SCIM)..

 

Claims are just resources that OIDC provides a n= ame registry and some extra features for:

  • Optionally get the value bundled with the authenticatio= n response, without needing to call a separate endpoint.

 In my opinion, all the different ways to get cl= aims in OIDC is a bug, not a feature. With the optionality at the OP,  a= generic Client has to support both.

 

 

  •  
  • Optionally get the value in a signed or encrypted blob.=

This optionality is useful to the Client, as it can d= ecide what claims should be in the signed blob which may be used differently= than other claims.

 

  •  
  • Optionally provide some structured metadata describing t= he resource and/or requested authorization.

 

 

  •  

 

It=E2=80=99s telling that all of these are opti= onal. If we think these are features worth bringing forward into whatever pr= otocol we produce through TxAuth, we should look at them independently of the claim/resource dichotomy.

 

I agree that these features are orthogonal to the "ar= e claims and resources the same thing" debate. 

 

I strongly think it is a disservice to our audience t= o conflate claims and resources. Claims are statements about the User and re= ad-only.

 

Resources are independent of the GS. The Client may b= e able to do all of CRUD on the resource. 

 

While there is overlap with the UserInfo endpoint tha= t it could be considered a resource, I don't think that helps the audience.<= o:p>

 

The language in XAuth can definitely use improvement t= o provide more clarity here.

 

 

 

Section 12.12:

    &nbs=
p;   *Why complicate the sequence with "interaction"."keep"?*

 

I understand the use case you=E2=80=99re trying= to support here, but I think the proposal is too complicated to implement. = =46rom the sequences, it looks like the Client is expected to issue a Read Grant request, and that connection will be kept= open while the User is redirected to the GS and goes through the authentica= tion workflow (and possibly part of the authorization workflow). Only then w= ould the GS return the Read Grant response. Is this correct?

 

To implement this, the Client has to launch an a= synchronous thread to execute that request and awaiting the response.

Possible, but susceptible to failures. What hap= pens if that thread crashes? Or fails to send the Update Grant request to fl= ip interaction.keep to false? What is the GS doing in the meantime? Is it just showing the User a =E2=80=9Cloa= ding=E2=80=9D widget as it waits for the Client to update the grant? How lon= g does it wait for? For mobile apps, that background thread may get killed o= r lose network connectivity as soon as the user gets switched over to the system browser to load the GS sign in page. For a= pure-JS app that redirects, I don=E2=80=99t think this is possible at all. (= unless web workers can survive page unloads?)

 

This is an interesting use case for us to think= about, but it needs a lot of work and may not be something we should try to= bake into the core protocol if we don=E2=80=99t need to.

 

It might not have been obvious, but the Client callin= g the GS to get a result while the interaction is happening is what happens i= n any flow with an interaction started by the Client. It is not unique to "i= nteraction"."keep" -- we are just adding additional back and forths between the Client and GS.

=

 

A QR Code example HAS to work this way, as there is n= o other way for the Client to know the interaction has completed.=

 

Google and Microsoft both have a similar user experie= nce. The User wants to log into an app -- they are instructed to go to the r= espective mobile app to approve the authentication -- and then the User retu= rns to the app which changes to a logged in state.  An authentication only flow using XAuth would work= the same way.

 

 

 

Section 12.14:

    &nbs=
p;   *Why use URIs to instead of handles for the Grant and<=
span lang=3D"EN-US">
    &nbs=
p;   Authorization?*=

 

I didn=E2=80=99t like this until I realized tha= t you=E2=80=99re distinguishing between handles/URIs and tokens. Now that I=E2= =80=99ve thought about it more, I like this from the standpoint that it underscores the idea of Grants and Authorizations being persistent o= bjects within the protocol.

 

:)

 

And it=E2=80=99s really just making public some= thing that the GS is probably going to be doing under the hood anyway. Howev= er, we have to be careful that we don=E2=80=99t accidentally encourage implementers to start shoving things into these URIs.<= /span>

 

The URI content is intended to be opaque. There would= be security considerations would keep people from putting visible stuff in t= here they shouldn't.

 

I would expect implementations to use a random value w= ith a checksum, or a JWT.

 

 

=E2=80=93

Annabelle Backman (s= he/her)

AWS Identity<= span lang=3D"EN-US">

htt= ps://aws.amazon.com/identity/

 

 

From: = Txauth <<= a href=3D"mailto:txauth-bounces@ietf.org" target=3D"_blank">txauth-bounces@i= etf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 7, 2020 at 8:00 PM
To: "txauth@ietf= .org" <txauth@ie= tf.org>
Subject: [Txauth] XAuth -02

 

I've heavily revised XAuth again.

 

https://tools.ietf.org/html/draft-hardt-xa= uth-protocol-02

 

A number of new ideas to bounce around:

 

I have included a bunch of sequences to show different u= se cases possible.

 

Rather than a transaction, I use a Grant as the central= object.

 

The interface is very RESTful.

 

The AS is now a Grant Server (GS)

=

 

This also seemed appropriate at it is both an OAuth AS,= and an OIDC OP.

 

Rather than a handle, the Grant has a URI. 

 

The endpoint URI for the GS is the GS URI, and is the G= S identifier.

 

An access token, refresh token etc. are all an Authoriz= ation. An Authorization has an AuthZ URI..

 

The Grant URI and AuthZ URI all start with the GS URI.<= o:p>

 

A Grant is created by doing a POST to the GS URI, retur= ning a Grant URI.

 

Metadata for the GS is done with an OPTIONS to the GS U= RI.

 

The Client can do GET, UPDATE, and DELETE against a Gra= nt URI.

 

An access token refresh is a GET on the AuthZ URI.=

 

Adding in Reciprocal OAuth functionality was more strai= ghtforward than in OAuth 2.0 -- but not as straight forward as I would like -= - but not clear how to make it better and start from the Client and GS havin= g context of one authorization before swapping roles.

 

Per my last emails, naming is hard, there are likely lo= ts of mistakes, and lots of aspects that need normative language. Hopefully t= he concepts come through!

 

/Dick

=E1=90=A7


This e-mail, including attachments, is intended for the person(s) o= r company named and may contain confidential and/or legally privileged infor= mation.
Unauthorized disclosure, copying or use of this information may= be unlawful and is prohibited. If you are not the intended recipient, pleas= e delete this message and notify the sender.
All incoming and outgoing e-= mail messages are stored in the Swiss Re Electronic Message Repository.
I= f you do not wish the retention of potentially private e-mails by Swiss Re, w= e strongly advise you not to use the Swiss Re e-mail account for any private= , non-business related communications. --
Txauth mailing list
Txauth@ietf.or= g
https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail-E7381976-5659-43DE-943B-2117EC5059AB-- From nobody Thu Feb 13 03:32:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1A11200F1 for ; Thu, 13 Feb 2020 03:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swissre.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfdfqK3udS2F for ; Thu, 13 Feb 2020 03:32:40 -0800 (PST) Received: from esa8.hc1106-67.c3s2.iphmx.com (esa8.hc1106-67.c3s2.iphmx.com [139.138.36.49]) (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 74648120043 for ; Thu, 13 Feb 2020 03:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1581593560; x=1613129560; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qWRainW3F3/uNifNRxxMKmZYWJcM26vmmYKUMUXXgjU=; b=KJiXMzFaupNWwotwLsm5ipJKXChOWgyTSm2RaHwkTqUrhK6rZDcrnc9t bGtI/+jcE2Tt5AK4UtA0buX7e8V07Splwx94q1qhjDOKjd6cn6xS+xUpI I5jmK/IjpncaTpaLdsl/PUY6gurerO9iezdHiCP5+AN5UMIak3YD2TGFg bA6R1PvNqQkd70BbmNl+QrWySI7OozYwcgrOi6PGFfpkYBLdII/Mbve0I ySGNdiHUW4Ws7iU3vOxyJW/58U7cHCQBkED2QLfLfMjxolaWHVe7C2USR EdtqSJHbCGEP6ykkFvKw+KHVeuXoPXnFTPeW6cjafKn9Dr4iwnhElFfHt A==; IronPort-SDR: jGIhCM0yVqbEewQ1BtwS96VC0RleSDOcbfczgWRU+j2dY5sk8MDvQSnd2KIPu4TJ5mRGawoPNh yo6Eg1CmN5/9X7oMJPTkthmWfadecCUV2GKxbHgMIGI3GETIVaY+78T4J0TIE1BUO7wgVUMvJg nC2sq5Mz14yi1mB8Hhz/10k8z/eCDucJHt2erledZ8QXKhWxoiCLmZaYs9T1Zli4njaEYAKmvr ZLOALGyT+DJyiQE+NoIjrYzBmbwtxKpnJiKlY2RBoSPC6ykvDx8juh2uSDc3owPZMb0r2DN8S+ I/s= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.103]) by esa8.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 13 Feb 2020 11:32:37 +0000 Received: from CHRP5010.corp.gwpnet.com (10.53.3.188) by edge.swissre.com (193.246.239.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Feb 2020 12:32:36 +0100 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5010.corp.gwpnet.com (10.53.3.188) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Feb 2020 12:32:34 +0100 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.000; Thu, 13 Feb 2020 12:32:34 +0100 From: Lee McGovern To: David CC: Dick Hardt , "Richard Backman, Annabelle" , "txauth@ietf.org" Thread-Topic: [Txauth] XAuth -02 Thread-Index: AQHV4hY2vRTdwp1ZM0C4ZJEDoPnnE6gY0MvggAARdQCAABuH0A== Date: Thu, 13 Feb 2020 11:32:33 +0000 Message-ID: <93f0a28651cc447182ffb2d0ccd9107e@CHRP5009.corp.gwpnet.com> References: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2020-02-13T11:32:32.9164687Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.10] x-rcom-deduphash: 5beeecb6-57f8-4951-99bc-2c5c7284a26d Content-Type: multipart/alternative; boundary="_000_93f0a28651cc447182ffb2d0ccd9107eCHRP5009corpgwpnetcom_" MIME-Version: 1.0 X-GBS-PROC: NlZb6SSb3rIQOquSs+1yeSMtO7Pg7HGpbodZEt9+TQ8= Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 11:32:45 -0000 --_000_93f0a28651cc447182ffb2d0ccd9107eCHRP5009corpgwpnetcom_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SW4gcmVmZXJlbmNlIHRvIHNlY3Rpb25zIDEwLjEuMywgMTAuMi4xLCAxMC4yLjIsIDEwLjIuMy4g SWYgdGhlIGN1cnJlbnQgUkZDJ3MgZm9yIEpPU0UgcmVxdWlyZSB0aGUgSldUIEJDUCB0byBiZSBp bXBsZW1lbnRlZCBjb3JyZWN0bHkgcGVyaGFwcyBpdCBtYXkgYmUgYmV0dGVyIHRvIHN0YXJ0IGZy b20gYSBuZXcgaW1wbGVtZW50YXRpb24gd2hpY2ggYWltcyB0byBzb2x2ZSB0aG9zZSBmcm9tIHRo ZSBiZWdpbm5pbmc/DQoNCkZyb206IERhdmlkIDxkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29t Pg0KU2VudDogRG9ubmVyc3RhZywgMTMuIEZlYnJ1YXIgMjAyMCAxMTo1Mg0KVG86IExlZSBNY0dv dmVybiA8TGVlX01jR292ZXJuQHN3aXNzcmUuY29tPg0KQ2M6IERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPjsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpv bi5jb20+OyB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBYQXV0aCAtMDIN Cg0KSW4gd2hhdCBjb250ZXh0PyBJIGRvIG5vdCBiZWxpZXZlIHRoaXMgZHJhZnQgbWFuZGF0ZXMg dG9rZW5zIGluIGEgcGFydGljdWxhciBmb3JtYXQuDQoNClRoYXQgc2FpZCAtIGxpa2VseSBub3Qg Zm9yIGFueSBzdGFuZGFyZGl6ZWQgY29tbXVuaWNhdGlvbiwgc2luY2UgUEFTRVRPIGlzIGEgbm9u IHN0YW5kYXJkaXplZCB2ZW5kb3IgZm9ybWF0Lg0KDQotRFcNCg0KDQpPbiBGZWIgMTMsIDIwMjAs IGF0IDE6NTcgQU0sIExlZSBNY0dvdmVybiA8TGVlX01jR292ZXJuQHN3aXNzcmUuY29tPG1haWx0 bzpMZWVfTWNHb3Zlcm5Ac3dpc3NyZS5jb20+PiB3cm90ZToNCu+7vw0KSXMgYW4gYWx0ZXJuYXRp dmUgdG8gSk9TRSBiZWluZyBjb25zaWRlcmVkIGZvciBleGFtcGxlIFBBU0VUTz8NCg0KDQpGcm9t OiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20+Pg0KU2VudDogRG9ubmVyc3RhZywgMTMuIEZlYnJ1YXIgMjAyMCAwMzozNA0KVG86IFJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNo YW5uYUBhbWF6b24uY29tPj4NCkNjOiB0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBYQXV0aCAtMDINCg0KVGhhbmtzIGZvciB0aGUg ZmVlZGJhY2sgQW5uYWJlbGxlLCBzb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuDQoN CkNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgaW5zZXJ0ZWQ6DQoNCk9uIE1vbiwgRmViIDEwLCAyMDIw IGF0IDM6MzggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5j b208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCkludGVyZXN0aW5nIHdvcmsu IEkgYW0gZW5qb3lpbmcgdGhlIGZhY3QgdGhhdCB3ZSBoYXZlIHR3byBkaWZmZXJlbnQgdGFrZXMg b24gdGhlIHNhbWUgcHJvYmxlbS4gVGhlIGNvbXBhcmlzb25zIGFuZCBkaXNjdXNzaW9ucyB3aWxs IGxlYWQgdXMgdG8gYSBiZXR0ZXIgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KVGhhdCB3YXMgbXkgZ29h bCBvZiBwdWJsaXNoaW5nIHRoZSBkcmFmdCENCg0KDQpIZXJlIGFyZSBteSBjb21tZW50cyBvbiBY QXV0aC0wMjoNCg0KU2VjdGlvbiAyLjE6DQogICAqICAqUmVzb3VyY2UgT3duZXIqIChSTykgLSBv d25zIHRoZSBSUywgYW5kIGhhcyBkZWxlZ2F0ZWQgUlMgYWNjZXNzDQogICAgICBtYW5hZ2VtZW50 IHRvIHRoZSBHUy4gIFRoZSBSTyBtYXkgYmUgdGhlIHNhbWUgZW50aXR5IGFzIHRoZSBVc2VyLCAu Li4NCg0KSeKAmW0gcmF0aGVyIGJhZmZsZWQgYnkgdGhpcyBkZWZpbml0aW9uLCBhbmQgd29uZGVy aW5nIGlmIGl04oCZcyBhIG1pc3Rha2Ugb3IgaWYgSeKAmW0gbWlzaW50ZXJwcmV0aW5nIGl0LiBJ cyB0aGlzIGFuIGludGVudGlvbmFsIGRlcGFydHVyZSBmcm9tIGhvdyDigJxST+KAnSBpcyB0eXBp Y2FsbHkgdXNlZCB3aXRoaW4gdGhlIE9BdXRoIDIuMCBzcGFjZT8gVXN1YWxseSB0aGUgdGVybSBS TyByZWZlcnMgdG8gdGhlIGVudGl0eSB0aGF0IG93bnMgdGhlIHNwZWNpZmljIHJlc291cmNlcyB0 aGUgY2xpZW50IGlzIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiBmb3IuIFRoZSBSTyBkb2VzIG5v dCB0eXBpY2FsbHkgb3duIHRoZSBSUyBpdHNlbGYuDQoNCk1pc3Rha2UuIFRoYW5rcyBmb3IgY2F0 Y2hpbmchDQoNCg0KU2VjdGlvbiA1LjUuMjoNCg0KICAgVGhlIGludGVyYWN0aW9uIG9iamVjdCBj b250YWlucyB0aGUgdHlwZSBvZiBpbnRlcmFjdGlvbiB0aGUgQ2xpZW50DQoNCiAgIHdpbGwgcHJv dmlkZSB0aGUgVXNlci4gIE90aGVyIGF0dHJpYnV0ZXMNCg0KPHNuaXA+DQoNCiAgICAgICAgLSAg KnR5cGUqIC0gY29udGFpbnMgb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzOiAicG9wdXAiLA0K DQogICAgICAgICAgICJyZWRpcmVjdCIsIG9yICJxcmNvZGUiLi4uLg0KDQozIGlzc3VlcyB3aXRo IHRoaXM6DQoNCiAgMS4gIEhvdyB3b3VsZCBJIGRvIGEgdXNlciBjb2RlLWJhc2VkIGludGVyYWN0 aW9uPw0KVG8gY2xhcmlmeSwgdGhlIFVzZXIgaXMgZW50ZXJpbmcgYSBjb2RlIGluIHRoZSBDbGll bnQgaW50byB0aGUgR1MsIG9yIHRoZSBVc2VyIGlzIGVudGVyaW5nIGEgY29kZSBpbnRvIHRoZSBD bGllbnQ/DQoNCklmIHRoZSBwcmlvciwgdGhlIFFSIGNvZGUgYWxzbyBhbGxvd3MgYSBtZXNzYWdl LiBJJ20gZW52aXNpb25pbmcgYSBVc2VyIHdpdGggYSBtb2JpbGUgcGhvbmUgY2FuIHNjYW4gdGhl IFFSIGNvZGUgd2hpY2ggY29udGFpbnMgYSBVUkwgYXQgdGhlIEdTLCBhbmQgaW5jbHVkZXMgdGhl IGNvZGUuDQoNClRoZSBtZXNzYWdlIHdvdWxkIGRlc2NyaWJlIHdoYXQgdG8gZG8gYW5kIGluY2x1 ZGUgdGhlIGNvZGUuDQoNCg0KICAxLg0KICAyLiAgQ2xpZW50cyBzdXBwb3J0IG11bHRpcGxlIGlu dGVyYWN0aW9uIG1vZGVzIGFuZCBtYXkgbm90IGFsd2F5cyBrbm93IHdoYXQgdGhlIEdTIHN1cHBv cnRzIChhbmQgdmljZS12ZXJzYSkuIEZvciBhIG11bHRpLXRlbmFudCBHUywgaXQgbWF5IHZhcnkg YnkgdGVuYW50IGNvbmZpZ3VyYXRpb24uIENsaWVudHMgc2hvdWxkIGJlIGFibGUgdG8gc2F5IHdo YXQgdGhleSBjYW4gZG8sIGFuZCB0aGUgR1Mgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCB0aGVtIHdo aWNoIG9uZSB0byB1c2UuIEl04oCZcyBhIHZlcnkgc2ltcGxlIGJ1dCBwb3dlcmZ1bCBpbmxpbmUg bmVnb3RpYXRpb24uDQoNClRoYXQgaXMgd2hhdCBpcyBpbiBUeEF1dGguIFdvdWxkIHlvdSBlbGFi b3JhdGUgb24gaG93IHRoZSBHUyBtaWdodCBiZSBjb25zdHJhaW5lZD8gV2h5IHdvdWxkIHRoZSBH UyBub3QgYmUgYWJsZSB0byBkbyBhbGw/DQoNCkkgd291bGQgdGhpbmsgYWxsIGNvbnN0cmFpbnRz IHdvdWxkIGJlIGF0IHRoZSBDbGllbnQuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCg0KICAx Lg0KICAyLiAgSSBkb27igJl0IHNlZSB0aGUgdmFsdWUgb2YgdGhlIOKAnHBvcHVw4oCdIGludGVy YWN0aW9uIG1vZGUuIENsaWVudHMgY2FuIHVzZSDigJxyZWRpcmVjdOKAnSBtb2RlIHdpdGhpbiBw b3B1cHMuIEhvd2V2ZXIsIHNwZWFraW5nIGFzIHNvbWVvbmUgd2hvIGhhcyBkb25lIHRoYXQsIEkg cmVhbGx5IGRvbuKAmXQgcmVjb21tZW5kIGl0LiBQb3B1cHMgYXJlIGluY3JlYXNpbmdseSB1bnN1 cHBvcnRlZCwgYW5kIHByb25lIHRvIHdlaXJkIGJlaGF2aW9yYWwgaXNzdWVzLiBJbi1hcHAgYnJv d3NlcnMgaW4gRmFjZWJvb2ssIFR3aXR0ZXIsIGV0Yy4gdGVuZCB0byBoYXZlIHBvcHVwcyBkaXNh YmxlZC4gVGhlIGxhc3QgdmVyc2lvbnMgb2YgSUUgTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhl bSBhdCBhbGwgKHRoZSBwb3BwZWQgdXAgcGFnZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0 aGUgY3VycmVudCB3aW5kb3cpLiBpbg0KDQpQb3B1cHMgYXJlIHJlYWxseSB1c2VmdWwgaW4gc2lu Z2xlLXBhZ2UgYXBwcyBhcyB5b3Ugd2FudCB0byBrZWVwIHRoZSBjb250ZXh0IGFuZCBub3QgcmVs b2FkIHRoZSBwYWdlLg0KDQpBZ3JlZSB0aGF0IHBvcHVwcyBkb24ndCBtYWtlIHNlbnNlIGluIG1v YmlsZS4gQSBmdWxsIHJlZGlyZWN0IGRvZXMgb2YgY291cnNlLiBBIHNpbmdsZS1wYWdlIGFwcCBv biBtb2JpbGUgd291bGQgb3BlbiBhIG5ldyB0YWIgd2hpY2ggd291bGQgYmUgYSBzZXBhcmF0ZSBj b250ZXh0IHJhdGhlciB0aGFuIGEgcmVkaXJlY3QuDQoNCg0KICAxLg0KDQpTZWN0aW9uIDEyLjY6 DQoNCiAgICAgICAgW0VkaXRvcjogaXMgdGhlcmUgc29tZSBvdGhlciByZWFzb24gdG8gaGF2ZSB0 aGUgVXNlckluZm8NCg0KICAgICAgICBlbmRwb2ludD9dDQoNCkkgbWF5IHdhbnQgdG8gaG9zdCBt eSBVc2VySW5mbyBlbmRwb2ludCBvbiBhIHNlcGFyYXRlIG1pY3Jvc2VydmljZSBmcm9tIG15IHRv a2VuIGVuZHBvaW50IChpbiBPQXV0aCAyLjAvT0lEQyB0ZXJtcykuIFRoZSBmb3JtZXIgbWlnaHQg YmUgcGFydCBvZiBteSB1c2VyIHByb2ZpbGUvZGlyZWN0b3J5IHN0YWNrLCB3aGlsZSB0aGUgbGF0 dGVyIGlzIHBhcnQgb2YgdGhlIGhpZ2hseSBwcml2aWxlZ2VkIGF1dGhlbnRpY2F0aW9uL2F1dGhv cml6YXRpb24gc3RhY2suDQoNCg0KVGhlIHRva2VuIGVuZHBvaW50IGhhcyB0aGUgYWNjZXNzIHRv a2VuIGFueXdheSwgc28gaXQgY2FuIGZldGNoIHRoZSBkYXRhIGZyb20gdGhlIG90aGVyIGVuZHBv aW50IGl0c2VsZiBpZiBpdCB3YW50ZWQgdG8uIElFLCB0aGVyZSBpcyBubyBzZXBhcmF0aW9uIG9m IGR1dGllcy4NCg0KV2hhdCBhcmUgdGhlIGFkdmFudGFnZXMgb2YgdGhlIFVzZXJJbmZvIGVuZHBv aW50IHRvIHRoZSBVc2VyIG9yIENsaWVudD8NCg0KVGhlIFVzZXJJbmZvIGVuZHBvaW50IHNlZW1z IHRvIGp1c3QgYWRkIG1vcmUgY29tcGxleGl0eSwgd2l0aCBubyBhYmlsaXR5IHRvIHN0YXJ0IGEg VXNlciBpbnRlcmFjdGlvbiBpZiBhZGRpdGlvbmFsIGNvbnNlbnQgaXMgbmVlZGVkLg0KDQoNCg0K U2VjdGlvbiAxMi44Og0KDQogICAgICAgICpXaHkgaGF2ZSBib3RoIGNsYWltcyBhbmQgYXV0aG9y aXphdGlvbnM/Kg0KDQoNCg0KICAgICAgICBUaGVyZSBhcmUgdXNlIGNhc2VzIGZvciBlYWNoIHRo YXQgYXJlIGluZGVwZW5kZW50Og0KDQogICAgICAgIGF1dGhlbnRpY2F0aW5nIGEgdXNlciB2cyBn cmFudGluZyBhY2Nlc3MgdG8gYSByZXNvdXJjZS4gIEENCg0KICAgICAgICByZXF1ZXN0IGZvciBh biBhdXRob3JpemF0aW9uIHJldHVybnMgYW4gYWNjZXNzIHRva2VuIG9yIGhhbmRsZSwNCg0KICAg ICAgICB3aGlsZSBhIHJlcXVlc3QgZm9yIGEgY2xhaW0gcmV0dXJucyB0aGUgY2xhaW0uDQoNCkkg ZG9u4oCZdCBhZ3JlZSB0aGF0IHRoZSB1c2UgY2FzZXMgYXJlIGRpc3RpbmN0LiBUaGUgb25seSBj bGFpbSB0aGF0IGlzIHN0cmljdGx5IG5lY2Vzc2FyeSBmb3IgYXV0aGVudGljYXRpb24gaXMgdGhl IHVzZXIgaWRlbnRpZmllci4gT3RoZXIgY2xhaW1zIGxpa2UgZW1haWwgYW5kIHBob25lX251bWJl ciBhcmUgb2Z0ZW4gdXNlZCB0byBhaWQgaW4gbG9jYWwgYWNjb3VudCBpZGVudGlmaWNhdGlvbiAo aS5lLiwgYWNjb3VudCBsaW5raW5nKSwgYnV0IGFyZSB1c2VmdWwgYW5kIGludGVyZXN0aW5nIGJl eW9uZCB0aGlzIHVzZSBjYXNlLg0KDQpTb21lIENsaWVudHMgdXNlIGVtYWlsIGFuZCBwaG9uZV9u dW1iZXIgYXMgdGhlIGlkZW50aWZpZXIgYW5kIGRvbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIGRp cmVjdGVkIGlkZW50aWZpZXIuIE5vdCB0aGUgYmVzdCBwcmFjdGljZSwgYnV0IGl0IGlzIHdoYXQg cGVvcGxlIGRvLg0KDQpPdGhlciBjbGFpbXMgc3VjaCBhcyBuYW1lLCBwcmVmZXJyZWRfdXNlcm5h bWUsIGFuZCBiaXJ0aGRhdGUgY291bGQgYmUgdXNlZCBpbiBhIHNpbWlsYXIgZmFzaGlvbiwgdGhv dWdoIHRoZXkgZnJlcXVlbnRseSBhcmVu4oCZdC4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3Igb3RoZXIg cmVzb3VyY2VzIG5vdCBjdXJyZW50bHkgZGVmaW5lZCBhcyBjbGFpbXMgKGUuZy4sIHRoZSBleHRl cm5hbElkIGVzdGFibGlzaGVkIHdoZW4gdGhlIHVzZXIgd2FzIGltcG9ydGVkIHRocm91Z2ggU0NJ TSkuLg0KDQpDbGFpbXMgYXJlIGp1c3QgcmVzb3VyY2VzIHRoYXQgT0lEQyBwcm92aWRlcyBhIG5h bWUgcmVnaXN0cnkgYW5kIHNvbWUgZXh0cmEgZmVhdHVyZXMgZm9yOg0KDQogICogICBPcHRpb25h bGx5IGdldCB0aGUgdmFsdWUgYnVuZGxlZCB3aXRoIHRoZSBhdXRoZW50aWNhdGlvbiByZXNwb25z ZSwgd2l0aG91dCBuZWVkaW5nIHRvIGNhbGwgYSBzZXBhcmF0ZSBlbmRwb2ludC4NCiBJbiBteSBv cGluaW9uLCBhbGwgdGhlIGRpZmZlcmVudCB3YXlzIHRvIGdldCBjbGFpbXMgaW4gT0lEQyBpcyBh IGJ1Zywgbm90IGEgZmVhdHVyZS4gV2l0aCB0aGUgb3B0aW9uYWxpdHkgYXQgdGhlIE9QLCAgYSBn ZW5lcmljIENsaWVudCBoYXMgdG8gc3VwcG9ydCBib3RoLg0KDQoNCg0KICAqDQogICogICBPcHRp b25hbGx5IGdldCB0aGUgdmFsdWUgaW4gYSBzaWduZWQgb3IgZW5jcnlwdGVkIGJsb2IuDQpUaGlz IG9wdGlvbmFsaXR5IGlzIHVzZWZ1bCB0byB0aGUgQ2xpZW50LCBhcyBpdCBjYW4gZGVjaWRlIHdo YXQgY2xhaW1zIHNob3VsZCBiZSBpbiB0aGUgc2lnbmVkIGJsb2Igd2hpY2ggbWF5IGJlIHVzZWQg ZGlmZmVyZW50bHkgdGhhbiBvdGhlciBjbGFpbXMuDQoNCg0KICAqDQogICogICBPcHRpb25hbGx5 IHByb3ZpZGUgc29tZSBzdHJ1Y3R1cmVkIG1ldGFkYXRhIGRlc2NyaWJpbmcgdGhlIHJlc291cmNl IGFuZC9vciByZXF1ZXN0ZWQgYXV0aG9yaXphdGlvbi4NCg0KDQoNCiAgKg0KDQpJdOKAmXMgdGVs bGluZyB0aGF0IGFsbCBvZiB0aGVzZSBhcmUgb3B0aW9uYWwuIElmIHdlIHRoaW5rIHRoZXNlIGFy ZSBmZWF0dXJlcyB3b3J0aCBicmluZ2luZyBmb3J3YXJkIGludG8gd2hhdGV2ZXIgcHJvdG9jb2wg d2UgcHJvZHVjZSB0aHJvdWdoIFR4QXV0aCwgd2Ugc2hvdWxkIGxvb2sgYXQgdGhlbSBpbmRlcGVu ZGVudGx5IG9mIHRoZSBjbGFpbS9yZXNvdXJjZSBkaWNob3RvbXkuDQoNCkkgYWdyZWUgdGhhdCB0 aGVzZSBmZWF0dXJlcyBhcmUgb3J0aG9nb25hbCB0byB0aGUgImFyZSBjbGFpbXMgYW5kIHJlc291 cmNlcyB0aGUgc2FtZSB0aGluZyIgZGViYXRlLg0KDQpJIHN0cm9uZ2x5IHRoaW5rIGl0IGlzIGEg ZGlzc2VydmljZSB0byBvdXIgYXVkaWVuY2UgdG8gY29uZmxhdGUgY2xhaW1zIGFuZCByZXNvdXJj ZXMuIENsYWltcyBhcmUgc3RhdGVtZW50cyBhYm91dCB0aGUgVXNlciBhbmQgcmVhZC1vbmx5Lg0K DQpSZXNvdXJjZXMgYXJlIGluZGVwZW5kZW50IG9mIHRoZSBHUy4gVGhlIENsaWVudCBtYXkgYmUg YWJsZSB0byBkbyBhbGwgb2YgQ1JVRCBvbiB0aGUgcmVzb3VyY2UuDQoNCldoaWxlIHRoZXJlIGlz IG92ZXJsYXAgd2l0aCB0aGUgVXNlckluZm8gZW5kcG9pbnQgdGhhdCBpdCBjb3VsZCBiZSBjb25z aWRlcmVkIGEgcmVzb3VyY2UsIEkgZG9uJ3QgdGhpbmsgdGhhdCBoZWxwcyB0aGUgYXVkaWVuY2Uu DQoNClRoZSBsYW5ndWFnZSBpbiBYQXV0aCBjYW4gZGVmaW5pdGVseSB1c2UgaW1wcm92ZW1lbnQg dG8gcHJvdmlkZSBtb3JlIGNsYXJpdHkgaGVyZS4NCg0KDQoNClNlY3Rpb24gMTIuMTI6DQoNCiAg ICAgICAgKldoeSBjb21wbGljYXRlIHRoZSBzZXF1ZW5jZSB3aXRoICJpbnRlcmFjdGlvbiIuImtl ZXAiPyoNCg0KSSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3XigJlyZSB0cnlpbmcgdG8gc3Vw cG9ydCBoZXJlLCBidXQgSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdG9vIGNvbXBsaWNhdGVkIHRv IGltcGxlbWVudC4gRnJvbSB0aGUgc2VxdWVuY2VzLCBpdCBsb29rcyBsaWtlIHRoZSBDbGllbnQg aXMgZXhwZWN0ZWQgdG8gaXNzdWUgYSBSZWFkIEdyYW50IHJlcXVlc3QsIGFuZCB0aGF0IGNvbm5l Y3Rpb24gd2lsbCBiZSBrZXB0IG9wZW4gd2hpbGUgdGhlIFVzZXIgaXMgcmVkaXJlY3RlZCB0byB0 aGUgR1MgYW5kIGdvZXMgdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gd29ya2Zsb3cgKGFuZCBw b3NzaWJseSBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHdvcmtmbG93KS4gT25seSB0aGVuIHdv dWxkIHRoZSBHUyByZXR1cm4gdGhlIFJlYWQgR3JhbnQgcmVzcG9uc2UuIElzIHRoaXMgY29ycmVj dD8NCg0KVG8gaW1wbGVtZW50IHRoaXMsIHRoZSBDbGllbnQgaGFzIHRvIGxhdW5jaCBhbiBhc3lu Y2hyb25vdXMgdGhyZWFkIHRvIGV4ZWN1dGUgdGhhdCByZXF1ZXN0IGFuZCBhd2FpdGluZyB0aGUg cmVzcG9uc2UuDQpQb3NzaWJsZSwgYnV0IHN1c2NlcHRpYmxlIHRvIGZhaWx1cmVzLiBXaGF0IGhh cHBlbnMgaWYgdGhhdCB0aHJlYWQgY3Jhc2hlcz8gT3IgZmFpbHMgdG8gc2VuZCB0aGUgVXBkYXRl IEdyYW50IHJlcXVlc3QgdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVwIHRvIGZhbHNlPyBXaGF0IGlz IHRoZSBHUyBkb2luZyBpbiB0aGUgbWVhbnRpbWU/IElzIGl0IGp1c3Qgc2hvd2luZyB0aGUgVXNl ciBhIOKAnGxvYWRpbmfigJ0gd2lkZ2V0IGFzIGl0IHdhaXRzIGZvciB0aGUgQ2xpZW50IHRvIHVw ZGF0ZSB0aGUgZ3JhbnQ/IEhvdyBsb25nIGRvZXMgaXQgd2FpdCBmb3I/IEZvciBtb2JpbGUgYXBw cywgdGhhdCBiYWNrZ3JvdW5kIHRocmVhZCBtYXkgZ2V0IGtpbGxlZCBvciBsb3NlIG5ldHdvcmsg Y29ubmVjdGl2aXR5IGFzIHNvb24gYXMgdGhlIHVzZXIgZ2V0cyBzd2l0Y2hlZCBvdmVyIHRvIHRo ZSBzeXN0ZW0gYnJvd3NlciB0byBsb2FkIHRoZSBHUyBzaWduIGluIHBhZ2UuIEZvciBhIHB1cmUt SlMgYXBwIHRoYXQgcmVkaXJlY3RzLCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBwb3NzaWJsZSBh dCBhbGwuICh1bmxlc3Mgd2ViIHdvcmtlcnMgY2FuIHN1cnZpdmUgcGFnZSB1bmxvYWRzPykNCg0K VGhpcyBpcyBhbiBpbnRlcmVzdGluZyB1c2UgY2FzZSBmb3IgdXMgdG8gdGhpbmsgYWJvdXQsIGJ1 dCBpdCBuZWVkcyBhIGxvdCBvZiB3b3JrIGFuZCBtYXkgbm90IGJlIHNvbWV0aGluZyB3ZSBzaG91 bGQgdHJ5IHRvIGJha2UgaW50byB0aGUgY29yZSBwcm90b2NvbCBpZiB3ZSBkb27igJl0IG5lZWQg dG8uDQoNCkl0IG1pZ2h0IG5vdCBoYXZlIGJlZW4gb2J2aW91cywgYnV0IHRoZSBDbGllbnQgY2Fs bGluZyB0aGUgR1MgdG8gZ2V0IGEgcmVzdWx0IHdoaWxlIHRoZSBpbnRlcmFjdGlvbiBpcyBoYXBw ZW5pbmcgaXMgd2hhdCBoYXBwZW5zIGluIGFueSBmbG93IHdpdGggYW4gaW50ZXJhY3Rpb24gc3Rh cnRlZCBieSB0aGUgQ2xpZW50LiBJdCBpcyBub3QgdW5pcXVlIHRvICJpbnRlcmFjdGlvbiIuImtl ZXAiIC0tIHdlIGFyZSBqdXN0IGFkZGluZyBhZGRpdGlvbmFsIGJhY2sgYW5kIGZvcnRocyBiZXR3 ZWVuIHRoZSBDbGllbnQgYW5kIEdTLg0KDQpBIFFSIENvZGUgZXhhbXBsZSBIQVMgdG8gd29yayB0 aGlzIHdheSwgYXMgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGZvciB0aGUgQ2xpZW50IHRvIGtub3cg dGhlIGludGVyYWN0aW9uIGhhcyBjb21wbGV0ZWQuDQoNCkdvb2dsZSBhbmQgTWljcm9zb2Z0IGJv dGggaGF2ZSBhIHNpbWlsYXIgdXNlciBleHBlcmllbmNlLiBUaGUgVXNlciB3YW50cyB0byBsb2cg aW50byBhbiBhcHAgLS0gdGhleSBhcmUgaW5zdHJ1Y3RlZCB0byBnbyB0byB0aGUgcmVzcGVjdGl2 ZSBtb2JpbGUgYXBwIHRvIGFwcHJvdmUgdGhlIGF1dGhlbnRpY2F0aW9uIC0tIGFuZCB0aGVuIHRo ZSBVc2VyIHJldHVybnMgdG8gdGhlIGFwcCB3aGljaCBjaGFuZ2VzIHRvIGEgbG9nZ2VkIGluIHN0 YXRlLiAgQW4gYXV0aGVudGljYXRpb24gb25seSBmbG93IHVzaW5nIFhBdXRoIHdvdWxkIHdvcmsg dGhlIHNhbWUgd2F5Lg0KDQoNCg0KU2VjdGlvbiAxMi4xNDoNCg0KICAgICAgICAqV2h5IHVzZSBV UklzIHRvIGluc3RlYWQgb2YgaGFuZGxlcyBmb3IgdGhlIEdyYW50IGFuZA0KDQogICAgICAgIEF1 dGhvcml6YXRpb24/Kg0KDQpJIGRpZG7igJl0IGxpa2UgdGhpcyB1bnRpbCBJIHJlYWxpemVkIHRo YXQgeW914oCZcmUgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBoYW5kbGVzL1VSSXMgYW5kIHRva2Vu cy4gTm93IHRoYXQgSeKAmXZlIHRob3VnaHQgYWJvdXQgaXQgbW9yZSwgSSBsaWtlIHRoaXMgZnJv bSB0aGUgc3RhbmRwb2ludCB0aGF0IGl0IHVuZGVyc2NvcmVzIHRoZSBpZGVhIG9mIEdyYW50cyBh bmQgQXV0aG9yaXphdGlvbnMgYmVpbmcgcGVyc2lzdGVudCBvYmplY3RzIHdpdGhpbiB0aGUgcHJv dG9jb2wuDQoNCjopDQoNCkFuZCBpdOKAmXMgcmVhbGx5IGp1c3QgbWFraW5nIHB1YmxpYyBzb21l dGhpbmcgdGhhdCB0aGUgR1MgaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgZG9pbmcgdW5kZXIgdGhl IGhvb2QgYW55d2F5LiBIb3dldmVyLCB3ZSBoYXZlIHRvIGJlIGNhcmVmdWwgdGhhdCB3ZSBkb27i gJl0IGFjY2lkZW50YWxseSBlbmNvdXJhZ2UgaW1wbGVtZW50ZXJzIHRvIHN0YXJ0IHNob3Zpbmcg dGhpbmdzIGludG8gdGhlc2UgVVJJcy4NCg0KVGhlIFVSSSBjb250ZW50IGlzIGludGVuZGVkIHRv IGJlIG9wYXF1ZS4gVGhlcmUgd291bGQgYmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQg a2VlcCBwZW9wbGUgZnJvbSBwdXR0aW5nIHZpc2libGUgc3R1ZmYgaW4gdGhlcmUgdGhleSBzaG91 bGRuJ3QuDQoNCkkgd291bGQgZXhwZWN0IGltcGxlbWVudGF0aW9ucyB0byB1c2UgYSByYW5kb20g dmFsdWUgd2l0aCBhIGNoZWNrc3VtLCBvciBhIEpXVC4NCg0KDQrigJMNCkFubmFiZWxsZSBCYWNr bWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50 aXR5Lw0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnR4 YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXks IEZlYnJ1YXJ5IDcsIDIwMjAgYXQgODowMCBQTQ0KVG86ICJ0eGF1dGhAaWV0Zi5vcmc8bWFpbHRv OnR4YXV0aEBpZXRmLm9yZz4iIDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBbVHhhdXRoXSBYQXV0aCAtMDINCg0KSSd2ZSBoZWF2aWx5IHJldmlzZWQg WEF1dGggYWdhaW4uDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14 YXV0aC1wcm90b2NvbC0wMjxodHRwczovL3Rvb2xzLi5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0 LXhhdXRoLXByb3RvY29sLTAyPg0KDQpBIG51bWJlciBvZiBuZXcgaWRlYXMgdG8gYm91bmNlIGFy b3VuZDoNCg0KSSBoYXZlIGluY2x1ZGVkIGEgYnVuY2ggb2Ygc2VxdWVuY2VzIHRvIHNob3cgZGlm ZmVyZW50IHVzZSBjYXNlcyBwb3NzaWJsZS4NCg0KUmF0aGVyIHRoYW4gYSB0cmFuc2FjdGlvbiwg SSB1c2UgYSBHcmFudCBhcyB0aGUgY2VudHJhbCBvYmplY3QuDQoNClRoZSBpbnRlcmZhY2UgaXMg dmVyeSBSRVNUZnVsLg0KDQpUaGUgQVMgaXMgbm93IGEgR3JhbnQgU2VydmVyIChHUykNCg0KVGhp cyBhbHNvIHNlZW1lZCBhcHByb3ByaWF0ZSBhdCBpdCBpcyBib3RoIGFuIE9BdXRoIEFTLCBhbmQg YW4gT0lEQyBPUC4NCg0KUmF0aGVyIHRoYW4gYSBoYW5kbGUsIHRoZSBHcmFudCBoYXMgYSBVUkku DQoNClRoZSBlbmRwb2ludCBVUkkgZm9yIHRoZSBHUyBpcyB0aGUgR1MgVVJJLCBhbmQgaXMgdGhl IEdTIGlkZW50aWZpZXIuDQoNCkFuIGFjY2VzcyB0b2tlbiwgcmVmcmVzaCB0b2tlbiBldGMuIGFy ZSBhbGwgYW4gQXV0aG9yaXphdGlvbi4gQW4gQXV0aG9yaXphdGlvbiBoYXMgYW4gQXV0aFogVVJJ Li4NCg0KVGhlIEdyYW50IFVSSSBhbmQgQXV0aFogVVJJIGFsbCBzdGFydCB3aXRoIHRoZSBHUyBV UkkuDQoNCkEgR3JhbnQgaXMgY3JlYXRlZCBieSBkb2luZyBhIFBPU1QgdG8gdGhlIEdTIFVSSSwg cmV0dXJuaW5nIGEgR3JhbnQgVVJJLg0KDQpNZXRhZGF0YSBmb3IgdGhlIEdTIGlzIGRvbmUgd2l0 aCBhbiBPUFRJT05TIHRvIHRoZSBHUyBVUkkuDQoNClRoZSBDbGllbnQgY2FuIGRvIEdFVCwgVVBE QVRFLCBhbmQgREVMRVRFIGFnYWluc3QgYSBHcmFudCBVUkkuDQoNCkFuIGFjY2VzcyB0b2tlbiBy ZWZyZXNoIGlzIGEgR0VUIG9uIHRoZSBBdXRoWiBVUkkuDQoNCkFkZGluZyBpbiBSZWNpcHJvY2Fs IE9BdXRoIGZ1bmN0aW9uYWxpdHkgd2FzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRoYW4gaW4gT0F1 dGggMi4wIC0tIGJ1dCBub3QgYXMgc3RyYWlnaHQgZm9yd2FyZCBhcyBJIHdvdWxkIGxpa2UgLS0g YnV0IG5vdCBjbGVhciBob3cgdG8gbWFrZSBpdCBiZXR0ZXIgYW5kIHN0YXJ0IGZyb20gdGhlIENs aWVudCBhbmQgR1MgaGF2aW5nIGNvbnRleHQgb2Ygb25lIGF1dGhvcml6YXRpb24gYmVmb3JlIHN3 YXBwaW5nIHJvbGVzLg0KDQpQZXIgbXkgbGFzdCBlbWFpbHMsIG5hbWluZyBpcyBoYXJkLCB0aGVy ZSBhcmUgbGlrZWx5IGxvdHMgb2YgbWlzdGFrZXMsIGFuZCBsb3RzIG9mIGFzcGVjdHMgdGhhdCBu ZWVkIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSG9wZWZ1bGx5IHRoZSBjb25jZXB0cyBjb21lIHRocm91 Z2ghDQoNCi9EaWNrDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFa R2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTdjZDE4 ZWE2LThjNTAtNDZkYy1iZTI1LWU5OWY2MTRkYWI4Ml3hkKcNCg0KVGhpcyBlLW1haWwsIGluY2x1 ZGluZyBhdHRhY2htZW50cywgaXMgaW50ZW5kZWQgZm9yIHRoZSBwZXJzb24ocykgb3IgY29tcGFu eSBuYW1lZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5IHByaXZp bGVnZWQgaW5mb3JtYXRpb24uDQpVbmF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZyBvciB1 c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBtYXkgYmUgdW5sYXdmdWwgYW5kIGlzIHByb2hpYml0ZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCkFsbCBpbmNvbWluZyBhbmQgb3V0Z29p bmcgZS1tYWlsIG1lc3NhZ2VzIGFyZSBzdG9yZWQgaW4gdGhlIFN3aXNzIFJlIEVsZWN0cm9uaWMg TWVzc2FnZSBSZXBvc2l0b3J5Lg0KSWYgeW91IGRvIG5vdCB3aXNoIHRoZSByZXRlbnRpb24gb2Yg cG90ZW50aWFsbHkgcHJpdmF0ZSBlLW1haWxzIGJ5IFN3aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZp c2UgeW91IG5vdCB0byB1c2UgdGhlIFN3aXNzIFJlIGUtbWFpbCBhY2NvdW50IGZvciBhbnkgcHJp dmF0ZSwgbm9uLWJ1c2luZXNzIHJlbGF0ZWQgY29tbXVuaWNhdGlvbnMuIC0tDQpUeGF1dGggbWFp bGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoKClRoaXMgZS1tYWlsLCBp bmNsdWRpbmcgYXR0YWNobWVudHMsIGlzIGludGVuZGVkIGZvciB0aGUgcGVyc29uKHMpIG9yIGNv bXBhbnkgbmFtZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBw cml2aWxlZ2VkIGluZm9ybWF0aW9uLgoKVW5hdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlpbmcg b3IgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gbWF5IGJlIHVubGF3ZnVsIGFuZCBpcyBwcm9oaWJp dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCkFsbCBpbmNvbWluZyBhbmQgb3V0 Z29pbmcgZS1tYWlsIG1lc3NhZ2VzIGFyZSBzdG9yZWQgaW4gdGhlIFN3aXNzIFJlIEVsZWN0cm9u aWMgTWVzc2FnZSBSZXBvc2l0b3J5LgpJZiB5b3UgZG8gbm90IHdpc2ggdGhlIHJldGVudGlvbiBv ZiBwb3RlbnRpYWxseSBwcml2YXRlIGUtbWFpbHMgYnkgU3dpc3MgUmUsIHdlIHN0cm9uZ2x5IGFk dmlzZSB5b3Ugbm90IHRvIHVzZSB0aGUgU3dpc3MgUmUgZS1tYWlsIGFjY291bnQgZm9yIGFueSBw cml2YXRlLCBub24tYnVzaW5lc3MgcmVsYXRlZCBjb21tdW5pY2F0aW9ucy4K --_000_93f0a28651cc447182ffb2d0ccd9107eCHRP5009corpgwpnetcom_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpERS1DSDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM3NDAxNDE2NTsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NjQ5ODgyOTM0O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoy ODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0NzM1MjEzMjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjExMzMyODg1NjA7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDoz Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1s ZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4 OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjQ3NDgzNTczMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTExNDY4NjcyODI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzDQoJe21zby1saXN0LWlkOjU1MzIwNDYxNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEx Nzk2MzU3MzI7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVs NA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC10 YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGw0DQoJe21zby1saXN0LWlkOjkwNzMwMDkyNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0 OTM5NDAwNzg7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy ODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1DQoJ e21zby1saXN0LWlkOjEzOTYwMTEzNzA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTI3NjM3 ODAwO30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNg0KCXttc28t bGlzdC1pZDoxNTYzNTYxMzg1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTQwMTUzNTQ4O30N CkBsaXN0IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw2 OmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw2OmxldmVsMw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNjpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDY6bGV2ZWw1DQoJe21zby1sZXZlbC10YWIt c3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDY6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw2 OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNw0KCXttc28t bGlzdC1pZDoyMDA0ODk2Mjg4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTEwNjA4ODU2MDt9 DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i REUtQ0giIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIHJlZmVyZW5jZSB0byBzZWN0aW9ucyAxMC4xLjMs IDEwLjIuMSwgMTAuMi4yLCAxMC4yLjMuIElmIHRoZSBjdXJyZW50IFJGQydzIGZvciBKT1NFIHJl cXVpcmUgdGhlIEpXVCBCQ1AgdG8gYmUgaW1wbGVtZW50ZWQgY29ycmVjdGx5IHBlcmhhcHMgaXQg bWF5IGJlIGJldHRlciB0byBzdGFydCBmcm9tIGEgbmV3IGltcGxlbWVudGF0aW9uDQogd2hpY2gg YWltcyB0byBzb2x2ZSB0aG9zZSBmcm9tIHRoZSBiZWdpbm5pbmc/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBEYXZp ZCAmbHQ7ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9i PiBEb25uZXJzdGFnLCAxMy4gRmVicnVhciAyMDIwIDExOjUyPGJyPg0KPGI+VG86PC9iPiBMZWUg TWNHb3Zlcm4gJmx0O0xlZV9NY0dvdmVybkBzd2lzc3JlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OzsgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7OyB0eGF1dGhAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUeGF1dGhdIFhBdXRoIC0wMjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHdoYXQgY29udGV4dD8gSSBkbyBu b3QgYmVsaWV2ZSB0aGlzIGRyYWZ0IG1hbmRhdGVzIHRva2VucyBpbiBhIHBhcnRpY3VsYXIgZm9y bWF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhdCBzYWlkIC0gbGlrZWx5IG5vdCBmb3IgYW55IHN0YW5kYXJkaXplZCBjb21tdW5pY2F0aW9u LCBzaW5jZSBQQVNFVE8gaXMgYSBub24gc3RhbmRhcmRpemVkIHZlbmRvciBmb3JtYXQuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LURX PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5PbiBGZWIgMTMsIDIwMjAsIGF0IDE6NTcgQU0sIExlZSBNY0dv dmVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkxlZV9NY0dvdmVybkBzd2lzc3JlLmNvbSI+TGVlX01j R292ZXJuQHN3aXNzcmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPu+7vyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklzIGFuIGFsdGVybmF0aXZlIHRvIEpPU0UgYmVp bmcgY29uc2lkZXJlZCBmb3IgZXhhbXBsZSBQQVNFVE8/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IERvbm5lcnN0 YWcsIDEzLiBGZWJydWFyIDIwMjAgMDM6MzQ8YnI+DQo8Yj5Ubzo8L2I+IFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+cmlj aGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 dHhhdXRoQGlldGYub3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbVHhhdXRoXSBYQXV0aCAtMDI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgQW5uYWJlbGxlLCBzb3JyeSBmb3Ig dGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgaW5zZXJ0ZWQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiAx MCwgMjAyMCBhdCAzOjM4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVm PSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFt YXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkludGVyZXN0aW5nIHdvcmsu IEkgYW0gZW5qb3lpbmcgdGhlIGZhY3QgdGhhdCB3ZSBoYXZlIHR3byBkaWZmZXJlbnQgdGFrZXMg b24gdGhlIHNhbWUgcHJvYmxlbS4gVGhlIGNvbXBhcmlzb25zIGFuZCBkaXNjdXNzaW9ucyB3aWxs IGxlYWQgdXMgdG8gYSBiZXR0ZXIgb3ZlcmFsbA0KIHNvbHV0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGF0IHdhcyBteSBnb2FsIG9mIHB1Ymxpc2hpbmcgdGhlIGRyYWZ0ITxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IZXJlIGFyZSBteSBjb21tZW50cyBvbiBYQXV0 aC0wMjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5TZWN0aW9uIDIuMTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7ICombmJzcDsgKlJlc291cmNlIE93bmVyKiAoUk8pIC0gb3du cyB0aGUgUlMsIGFuZCBoYXMgZGVsZWdhdGVkIFJTIGFjY2Vzczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFuYWdlbWVudCB0byB0aGUgR1Mu Jm5ic3A7IFRoZSBSTyBtYXkgYmUgdGhlIHNhbWUgZW50aXR5IGFzIHRoZSBVc2VyLCAuLi4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJltIHJhdGhlciBiYWZmbGVkIGJ5IHRoaXMgZGVmaW5p dGlvbiwgYW5kIHdvbmRlcmluZyBpZiBpdOKAmXMgYSBtaXN0YWtlIG9yIGlmIEnigJltIG1pc2lu dGVycHJldGluZyBpdC4gSXMgdGhpcyBhbiBpbnRlbnRpb25hbCBkZXBhcnR1cmUgZnJvbSBob3cg 4oCcUk/igJ0gaXMgdHlwaWNhbGx5DQogdXNlZCB3aXRoaW4gdGhlIE9BdXRoIDIuMCBzcGFjZT8g VXN1YWxseSB0aGUgdGVybSBSTyByZWZlcnMgdG8gdGhlIGVudGl0eSB0aGF0IG93bnMgdGhlIHNw ZWNpZmljIHJlc291cmNlcyB0aGUgY2xpZW50IGlzIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiBm b3IuIFRoZSBSTyBkb2VzIG5vdCB0eXBpY2FsbHkgb3duIHRoZSBSUyBpdHNlbGYuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1pc3Rha2UuIFRoYW5rcyBmb3IgY2F0Y2hpbmchPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gNS41LjI6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgVGhlIGludGVyYWN0aW9uIG9iamVjdCBjb250YWlucyB0aGUgdHlwZSBvZiBpbnRlcmFj dGlvbiB0aGUgQ2xpZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB3aWxsIHByb3ZpZGUgdGhl IFVzZXIuJm5ic3A7IE90aGVyIGF0dHJpYnV0ZXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZsdDtzbmlwJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZuYnNwOyAqdHlwZSogLSBjb250YWlucyBvbmUg b2YgdGhlIGZvbGxvd2luZyB2YWx1ZXM6ICZxdW90O3BvcHVwJnF1b3Q7LDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7JnF1b3Q7cmVkaXJlY3QmcXVvdDssIG9yICZxdW90O3FyY29kZSZxdW90Oy4uLi48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPjMgaXNzdWVzIHdpdGggdGhpczo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SG93IHdvdWxkIEkgZG8g YSB1c2VyIGNvZGUtYmFzZWQgaW50ZXJhY3Rpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L29s Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UbyBjbGFyaWZ5LCB0aGUgVXNlciBpcyBlbnRlcmluZyBhIGNvZGUgaW4gdGhlIENsaWVu dCBpbnRvIHRoZSBHUywgb3IgdGhlIFVzZXIgaXMgZW50ZXJpbmcgYSBjb2RlIGludG8gdGhlIENs aWVudD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWYgdGhlIHByaW9yLCB0aGUgUVIgY29kZSBhbHNvIGFsbG93cyBhIG1lc3NhZ2Uu IEknbSBlbnZpc2lvbmluZyBhIFVzZXIgd2l0aCBhIG1vYmlsZSBwaG9uZSBjYW4gc2NhbiB0aGUg UVIgY29kZSB3aGljaCBjb250YWlucyBhIFVSTCBhdCB0aGUgR1MsIGFuZCBpbmNsdWRlcyB0aGUg Y29kZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIG1lc3NhZ2Ugd291bGQgZGVzY3JpYmUgd2hhdCB0byBkbyBhbmQgaW5jbHVk ZSB0aGUgY29kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIx IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDYgbGV2ZWwxIGxm bzIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNiBsZXZlbDEgbGZvMiI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+Q2xpZW50cyBzdXBwb3J0IG11bHRpcGxlIGludGVyYWN0aW9uIG1vZGVzIGFuZCBt YXkgbm90IGFsd2F5cyBrbm93IHdoYXQgdGhlIEdTIHN1cHBvcnRzIChhbmQgdmljZS12ZXJzYSku IEZvciBhIG11bHRpLXRlbmFudCBHUywgaXQgbWF5IHZhcnkgYnkgdGVuYW50IGNvbmZpZ3VyYXRp b24uIENsaWVudHMgc2hvdWxkIGJlIGFibGUgdG8gc2F5IHdoYXQgdGhleSBjYW4gZG8sIGFuZCB0 aGUgR1Mgc2hvdWxkIGJlIGFibGUNCiB0byB0ZWxsIHRoZW0gd2hpY2ggb25lIHRvIHVzZS4gSXTi gJlzIGEgdmVyeSBzaW1wbGUgYnV0IHBvd2VyZnVsIGlubGluZSBuZWdvdGlhdGlvbi48L3NwYW4+ PG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyB3aGF0IGlzIGluIFR4QXV0aC4gV291 bGQgeW91IGVsYWJvcmF0ZSBvbiBob3cgdGhlIEdTIG1pZ2h0IGJlIGNvbnN0cmFpbmVkPyBXaHkg d291bGQgdGhlIEdTIG5vdCBiZSBhYmxlIHRvIGRvIGFsbD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCB0aGluayBhbGwgY29uc3Ry YWludHMgd291bGQgYmUgYXQgdGhlIENsaWVudC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSBkb27i gJl0IHNlZSB0aGUgdmFsdWUgb2YgdGhlIOKAnHBvcHVw4oCdIGludGVyYWN0aW9uIG1vZGUuIENs aWVudHMgY2FuIHVzZSDigJxyZWRpcmVjdOKAnSBtb2RlIHdpdGhpbiBwb3B1cHMuIEhvd2V2ZXIs IHNwZWFraW5nIGFzIHNvbWVvbmUgd2hvIGhhcyBkb25lIHRoYXQsIEkgcmVhbGx5IGRvbuKAmXQg cmVjb21tZW5kIGl0LiBQb3B1cHMgYXJlIGluY3JlYXNpbmdseSB1bnN1cHBvcnRlZCwgYW5kIHBy b25lIHRvIHdlaXJkIGJlaGF2aW9yYWwNCiBpc3N1ZXMuIEluLWFwcCBicm93c2VycyBpbiBGYWNl Ym9vaywgVHdpdHRlciwgZXRjLiB0ZW5kIHRvIGhhdmUgcG9wdXBzIGRpc2FibGVkLiBUaGUgbGFz dCB2ZXJzaW9ucyBvZiBJRSBNb2JpbGUgZGlkbuKAmXQgc3VwcG9ydCB0aGVtIGF0IGFsbCAodGhl IHBvcHBlZCB1cCBwYWdlIGJhc2ljYWxseSBqdXN0IGxvYWRlZCBpbnRvIHRoZSBjdXJyZW50IHdp bmRvdykuIGluJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBvcHVwcyBh cmUgcmVhbGx5IHVzZWZ1bCBpbiBzaW5nbGUtcGFnZSBhcHBzIGFzIHlvdSB3YW50IHRvIGtlZXAg dGhlIGNvbnRleHQgYW5kIG5vdCByZWxvYWQgdGhlIHBhZ2UuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlIHRoYXQgcG9wdXBzIGRvbid0 IG1ha2Ugc2Vuc2UgaW4gbW9iaWxlLiBBIGZ1bGwgcmVkaXJlY3QgZG9lcyBvZiBjb3Vyc2UuIEEg c2luZ2xlLXBhZ2UgYXBwIG9uIG1vYmlsZSB3b3VsZCBvcGVuIGEgbmV3IHRhYiB3aGljaCB3b3Vs ZCBiZSBhIHNlcGFyYXRlIGNvbnRleHQgcmF0aGVyIHRoYW4gYSByZWRpcmVjdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gMTIuNjo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtbRWRpdG9y OiBpcyB0aGVyZSBzb21lIG90aGVyIHJlYXNvbiB0byBoYXZlIHRoZSBVc2VySW5mbzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5kcG9pbnQ/ XTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBtYXkgd2FudCB0byBob3N0IG15IFVzZXJJbmZv IGVuZHBvaW50IG9uIGEgc2VwYXJhdGUgbWljcm9zZXJ2aWNlIGZyb20gbXkgdG9rZW4gZW5kcG9p bnQgKGluIE9BdXRoIDIuMC9PSURDIHRlcm1zKS4gVGhlIGZvcm1lciBtaWdodCBiZSBwYXJ0IG9m IG15IHVzZXIgcHJvZmlsZS9kaXJlY3RvcnkNCiBzdGFjaywgd2hpbGUgdGhlIGxhdHRlciBpcyBw YXJ0IG9mIHRoZSBoaWdobHkgcHJpdmlsZWdlZCBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9u IHN0YWNrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0b2tlbiBlbmRwb2ludCBo YXMgdGhlIGFjY2VzcyB0b2tlbiBhbnl3YXksIHNvIGl0IGNhbiBmZXRjaCB0aGUgZGF0YSBmcm9t IHRoZSBvdGhlciBlbmRwb2ludCBpdHNlbGYgaWYgaXQgd2FudGVkIHRvLiBJRSwgdGhlcmUgaXMg bm8gc2VwYXJhdGlvbiBvZiBkdXRpZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBVc2Vy SW5mbyBlbmRwb2ludCB0byB0aGUgVXNlciBvciBDbGllbnQ/Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBVc2VySW5mbyBlbmRw b2ludCBzZWVtcyB0byBqdXN0IGFkZCBtb3JlIGNvbXBsZXhpdHksIHdpdGggbm8gYWJpbGl0eSB0 byBzdGFydCBhIFVzZXIgaW50ZXJhY3Rpb24gaWYgYWRkaXRpb25hbCBjb25zZW50IGlzIG5lZWRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5TZWN0aW9uIDEyLjg6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKldoeSBoYXZl IGJvdGggY2xhaW1zIGFuZCBhdXRob3JpemF0aW9ucz8qPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUg YXJlIHVzZSBjYXNlcyBmb3IgZWFjaCB0aGF0IGFyZSBpbmRlcGVuZGVudDo8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0aW5n IGEgdXNlciB2cyBncmFudGluZyBhY2Nlc3MgdG8gYSByZXNvdXJjZS4mbmJzcDsgQTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdCBm b3IgYW4gYXV0aG9yaXphdGlvbiByZXR1cm5zIGFuIGFjY2VzcyB0b2tlbiBvciBoYW5kbGUsPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGls ZSBhIHJlcXVlc3QgZm9yIGEgY2xhaW0gcmV0dXJucyB0aGUgY2xhaW0uPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5JIGRvbuKAmXQgYWdyZWUgdGhhdCB0aGUgdXNlIGNhc2VzIGFyZSBkaXN0aW5j dC4gVGhlIG9ubHkgY2xhaW0gdGhhdCBpcyBzdHJpY3RseSBuZWNlc3NhcnkgZm9yIGF1dGhlbnRp Y2F0aW9uIGlzIHRoZSB1c2VyIGlkZW50aWZpZXIuIE90aGVyIGNsYWltcyBsaWtlIGVtYWlsIGFu ZA0KIHBob25lX251bWJlciBhcmUgb2Z0ZW4gdXNlZCB0byBhaWQgaW4gbG9jYWwgYWNjb3VudCBp ZGVudGlmaWNhdGlvbiAoaS5lLiwgYWNjb3VudCBsaW5raW5nKSwgYnV0IGFyZSB1c2VmdWwgYW5k IGludGVyZXN0aW5nIGJleW9uZCB0aGlzIHVzZSBjYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Tb21lIENsaWVudHMgdXNlIGVtYWlsIGFuZCBwaG9uZV9udW1iZXIgYXMgdGhlIGlkZW50 aWZpZXIgYW5kIGRvbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIGRpcmVjdGVkIGlkZW50aWZpZXIu IE5vdCB0aGUgYmVzdCBwcmFjdGljZSwgYnV0IGl0IGlzIHdoYXQgcGVvcGxlIGRvLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5PdGhlciBjbGFpbXMgc3VjaCBhcyBuYW1lLCBwcmVmZXJyZWRfdXNlcm5hbWUs IGFuZCBiaXJ0aGRhdGUgY291bGQgYmUgdXNlZCBpbiBhIHNpbWlsYXIgZmFzaGlvbiwgdGhvdWdo IHRoZXkgZnJlcXVlbnRseSBhcmVu4oCZdC4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3Igb3RoZXIgcmVz b3VyY2VzDQogbm90IGN1cnJlbnRseSBkZWZpbmVkIGFzIGNsYWltcyAoZS5nLiwgdGhlIGV4dGVy bmFsSWQgZXN0YWJsaXNoZWQgd2hlbiB0aGUgdXNlciB3YXMgaW1wb3J0ZWQgdGhyb3VnaCBTQ0lN KS4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2xhaW1zIGFyZSBqdXN0IHJlc291cmNlcyB0aGF0 IE9JREMgcHJvdmlkZXMgYSBuYW1lIHJlZ2lzdHJ5IGFuZCBzb21lIGV4dHJhIGZlYXR1cmVzIGZv cjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm81Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5P cHRpb25hbGx5IGdldCB0aGUgdmFsdWUgYnVuZGxlZCB3aXRoIHRoZSBhdXRoZW50aWNhdGlvbiBy ZXNwb25zZSwgd2l0aG91dCBuZWVkaW5nIHRvIGNhbGwgYSBzZXBhcmF0ZSBlbmRwb2ludC48L3Nw YW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0luIG15IG9waW5pb24sIGFsbCB0aGUg ZGlmZmVyZW50IHdheXMgdG8gZ2V0IGNsYWltcyBpbiBPSURDIGlzIGEgYnVnLCBub3QgYSBmZWF0 dXJlLiBXaXRoIHRoZSBvcHRpb25hbGl0eSBhdCB0aGUgT1AsJm5ic3A7IGEgZ2VuZXJpYyBDbGll bnQgaGFzIHRvIHN1cHBvcnQgYm90aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw3IGxl dmVsMSBsZm82Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzYiPg0KPHNw YW4gbGFuZz0iRU4tVVMiPk9wdGlvbmFsbHkgZ2V0IHRoZSB2YWx1ZSBpbiBhIHNpZ25lZCBvciBl bmNyeXB0ZWQgYmxvYi48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgb3B0aW9u YWxpdHkgaXMgdXNlZnVsIHRvIHRoZSBDbGllbnQsIGFzIGl0IGNhbiBkZWNpZGUgd2hhdCBjbGFp bXMgc2hvdWxkIGJlIGluIHRoZSBzaWduZWQgYmxvYiB3aGljaCBtYXkgYmUgdXNlZCBkaWZmZXJl bnRseSB0aGFuIG90aGVyIGNsYWltcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNSBsZXZl bDEgbGZvNyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVsMSBsZm83Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIj5PcHRpb25hbGx5IHByb3ZpZGUgc29tZSBzdHJ1Y3R1cmVkIG1ldGFkYXRh IGRlc2NyaWJpbmcgdGhlIHJlc291cmNlIGFuZC9vciByZXF1ZXN0ZWQgYXV0aG9yaXphdGlvbi48 L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0Omw0IGxldmVsMSBsZm84Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JdOKAmXMgdGVsbGluZyB0aGF0IGFsbCBvZiB0aGVzZSBh cmUgb3B0aW9uYWwuIElmIHdlIHRoaW5rIHRoZXNlIGFyZSBmZWF0dXJlcyB3b3J0aCBicmluZ2lu ZyBmb3J3YXJkIGludG8gd2hhdGV2ZXIgcHJvdG9jb2wgd2UgcHJvZHVjZSB0aHJvdWdoIFR4QXV0 aCwgd2Ugc2hvdWxkDQogbG9vayBhdCB0aGVtIGluZGVwZW5kZW50bHkgb2YgdGhlIGNsYWltL3Jl c291cmNlIGRpY2hvdG9teS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0 IHRoZXNlIGZlYXR1cmVzIGFyZSBvcnRob2dvbmFsIHRvIHRoZSAmcXVvdDthcmUgY2xhaW1zIGFu ZCByZXNvdXJjZXMgdGhlIHNhbWUgdGhpbmcmcXVvdDsgZGViYXRlLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0cm9uZ2x5IHRo aW5rIGl0IGlzIGEgZGlzc2VydmljZSB0byBvdXIgYXVkaWVuY2UgdG8gY29uZmxhdGUgY2xhaW1z IGFuZCByZXNvdXJjZXMuIENsYWltcyBhcmUgc3RhdGVtZW50cyBhYm91dCB0aGUgVXNlciBhbmQg cmVhZC1vbmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZXNvdXJjZXMgYXJlIGluZGVwZW5kZW50IG9mIHRoZSBHUy4gVGhlIENsaWVudCBt YXkgYmUgYWJsZSB0byBkbyBhbGwgb2YgQ1JVRCBvbiB0aGUgcmVzb3VyY2UuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRo ZXJlIGlzIG92ZXJsYXAgd2l0aCB0aGUgVXNlckluZm8gZW5kcG9pbnQgdGhhdCBpdCBjb3VsZCBi ZSBjb25zaWRlcmVkIGEgcmVzb3VyY2UsIEkgZG9uJ3QgdGhpbmsgdGhhdCBoZWxwcyB0aGUgYXVk aWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBsYW5ndWFnZSBpbiBYQXV0aCBjYW4gZGVmaW5pdGVseSB1c2UgaW1wcm92ZW1lbnQg dG8gcHJvdmlkZSBtb3JlIGNsYXJpdHkgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5TZWN0aW9uIDEyLjEyOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpXaHkgY29tcGxpY2F0ZSB0aGUgc2VxdWVuY2Ugd2l0aCAmcXVv dDtpbnRlcmFjdGlvbiZxdW90Oy4mcXVvdDtrZWVwJnF1b3Q7Pyo8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkkgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2UgeW914oCZcmUgdHJ5aW5nIHRvIHN1cHBv cnQgaGVyZSwgYnV0IEkgdGhpbmsgdGhlIHByb3Bvc2FsIGlzIHRvbyBjb21wbGljYXRlZCB0byBp bXBsZW1lbnQuIEZyb20gdGhlIHNlcXVlbmNlcywgaXQgbG9va3MgbGlrZSB0aGUgQ2xpZW50DQog aXMgZXhwZWN0ZWQgdG8gaXNzdWUgYSBSZWFkIEdyYW50IHJlcXVlc3QsIGFuZCB0aGF0IGNvbm5l Y3Rpb24gd2lsbCBiZSBrZXB0IG9wZW4gd2hpbGUgdGhlIFVzZXIgaXMgcmVkaXJlY3RlZCB0byB0 aGUgR1MgYW5kIGdvZXMgdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gd29ya2Zsb3cgKGFuZCBw b3NzaWJseSBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHdvcmtmbG93KS4gT25seSB0aGVuIHdv dWxkIHRoZSBHUyByZXR1cm4gdGhlIFJlYWQgR3JhbnQNCiByZXNwb25zZS4gSXMgdGhpcyBjb3Jy ZWN0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvIGltcGxlbWVudCB0aGlzLCB0aGUgQ2xpZW50 IGhhcyB0byBsYXVuY2ggYW4gYXN5bmNocm9ub3VzIHRocmVhZCB0byBleGVjdXRlIHRoYXQgcmVx dWVzdCBhbmQgYXdhaXRpbmcgdGhlIHJlc3BvbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+UG9zc2libGUsIGJ1dCBzdXNjZXB0aWJsZSB0byBmYWlsdXJl cy4gV2hhdCBoYXBwZW5zIGlmIHRoYXQgdGhyZWFkIGNyYXNoZXM/IE9yIGZhaWxzIHRvIHNlbmQg dGhlIFVwZGF0ZSBHcmFudCByZXF1ZXN0IHRvIGZsaXAgaW50ZXJhY3Rpb24ua2VlcCB0byBmYWxz ZT8gV2hhdA0KIGlzIHRoZSBHUyBkb2luZyBpbiB0aGUgbWVhbnRpbWU/IElzIGl0IGp1c3Qgc2hv d2luZyB0aGUgVXNlciBhIOKAnGxvYWRpbmfigJ0gd2lkZ2V0IGFzIGl0IHdhaXRzIGZvciB0aGUg Q2xpZW50IHRvIHVwZGF0ZSB0aGUgZ3JhbnQ/IEhvdyBsb25nIGRvZXMgaXQgd2FpdCBmb3I/IEZv ciBtb2JpbGUgYXBwcywgdGhhdCBiYWNrZ3JvdW5kIHRocmVhZCBtYXkgZ2V0IGtpbGxlZCBvciBs b3NlIG5ldHdvcmsgY29ubmVjdGl2aXR5IGFzIHNvb24gYXMgdGhlIHVzZXINCiBnZXRzIHN3aXRj aGVkIG92ZXIgdG8gdGhlIHN5c3RlbSBicm93c2VyIHRvIGxvYWQgdGhlIEdTIHNpZ24gaW4gcGFn ZS4gRm9yIGEgcHVyZS1KUyBhcHAgdGhhdCByZWRpcmVjdHMsIEkgZG9u4oCZdCB0aGluayB0aGlz IGlzIHBvc3NpYmxlIGF0IGFsbC4gKHVubGVzcyB3ZWIgd29ya2VycyBjYW4gc3Vydml2ZSBwYWdl IHVubG9hZHM/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgaXMgYW4gaW50ZXJlc3Rpbmcg dXNlIGNhc2UgZm9yIHVzIHRvIHRoaW5rIGFib3V0LCBidXQgaXQgbmVlZHMgYSBsb3Qgb2Ygd29y ayBhbmQgbWF5IG5vdCBiZSBzb21ldGhpbmcgd2Ugc2hvdWxkIHRyeSB0byBiYWtlIGludG8gdGhl IGNvcmUgcHJvdG9jb2wgaWYgd2UNCiBkb27igJl0IG5lZWQgdG8uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0IG1pZ2h0IG5vdCBoYXZlIGJlZW4gb2J2aW91cywgYnV0IHRoZSBDbGllbnQg Y2FsbGluZyB0aGUgR1MgdG8gZ2V0IGEgcmVzdWx0IHdoaWxlIHRoZSBpbnRlcmFjdGlvbiBpcyBo YXBwZW5pbmcgaXMgd2hhdCBoYXBwZW5zIGluIGFueSBmbG93IHdpdGggYW4gaW50ZXJhY3Rpb24g c3RhcnRlZCBieSB0aGUgQ2xpZW50LiBJdCBpcyBub3QgdW5pcXVlIHRvICZxdW90O2ludGVyYWN0 aW9uJnF1b3Q7LiZxdW90O2tlZXAmcXVvdDsgLS0gd2UgYXJlIGp1c3QNCiBhZGRpbmcgYWRkaXRp b25hbCBiYWNrIGFuZCBmb3J0aHMgYmV0d2VlbiB0aGUgQ2xpZW50IGFuZCBHUy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBRUiBDb2RlIGV4 YW1wbGUgSEFTIHRvIHdvcmsgdGhpcyB3YXksIGFzIHRoZXJlIGlzIG5vIG90aGVyIHdheSBmb3Ig dGhlIENsaWVudCB0byBrbm93IHRoZSBpbnRlcmFjdGlvbiBoYXMgY29tcGxldGVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29nbGUgYW5k IE1pY3Jvc29mdCBib3RoIGhhdmUgYSBzaW1pbGFyIHVzZXIgZXhwZXJpZW5jZS4gVGhlIFVzZXIg d2FudHMgdG8gbG9nIGludG8gYW4gYXBwIC0tIHRoZXkgYXJlIGluc3RydWN0ZWQgdG8gZ28gdG8g dGhlIHJlc3BlY3RpdmUgbW9iaWxlIGFwcCB0byBhcHByb3ZlIHRoZSBhdXRoZW50aWNhdGlvbiAt LSBhbmQgdGhlbiB0aGUgVXNlciByZXR1cm5zIHRvIHRoZSBhcHAgd2hpY2ggY2hhbmdlcyB0bw0K IGEgbG9nZ2VkIGluIHN0YXRlLiZuYnNwOyBBbiBhdXRoZW50aWNhdGlvbiBvbmx5IGZsb3cgdXNp bmcgWEF1dGggd291bGQgd29yayB0aGUgc2FtZSB3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+U2VjdGlvbiAxMi4xNDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqV2h5IHVzZSBVUklzIHRvIGluc3RlYWQgb2YgaGFuZGxl cyBmb3IgdGhlIEdyYW50IGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbj8qPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGRpZG7igJl0IGxpa2UgdGhpcyB1bnRpbCBJIHJlYWxpemVkIHRoYXQgeW914oCZcmUgZGlz dGluZ3Vpc2hpbmcgYmV0d2VlbiBoYW5kbGVzL1VSSXMgYW5kIHRva2Vucy4gTm93IHRoYXQgSeKA mXZlIHRob3VnaHQgYWJvdXQgaXQgbW9yZSwgSSBsaWtlIHRoaXMgZnJvbSB0aGUgc3RhbmRwb2lu dA0KIHRoYXQgaXQgdW5kZXJzY29yZXMgdGhlIGlkZWEgb2YgR3JhbnRzIGFuZCBBdXRob3JpemF0 aW9ucyBiZWluZyBwZXJzaXN0ZW50IG9iamVjdHMgd2l0aGluIHRoZSBwcm90b2NvbC4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj46KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmQgaXTigJlzIHJl YWxseSBqdXN0IG1ha2luZyBwdWJsaWMgc29tZXRoaW5nIHRoYXQgdGhlIEdTIGlzIHByb2JhYmx5 IGdvaW5nIHRvIGJlIGRvaW5nIHVuZGVyIHRoZSBob29kIGFueXdheS4gSG93ZXZlciwgd2UgaGF2 ZSB0byBiZSBjYXJlZnVsIHRoYXQgd2UgZG9u4oCZdCBhY2NpZGVudGFsbHkNCiBlbmNvdXJhZ2Ug aW1wbGVtZW50ZXJzIHRvIHN0YXJ0IHNob3ZpbmcgdGhpbmdzIGludG8gdGhlc2UgVVJJcy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFVSSSBjb250ZW50IGlzIGludGVuZGVkIHRvIGJl IG9wYXF1ZS4gVGhlcmUgd291bGQgYmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQga2Vl cCBwZW9wbGUgZnJvbSBwdXR0aW5nIHZpc2libGUgc3R1ZmYgaW4gdGhlcmUgdGhleSBzaG91bGRu J3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgd291bGQgZXhwZWN0IGltcGxlbWVudGF0aW9ucyB0byB1c2UgYSByYW5kb20gdmFsdWUgd2l0 aCBhIGNoZWNrc3VtLCBvciBhIEpXVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+QW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48YSBocmVmPSJodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5LyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24uY29t L2lkZW50aXR5Lzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PlR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5GcmlkYXksIEZlYnJ1YXJ5IDcsIDIwMjAgYXQgODowMCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0 aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5bVHhhdXRoXSBYQXV0aCAtMDI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+SSd2ZSBoZWF2aWx5IHJldmlzZWQgWEF1dGggYWdhaW4uIDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLi5pZXRmLm9yZy9odG1s L2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAyPC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5BIG51bWJlciBvZiBuZXcgaWRlYXMgdG8gYm91bmNl IGFyb3VuZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgaW5j bHVkZWQgYSBidW5jaCBvZiBzZXF1ZW5jZXMgdG8gc2hvdyBkaWZmZXJlbnQgdXNlIGNhc2VzIHBv c3NpYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlJhdGhlciB0aGFu IGEgdHJhbnNhY3Rpb24sIEkgdXNlIGEgR3JhbnQgYXMgdGhlIGNlbnRyYWwgb2JqZWN0Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBpbnRlcmZhY2UgaXMgdmVyeSBS RVNUZnVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBBUyBpcyBu b3cgYSBHcmFudCBTZXJ2ZXIgKEdTKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPlRoaXMgYWxzbyBzZWVtZWQgYXBwcm9wcmlhdGUgYXQgaXQgaXMgYm90aCBhbiBPQXV0aCBB UywgYW5kIGFuIE9JREMgT1AuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ UmF0aGVyIHRoYW4gYSBoYW5kbGUsIHRoZSBHcmFudCBoYXMgYSBVUkkuJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGVuZHBvaW50IFVSSSBmb3IgdGhlIEdT IGlzIHRoZSBHUyBVUkksIGFuZCBpcyB0aGUgR1MgaWRlbnRpZmllci48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5BbiBhY2Nlc3MgdG9rZW4sIHJlZnJlc2ggdG9rZW4gZXRj LiBhcmUgYWxsIGFuIEF1dGhvcml6YXRpb24uIEFuIEF1dGhvcml6YXRpb24gaGFzIGFuIEF1dGha IFVSSS4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlIEdyYW50IFVS SSBhbmQgQXV0aFogVVJJIGFsbCBzdGFydCB3aXRoIHRoZSBHUyBVUkkuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QSBHcmFudCBpcyBjcmVhdGVkIGJ5IGRvaW5nIGEgUE9T VCB0byB0aGUgR1MgVVJJLCByZXR1cm5pbmcgYSBHcmFudCBVUkkuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+TWV0YWRhdGEgZm9yIHRoZSBHUyBpcyBkb25lIHdpdGggYW4g T1BUSU9OUyB0byB0aGUgR1MgVVJJLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPlRoZSBDbGllbnQgY2FuIGRvIEdFVCwgVVBEQVRFLCBhbmQgREVMRVRFIGFnYWluc3QgYSBH cmFudCBVUkkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QW4gYWNjZXNz IHRva2VuIHJlZnJlc2ggaXMgYSBHRVQgb24gdGhlIEF1dGhaIFVSSS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkFkZGluZyBpbiBSZWNpcHJvY2FsIE9BdXRo IGZ1bmN0aW9uYWxpdHkgd2FzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRoYW4gaW4gT0F1dGggMi4w IC0tIGJ1dCBub3QgYXMgc3RyYWlnaHQgZm9yd2FyZCBhcyBJIHdvdWxkIGxpa2UgLS0gYnV0IG5v dCBjbGVhciBob3cgdG8gbWFrZSBpdCBiZXR0ZXIgYW5kIHN0YXJ0IGZyb20gdGhlIENsaWVudCBh bmQgR1MgaGF2aW5nIGNvbnRleHQgb2Ygb25lIGF1dGhvcml6YXRpb24NCiBiZWZvcmUgc3dhcHBp bmcgcm9sZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+UGVyIG15IGxh c3QgZW1haWxzLCBuYW1pbmcgaXMgaGFyZCwgdGhlcmUgYXJlIGxpa2VseSBsb3RzIG9mIG1pc3Rh a2VzLCBhbmQgbG90cyBvZiBhc3BlY3RzIHRoYXQgbmVlZCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEhv cGVmdWxseSB0aGUgY29uY2VwdHMgY29tZSB0aHJvdWdoITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tVVMiPi9EaWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBf aTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xq YXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9 N2NkMThlYTYtOGM1MC00NmRjLWJlMjUtZTk5ZjYxNGRhYjgyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgZS1tYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIGlzIGludGVuZGVkIGZvciB0aGUg cGVyc29uKHMpIG9yIGNvbXBhbnkgbmFtZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQvb3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWlu ZyBvciB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBtYXkgYmUgdW5sYXdmdWwgYW5kIGlzIHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpBbGwgaW5jb21pbmcg YW5kIG91dGdvaW5nIGUtbWFpbCBtZXNzYWdlcyBhcmUgc3RvcmVkIGluIHRoZSBTd2lzcyBSZSBF bGVjdHJvbmljIE1lc3NhZ2UgUmVwb3NpdG9yeS48YnI+DQpJZiB5b3UgZG8gbm90IHdpc2ggdGhl IHJldGVudGlvbiBvZiBwb3RlbnRpYWxseSBwcml2YXRlIGUtbWFpbHMgYnkgU3dpc3MgUmUsIHdl IHN0cm9uZ2x5IGFkdmlzZSB5b3Ugbm90IHRvIHVzZSB0aGUgU3dpc3MgUmUgZS1tYWlsIGFjY291 bnQgZm9yIGFueSBwcml2YXRlLCBub24tYnVzaW5lc3MgcmVsYXRlZCBjb21tdW5pY2F0aW9ucy4g LS0NCjxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRo QGlldGYub3JnIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+PGRpdj5UaGlzIGUtbWFpbCwgaW5j bHVkaW5nIGF0dGFjaG1lbnRzLCBpcyBpbnRlbmRlZCBmb3IgdGhlIHBlcnNvbihzKSBvciBjb21w YW55IG5hbWVkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbi48L2Rpdj5VbmF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWlu ZyBvciB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBtYXkgYmUgdW5sYXdmdWwgYW5kIGlzIHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+QWxsIGluY29taW5nIGFu ZCBvdXRnb2luZyBlLW1haWwgbWVzc2FnZXMgYXJlIHN0b3JlZCBpbiB0aGUgU3dpc3MgUmUgRWxl Y3Ryb25pYyBNZXNzYWdlIFJlcG9zaXRvcnkuPGJyPklmIHlvdSBkbyBub3Qgd2lzaCB0aGUgcmV0 ZW50aW9uIG9mIHBvdGVudGlhbGx5IHByaXZhdGUgZS1tYWlscyBieSBTd2lzcyBSZSwgd2Ugc3Ry b25nbHkgYWR2aXNlIHlvdSBub3QgdG8gdXNlIHRoZSBTd2lzcyBSZSBlLW1haWwgYWNjb3VudCBm b3IgYW55IHByaXZhdGUsIG5vbi1idXNpbmVzcyByZWxhdGVkIGNvbW11bmljYXRpb25zLjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_93f0a28651cc447182ffb2d0ccd9107eCHRP5009corpgwpnetcom_-- From nobody Thu Feb 13 07:00:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532612011D for ; Thu, 13 Feb 2020 07:00:55 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLpwlTtjPs9O for ; Thu, 13 Feb 2020 07:00:51 -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 E4DD4120013 for ; Thu, 13 Feb 2020 07:00:50 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id 9so4478552lfq.10 for ; Thu, 13 Feb 2020 07:00:50 -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=u2ngigRqibU6AFlbbNkcd8IghmsmkZRrOrOxtqa0YfA=; b=T7WSrdYyCPAbTCQpI2hXr2dQ0EdBZJsaBa4KdZB33hTPx0ni+uegI3Q4hBWgyRYkg6 2PonOa5u3zRdu01pdPOg3FGlhYowTr0oT0EUQ3ssb9EXKIzUaKsFRFUGCPuddpMJ/QEE xRpELnC6c3Kl7kCvZZy6b2+IOQZcsE2QRadoZPOIkwJ0xm/KEPcleU/uicv80mOez/OM buiOz7t6knp6oGmSvcN9tjmlWZs9fVSpv927qj9/jkf1/MLdO+aosQuKPGMjYDmy+VY4 YX8TQ62mXrRjTJhUuov39d7F9uziAquD/Gjk9DhO6RUvkHc/3FDQycYzRnrSHDxGn4R/ 3MNA== 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=u2ngigRqibU6AFlbbNkcd8IghmsmkZRrOrOxtqa0YfA=; b=l5oS3bvwjr+5QIYHrmLdYJ5WQ/lLiYYDmwiW86GufiG3wBywZgQJtSjVkF4AE5nMoV ZfOZI2kl2V0ST/RVhvO72T1Cb7Rp5zzYO7xHItNzpneR8Sxr7InZV5Z/Lf2yXp1OZrls ZKvbIT1wPPdmoyYUpUwD7bztQrsogtDelL3vttdqon92eeVlLUatBWzqaFQ4GgY26bHM hYlksuVXWO0G7lFMSStYoGJbZiLjxuW8xqSlIEwAeWSmaKMhef5EMdYWi6sbkzD2zlvc MEI9DeVGySPvIDwV2L7UDYpVg3ah/7JfnGKh2tTEBAliRvjmYkj78RvyoxVFAPxAIDV6 WeDA== X-Gm-Message-State: APjAAAVkO/AXcrBB3vvbdmDXxJ/pdqasCJ5HUktULj56M2o4cYDwwEeC aNJ8C8wgzzgVpUugOFaLcHs6XpS3oDdoHpea8gc= X-Google-Smtp-Source: APXvYqy8uhOpTt5CJTguqvqqRmEqnd2x8cIJzyVuCCDhU/JpUymfm6Oosx+6367gOZ/yKbjNCAOSDsIkHMicx14gy6I= X-Received: by 2002:a05:6512:4c6:: with SMTP id w6mr9576543lfq.157.1581606048857; Thu, 13 Feb 2020 07:00:48 -0800 (PST) MIME-Version: 1.0 References: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> In-Reply-To: From: Dick Hardt Date: Thu, 13 Feb 2020 07:00:18 -0800 Message-ID: To: David Cc: Lee McGovern , "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b78656059e765aa4" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 15:00:56 -0000 --000000000000b78656059e765aa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was not familiar PASETO before you mentioned it Lee. (David: it is an expired RFC, https://tools.ietf.org/html/draft-paragon-paseto-rfc-00) An extension could replace the JOSE in section 10 with PASETO. Any new claim types defined with PASETO could be added to the claims request (5.5.6) and response (7.4.5) On Thu, Feb 13, 2020 at 2:51 AM David wrote: > In what context? I do not believe this draft mandates tokens in a > particular format. > > That said - likely not for any standardized communication, since PASETO i= s > a non standardized vendor format. > > -DW > > On Feb 13, 2020, at 1:57 AM, Lee McGovern > wrote: > > =EF=BB=BF > > Is an alternative to JOSE being considered for example PASETO? > > > > > > *From:* Dick Hardt > *Sent:* Donnerstag, 13. Februar 2020 03:34 > *To:* Richard Backman, Annabelle > *Cc:* txauth@ietf.org > *Subject:* Re: [Txauth] XAuth -02 > > > > Thanks for the feedback Annabelle, sorry for the delay in responding. > > > > Comments and questions inserted: > > > > On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Interesting work. I am enjoying the fact that we have two different takes > on the same problem. The comparisons and discussions will lead us to a > better overall solution. > > > > That was my goal of publishing the draft! > > > > > > Here are my comments on XAuth-02: > > > > Section 2.1: > > * *Resource Owner* (RO) - owns the RS, and has delegated RS access > > management to the GS. The RO may be the same entity as the User, > ... > > > > I=E2=80=99m rather baffled by this definition, and wondering if it=E2=80= =99s a mistake or > if I=E2=80=99m misinterpreting it. Is this an intentional departure from = how =E2=80=9CRO=E2=80=9D > is typically used within the OAuth 2.0 space? Usually the term RO refers = to > the entity that owns the specific resources the client is requesting > authorization for. The RO does not typically own the RS itself. > > > > Mistake. Thanks for catching! > > > > > > Section 5.5.2: > > The interaction object contains the type of interaction the Client > > will provide the User. Other attributes > > > > - *type* - contains one of the following values: "popup", > > "redirect", or "qrcode".... > > > > 3 issues with this: > > 1. How would I do a user code-based interaction? > > To clarify, the User is entering a code in the Client into the GS, or the > User is entering a code into the Client? > > > > If the prior, the QR code also allows a message. I'm envisioning a User > with a mobile phone can scan the QR code which contains a URL at the GS, > and includes the code. > > > > The message would describe what to do and include the code. > > > > > 1. > 2. Clients support multiple interaction modes and may not always know > what the GS supports (and vice-versa). For a multi-tenant GS, it may v= ary > by tenant configuration. Clients should be able to say what they can d= o, > and the GS should be able to tell them which one to use. It=E2=80=99s = a very simple > but powerful inline negotiation. > > > > That is what is in TxAuth. Would you elaborate on how the GS might be > constrained? Why would the GS not be able to do all? > > > > I would think all constraints would be at the Client. Am I missing > something? > > > > > 1. > 2. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D intera= ction mode. Clients can > use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking a= s someone who has > done that, I really don=E2=80=99t recommend it. Popups are increasingl= y > unsupported, and prone to weird behavioral issues. In-app browsers in > Facebook, Twitter, etc. tend to have popups disabled. The last version= s of > IE Mobile didn=E2=80=99t support them at all (the popped up page basic= ally just > loaded into the current window). in > > > > Popups are really useful in single-page apps as you want to keep the > context and not reload the page. > > > > Agree that popups don't make sense in mobile. A full redirect does of > course. A single-page app on mobile would open a new tab which would be a > separate context rather than a redirect. > > > > > 1. > > > > Section 12.6: > > [Editor: is there some other reason to have the UserInfo > > endpoint?] > > > > I may want to host my UserInfo endpoint on a separate microservice from m= y > token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my > user profile/directory stack, while the latter is part of the highly > privileged authentication/authorization stack. > > > > > > The token endpoint has the access token anyway, so it can fetch the data > from the other endpoint itself if it wanted to. IE, there is no separatio= n > of duties. > > > > What are the advantages of the UserInfo endpoint to the User or Client? > > > > The UserInfo endpoint seems to just add more complexity, with no ability > to start a User interaction if additional consent is needed. > > > > > > > > Section 12.8: > > *Why have both claims and authorizations?* > > > > There are use cases for each that are independent: > > authenticating a user vs granting access to a resource. A > > request for an authorization returns an access token or handle, > > while a request for a claim returns the claim. > > > > I don=E2=80=99t agree that the use cases are distinct. The only claim tha= t is > strictly necessary for authentication is the user identifier. Other claim= s > like email and phone_number are often used to aid in local account > identification (i.e., account linking), but are useful and interesting > beyond this use case. > > > > Some Clients use email and phone_number as the identifier and don't pay > attention to the directed identifier. Not the best practice, but it is wh= at > people do. > > > > Other claims such as name, preferred_username, and birthdate could be use= d > in a similar fashion, though they frequently aren=E2=80=99t. The same is = true for > other resources not currently defined as claims (e.g., the externalId > established when the user was imported through SCIM).. > > > > Claims are just resources that OIDC provides a name registry and some > extra features for: > > - Optionally get the value bundled with the authentication response, > without needing to call a separate endpoint. > > In my opinion, all the different ways to get claims in OIDC is a bug, no= t > a feature. With the optionality at the OP, a generic Client has to suppo= rt > both. > > > > > > > - > - Optionally get the value in a signed or encrypted blob. > > This optionality is useful to the Client, as it can decide what claims > should be in the signed blob which may be used differently than other > claims. > > > > > - > - Optionally provide some structured metadata describing the resource > and/or requested authorization. > > > > > > > - > > > > It=E2=80=99s telling that all of these are optional. If we think these ar= e > features worth bringing forward into whatever protocol we produce through > TxAuth, we should look at them independently of the claim/resource > dichotomy. > > > > I agree that these features are orthogonal to the "are claims and > resources the same thing" debate. > > > > I strongly think it is a disservice to our audience to conflate claims an= d > resources. Claims are statements about the User and read-only. > > > > Resources are independent of the GS. The Client may be able to do all of > CRUD on the resource. > > > > While there is overlap with the UserInfo endpoint that it could be > considered a resource, I don't think that helps the audience. > > > > The language in XAuth can definitely use improvement to provide more > clarity here. > > > > > > > > Section 12.12: > > *Why complicate the sequence with "interaction"."keep"?* > > > > I understand the use case you=E2=80=99re trying to support here, but I th= ink the > proposal is too complicated to implement. From the sequences, it looks li= ke > the Client is expected to issue a Read Grant request, and that connection > will be kept open while the User is redirected to the GS and goes through > the authentication workflow (and possibly part of the authorization > workflow). Only then would the GS return the Read Grant response. Is this > correct? > > > > To implement this, the Client has to launch an asynchronous thread to > execute that request and awaiting the response. > > Possible, but susceptible to failures. What happens if that thread > crashes? Or fails to send the Update Grant request to flip interaction.ke= ep > to false? What is the GS doing in the meantime? Is it just showing the Us= er > a =E2=80=9Cloading=E2=80=9D widget as it waits for the Client to update t= he grant? How long > does it wait for? For mobile apps, that background thread may get killed = or > lose network connectivity as soon as the user gets switched over to the > system browser to load the GS sign in page. For a pure-JS app that > redirects, I don=E2=80=99t think this is possible at all. (unless web wor= kers can > survive page unloads?) > > > > This is an interesting use case for us to think about, but it needs a lot > of work and may not be something we should try to bake into the core > protocol if we don=E2=80=99t need to. > > > > It might not have been obvious, but the Client calling the GS to get a > result while the interaction is happening is what happens in any flow wit= h > an interaction started by the Client. It is not unique to > "interaction"."keep" -- we are just adding additional back and forths > between the Client and GS. > > > > A QR Code example HAS to work this way, as there is no other way for the > Client to know the interaction has completed. > > > > Google and Microsoft both have a similar user experience. The User wants > to log into an app -- they are instructed to go to the respective mobile > app to approve the authentication -- and then the User returns to the app > which changes to a logged in state. An authentication only flow using > XAuth would work the same way. > > > > > > > > Section 12.14: > > *Why use URIs to instead of handles for the Grant and > > Authorization?* > > > > I didn=E2=80=99t like this until I realized that you=E2=80=99re distingui= shing between > handles/URIs and tokens. Now that I=E2=80=99ve thought about it more, I l= ike this > from the standpoint that it underscores the idea of Grants and > Authorizations being persistent objects within the protocol. > > > > :) > > > > And it=E2=80=99s really just making public something that the GS is proba= bly going > to be doing under the hood anyway. However, we have to be careful that we > don=E2=80=99t accidentally encourage implementers to start shoving things= into > these URIs. > > > > The URI content is intended to be opaque. There would be security > considerations would keep people from putting visible stuff in there they > shouldn't. > > > > I would expect implementations to use a random value with a checksum, or = a > JWT. > > > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, February 7, 2020 at 8:00 PM > *To: *"txauth@ietf.org" > *Subject: *[Txauth] XAuth -02 > > > > I've heavily revised XAuth again. > > > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02 > > > > > A number of new ideas to bounce around: > > > > I have included a bunch of sequences to show different use cases possible= . > > > > Rather than a transaction, I use a Grant as the central object. > > > > The interface is very RESTful. > > > > The AS is now a Grant Server (GS) > > > > This also seemed appropriate at it is both an OAuth AS, and an OIDC OP. > > > > Rather than a handle, the Grant has a URI. > > > > The endpoint URI for the GS is the GS URI, and is the GS identifier. > > > > An access token, refresh token etc. are all an Authorization. An > Authorization has an AuthZ URI.. > > > > The Grant URI and AuthZ URI all start with the GS URI. > > > > A Grant is created by doing a POST to the GS URI, returning a Grant URI. > > > > Metadata for the GS is done with an OPTIONS to the GS URI. > > > > The Client can do GET, UPDATE, and DELETE against a Grant URI. > > > > An access token refresh is a GET on the AuthZ URI. > > > > Adding in Reciprocal OAuth functionality was more straightforward than in > OAuth 2.0 -- but not as straight forward as I would like -- but not clear > how to make it better and start from the Client and GS having context of > one authorization before swapping roles. > > > > Per my last emails, naming is hard, there are likely lots of mistakes, an= d > lots of aspects that need normative language. Hopefully the concepts come > through! > > > > /Dick > > =E1=90=A7 > > This e-mail, including attachments, is intended for the person(s) or > company named and may contain confidential and/or legally privileged > information. > Unauthorized disclosure, copying or use of this information may be > unlawful and is prohibited. If you are not the intended recipient, please > delete this message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re > Electronic Message Repository. > If you do not wish the retention of potentially private e-mails by Swiss > Re, we strongly advise you not to use the Swiss Re e-mail account for any > private, non-business related communications. -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000b78656059e765aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was not familiar PASETO before you mentioned it Lee.

An extension could r= eplace the JOSE in section 10 with PASETO.

Any new= claim types defined with PASETO could be added to the claims request (5.5.= 6) and response (7.4.5)


On Thu, Feb 13, 2020 at 2:51 AM= David <david@alkaline-s= olutions.com> wrote:
In what context? I do not believe this draft = mandates tokens in a particular format.=C2=A0

That said = - likely not for any standardized communication, since PASETO is a non stan= dardized vendor format.=C2=A0

-DW
=

On Feb 13, 2020, at 1:57 AM,= Lee McGovern <Lee_McGovern@swissre.com> wrote:

=EF=BB=BF

Is an alternative to JOSE being= considered for example PASETO?

=C2=A0

=C2=A0

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Donnerstag, 13. Februar 2020 03:34
To: Richard Backman, Annabelle <richanna@amazon.com>
Cc: txauth@ietf= .org
Subject: Re: [Txauth] XAuth -02

=C2=A0

Thanks for the feedback Annabelle, sorry for the del= ay in responding.

=C2=A0

Comments and questions inserted:

=C2=A0

On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Ann= abelle <richann= a@amazon.com> wrote:

Interesting work. I am enjoying= the fact that we have two different takes on the same problem. The compari= sons and discussions will lead us to a better overall solution.

=C2=A0

That was my goal of publishing the draft!<= /u>

=C2=A0

=C2=A0

Here are my comments on XAuth-0= 2:

=C2=A0

Section 2.1:

=C2=A0=C2=A0 *=C2=A0 *Resource Ow= ner* (RO) - owns the RS, and has delegated RS access

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ma= nagement to the GS.=C2=A0 The RO may be the same entity as the User, ...

=C2=A0

I=E2=80=99m rather baffled by t= his definition, and wondering if it=E2=80=99s a mistake or if I=E2=80=99m m= isinterpreting it. Is this an intentional departure from how =E2=80=9CRO=E2= =80=9D is typically used within the OAuth 2.0 space? Usually the term RO refers to the entity = that owns the specific resources the client is requesting authorization for= . The RO does not typically own the RS itself.

=C2=A0

Mistake. Thanks for catching!

=C2=A0

=C2=A0

Section 5.5.2:

=C2=A0=C2=A0 The interactio=
n object contains the type of interaction the Client
=C2=A0=C2=A0 will provide t=
he User.=C2=A0 Other attributes
<snip=
>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 -=C2=A0 *type* - contains one of the following values: &quo=
t;popup",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0"redirect", or "qrcode&quo=
t;....

=C2=A0

3 issues with this:

  1. How would I do a user code-based interaction?

To clarify, the User is entering a code in the Clien= t into the GS, or the User is entering a code into the Client?=C2=A0=

=C2=A0

If the prior, the QR code also allows a message. I&#= 39;m envisioning a User with a mobile phone can scan the QR code which cont= ains a URL at the GS, and includes the code.=C2=A0

=C2=A0

The message would describe what to do and include th= e code.

=C2=A0

  1. =C2=A0
  2. Clients support multiple interaction modes and may not= always know what the GS supports (and vice-versa). For a multi-tenant GS, = it may vary by tenant configuration. Clients should be able to say what the= y can do, and the GS should be able to tell them which one to use. It=E2=80=99s a very simple but powerful inl= ine negotiation.

=C2=A0

That is what is in TxAuth. Would you elaborate on ho= w the GS might be constrained? Why would the GS not be able to do all?

=C2=A0

I would think all constraints would be at the Client= . Am I missing something?

=C2=A0

  1. =C2=A0
  2. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2= =80=9D interaction mode. Clients can use =E2=80=9Credirect=E2=80=9D mode wi= thin popups. However, speaking as someone who has done that, I really don= =E2=80=99t recommend it. Popups are increasingly unsupported, and prone to = weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups dis= abled. The last versions of IE Mobile didn=E2=80=99t support them at all (t= he popped up page basically just loaded into the current window). in=C2=A0<= u>

=C2=A0

Popups are really useful in single-page apps as you = want to keep the context and not reload the page.

=C2=A0

Agree that popups don't make sense in mobile. A = full redirect does of course. A single-page app on mobile would open a new = tab which would be a separate context rather than a redirect.=

=C2=A0

  1. =C2=A0

=C2=A0

Section 12.6:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =C2=A0[Editor: is there some other reason to have the UserInfo
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 endpoint?]=

=C2=A0

I may want to host my UserInfo = endpoint on a separate microservice from my token endpoint (in OAuth 2.0/OI= DC terms). The former might be part of my user profile/directory stack, while the latter is part of the highly privileged authentication/au= thorization stack.

=C2=A0

=C2=A0

The token endpoint has the access token anyway, so i= t can fetch the data from the other endpoint itself if it wanted to. IE, th= ere is no separation of duties.

=C2=A0

What are the advantages of the UserInfo endpoint to = the User or Client?=C2=A0

=C2=A0

The UserInfo endpoint seems to just add more complex= ity, with no ability to start a User interaction if additional consent is n= eeded.

=C2=A0

=C2=A0

=C2=A0

Section 12.8:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *Why have both claims and authorizations?*
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 There are use cases for each that are independent:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 authenticating a user vs granting access to a resource.=C2=
=A0 A
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 request for an authorization returns an access token or han=
dle,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 while a request for a claim returns the claim.

=C2=A0

I don=E2=80=99t agree that the = use cases are distinct. The only claim that is strictly necessary for authe= ntication is the user identifier. Other claims like email and phone_number are often used to aid in local account identification (i.e., = account linking), but are useful and interesting beyond this use case.

=C2=A0

Some Clients use email and phone_number as the ident= ifier and don't pay attention to the directed identifier. Not the best = practice, but it is what people do.

=C2=A0

Other claims such as name, pref= erred_username, and birthdate could be used in a similar fashion, though th= ey frequently aren=E2=80=99t. The same is true for other resources not currently defined as claims (e.g., the externalId established when the= user was imported through SCIM)..

=C2=A0

Claims are just resources that = OIDC provides a name registry and some extra features for:

  • Optionally get the value bundled with the authenticati= on response, without needing to call a separate endpoint.

=C2=A0In my opinion, all the different ways to get c= laims in OIDC is a bug, not a feature. With the optionality at the OP,=C2= =A0 a generic Client has to support both.

=C2=A0

=C2=A0

  • =C2=A0
  • Optionally get the value in a signed or encrypted blob= .

This optionality is useful to the Client, as it can = decide what claims should be in the signed blob which may be used different= ly than other claims.

=C2=A0

  • =C2=A0
  • Optionally provide some structured metadata describing= the resource and/or requested authorization.

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

It=E2=80=99s telling that all o= f these are optional. If we think these are features worth bringing forward= into whatever protocol we produce through TxAuth, we should look at them independently of the claim/resource dichotomy.<= /span>

=C2=A0

I agree that these features are orthogonal to the &q= uot;are claims and resources the same thing" debate.=C2=A0

=C2=A0

I strongly think it is a disservice to our audience = to conflate claims and resources. Claims are statements about the User and = read-only.

=C2=A0

Resources are independent of the GS. The Client may = be able to do all of CRUD on the resource.=C2=A0

=C2=A0

While there is overlap with the UserInfo endpoint th= at it could be considered a resource, I don't think that helps the audi= ence.

=C2=A0

The language in XAuth can definitely use improvement= to provide more clarity here.

=C2=A0

=C2=A0

=C2=A0

Section 12.12:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *Why complicate the sequence with "interaction".&=
quot;keep"?*

=C2=A0

I understand the use case you= =E2=80=99re trying to support here, but I think the proposal is too complic= ated to implement. From the sequences, it looks like the Client is expected to issue a Read Grant request, and that connection will be kep= t open while the User is redirected to the GS and goes through the authenti= cation workflow (and possibly part of the authorization workflow). Only the= n would the GS return the Read Grant response. Is this correct?

=C2=A0

To implement this, the Client h= as to launch an asynchronous thread to execute that request and awaiting th= e response.

Possible, but susceptible to fa= ilures. What happens if that thread crashes? Or fails to send the Update Gr= ant request to flip interaction.keep to false? What is the GS doing in the meantime? Is it just showing the User a =E2=80=9Clo= ading=E2=80=9D widget as it waits for the Client to update the grant? How l= ong does it wait for? For mobile apps, that background thread may get kille= d or lose network connectivity as soon as the user gets switched over to the system browser to load the GS sign in page. For = a pure-JS app that redirects, I don=E2=80=99t think this is possible at all= . (unless web workers can survive page unloads?)

=C2=A0

This is an interesting use case= for us to think about, but it needs a lot of work and may not be something= we should try to bake into the core protocol if we don=E2=80=99t need to.

=C2=A0

It might not have been obvious, but the Client calli= ng the GS to get a result while the interaction is happening is what happen= s in any flow with an interaction started by the Client. It is not unique t= o "interaction"."keep" -- we are just adding additional back and forths between the Client and GS.=

=C2=A0

A QR Code example HAS to work this way, as there is = no other way for the Client to know the interaction has completed.

=C2=A0

Google and Microsoft both have a similar user experi= ence. The User wants to log into an app -- they are instructed to go to the= respective mobile app to approve the authentication -- and then the User r= eturns to the app which changes to a logged in state.=C2=A0 An authentication only flow using XAuth would wor= k the same way.

=C2=A0

=C2=A0

=C2=A0

Section 12.14:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *Why use URIs to instead of handles for the Grant and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Authorization?*

=C2=A0

I didn=E2=80=99t like this unti= l I realized that you=E2=80=99re distinguishing between handles/URIs and to= kens. Now that I=E2=80=99ve thought about it more, I like this from the sta= ndpoint that it underscores the idea of Grants and Authorizations being persistent= objects within the protocol.

=C2=A0

:)

=C2=A0

And it=E2=80=99s really just ma= king public something that the GS is probably going to be doing under the h= ood anyway. However, we have to be careful that we don=E2=80=99t accidental= ly encourage implementers to start shoving things into these URIs.<= /u>

=C2=A0

The URI content is intended to be opaque. There woul= d be security considerations would keep people from putting visible stuff i= n there they shouldn't.

=C2=A0

I would expect implementations to use a random value= with a checksum, or a JWT.

=C2=A0

=C2=A0

=E2=80= =93

Annabe= lle Backman (she/her)

AWS Id= entity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: <= /b>Txauth <txauth-bounces@ie= tf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 7, 2020 at 8:00 PM
To: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: [Txauth] XAuth -02

=C2=A0

I've heavily revised XAuth again.

=C2=A0

https://tools.ietf.org/html/draft-hardt-= xauth-protocol-02

=C2=A0

A number of new ideas to bounce around:<= /span>

=C2=A0

I have included a bunch of sequences to show different= use cases possible.

=C2=A0

Rather than a transaction, I use a Grant as the centra= l object.

=C2=A0

The interface is very RESTful.

=C2=A0

The AS is now a Grant Server (GS)=

=C2=A0

This also seemed appropriate at it is both an OAuth AS= , and an OIDC OP.

=C2=A0

Rather than a handle, the Grant has a URI.=C2=A0

=C2=A0

The endpoint URI for the GS is the GS URI, and is the = GS identifier.

=C2=A0

An access token, refresh token etc. are all an Authori= zation. An Authorization has an AuthZ URI..

=C2=A0

The Grant URI and AuthZ URI all start with the GS URI.=

=C2=A0

A Grant is created by doing a POST to the GS URI, retu= rning a Grant URI.

=C2=A0

Metadata for the GS is done with an OPTIONS to the GS = URI.

=C2=A0

The Client can do GET, UPDATE, and DELETE against a Gr= ant URI.

=C2=A0

An access token refresh is a GET on the AuthZ URI.<= /u>

=C2=A0

Adding in Reciprocal OAuth functionality was more stra= ightforward than in OAuth 2.0 -- but not as straight forward as I would lik= e -- but not clear how to make it better and start from the Client and GS h= aving context of one authorization before swapping roles.

=C2=A0

Per my last emails, naming is hard, there are likely l= ots of mistakes, and lots of aspects that need normative language. Hopefull= y the concepts come through!

=C2=A0

/Dick

=E1=90=A7


This e-mail, including attachments, is intended for the person(s) = or company named and may contain confidential and/or legally privileged inf= ormation.
Unauthorized disclosure, copying or use of this information = may be unlawful and is prohibited. If you are not the intended recipient, p= lease delete this message and notify the sender.
All incoming and outgoi= ng e-mail messages are stored in the Swiss Re Electronic Message Repository= .
If you do not wish the retention of potentially private e-mails by Swi= ss Re, we strongly advise you not to use the Swiss Re e-mail account for an= y private, non-business related communications. --
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--000000000000b78656059e765aa4-- From nobody Thu Feb 13 07:08:31 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91AE1200C7 for ; Thu, 13 Feb 2020 07:08:29 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDfrwuL96VWd for ; Thu, 13 Feb 2020 07:08:26 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB01120013 for ; Thu, 13 Feb 2020 07:08:25 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id n18so6983053ljo.7 for ; Thu, 13 Feb 2020 07:08:25 -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=+1SF9/5f/kQKpxsWUO2XIpLaohu2PBr2gpGU07kOI7w=; b=nZIrEZy195Oztr0e0keom+e8CSGbtXsiYGXY1YJpAVn0X7CpeNAglDbzqK+5TZcIDu f4aMg5meSMYXEv3L+3sHuZrmyu7i3tcOMWdVo8+r+HEZ/6v4rgaxfO5DaRBnkKLOm4xG nJk82q0yjOXC62vJWIsLvIwHOzVjA/oV+YSFq2D09gQwVaVbagX3qZa1vcOqOGn/6mgA 96oUV5qyH6vKmE9NsZQkwJaEOHW5BjS4DD34/1t+RrlOL8UhyiUtbDPYGDz8dHKZBnDk fP82e4vVGkd7MvhmcUpc+dhrI8/WjnBS2J+ikkgLqJQd6bG3DbTota/6izrBhaKzF8Ab YsdQ== 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=+1SF9/5f/kQKpxsWUO2XIpLaohu2PBr2gpGU07kOI7w=; b=rgQo5RF+JxByaYNNdPZWy311xslMGwAoOSha64zsbcG4OcpQYZ+TR0axpNjdFjT81M omBgloNvUeR0XY0udN27U9/Q71/DQx8CWDsJcatseWPYWBUtyRAVrUYRJOHDZcRDfF1o jySe8thO6kHw2Xsb+yo9oSwnZgdtUIsHBquIrMPaRfEp/mT7piFOmsVCRZHjn+tiRZQE Sq7ZKsgCEKiepS7IDiotYtApJoAkglmuhR3oYGoE43JfRKn8uO+VF9zpd0RceBuYE+Ml d3QKCeJ9H4KY0/DdwFuGncXvSj9s7L5UVwIqdm3ej13j0sHSGC+MDJOSRjtXVo1fsrN8 7SvA== X-Gm-Message-State: APjAAAV7IE+l7IiRjQqeFn0p3p4AfUgPTs53OmguHnNze61mAxcjl6xl iRXznBRk/LIXluI9TPA1HaX0Mmeo0lA88Wdl7OU= X-Google-Smtp-Source: APXvYqzWmD7R6L4c4ruxKxPwC66Xlo9INRM/pIq0Iy/FhgBSWI3iPn4+XDdWNWBv4yz0hFIprF3O9aM+x28kyhwqHuk= X-Received: by 2002:a2e:808a:: with SMTP id i10mr11412567ljg.151.1581606503642; Thu, 13 Feb 2020 07:08:23 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> In-Reply-To: From: Dick Hardt Date: Thu, 13 Feb 2020 07:07:50 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d2fa8f059e7675b5" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 15:08:30 -0000 --000000000000d2fa8f059e7675b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I got distracted and left out responding to one of your comments. While a single stage Grant request (3.1) in a mobile app that has been put to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only makes sense if the Client is checking a database along the way, I would expect the Client to have a server side, and the server could take each step. A related point that I did not call out in the draft is that I expect the connection between the Client and the GS to be maintained between each of the calls, and by requiring TLS 1.3, there should be no extra round trips to set up TLS if the connection fails. =E1=90=A7 On Wed, Feb 12, 2020 at 6:34 PM Dick Hardt wrote: > Thanks for the feedback Annabelle, sorry for the delay in responding. > > Comments and questions inserted: > > On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> Interesting work. I am enjoying the fact that we have two different take= s >> on the same problem. The comparisons and discussions will lead us to a >> better overall solution. >> > > That was my goal of publishing the draft! > > >> >> >> Here are my comments on XAuth-02: >> >> >> >> Section 2.1: >> >> * *Resource Owner* (RO) - owns the RS, and has delegated RS access >> >> management to the GS. The RO may be the same entity as the User, >> ... >> >> >> >> I=E2=80=99m rather baffled by this definition, and wondering if it=E2=80= =99s a mistake or >> if I=E2=80=99m misinterpreting it. Is this an intentional departure from= how =E2=80=9CRO=E2=80=9D >> is typically used within the OAuth 2.0 space? Usually the term RO refers= to >> the entity that owns the specific resources the client is requesting >> authorization for. The RO does not typically own the RS itself. >> > > Mistake. Thanks for catching! > > >> >> >> Section 5.5.2: >> >> The interaction object contains the type of interaction the Client >> >> will provide the User. Other attributes >> >> >> >> - *type* - contains one of the following values: "popup", >> >> "redirect", or "qrcode".... >> >> >> >> 3 issues with this: >> >> 1. How would I do a user code-based interaction? >> >> To clarify, the User is entering a code in the Client into the GS, or th= e > User is entering a code into the Client? > > If the prior, the QR code also allows a message. I'm envisioning a User > with a mobile phone can scan the QR code which contains a URL at the GS, > and includes the code. > > The message would describe what to do and include the code. > > >> >> 1. >> 2. Clients support multiple interaction modes and may not always know >> what the GS supports (and vice-versa). For a multi-tenant GS, it may = vary >> by tenant configuration. Clients should be able to say what they can = do, >> and the GS should be able to tell them which one to use. It=E2=80=99s= a very simple >> but powerful inline negotiation. >> >> > That is what is in TxAuth. Would you elaborate on how the GS might be > constrained? Why would the GS not be able to do all? > > I would think all constraints would be at the Client. Am I missing > something? > > >> >> 1. >> 2. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D inter= action mode. Clients can >> use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking = as someone who has >> done that, I really don=E2=80=99t recommend it. Popups are increasing= ly >> unsupported, and prone to weird behavioral issues. In-app browsers in >> Facebook, Twitter, etc. tend to have popups disabled. The last versio= ns of >> IE Mobile didn=E2=80=99t support them at all (the popped up page basi= cally just >> loaded into the current window). in >> >> > Popups are really useful in single-page apps as you want to keep the > context and not reload the page. > > Agree that popups don't make sense in mobile. A full redirect does of > course. A single-page app on mobile would open a new tab which would be a > separate context rather than a redirect. > > >> >> 1. >> >> >> >> Section 12.6: >> >> [Editor: is there some other reason to have the UserInfo >> >> endpoint?] >> >> >> >> I may want to host my UserInfo endpoint on a separate microservice from >> my token endpoint (in OAuth 2.0/OIDC terms). The former might be part of= my >> user profile/directory stack, while the latter is part of the highly >> privileged authentication/authorization stack. >> > > > The token endpoint has the access token anyway, so it can fetch the data > from the other endpoint itself if it wanted to. IE, there is no separatio= n > of duties. > > What are the advantages of the UserInfo endpoint to the User or Client? > > The UserInfo endpoint seems to just add more complexity, with no ability > to start a User interaction if additional consent is needed. > > > >> >> >> Section 12.8: >> >> *Why have both claims and authorizations?* >> >> >> >> There are use cases for each that are independent: >> >> authenticating a user vs granting access to a resource. A >> >> request for an authorization returns an access token or handle, >> >> while a request for a claim returns the claim. >> >> >> >> I don=E2=80=99t agree that the use cases are distinct. The only claim th= at is >> strictly necessary for authentication is the user identifier. Other clai= ms >> like email and phone_number are often used to aid in local account >> identification (i.e., account linking), but are useful and interesting >> beyond this use case. >> > > Some Clients use email and phone_number as the identifier and don't pay > attention to the directed identifier. Not the best practice, but it is wh= at > people do. > > >> Other claims such as name, preferred_username, and birthdate could be >> used in a similar fashion, though they frequently aren=E2=80=99t. The sa= me is true >> for other resources not currently defined as claims (e.g., the externalI= d >> established when the user was imported through SCIM). >> >> >> >> Claims are just resources that OIDC provides a name registry and some >> extra features for: >> >> - Optionally get the value bundled with the authentication response, >> without needing to call a separate endpoint. >> >> In my opinion, all the different ways to get claims in OIDC is a bug, > not a feature. With the optionality at the OP, a generic Client has to > support both. > > > >> >> - >> - Optionally get the value in a signed or encrypted blob. >> >> This optionality is useful to the Client, as it can decide what claims > should be in the signed blob which may be used differently than other > claims. > > >> - >> - Optionally provide some structured metadata describing the resource >> and/or requested authorization. >> >> > > >> >> - >> >> >> >> It=E2=80=99s telling that all of these are optional. If we think these a= re >> features worth bringing forward into whatever protocol we produce throug= h >> TxAuth, we should look at them independently of the claim/resource >> dichotomy. >> > > I agree that these features are orthogonal to the "are claims and > resources the same thing" debate. > > I strongly think it is a disservice to our audience to conflate claims an= d > resources. Claims are statements about the User and read-only. > > Resources are independent of the GS. The Client may be able to do all of > CRUD on the resource. > > While there is overlap with the UserInfo endpoint that it could be > considered a resource, I don't think that helps the audience. > > The language in XAuth can definitely use improvement to provide more > clarity here. > > > >> >> >> Section 12.12: >> >> *Why complicate the sequence with "interaction"."keep"?* >> >> >> >> I understand the use case you=E2=80=99re trying to support here, but I t= hink the >> proposal is too complicated to implement. From the sequences, it looks l= ike >> the Client is expected to issue a Read Grant request, and that connectio= n >> will be kept open while the User is redirected to the GS and goes throug= h >> the authentication workflow (and possibly part of the authorization >> workflow). Only then would the GS return the Read Grant response. Is thi= s >> correct? >> >> >> >> To implement this, the Client has to launch an asynchronous thread to >> execute that request and awaiting the response. >> > Possible, but susceptible to failures. What happens if that thread >> crashes? Or fails to send the Update Grant request to flip interaction.k= eep >> to false? What is the GS doing in the meantime? Is it just showing the U= ser >> a =E2=80=9Cloading=E2=80=9D widget as it waits for the Client to update = the grant? How long >> does it wait for? For mobile apps, that background thread may get killed= or >> lose network connectivity as soon as the user gets switched over to the >> system browser to load the GS sign in page. For a pure-JS app that >> redirects, I don=E2=80=99t think this is possible at all. (unless web wo= rkers can >> survive page unloads?) >> >> >> >> This is an interesting use case for us to think about, but it needs a lo= t >> of work and may not be something we should try to bake into the core >> protocol if we don=E2=80=99t need to. >> > > It might not have been obvious, but the Client calling the GS to get a > result while the interaction is happening is what happens in any flow wit= h > an interaction started by the Client. It is not unique to > "interaction"."keep" -- we are just adding additional back and forths > between the Client and GS. > > A QR Code example HAS to work this way, as there is no other way for the > Client to know the interaction has completed. > > Google and Microsoft both have a similar user experience. The User wants > to log into an app -- they are instructed to go to the respective mobile > app to approve the authentication -- and then the User returns to the app > which changes to a logged in state. An authentication only flow using > XAuth would work the same way. > > > >> >> >> Section 12.14: >> >> *Why use URIs to instead of handles for the Grant and >> >> Authorization?* >> >> >> >> I didn=E2=80=99t like this until I realized that you=E2=80=99re distingu= ishing between >> handles/URIs and tokens. Now that I=E2=80=99ve thought about it more, I = like this >> from the standpoint that it underscores the idea of Grants and >> Authorizations being persistent objects within the protocol. >> > > :) > > >> And it=E2=80=99s really just making public something that the GS is prob= ably >> going to be doing under the hood anyway. However, we have to be careful >> that we don=E2=80=99t accidentally encourage implementers to start shovi= ng things >> into these URIs. >> > > The URI content is intended to be opaque. There would be security > considerations would keep people from putting visible stuff in there they > shouldn't. > > I would expect implementations to use a random value with a checksum, or = a > JWT. > > >> >> >> =E2=80=93 >> >> Annabelle Backman (she/her) >> >> AWS Identity >> >> https://aws.amazon.com/identity/ >> >> >> >> >> >> *From: *Txauth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Friday, February 7, 2020 at 8:00 PM >> *To: *"txauth@ietf.org" >> *Subject: *[Txauth] XAuth -02 >> >> >> >> I've heavily revised XAuth again. >> >> >> >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-02 >> >> >> >> A number of new ideas to bounce around: >> >> >> >> I have included a bunch of sequences to show different use cases possibl= e. >> >> >> >> Rather than a transaction, I use a Grant as the central object. >> >> >> >> The interface is very RESTful. >> >> >> >> The AS is now a Grant Server (GS) >> >> >> >> This also seemed appropriate at it is both an OAuth AS, and an OIDC OP. >> >> >> >> Rather than a handle, the Grant has a URI. >> >> >> >> The endpoint URI for the GS is the GS URI, and is the GS identifier. >> >> >> >> An access token, refresh token etc. are all an Authorization. An >> Authorization has an AuthZ URI.. >> >> >> >> The Grant URI and AuthZ URI all start with the GS URI. >> >> >> >> A Grant is created by doing a POST to the GS URI, returning a Grant URI. >> >> >> >> Metadata for the GS is done with an OPTIONS to the GS URI. >> >> >> >> The Client can do GET, UPDATE, and DELETE against a Grant URI. >> >> >> >> An access token refresh is a GET on the AuthZ URI. >> >> >> >> Adding in Reciprocal OAuth functionality was more straightforward than i= n >> OAuth 2.0 -- but not as straight forward as I would like -- but not clea= r >> how to make it better and start from the Client and GS having context of >> one authorization before swapping roles. >> >> >> >> Per my last emails, naming is hard, there are likely lots of mistakes, >> and lots of aspects that need normative language. Hopefully the concepts >> come through! >> >> >> >> /Dick >> > =E1=90=A7 > --000000000000d2fa8f059e7675b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I got distracted and left out responding to one of your co= mments.

While a single stage Grant request (3.1) in a mo= bile app that has been put to sleep will recover fine, a multi-step (3.4) w= ill fail. Since 3.4 only makes sense if the Client is checking a database a= long the way, I would=C2=A0expect the Client to have a server side, and the= server could take each step.

A related point that= I did not call out in the draft is that I expect the connection between th= e Client and the GS to be maintained between each of the calls, and by requ= iring TLS 1.3, there should be no extra round trips to set up TLS if the co= nnection fails.
3D""=E1=90=A7

On Wed, Feb 12, 2020 at= 6:34 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Thanks for the feedback An= nabelle, sorry for the delay in responding.

Commen= ts and questions inserted:

On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, = Annabelle <rich= anna@amazon.com> wrote:

Interesting work. I am enjoying the fact that we hav= e two different takes on the same problem. The comparisons and discussions = will lead us to a better overall solution.


That was my goal of publishing the draft!
=C2=A0<= /div>
=

=C2=A0

Here are my comments on XAuth-02:

=C2=A0

Section 2.1:

=C2=A0=C2=A0 *=C2=A0 *Resource Owner* (RO) - own= s the RS, and has delegated RS access

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 management to the= GS.=C2=A0 The RO may be the same entity as the User, ...

=C2=A0

I=E2=80=99m rather baffled by this definition, and w= ondering if it=E2=80=99s a mistake or if I=E2=80=99m misinterpreting it. Is= this an intentional departure from how =E2=80=9CRO=E2=80=9D is typically u= sed within the OAuth 2.0 space? Usually the term RO refers to the entity th= at owns the specific resources the client is requesting authorization for. Th= e RO does not typically own the RS itself.


Mistake. Thanks for catching!
=C2=A0

=C2=A0

Section 5.5.2:

=C2=A0=C2=A0 The interaction object contai=
ns the type of interaction the Client
=C2=A0=C2=A0 will provide the User.=C2=A0 =
Other attributes
<snip>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 -=C2=A0 *type* - contains one of the following values: "popup",<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =C2=A0=C2=A0=C2=A0"redirect", or "qrcode"....

=C2=A0

3 issues with this:

  1. How would I do a user code-based interaction?=
To clarify, the User is entering a = code in the Client into the GS, or the User is entering a code into the Cli= ent?=C2=A0

If the prior, the QR code also allows a= message. I'm envisioning a User with a mobile phone can scan the QR co= de which contains a URL at the GS, and includes the code.=C2=A0
<= br>
The message would describe what to do and include the code.
=C2=A0
  1. Clients support multiple interaction modes and may not always know what t= he GS supports (and vice-versa). For a multi-tenant GS, it may vary by tena= nt configuration. Clients should be able to say what they can do, and the GS should be able to tell them wh= ich one to use. It=E2=80=99s a very simple but powerful inline negotiation.=

That is what is in T= xAuth. Would you elaborate on how the GS might be constrained? Why would th= e GS not be able to do all?

I would think all cons= traints would be at the Client. Am I missing something?
=C2=A0
  2. I don=E2=80= =99t see the value of the =E2=80=9Cpopup=E2=80=9D interaction mode. Clients= can use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking a= s someone who has done that, I really don=E2=80=99t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app= browsers in Facebook, Twitter, etc. tend to have popups disabled. The last= versions of IE Mobile didn=E2=80=99t support them at all (the popped up pa= ge basically just loaded into the current window). in=C2=A0

Po= pups are really useful in single-page apps as you want to keep the context = and not reload the page.

Agree that popups don'= ;t make sense in mobile. A full redirect does of course. A single-page app = on mobile would open a new tab which would be a separate context rather tha= n a redirect.
=C2=A0

=C2=A0

Section 12.6:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0[Editor: is there some other reason to have the UserInfo
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 endpoint?]

=C2=A0

I may want to host my UserInfo endpoint on a separat= e microservice from my token endpoint (in OAuth 2.0/OIDC terms). The former= might be part of my user profile/directory stack, while the latter is part= of the highly privileged authentication/authorization stack.



The = token endpoint has the access token anyway, so it can fetch the data from t= he other endpoint itself if it wanted to. IE, there is no separation of dut= ies.

What are the advantages of the UserInfo endpo= int to the User or Client?=C2=A0

The UserInfo endp= oint seems to just add more complexity, with no ability to start a User int= eraction if additional consent is needed.

=C2=A0
<= div>

=C2=A0

Section 12.8:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 *Why have both claims and authorizations?*
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 There are use cases for each that are independent:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 authenticating a user vs granting access to a resource.=C2=A0 A<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 request for an authorization returns an access token or handle,<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 while a request for a claim returns the claim.


=C2=A0


I don=E2=80=99t agree that the use cases are distinc=
t. The only claim that is strictly necessary for authentication is the user=
 identifier. Other claims like email and phone_number are often used to aid=
 in local account identification (i.e., account
 linking), but are useful and interesting beyond this use case.

Some Clients use email and phone_numbe= r as the identifier and don't pay attention to the directed identifier.= Not the best practice, but it is what people do.
=C2=A0

Other claims such as name, preferred_username, and bir= thdate could be used in a similar fashion, though they frequently aren=E2= =80=99t. The same is true for other resources not currently defined as clai= ms (e.g., the externalId established when the user was imported through SCIM)= .

=C2=A0

Claims are just resources that OIDC provides a name = registry and some extra features for:

  • Optionally get the value bundled with the aut= hentication response, without needing to call a separate endpoint.
=C2=A0In my opinion, all the different ways = to get claims in OIDC is a bug, not a feature. With the optionality at the = OP,=C2=A0 a generic Client has to support both.

=C2=A0
  • Optio= nally get the value in a signed or encrypted blob.
This optionality is useful to the Client, as it can decide w= hat claims should be in the signed blob which may be used differently than = other claims.

  • Optionally provide some structured metadata describing the resource= and/or requested authorization.
=C2=A0
<= div lang=3D"EN-US">

=C2=A0

It=E2=80=99s telling that all of these are optional.= If we think these are features worth bringing forward into whatever protoc= ol we produce through TxAuth, we should look at them independently of the c= laim/resource dichotomy.


I = agree that these features are orthogonal to the "are claims and resour= ces the same thing" debate.=C2=A0

I strongly = think it is a disservice to our audience to conflate claims and resources. = Claims are statements about the User and read-only.

Resources are independent of the GS. The Client may be able to do all of = CRUD on the resource.=C2=A0

While there is overlap= with the UserInfo endpoint that it could be considered a resource, I don&#= 39;t think that helps the audience.

The language i= n XAuth can definitely use improvement to provide more clarity here.
<= div>
=C2=A0

=C2=A0

Section 12.12:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 *Why complicate the sequence with "interaction"."keep"=
?*

=C2=A0

I understand the use case you=E2=80=99re trying to s= upport here, but I think the proposal is too complicated to implement. From= the sequences, it looks like the Client is expected to issue a Read Grant = request, and that connection will be kept open while the User is redirected to the GS and goes through the authentic= ation workflow (and possibly part of the authorization workflow). Only then= would the GS return the Read Grant response. Is this correct?

=C2=A0

To implement this, the Client has to launch an async= hronous thread to execute that request and awaiting the response.

=

Possible, but susceptible to fail= ures. What happens if that thread crashes? Or fails to send the Update Gran= t request to flip interaction.keep to false? What is the GS doing in the meantime? I= s it just showing the User a =E2=80=9Cloading=E2=80=9D widget as it waits f= or the Client to update the grant? How long does it wait for? For mobile ap= ps, that background thread may get killed or lose network connectivity as soon as the user gets switched over to the system = browser to load the GS sign in page. For a pure-JS app that redirects, I do= n=E2=80=99t think this is possible at all. (unless web workers can survive = page unloads?)

=C2=A0

This is an interesting use case for us to think abou= t, but it needs a lot of work and may not be something we should try to bak= e into the core protocol if we don=E2=80=99t need to.


It might not have been obvious, but the Client c= alling the GS to get a result while the interaction is happening is what ha= ppens in any flow with an interaction started by the Client. It is not uniq= ue to "interaction"."keep" -- we are just adding additi= onal back and forths between the Client and GS.

A = QR Code example HAS to work this way, as there is no other way for the Clie= nt to know the interaction has completed.

Google a= nd Microsoft both have a similar user experience. The User wants to log int= o an app -- they are instructed to go to the respective mobile app to appro= ve the authentication -- and then the User returns to the app which changes= to a logged in state.=C2=A0 An authentication only flow using XAuth would = work the same way.

=C2=A0

=C2=A0

Section 12.14:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 *Why use URIs to instead of handles for the Grant and=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Authorization?*

=C2=A0

I didn=E2=80=99t like this until I realized that you= =E2=80=99re distinguishing between handles/URIs and tokens. Now that I=E2= =80=99ve thought about it more, I like this from the standpoint that it und= erscores the idea of Grants and Authorizations being persistent objects within the protocol.


<= div>:)
=C2=A0

And it=E2=80=99s really= just making public something that the GS is probably going to be doing und= er the hood anyway. However, we have to be careful that we don=E2=80=99t ac= cidentally encourage implementers to start shoving things into these URIs.<= /p>


The URI content is intended= to be opaque. There would be security considerations would keep people fro= m putting visible stuff in there they shouldn't.

I would expect implementations to use a random value with a checksum, or= a JWT.
=C2=A0

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 7, 2020 at 8:00 PM
To: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: [Txauth] XAuth -02

=C2=A0

I've heavily revised= XAuth again.

=C2=A0

https://too= ls.ietf.org/html/draft-hardt-xauth-protocol-02

=C2=A0

A number of new ideas to= bounce around:

=C2=A0

I have included a bunch = of sequences to show different use cases possible.

=C2=A0

Rather than a transactio= n, I use a Grant as the central object.

=C2=A0

The interface is very RE= STful.

=C2=A0

The AS is now a Grant Se= rver (GS)

=C2=A0

This also seemed appropr= iate at it is both an OAuth AS, and an OIDC OP.

=C2=A0

Rather than a handle, th= e Grant has a URI.=C2=A0

=C2=A0

The endpoint URI for the= GS is the GS URI, and is the GS identifier.

=C2=A0

An access token, refresh= token etc. are all an Authorization. An Authorization has an AuthZ URI..

=C2=A0

The Grant URI and AuthZ = URI all start with the GS URI.

=C2=A0

A Grant is created by do= ing a POST to the GS URI, returning a Grant URI.

=C2=A0

Metadata for the GS is d= one with an OPTIONS to the GS URI.

=C2=A0

The Client can do GET, U= PDATE, and DELETE against a Grant URI.

=C2=A0

An access token refresh = is a GET on the AuthZ URI.

=C2=A0

Adding in Reciprocal OAu= th functionality was more straightforward than in OAuth 2.0 -- but not as s= traight forward as I would like -- but not clear how to make it better and = start from the Client and GS having context of one authorization before swapping roles.

=C2=A0

Per my last emails, nami= ng is hard, there are likely lots of mistakes, and lots of aspects that nee= d normative language. Hopefully the concepts come through!

=C2=A0

/Dick

3D""=E1=90=A7
--000000000000d2fa8f059e7675b5-- From nobody Thu Feb 13 08:00:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF683120121 for ; Thu, 13 Feb 2020 07:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 e-gi63SNghy3 for ; Thu, 13 Feb 2020 07:59:57 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6BAC7120147 for ; Thu, 13 Feb 2020 07:59:57 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01DFxtlI028021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 13 Feb 2020 10:59:56 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 13 Feb 2020 10:59:54 -0500 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 15:59:59 -0000 I=E2=80=99ve been doing some implementation of OIDC session management = lately, and I had a realization that the pattern in TxAuth can give us a = chance to do something a lot better. In OIDC, you use the ID token as a secondary artifact to indicate which = client you are and which session you=E2=80=99re talking about. This is = used as a drive-by client authentication (even though it=E2=80=99s = really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers internally, and so it = gets replayed as an assertion to reference those identifiers later on in = the protocol. Basically, it=E2=80=99s building a lot of functionality on = top of the ID token that it wasn=E2=80=99t really meant to bear.=20 For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re = looking to handle user interaction to begin with: - Client gets some kind of session management handle/identifier (and/or = URL, depending on which model we go with).=20 - When the user wants to log out, client can send that back to the AS in = the back channel, and get back an interaction mechanism that the client = can use to interact with the AS for determining if they want to kill the = session there as well.=20 - The AS can group together different clients into a =E2=80=9Csingle = sign out=E2=80=9D cluster=20 - When the AS learns that the user wants to log out, it might be able to = push messages out to other clients =E2=80=94 maybe they register back = channel callback endpoints, or maybe a push message over http/2 or 3 or = COAP, or some other mechanism. But the client can push that information = in the initial request, and it can be user- and session- specific.=20 These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me = that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before. To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.=20 From nobody Thu Feb 13 08:36:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A0212016E for ; Thu, 13 Feb 2020 08:36:27 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LODhMGRWO7C for ; Thu, 13 Feb 2020 08:36:25 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E1D1200C4 for ; Thu, 13 Feb 2020 08:36:25 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id x14so7310792ljd.13 for ; Thu, 13 Feb 2020 08:36:25 -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=K4NRaEzr3+cHUz26ubxYQd/7YWlJ+f1odynKZEJuPtA=; b=LOmXvOzPrf5GEwhGa5ihJQJfYnDz/d4fBp/G72Wu70bKrsxl1GtrCFBBD65XrjahoP +BLC9IJaEBc6+EY+eIMT5g+B+5AzVQVciI/DOZGkcTokcGDO4JISSDRSW5BZZPZ/4nkn f9pAg6YHB9tf4yeHMXR1GIjIpjdplZDy/j3+sY1dledkJCkSpkCBHmqj+tL67u0rygnv nhHIdDjZHgYU6JIVTeByaYESGcgIg1hkNp5svdw+etPXvuUsqyrLDzh1SifsX2UVEw0d X0DO9LLD3TsUZe+UGdjzFxoPPVp1/VEWQ9FIB1T4+RSPZpNToIgdXy71FHfnLnvZ7dsW 1XdQ== 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=K4NRaEzr3+cHUz26ubxYQd/7YWlJ+f1odynKZEJuPtA=; b=QhxTXIcKybU3t6Bn1t1e0h0oko7J7NDx0DddHNynO0YxmX1y06TpzAQmyGYcCoUv67 6EyJ8c+hyJnILjV8mgn025vJaLToInk0aLbyP2n4+Siutjz5FqwMWo7/JrEbG1S320hn 3JvQSa7OXghmoLxE+XoHguWTbl9c3hdyi8OTIp/cbxwY4/x/hHSJ2nc76igOG9yVE1wj rDwRCQ5hvNY2A7+cCqIhQIo9NEJxH2SkNbZwUKZxb9cCJDS4XHRC+BVreD933+WuiIjb 6/CHJcazk5YvsQ8w3ohv78UeynTZlT5ewqefk/vImfgr46uGyffkYGy8qDTkzTjYNLCf V3nw== X-Gm-Message-State: APjAAAUTGKfUzdGd3p9RVbvB8iD6MZeNr4dEIH18gI0QUvBu3wFXjLRC 6YMWqow2clo522EO3FrxUmbAYR/YuoxfArjvBeM= X-Google-Smtp-Source: APXvYqxY5QULZjhltuzNTz+54w1Mjzw4C1Rm9es4a0oi30rhuY5rHUSVt/dvpV8J7KrBwr6ocM0TuA4Bsxbepxrnaj0= X-Received: by 2002:a2e:865a:: with SMTP id i26mr11848382ljj.236.1581611783533; Thu, 13 Feb 2020 08:36:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 13 Feb 2020 08:35:57 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000087b7b1059e77b079" Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 16:36:28 -0000 --00000000000087b7b1059e77b079 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2020 at 8:00 AM Justin Richer wrote: > I=E2=80=99ve been doing some implementation of OIDC session management la= tely, and > I had a realization that the pattern in TxAuth can give us a chance to do > something a lot better. > > In OIDC, you use the ID token as a secondary artifact to indicate which > client you are and which session you=E2=80=99re talking about. This is us= ed as a > drive-by client authentication (even though it=E2=80=99s really another b= earer > token sent through the front channel), which is what lets you do a > post-logout redirect in a somewhat safe manner. The ID token is also used > to carry session identifiers internally, Is carrying the session identifiers specified somewhere, or is this an implementation decision? > and so it gets replayed as an assertion to reference those identifiers > later on in the protocol. Basically, it=E2=80=99s building a lot of funct= ionality > on top of the ID token that it wasn=E2=80=99t really meant to bear. > > For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re = looking > to handle user interaction to begin with: > > - Client gets some kind of session management handle/identifier (and/or > URL, depending on which model we go with). > - When the user wants to log out, client can send that back to the AS in > the back channel, and get back an interaction mechanism that the client c= an > use to interact with the AS for determining if they want to kill the > session there as well. > - The AS can group together different clients into a =E2=80=9Csingle sign= out=E2=80=9D > cluster > - When the AS learns that the user wants to log out, it might be able to > push messages out to other clients =E2=80=94 maybe they register back cha= nnel > callback endpoints, or maybe a push message over http/2 or 3 or COAP, or > some other mechanism. But the client can push that information in the > initial request, and it can be user- and session- specific. > Mapping this to XAuth, a Client could update the Grant URI with a PUT to logout all sessions, and as you mention, the GS could respond with an interaction object for the Client to transfer interaction to the GS. Other Clients could regularly read the Grant URI, and the logged in status can be returned, or it could be a long lasting connection that returns a logged out response if the User is logged out somewhere else. > > These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me th= at with this new > pattern we=E2=80=99ve got a chance to make a much cleaner take on session= s than we > were able to do before. > Agreed. Neither is what I wrote above -- but with an established back channel from Client to GS, there are interesting things that can be done. > > To be clear, I=E2=80=99m not saying any of this belongs explicitly in the= charter, > or that this is something that we need to tackle right now, but I think > that addressing this eventually will make sense as part of the identity > work as we move forward. > Agreed > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000087b7b1059e77b079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 13, 2020 at 8:00 AM Justi= n Richer <jricher@m= it.edu> wrote:
I=E2=80=99ve been doing some implementation of OIDC session managemen= t lately, and I had a realization that the pattern in TxAuth can give us a = chance to do something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which cli= ent you are and which session you=E2=80=99re talking about. This is used as= a drive-by client authentication (even though it=E2=80=99s really another = bearer token sent through the front channel), which is what lets you do a p= ost-logout redirect in a somewhat safe manner. The ID token is also used to= carry session identifiers internally,

Is c= arrying the session identifiers specified somewhere, or is this an implemen= tation decision?
=C2=A0
and so it gets replayed as an assertion to reference those i= dentifiers later on in the protocol. Basically, it=E2=80=99s building a lot= of functionality on top of the ID token that it wasn=E2=80=99t really mean= t to bear.

For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re lo= oking to handle user interaction to begin with:

- Client gets some kind of session management handle/identifier (and/or URL= , depending on which model we go with).
- When the user wants to log out, client can send that back to the AS in th= e back channel, and get back an interaction mechanism that the client can u= se to interact with the AS for determining if they want to kill the session= there as well.
- The AS can group together different clients into a =E2=80=9Csingle sign o= ut=E2=80=9D cluster
- When the AS learns that the user wants to log out, it might be able to pu= sh messages out to other clients =E2=80=94 maybe they register back channel= callback endpoints, or maybe a push message over http/2 or 3 or COAP, or s= ome other mechanism. But the client can push that information in the initia= l request, and it can be user- and session- specific.

Mapping this to XAuth, a Client could update the Grant URI = with a PUT to logout all sessions, and as you mention, the GS could respond= with an interaction object for the Client to transfer interaction to the G= S.

Other Clients could regularly read the Grant UR= I, and the logged in status can be returned, or it could be a long lasting = connection that returns a logged out response if the User is logged out som= ewhere else.
=C2=A0

These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me that= with this new pattern we=E2=80=99ve got a chance to make a much cleaner ta= ke on sessions than we were able to do before.

Agreed. Neither is what I wrote above -- but with an established ba= ck channel from Client to GS, there are interesting things that can be done= .
=C2=A0

To be clear, I=E2=80=99m not saying any of this belongs explicitly in the c= harter, or that this is something that we need to tackle right now, but I t= hink that addressing this eventually will make sense as part of the identit= y work as we move forward.

--00000000000087b7b1059e77b079-- From nobody Thu Feb 13 08:54:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADE912011D for ; Thu, 13 Feb 2020 08:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 z8RIShkSd2KR for ; Thu, 13 Feb 2020 08:54:37 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 661E4120058 for ; Thu, 13 Feb 2020 08:54:37 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01DGsYxB015993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 11:54:35 -0500 From: Justin Richer Message-Id: <7A55D6F3-DBB3-4682-88A9-F828DD9E9664@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DB30BF31-AD0E-4C5C-A158-4B6DCA8FC1D8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 13 Feb 2020 11:54:34 -0500 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 16:54:40 -0000 --Apple-Mail=_DB30BF31-AD0E-4C5C-A158-4B6DCA8FC1D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would see the place for the session identifier to fit into the overall = protocol is something that we=E2=80=99d specify, but the nature of the = identifier itself would be opaque. In XYZ terms I=E2=80=99m seeing it as = a separate handle, since it=E2=80=99s an independent artifact that lets = the client control something.=20 What=E2=80=99s important is that it needs to be separate from the = transaction handle, which is tied more to the overall authorizations in = the transaction and not necessarily the log-in session. We have run into = many, many problems in the OIDC world because we=E2=80=99ve got a whole = cavalcade of different things that aren=E2=80=99t tied very well = together: - lifetime of the access token - lifetime of the refresh token - lifetime of the ID token - lifetime of access tokens gotten from a refresh token - session at the IdP - session at the RP - validity time of user=E2=80=99s grant decision policy (ie, = =E2=80=9Cremember this=E2=80=9D or =E2=80=9Cwhitelist this=E2=80=9D) Sessions are really difficult, as evidenced by nobody really knowing = what they mean when they say they want to log out. =E2=80=94 Justin > On Feb 13, 2020, at 11:35 AM, Dick Hardt wrote: >=20 >=20 >=20 > On Thu, Feb 13, 2020 at 8:00 AM Justin Richer > wrote: > I=E2=80=99ve been doing some implementation of OIDC session management = lately, and I had a realization that the pattern in TxAuth can give us a = chance to do something a lot better. >=20 > In OIDC, you use the ID token as a secondary artifact to indicate = which client you are and which session you=E2=80=99re talking about. = This is used as a drive-by client authentication (even though it=E2=80=99s= really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers internally, >=20 > Is carrying the session identifiers specified somewhere, or is this an = implementation decision? > =20 > and so it gets replayed as an assertion to reference those identifiers = later on in the protocol. Basically, it=E2=80=99s building a lot of = functionality on top of the ID token that it wasn=E2=80=99t really meant = to bear.=20 >=20 > For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re= looking to handle user interaction to begin with: >=20 > - Client gets some kind of session management handle/identifier = (and/or URL, depending on which model we go with).=20 > - When the user wants to log out, client can send that back to the AS = in the back channel, and get back an interaction mechanism that the = client can use to interact with the AS for determining if they want to = kill the session there as well.=20 > - The AS can group together different clients into a =E2=80=9Csingle = sign out=E2=80=9D cluster=20 > - When the AS learns that the user wants to log out, it might be able = to push messages out to other clients =E2=80=94 maybe they register back = channel callback endpoints, or maybe a push message over http/2 or 3 or = COAP, or some other mechanism. But the client can push that information = in the initial request, and it can be user- and session- specific.=20 >=20 > Mapping this to XAuth, a Client could update the Grant URI with a PUT = to logout all sessions, and as you mention, the GS could respond with an = interaction object for the Client to transfer interaction to the GS. >=20 > Other Clients could regularly read the Grant URI, and the logged in = status can be returned, or it could be a long lasting connection that = returns a logged out response if the User is logged out somewhere else. > =20 >=20 > These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me = that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before. >=20 > Agreed. Neither is what I wrote above -- but with an established back = channel from Client to GS, there are interesting things that can be = done. > =20 >=20 > To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.=20 >=20 > Agreed > =20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_DB30BF31-AD0E-4C5C-A158-4B6DCA8FC1D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would see the place for the session identifier to fit into the overall = protocol is something that we=E2=80=99d specify, but the nature of the = identifier itself would be opaque. In XYZ terms I=E2=80=99m seeing it as = a separate handle, since it=E2=80=99s an independent artifact that lets = the client control something. 

What=E2=80=99s important is that it = needs to be separate from the transaction handle, which is tied more to = the overall authorizations in the transaction and not necessarily the = log-in session. We have run into many, many problems in the OIDC world = because we=E2=80=99ve got a whole cavalcade of different things that = aren=E2=80=99t tied very well together:

 - lifetime of the access = token
 - lifetime of the refresh = token
 - lifetime of the ID token
 - lifetime of access tokens gotten from a refresh = token
 - session at the IdP
 - session at the RP
 - = validity time of user=E2=80=99s grant decision policy (ie, =E2=80=9Crememb= er this=E2=80=9D or =E2=80=9Cwhitelist this=E2=80=9D)

Sessions are really = difficult, as evidenced by nobody really knowing what they mean when = they say they want to log out.

 =E2=80=94 Justin

On Feb 13, 2020, at 11:35 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Feb 13, 2020 at 8:00 AM Justin = Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been doing some = implementation of OIDC session management lately, and I had a = realization that the pattern in TxAuth can give us a chance to do = something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which = client you are and which session you=E2=80=99re talking about. This is = used as a drive-by client authentication (even though it=E2=80=99s = really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers = internally,

Is carrying the session identifiers specified somewhere, or = is this an implementation decision?
 
and so it gets replayed as an = assertion to reference those identifiers later on in the protocol. = Basically, it=E2=80=99s building a lot of functionality on top of the ID = token that it wasn=E2=80=99t really meant to bear.

For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re = looking to handle user interaction to begin with:

- Client gets some kind of session management handle/identifier (and/or = URL, depending on which model we go with).
- When the user wants to log out, client can send that back to the AS in = the back channel, and get back an interaction mechanism that the client = can use to interact with the AS for determining if they want to kill the = session there as well.
- The AS can group together different clients into a =E2=80=9Csingle = sign out=E2=80=9D cluster
- When the AS learns that the user wants to log out, it might be able to = push messages out to other clients =E2=80=94 maybe they register back = channel callback endpoints, or maybe a push message over http/2 or 3 or = COAP, or some other mechanism. But the client can push that information = in the initial request, and it can be user- and session- specific.

Mapping this to XAuth, a Client could update the Grant URI = with a PUT to logout all sessions, and as you mention, the GS could = respond with an interaction object for the Client to transfer = interaction to the GS.

Other Clients could regularly read the Grant URI, and the = logged in status can be returned, or it could be a long lasting = connection that returns a logged out response if the User is logged out = somewhere else.
 

These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me = that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before.

Agreed. Neither is what I wrote above -- but with an = established back channel from Client to GS, there are interesting things = that can be done.
 

To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.

Agreed
 

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_DB30BF31-AD0E-4C5C-A158-4B6DCA8FC1D8-- From nobody Thu Feb 13 09:15:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F951200C4 for ; Thu, 13 Feb 2020 09:15:05 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRxnNj4JqXY8 for ; Thu, 13 Feb 2020 09:15:03 -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 0719A120058 for ; Thu, 13 Feb 2020 09:15:03 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id n18so7489698ljo.7 for ; Thu, 13 Feb 2020 09:15:02 -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=No6Pw4ZlXLAAaVCw7/7lBC7bF+2TWcySWraiQPMOQzg=; b=noQUMpbcbKn0lw6OARiklyySShT2WIJwGqOXP6EmVDlqZCKdkGISjyXDM5idYCI5Cl Xf/C6Gr7/fMzWI6zlA4aWYO13euadAoZ+F+iZV5Ch/PePVarCrylcTu5U7qNmvlOdmLd qxqKVbzheOGNexiQkZz/Bg66/NgWo5jzU5QwJl9SQEXP5/AFh84bHU5vhnhXsAbXHQe2 FLl+OiU6NmaNY4+vJaRel/iyyE+FpcE5zqAyRqrYZ7Af28cKY/YKh6k9QTUB0iQO1IdH RqhUDso/tJNE+dFYTVjwrUpfOLGi7c+lCAITg/z+IgZdOSJkoDQfMYLx5ddIMa1ymgwW Vp2Q== 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=No6Pw4ZlXLAAaVCw7/7lBC7bF+2TWcySWraiQPMOQzg=; b=VEAWW6OjDIDodD91bY7gwPJog2l047Y5ntbqM/5FPusLWt9kWBHQ8Ll1+NW6NXJ+ce GWtaWX3QQr4aCS204zHU8jJVW+yPMRQ/gQCg7G0zFxOZRxZ8Sx/wdgJCk0femtn8o6Tu i2vRRX8GPJdCHPYEjGPUrNQsZ67GKg3R/8JZsCejLPcU4AfgECAuzYSpYxbjjtcOQpXP JytZCU6LxbatnKqm2OOVRv8QVH3UaS+nrxnWZMqorpu8TT7A89bn59cURsXMWyo4Dc+w FzeIvDDGX4v4/NS1+1MThZDqWm5VKKo06lCoX6552NjfDKVi2SrimE44lSCpereE06n9 8S3A== X-Gm-Message-State: APjAAAUYo+bFmAuHqsFNVATQu3mqPg6//LeIoxY3F3117rYFsAMqbQLf KSKguw/FWRDXAkjbHELv2gl1b0+bCelA9dCiA4w= X-Google-Smtp-Source: APXvYqyxq69WX2KvScTa+nApYIOW7sV6X25By3INEnb/5fn8OIs5Up0uga47MZsbMXVbftzXw07W614wA2JFFfBq1fQ= X-Received: by 2002:a2e:730e:: with SMTP id o14mr11881055ljc.51.1581614101055; Thu, 13 Feb 2020 09:15:01 -0800 (PST) MIME-Version: 1.0 References: <7A55D6F3-DBB3-4682-88A9-F828DD9E9664@mit.edu> In-Reply-To: <7A55D6F3-DBB3-4682-88A9-F828DD9E9664@mit.edu> From: Dick Hardt Date: Thu, 13 Feb 2020 09:14:34 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa4d23059e783adf" Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 17:15:05 -0000 --000000000000aa4d23059e783adf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Interesting! That leads me to think that a Session might be yet a another object of the Grant Request (using XAuth terms), that returns a Session URI that provides for Session operations (CRUD) independent of the Grant request. The Session operations could include updates for continuous authentication such as CAEP. =E1=90=A7 On Thu, Feb 13, 2020 at 8:54 AM Justin Richer wrote: > I would see the place for the session identifier to fit into the overall > protocol is something that we=E2=80=99d specify, but the nature of the id= entifier > itself would be opaque. In XYZ terms I=E2=80=99m seeing it as a separate = handle, > since it=E2=80=99s an independent artifact that lets the client control s= omething. > > What=E2=80=99s important is that it needs to be separate from the transac= tion > handle, which is tied more to the overall authorizations in the transacti= on > and not necessarily the log-in session. We have run into many, many > problems in the OIDC world because we=E2=80=99ve got a whole cavalcade of= different > things that aren=E2=80=99t tied very well together: > > - lifetime of the access token > - lifetime of the refresh token > - lifetime of the ID token > - lifetime of access tokens gotten from a refresh token > - session at the IdP > - session at the RP > - validity time of user=E2=80=99s grant decision policy (ie, =E2=80=9Cre= member this=E2=80=9D or > =E2=80=9Cwhitelist this=E2=80=9D) > > Sessions are really difficult, as evidenced by nobody really knowing what > they mean when they say they want to log out. > > =E2=80=94 Justin > > On Feb 13, 2020, at 11:35 AM, Dick Hardt wrote: > > > > On Thu, Feb 13, 2020 at 8:00 AM Justin Richer wrote: > >> I=E2=80=99ve been doing some implementation of OIDC session management l= ately, >> and I had a realization that the pattern in TxAuth can give us a chance = to >> do something a lot better. >> >> In OIDC, you use the ID token as a secondary artifact to indicate which >> client you are and which session you=E2=80=99re talking about. This is u= sed as a >> drive-by client authentication (even though it=E2=80=99s really another = bearer >> token sent through the front channel), which is what lets you do a >> post-logout redirect in a somewhat safe manner. The ID token is also use= d >> to carry session identifiers internally, > > > Is carrying the session identifiers specified somewhere, or is this an > implementation decision? > > >> and so it gets replayed as an assertion to reference those identifiers >> later on in the protocol. Basically, it=E2=80=99s building a lot of func= tionality >> on top of the ID token that it wasn=E2=80=99t really meant to bear. >> >> For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re= looking >> to handle user interaction to begin with: >> >> - Client gets some kind of session management handle/identifier (and/or >> URL, depending on which model we go with). >> - When the user wants to log out, client can send that back to the AS in >> the back channel, and get back an interaction mechanism that the client = can >> use to interact with the AS for determining if they want to kill the >> session there as well. >> - The AS can group together different clients into a =E2=80=9Csingle sig= n out=E2=80=9D >> cluster >> - When the AS learns that the user wants to log out, it might be able to >> push messages out to other clients =E2=80=94 maybe they register back ch= annel >> callback endpoints, or maybe a push message over http/2 or 3 or COAP, or >> some other mechanism. But the client can push that information in the >> initial request, and it can be user- and session- specific. >> > > Mapping this to XAuth, a Client could update the Grant URI with a PUT to > logout all sessions, and as you mention, the GS could respond with an > interaction object for the Client to transfer interaction to the GS. > > Other Clients could regularly read the Grant URI, and the logged in statu= s > can be returned, or it could be a long lasting connection that returns a > logged out response if the User is logged out somewhere else. > > >> >> These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me t= hat with this new >> pattern we=E2=80=99ve got a chance to make a much cleaner take on sessio= ns than we >> were able to do before. >> > > Agreed. Neither is what I wrote above -- but with an established back > channel from Client to GS, there are interesting things that can be done. > > >> >> To be clear, I=E2=80=99m not saying any of this belongs explicitly in th= e >> charter, or that this is something that we need to tackle right now, but= I >> think that addressing this eventually will make sense as part of the >> identity work as we move forward. >> > > Agreed > > >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --000000000000aa4d23059e783adf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting!

That leads me to think tha= t a Session might be yet a another object of the Grant Request (using XAuth= terms), that returns a Session URI that provides for Session operations (C= RUD) independent of the Grant request.

The Session= operations could include updates for continuous authentication such as CAE= P.
3D""=E1=90=A7

On Thu, Feb 13, 2020 at 8:54 AM Jus= tin Richer <jricher@mit.edu> w= rote:
I would see the place for the session ident= ifier to fit into the overall protocol is something that we=E2=80=99d speci= fy, but the nature of the identifier itself would be opaque. In XYZ terms I= =E2=80=99m seeing it as a separate handle, since it=E2=80=99s an independen= t artifact that lets the client control something.=C2=A0

What=E2=80=99s important is that it needs to be separate from the transact= ion handle, which is tied more to the overall authorizations in the transac= tion and not necessarily the log-in session. We have run into many, many pr= oblems in the OIDC world because we=E2=80=99ve got a whole cavalcade of dif= ferent things that aren=E2=80=99t tied very well together:

=C2=A0- lifetime of the access token
=C2=A0- lifetime of= the refresh token
=C2=A0- lifetime of the ID token
=C2= =A0- lifetime of access tokens gotten from a refresh token
=C2=A0= - session at the IdP
=C2=A0- session at the RP
=C2=A0- = validity time of user=E2=80=99s grant decision policy (ie, =E2=80=9Cremembe= r this=E2=80=9D or =E2=80=9Cwhitelist this=E2=80=9D)

Sessions are really difficult, as evidenced by nobody really knowing what = they mean when they say they want to log out.

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

On Feb 13, 2= 020, at 11:35 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Feb 13, 2020 at 8:00 AM Justin Richer= <jricher@mit.edu> wrote:
I= =E2=80=99ve been doing some implementation of OIDC session management latel= y, and I had a realization that the pattern in TxAuth can give us a chance = to do something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which cli= ent you are and which session you=E2=80=99re talking about. This is used as= a drive-by client authentication (even though it=E2=80=99s really another = bearer token sent through the front channel), which is what lets you do a p= ost-logout redirect in a somewhat safe manner. The ID token is also used to= carry session identifiers internally,

and so it gets replayed as an assertion to reference those i= dentifiers later on in the protocol. Basically, it=E2=80=99s building a lot= of functionality on top of the ID token that it wasn=E2=80=99t really mean= t to bear.

For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re lo= oking to handle user interaction to begin with:

- Client gets some kind of session management handle/identifier (and/or URL= , depending on which model we go with).
- When the user wants to log out, client can send that back to the AS in th= e back channel, and get back an interaction mechanism that the client can u= se to interact with the AS for determining if they want to kill the session= there as well.
- The AS can group together different clients into a =E2=80=9Csingle sign o= ut=E2=80=9D cluster
- When the AS learns that the user wants to log out, it might be able to pu= sh messages out to other clients =E2=80=94 maybe they register back channel= callback endpoints, or maybe a push message over http/2 or 3 or COAP, or s= ome other mechanism. But the client can push that information in the initia= l request, and it can be user- and session- specific.



These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me that= with this new pattern we=E2=80=99ve got a chance to make a much cleaner ta= ke on sessions than we were able to do before.

--000000000000aa4d23059e783adf-- From nobody Thu Feb 13 09:56:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE62D12012C for ; Thu, 13 Feb 2020 09:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 yyxsi-257zyW for ; Thu, 13 Feb 2020 09:56:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 205BF1200C3 for ; Thu, 13 Feb 2020 09:56:04 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01DHu274007431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 12:56:02 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_220A349F-0512-4638-9172-F31B6BB2FD18" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 13 Feb 2020 12:56:02 -0500 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <7A55D6F3-DBB3-4682-88A9-F828DD9E9664@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 17:56:08 -0000 --Apple-Mail=_220A349F-0512-4638-9172-F31B6BB2FD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That tracks, since XAuth=E2=80=99s =E2=80=9Cobjects=E2=80=9D are in many = ways analogous to XYZ=E2=80=99s =E2=80=9Chandle=E2=80=9D structures, and = what they represent.=20 I think it=E2=80=99s separate from the tx/grant but they should be = managed using parallel mechanisms to each other. That was the lightbulb = that I had here.=20 Plus the fact that the AS can tie together sessions from different = clients, even doing smart seamless logins when it knows the user is = present on another client right now. XYZ would manage that using user = handles, probably. But again, none of this is particularly well baked, but I am encouraged = at the possibility of simplifying our approach to such a complex issue = by taking a different view of it than we had in the past.=20 =E2=80=94 Justin > On Feb 13, 2020, at 12:14 PM, Dick Hardt wrote: >=20 > Interesting! >=20 > That leads me to think that a Session might be yet a another object of = the Grant Request (using XAuth terms), that returns a Session URI that = provides for Session operations (CRUD) independent of the Grant request. >=20 > The Session operations could include updates for continuous = authentication such as CAEP. > =E1=90=A7 >=20 > On Thu, Feb 13, 2020 at 8:54 AM Justin Richer > wrote: > I would see the place for the session identifier to fit into the = overall protocol is something that we=E2=80=99d specify, but the nature = of the identifier itself would be opaque. In XYZ terms I=E2=80=99m = seeing it as a separate handle, since it=E2=80=99s an independent = artifact that lets the client control something.=20 >=20 > What=E2=80=99s important is that it needs to be separate from the = transaction handle, which is tied more to the overall authorizations in = the transaction and not necessarily the log-in session. We have run into = many, many problems in the OIDC world because we=E2=80=99ve got a whole = cavalcade of different things that aren=E2=80=99t tied very well = together: >=20 > - lifetime of the access token > - lifetime of the refresh token > - lifetime of the ID token > - lifetime of access tokens gotten from a refresh token > - session at the IdP > - session at the RP > - validity time of user=E2=80=99s grant decision policy (ie, = =E2=80=9Cremember this=E2=80=9D or =E2=80=9Cwhitelist this=E2=80=9D) >=20 > Sessions are really difficult, as evidenced by nobody really knowing = what they mean when they say they want to log out. >=20 > =E2=80=94 Justin >=20 >> On Feb 13, 2020, at 11:35 AM, Dick Hardt > wrote: >>=20 >>=20 >>=20 >> On Thu, Feb 13, 2020 at 8:00 AM Justin Richer > wrote: >> I=E2=80=99ve been doing some implementation of OIDC session = management lately, and I had a realization that the pattern in TxAuth = can give us a chance to do something a lot better. >>=20 >> In OIDC, you use the ID token as a secondary artifact to indicate = which client you are and which session you=E2=80=99re talking about. = This is used as a drive-by client authentication (even though it=E2=80=99s= really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers internally, >>=20 >> Is carrying the session identifiers specified somewhere, or is this = an implementation decision? >> =20 >> and so it gets replayed as an assertion to reference those = identifiers later on in the protocol. Basically, it=E2=80=99s building a = lot of functionality on top of the ID token that it wasn=E2=80=99t = really meant to bear.=20 >>=20 >> For TxAuth, I think we can follow a pattern similar to how we=E2=80=99r= e looking to handle user interaction to begin with: >>=20 >> - Client gets some kind of session management handle/identifier = (and/or URL, depending on which model we go with).=20 >> - When the user wants to log out, client can send that back to the AS = in the back channel, and get back an interaction mechanism that the = client can use to interact with the AS for determining if they want to = kill the session there as well.=20 >> - The AS can group together different clients into a =E2=80=9Csingle = sign out=E2=80=9D cluster=20 >> - When the AS learns that the user wants to log out, it might be able = to push messages out to other clients =E2=80=94 maybe they register back = channel callback endpoints, or maybe a push message over http/2 or 3 or = COAP, or some other mechanism. But the client can push that information = in the initial request, and it can be user- and session- specific.=20 >>=20 >> Mapping this to XAuth, a Client could update the Grant URI with a PUT = to logout all sessions, and as you mention, the GS could respond with an = interaction object for the Client to transfer interaction to the GS. >>=20 >> Other Clients could regularly read the Grant URI, and the logged in = status can be returned, or it could be a long lasting connection that = returns a logged out response if the User is logged out somewhere else. >> =20 >>=20 >> These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to = me that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before. >>=20 >> Agreed. Neither is what I wrote above -- but with an established back = channel from Client to GS, there are interesting things that can be = done. >> =20 >>=20 >> To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.=20 >>=20 >> Agreed >> =20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_220A349F-0512-4638-9172-F31B6BB2FD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = tracks, since XAuth=E2=80=99s =E2=80=9Cobjects=E2=80=9D are in many ways = analogous to XYZ=E2=80=99s =E2=80=9Chandle=E2=80=9D structures, and what = they represent. 

I think it=E2=80=99s separate from the tx/grant but they = should be managed using parallel mechanisms to each other. That was the = lightbulb that I had here. 

Plus the fact that the AS can tie = together sessions from different clients, even doing smart seamless = logins when it knows the user is present on another client right now. = XYZ would manage that using user handles, probably.

But again, none of this = is particularly well baked, but I am encouraged at the possibility of = simplifying our approach to such a complex issue by taking a different = view of it than we had in the past. 

 =E2=80=94 Justin

On Feb 13, 2020, at 12:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Interesting!

That leads me to think that a Session = might be yet a another object of the Grant Request (using XAuth terms), = that returns a Session URI that provides for Session operations (CRUD) = independent of the Grant request.

The Session operations could include = updates for continuous authentication such as CAEP.
3D""=E1=90=A7

On Thu, Feb = 13, 2020 at 8:54 AM Justin Richer <jricher@mit.edu> wrote:
I would see the place for the session identifier = to fit into the overall protocol is something that we=E2=80=99d specify, = but the nature of the identifier itself would be opaque. In XYZ terms = I=E2=80=99m seeing it as a separate handle, since it=E2=80=99s an = independent artifact that lets the client control something. 

What=E2=80=99s important = is that it needs to be separate from the transaction handle, which is = tied more to the overall authorizations in the transaction and not = necessarily the log-in session. We have run into many, many problems in = the OIDC world because we=E2=80=99ve got a whole cavalcade of different = things that aren=E2=80=99t tied very well together:

 - lifetime of the = access token
 - lifetime of the refresh = token
 - lifetime of the ID token
 - lifetime of access tokens gotten from a refresh = token
 - session at the IdP
 - session at the RP
 - = validity time of user=E2=80=99s grant decision policy (ie, =E2=80=9Crememb= er this=E2=80=9D or =E2=80=9Cwhitelist this=E2=80=9D)

Sessions are really = difficult, as evidenced by nobody really knowing what they mean when = they say they want to log out.

 =E2=80=94 Justin

On Feb 13, 2020, at 11:35 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Feb 13, 2020 at 8:00 AM Justin = Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been doing some = implementation of OIDC session management lately, and I had a = realization that the pattern in TxAuth can give us a chance to do = something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which = client you are and which session you=E2=80=99re talking about. This is = used as a drive-by client authentication (even though it=E2=80=99s = really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers = internally,

Is carrying the session identifiers specified somewhere, or = is this an implementation decision?
 
and so it gets replayed as an = assertion to reference those identifiers later on in the protocol. = Basically, it=E2=80=99s building a lot of functionality on top of the ID = token that it wasn=E2=80=99t really meant to bear.

For TxAuth, I think we can follow a pattern similar to how we=E2=80=99re = looking to handle user interaction to begin with:

- Client gets some kind of session management handle/identifier (and/or = URL, depending on which model we go with).
- When the user wants to log out, client can send that back to the AS in = the back channel, and get back an interaction mechanism that the client = can use to interact with the AS for determining if they want to kill the = session there as well.
- The AS can group together different clients into a =E2=80=9Csingle = sign out=E2=80=9D cluster
- When the AS learns that the user wants to log out, it might be able to = push messages out to other clients =E2=80=94 maybe they register back = channel callback endpoints, or maybe a push message over http/2 or 3 or = COAP, or some other mechanism. But the client can push that information = in the initial request, and it can be user- and session- specific.

Mapping this to XAuth, a Client could update the Grant URI = with a PUT to logout all sessions, and as you mention, the GS could = respond with an interaction object for the Client to transfer = interaction to the GS.

Other Clients could regularly read the Grant URI, and the = logged in status can be returned, or it could be a long lasting = connection that returns a logged out response if the User is logged out = somewhere else.
 

These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me = that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before.

Agreed. Neither is what I wrote above -- but with an = established back channel from Client to GS, there are interesting things = that can be done.
 

To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.

Agreed
 

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


= --Apple-Mail=_220A349F-0512-4638-9172-F31B6BB2FD18-- From nobody Thu Feb 13 11:19:36 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E821201CE; Thu, 13 Feb 2020 11:19:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, txauth-chairs@ietf.org, avezza@amsl.com, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158162157372.20597.9461266090501654469.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2020 11:19:33 -0800 Archived-At: Subject: [Txauth] txauth - New Meeting Session Request for IETF 107 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 19:19:34 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the txauth working group. --------------------------------------------------------- Working Group Name: Transactional Authorization and Delegation Area Name: Security Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: oauth saag secdispatch httpbis uta cose ace acme calext curdle detnet dots emu i2nsf ipsecme kitten lake lamps mile mls rats sacm secevent suit teep tls tokbind trans People who must be present: Yaron Sheffer Roman Danyliw Dick Hardt Resources Requested: Special Requests: They would prefer 2.5 hours according to the wiki. --------------------------------------------------------- From nobody Thu Feb 13 11:34:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B55120823 for ; Thu, 13 Feb 2020 11:34:52 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egUCG97mbILu for ; Thu, 13 Feb 2020 11:34:51 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 D7EBA120824 for ; Thu, 13 Feb 2020 11:34:50 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 01DJYnHG003992 for ; Thu, 13 Feb 2020 14:34:49 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 01DJYnHG003992 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1581622489; bh=YUMuhXN2EL+eRjd8cmYrvkut2xou5zOvr9LESJaMy0k=; h=From:To:Subject:Date:References:In-Reply-To:From; b=ciQ7hmJv0vLINBoV5exCeImz8LA6ftsMME6PCzaS/9Nz/HNRtVMlO0RmNHyKU9QNM TapyVEtk/4HHOTzUDBkoPIgFAaVXO4PBicqd5VBFA8SbwLsfAeWqXUTau2iSRF3dpl uDt2agX9G7GMi/CbGwt13tghXDVJrCYb0+TQ/Xjc= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 01DJYl5T046188 for ; Thu, 13 Feb 2020 14:34:47 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Thu, 13 Feb 2020 14:34:47 -0500 From: Roman Danyliw To: "txauth@ietf.org" Thread-Topic: [Txauth] txauth - New Meeting Session Request for IETF 107 Thread-Index: AQHV4qKKC/GVOb0LtUCVI43GYYZFd6gZg6Lg Date: Thu, 13 Feb 2020 19:34:46 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216F35252@marchand> References: <158162157372.20597.9461266090501654469.idtracker@ietfa.amsl.com> In-Reply-To: <158162157372.20597.9461266090501654469.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Txauth] FW: txauth - New Meeting Session Request for IETF 107 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 19:34:57 -0000 Hi! This announcement practically means that the TxAuth BoF has been approved f= or IETF 107. Regards, Roman -----Original Message----- From: Txauth On Behalf Of IETF Meeting Session Re= quest Tool Sent: Thursday, February 13, 2020 2:20 PM To: session-request@ietf.org Cc: Roman Danyliw ; txauth-chairs@ietf.org; avezza@amsl.com; = txauth@ietf.org Subject: [Txauth] txauth - New Meeting Session Request for IETF 107 A new meeting session request has just been submitted by Amy K. Vezza, on b= ehalf of the txauth working group. --------------------------------------------------------- Working Group Name: Transactional Authorization and Delegation Area Name: S= ecurity Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid:=20 Technology Overlap: oauth saag secdispatch httpbis uta cose ace acme cale= xt curdle detnet dots emu i2nsf ipsecme kitten lake lamps mile mls rats sac= m secevent suit teep tls tokbind trans People who must be present: Yaron Sheffer Roman Danyliw Dick Hardt Resources Requested: Special Requests: They would prefer 2.5 hours according to the wiki.=20 --------------------------------------------------------- -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Feb 13 12:27:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678B1120219 for ; Thu, 13 Feb 2020 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JEkHexOW3oCd for ; Thu, 13 Feb 2020 12:27:43 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450: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 F0F661201CE for ; Thu, 13 Feb 2020 12:27:42 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id z26so5174940lfg.13 for ; Thu, 13 Feb 2020 12:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GWo9l8Hdw098YCi7lSltGSFt1QeyJn/eJ0S6SNr2e4c=; b=FolksBXFvbbUUTDs62Ju3+b/7o81msDHzlU7lnKDCExrBKgl2Y6VQOKYrdQfNqX7du wLcCryswY2p3qqEhfgNUcPyeKsqMubYmd6oRZPMye2QKsBQHnXMqFo5SLEcF+M6iVhqy 9h0pTBtbvecJix7m3jVgg18sG3GME+ObNV7h5c6um1mVibi0NnApTL0pNYnup0koxVBW FBp1rO37RqZ2ypkzxnkcOlBAfmfOpGM4xr4S5cZUcUPB6Va0hAbN8ULmkqXFJX8LBJJB DeC4jN5B2BVgUM4s5jA1fWRNxxDQsDZB+TmSsGkWqRRt/z+xbr5EiPWbMLTX9jJjLRfd C4+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=GWo9l8Hdw098YCi7lSltGSFt1QeyJn/eJ0S6SNr2e4c=; b=Jw9jXB8+E3SJmZwGXoQPZ1BeHWNYgNa8tGRxyiYVx/EsN6wXAo59GtjGjMIQyYE1WS P88nOiDyRDiUcq6tY3GoXqtHn22f6+HP5T1A9IJRxfuNM5u/zCxp7BBpUmc+xY1fu131 ullhfBFDGiff6XTYPYJZoUKrDoyvO6O1lUyh+exzxFgDH2uAfhEN2t62jkUa1EsCJV22 r7TCgrwMu7KIRCPJ7E1euh6FbVAMW/cAWphUaL+3lKcKonxsesswy39+/27r/qC73XFD e7h4fXqyBgyqWJJPWRTaJbjdgIJtBJb7MK6PyixKDKSVwyOtaM53LW9B323lscPrOdhm Iqaw== X-Gm-Message-State: APjAAAWTIxS/EgVUidW504FC6Bo01bHRqlBLWe6narIZQkWG6kfByyb4 rJh1up+4nK8S9x4zcXixuOm0FpAdZTLbmQYYlRVk3VejGPLXPI/YfprQUEpJ2rO+AjuRVpthwUh AGJO9UMPdOyBZUJ0= X-Google-Smtp-Source: APXvYqxXznKAeIzBjsF7gALDNQMlpf6vcR+VMfqGmtY8R/E++rZKXc5Aq7Nh8XhRw31O3QeDrnrKcZ5mfLxsm6bWIls= X-Received: by 2002:a19:9159:: with SMTP id y25mr10617424lfj.63.1581625661060; Thu, 13 Feb 2020 12:27:41 -0800 (PST) MIME-Version: 1.0 References: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> In-Reply-To: From: Brian Campbell Date: Thu, 13 Feb 2020 13:27:14 -0700 Message-ID: To: Dick Hardt Cc: David , "Richard Backman, Annabelle" , Lee McGovern , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b210bf059e7aebe7" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 20:27:46 -0000 --000000000000b210bf059e7aebe7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW that's not an RFC. It's an expired individual internet draft. That may seem like a pedantic distinction but this other expired individual internet draft https://tools.ietf.org/html/draft-abr-twitter-reply-00 is a nice exemplification of why the distinction is important. On Thu, Feb 13, 2020 at 8:01 AM Dick Hardt wrote: > > (David: it is an expired RFC, > https://tools.ietf.org/html/draft-paragon-paseto-rfc-00 > ) > > --=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._ --000000000000b210bf059e7aebe7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW that's not an RFC. It's an expired indiv= idual internet draft.

That may seem like a pe= dantic distinction but this other expired individual internet draft https://tools.i= etf.org/html/draft-abr-twitter-reply-00 is a nice exemplification of wh= y the distinction is important.

On Thu, Feb 13, 2020 at 8:01 AM Dick Ha= rdt <dick.hardt@gmail.com>= ; wrote:

<= 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. --000000000000b210bf059e7aebe7-- From nobody Thu Feb 13 12:30:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D197C1200EC for ; Thu, 13 Feb 2020 12:30: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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECKc_1Rn9mL6 for ; Thu, 13 Feb 2020 12:30:05 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 8B397120013 for ; Thu, 13 Feb 2020 12:30:05 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id m30so5199430lfp.8 for ; Thu, 13 Feb 2020 12:30:05 -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=FEm30u57sU1yUTyVi0BPFFkJcfdcFEzn7iYwa4HmzTg=; b=ENMUyM0lyI6XEg62toJAHeSUN9tvGlA+PkqEkoMBcUeDJdAfX/2F0y/Bd6cP9SdkQH ctkCrNc/3b4tydPJTJ991z7nwF+SJjZt5fyq+G4jnfEQcgdUTytndRIAQ5QHLayEchAn bS4GnDsx5fIm+bqS7BOYx+MCoZA8ePCfkCDpGFftipVa5mz13jML9xKX4RJcCn6QJ/rz IRVJI8oWJApfAdsnqp2x5aPrB2StHSjqWtJcqrQcqNnjGsS8MM+J1fJEw771JFKu8V3K WgDkAztVLONajI+RaVbvC8E46r5Q58r1PNEBASXUYVb0gFvo5DtumvAzkjjmHQTaYdcx 44UA== 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=FEm30u57sU1yUTyVi0BPFFkJcfdcFEzn7iYwa4HmzTg=; b=IG9N3uVZ4ylRi8WbIjjoYny+1zArO4sDzn1cosrpX1m7nvAPCk4/JVCrQ9g/RrwEG4 HSjErFWakZyNKTrrMpgLO9X8rhhaVzLQTEd1PAw89mWgCIOc4AhO8Js0jLbA9u3Xm1FM qC2eUfUMQYgzKIAyjR1W5vzEXv4krr/JNy9Rl2hCAcoYKXp2Z6fHozor4NI07ObSWvxl oRfKcYR3oY0tSiwiHyWb93CeIJIRCKhYGnWoizIhUsSApo3A5H+wYoisWNZnx6RXZbWo ec0FthN9IGJ9mo/EarviZCXhhMU4jTwCsYM1tkDPBLX2DamRszi9QoL97hNVbDCLtS8K RdUw== X-Gm-Message-State: APjAAAU234r7n+U8JGmsxDcuMpyOhm/VpNonOQNzMr/KueZFl3dzLlZ0 RHdHvi0moYjXdtAUc8enGiX6NtuUVSVZvwWsocY= X-Google-Smtp-Source: APXvYqxmYYgxA/WNn7/OSCu5lPJlQgYGLF1tT6BnUWsjvkzskWN2un482tLn3wJl78oMH7/rSxYSxqFQFE87k/G6/nI= X-Received: by 2002:a05:6512:4c6:: with SMTP id w6mr10192984lfq.157.1581625803651; Thu, 13 Feb 2020 12:30:03 -0800 (PST) MIME-Version: 1.0 References: <83d2e96f06e94a9d86d5e459dfa3584f@CHRP5009.corp.gwpnet.com> In-Reply-To: From: Dick Hardt Date: Thu, 13 Feb 2020 12:29:52 -0800 Message-ID: To: Brian Campbell Cc: David , Lee McGovern , "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000031c1f7059e7af4f9" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 20:30:08 -0000 --00000000000031c1f7059e7af4f9 Content-Type: text/plain; charset="UTF-8" Thanks for clarifying .. they are quite different ... I was careless in my language. On Thu, Feb 13, 2020 at 12:27 PM Brian Campbell wrote: > FWIW that's not an RFC. It's an expired individual internet draft. > > That may seem like a pedantic distinction but this other expired > individual internet draft > https://tools.ietf.org/html/draft-abr-twitter-reply-00 is a nice > exemplification of why the distinction is important. > > On Thu, Feb 13, 2020 at 8:01 AM Dick Hardt wrote: > >> >> (David: it is an expired RFC, >> https://tools.ietf.org/html/draft-paragon-paseto-rfc-00 >> ) >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended 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.* --00000000000031c1f7059e7af4f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for clarifying .. they are quite different ..= . I was careless in my language.

On Thu, Feb 13, 2020 at 12:27 PM= Brian Campbell <bcampbell= @pingidentity.com> wrote:
FWIW that's not an RFC. It's an expired individ= ual internet draft.

That may seem like a peda= ntic distinction but this other expired individual internet draft https://tools.ietf.org/html/draft-abr-twitter-reply-00 is a nice exe= mplification of why the distinction is important.

On Thu, Feb 13, 2020= at 8:01 AM Dick Hardt <dick.hardt@gmail.com> wrote:



<= 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.
--00000000000031c1f7059e7af4f9-- From nobody Thu Feb 13 18:08:55 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB27D120019 for ; Thu, 13 Feb 2020 18:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.798 X-Spam-Level: X-Spam-Status: No, score=-11.798 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 3v1Dhq8wHbuN for ; Thu, 13 Feb 2020 18:08:51 -0800 (PST) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 77A8F12001A for ; Thu, 13 Feb 2020 18:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1581646130; x=1613182130; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ix0FkO/eYyFY9sdMCxeWLJFJHxXEyX4MRe1T6Luhn84=; b=BZ93rbCVkOuSMemSv5JY644twklOZedsgkW2+sbFPjke6/iUiglzVa55 LTRY9zBk9u3M/hJewf2EeA2CtuX+DVj9TGzRZjVrAMSfSAdD0dy66RPTa Y6PRPFjeHs5TwoHDeXsVNPrMR5LiBfM7mTXyhCE63JeIRAZiNwjzfNQzu I=; IronPort-SDR: 63a6WQPpxUnCMEjHYJy1Rf/hoqH02F6E3Pz5vnx68tLtkWJuUl6rdtdoM73KzCej3ClQu8XdMv CLz1xX8PCecA== X-IronPort-AV: E=Sophos; i="5.70,438,1574121600"; d="scan'208,217"; a="16232145" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-c5104f52.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 14 Feb 2020 02:08:37 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-c5104f52.us-west-2.amazon.com (Postfix) with ESMTPS id 03FC6A286E for ; Fri, 14 Feb 2020 02:08:36 +0000 (UTC) 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, 14 Feb 2020 02:08:36 +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, 14 Feb 2020 02:08:36 +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, 14 Feb 2020 02:08:36 +0000 From: "Richard Backman, Annabelle" To: "txauth@ietf.org" Thread-Topic: [Txauth] XAuth -02 Thread-Index: AQHV3jRcCsQaXzP9e0Gex6TsPtSqQKgUiKoAgAPnIYCAAQUDgA== Date: Fri, 14 Feb 2020 02:08:36 +0000 Message-ID: <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@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.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.233] Content-Type: multipart/alternative; boundary="_000_5F770E76D07D4464A6AE2442AE055B43amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 02:08:54 -0000 --_000_5F770E76D07D4464A6AE2442AE055B43amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W3JpY2hhbm5hXQ0KUmVwbGllcyBpbmxpbmUNClsvcmljaGFubmFdDQoNCuKAkw0KQW5uYWJlbGxl IEJhY2ttYW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20v aWRlbnRpdHkvDQoNCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpE YXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDIwIGF0IDY6MzUgUE0NClRvOiAiUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6ICJ0eGF1dGhA aWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gWEF1dGgg LTAyDQoNCjxzbmlwPg0KDQpTZWN0aW9uIDUuNS4yOg0KDQogICBUaGUgaW50ZXJhY3Rpb24gb2Jq ZWN0IGNvbnRhaW5zIHRoZSB0eXBlIG9mIGludGVyYWN0aW9uIHRoZSBDbGllbnQNCg0KICAgd2ls bCBwcm92aWRlIHRoZSBVc2VyLiAgT3RoZXIgYXR0cmlidXRlcw0KDQo8c25pcD4NCg0KICAgICAg ICAtICAqdHlwZSogLSBjb250YWlucyBvbmUgb2YgdGhlIGZvbGxvd2luZyB2YWx1ZXM6ICJwb3B1 cCIsDQoNCiAgICAgICAgICAgInJlZGlyZWN0Iiwgb3IgInFyY29kZSIuLi4uDQoNCjMgaXNzdWVz IHdpdGggdGhpczoNCjEuICAgSG93IHdvdWxkIEkgZG8gYSB1c2VyIGNvZGUtYmFzZWQgaW50ZXJh Y3Rpb24/DQpUbyBjbGFyaWZ5LCB0aGUgVXNlciBpcyBlbnRlcmluZyBhIGNvZGUgaW4gdGhlIENs aWVudCBpbnRvIHRoZSBHUywgb3IgdGhlIFVzZXIgaXMgZW50ZXJpbmcgYSBjb2RlIGludG8gdGhl IENsaWVudD8NCg0KSWYgdGhlIHByaW9yLCB0aGUgUVIgY29kZSBhbHNvIGFsbG93cyBhIG1lc3Nh Z2UuIEknbSBlbnZpc2lvbmluZyBhIFVzZXIgd2l0aCBhIG1vYmlsZSBwaG9uZSBjYW4gc2NhbiB0 aGUgUVIgY29kZSB3aGljaCBjb250YWlucyBhIFVSTCBhdCB0aGUgR1MsIGFuZCBpbmNsdWRlcyB0 aGUgY29kZS4NCg0KVGhlIG1lc3NhZ2Ugd291bGQgZGVzY3JpYmUgd2hhdCB0byBkbyBhbmQgaW5j bHVkZSB0aGUgY29kZS4NCg0KW3JpY2hhbm5hXQ0KQnkgdXNlciBjb2RlLWJhc2VkIGludGVyYWN0 aW9uLCBJIG1lYW4gdGhlIGtpbmQgZGVzY3JpYmVkIGluIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEF1 dGhvcml6YXRpb24gR3JhbnQ8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODYyOD4sIHdo ZXJlIHRoZSB1c2VyIHJlY2VpdmVzIGEgY29kZSBhbmQgc2hvcnQgVVJMIGZyb20gdGhlIGNsaWVu dCwgbmF2aWdhdGVzIHRvIHRoYXQgVVJMIGluIGEgYnJvd3NlciwgYW5kIGVudGVycyB0aGUgY29k ZS4gV2hpbGUgdGhpcyBjb3VsZCBiZSBwYWNrZWQgaW50byBpbnRlcmFjdGlvbi5tZXNzYWdlLCB0 aGlzIHdpbGwgbGVhZCB0byBjbHVua2llciB1c2VyIGV4cGVyaWVuY2VzOg0KDQogIDEuICBUaGUg R1MgbWF5IG5vdCBiZSBhYmxlIHRvIHByb3ZpZGUgbG9jYWxpemVkIGluc3RydWN0aW9ucyB0aGF0 IG1hdGNoIHRoZSBsb2NhbGUgb24gdGhlIENsaWVudC4NCiAgMi4gIFN1cHBvc2UgdGhlIEdTIHNl bmRzIGEgbWVzc2FnZSB0aGF0IHJlYWRzOiDigJxTY2FuIHRoZSBRUiBjb2RlIG9yIG9wZW4gYSBi cm93c2VyIHRvIGh0dHA6Ly9jb2RlLmV4YW1wbGUvIGFuZCBlbnRlciB0aGUgY29kZTogMTIzNDUu 4oCdDQoNCiAgICAgKiAgIFRoYXQgaW5zdHJ1Y3Rpb24gZG9lcyBub3QgbWFrZSBzZW5zZSBvbiBh IGRldmljZSB0aGF0IGRvZXMgbm90IHByZXNlbnQgYSBRUiBjb2RlLiBJbWFnaW5lIGhlYXJpbmcg dGhhdCBmcm9tIGEgc21hcnQgc3BlYWtlci4NCiAgICAgKiAgIFRoYXQgaW5zdHJ1Y3Rpb24gaXMg Y29uZnVzaW5nbHkgcmVkdW5kYW50IGlmIHRoZSBDbGllbnQgZGlzcGxheXMgdGhlIFFSIGNvZGUg YWxvbmcgd2l0aCBpdHMgb3duIGluc3RydWN0aW9ucywgbGlrZTog4oCcU2NhbiB0aGUgUVIgY29k ZSBvciBmb2xsb3cgdGhlIGluc3RydWN0aW9ucyBiZWxvdy7igJ0NCg0KICAxLiAgV2lsbCDigJxl bWJlZCB0aGUgc2hvcnQgVVJMIGFuZCBjb2RlIGluIHRoZSBtZXNzYWdlIHN0cmluZ+KAnSBiZSBN VEk/IElmIG5vdCwgdGV4dC1vbmx5IGNsaWVudHMgd291bGQgaGF2ZSBhIGJyb2tlbiBleHBlcmll bmNlLg0KWy9yaWNoYW5uYV0NCg0KDQoyLiAgIENsaWVudHMgc3VwcG9ydCBtdWx0aXBsZSBpbnRl cmFjdGlvbiBtb2RlcyBhbmQgbWF5IG5vdCBhbHdheXMga25vdyB3aGF0IHRoZSBHUyBzdXBwb3J0 cyAoYW5kIHZpY2UtdmVyc2EpLiBGb3IgYSBtdWx0aS10ZW5hbnQgR1MsIGl0IG1heSB2YXJ5IGJ5 IHRlbmFudCBjb25maWd1cmF0aW9uLiBDbGllbnRzIHNob3VsZCBiZSBhYmxlIHRvIHNheSB3aGF0 IHRoZXkgY2FuIGRvLCBhbmQgdGhlIEdTIHNob3VsZCBiZSBhYmxlIHRvIHRlbGwgdGhlbSB3aGlj aCBvbmUgdG8gdXNlLiBJdOKAmXMgYSB2ZXJ5IHNpbXBsZSBidXQgcG93ZXJmdWwgaW5saW5lIG5l Z290aWF0aW9uLg0KDQpUaGF0IGlzIHdoYXQgaXMgaW4gVHhBdXRoLiBXb3VsZCB5b3UgZWxhYm9y YXRlIG9uIGhvdyB0aGUgR1MgbWlnaHQgYmUgY29uc3RyYWluZWQ/IFdoeSB3b3VsZCB0aGUgR1Mg bm90IGJlIGFibGUgdG8gZG8gYWxsPw0KDQpJIHdvdWxkIHRoaW5rIGFsbCBjb25zdHJhaW50cyB3 b3VsZCBiZSBhdCB0aGUgQ2xpZW50LiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KDQpbcmljaGFu bmFdDQpDbGllbnRzIG1heSBzdXBwb3J0IGN1c3RvbWVyLWRlZmluZWQgR1NlcyAoZS5nLiwgZW50 ZXJwcmlzZSBJZFBzKSwgd2hpY2ggd2lsbCB2YXJ5IGluIHRlcm1zIG9mIHdoaWNoIGludGVyYWN0 aW9uIG1vZGVzIHRoZXkgc3VwcG9ydC4gV2hpbGUgdGhlIHNldCBvZiBpbnRlcmFjdGlvbnMgZGVm aW5lZCBpbiBYQXV0aCBtaWdodCBhbGwgYmUgTVRJIGZvciBhIEdTLCB3ZSBzaG91bGQgYXNzdW1l IHRoYXQgZXh0ZW5zaW9ucyB3aWxsIGludHJvZHVjZSBuZXcgaW50ZXJhY3Rpb25zIHdoaWNoIHdp bGwgbm90IGJlIHVuaXZlcnNhbGx5IHN1cHBvcnRlZC4gQW4gaW50ZXJhY3Rpb24gbWVjaGFuaXNt IG1pZ2h0IGhhdmUgcHJvcGVydGllcyB0aGF0IGNhdXNlIHNvbWUgYWRtaW5pc3RyYXRvcnMgdG8g d2FudCB0byBkaXNhYmxlIGl0LCBvciB0byByZXN0cmljdCBDbGllbnRzIHRvIGFsd2F5cyB1c2Ug aXQuIEFyZSB5b3UgYXNzdW1pbmcgdGhhdCBhIENsaWVudCB3aWxsIGFsd2F5cyBtYWtlIGFuIE9Q VElPTlMgZGlzY292ZXJ5IHJlcXVlc3QgZmlyc3Q/DQpbL3JpY2hhbm5hXQ0KDQozLiAgIEkgZG9u 4oCZdCBzZWUgdGhlIHZhbHVlIG9mIHRoZSDigJxwb3B1cOKAnSBpbnRlcmFjdGlvbiBtb2RlLiBD bGllbnRzIGNhbiB1c2Ug4oCccmVkaXJlY3TigJ0gbW9kZSB3aXRoaW4gcG9wdXBzLiBIb3dldmVy LCBzcGVha2luZyBhcyBzb21lb25lIHdobyBoYXMgZG9uZSB0aGF0LCBJIHJlYWxseSBkb27igJl0 IHJlY29tbWVuZCBpdC4gUG9wdXBzIGFyZSBpbmNyZWFzaW5nbHkgdW5zdXBwb3J0ZWQsIGFuZCBw cm9uZSB0byB3ZWlyZCBiZWhhdmlvcmFsIGlzc3Vlcy4gSW4tYXBwIGJyb3dzZXJzIGluIEZhY2Vi b29rLCBUd2l0dGVyLCBldGMuIHRlbmQgdG8gaGF2ZSBwb3B1cHMgZGlzYWJsZWQuIFRoZSBsYXN0 IHZlcnNpb25zIG9mIElFIE1vYmlsZSBkaWRu4oCZdCBzdXBwb3J0IHRoZW0gYXQgYWxsICh0aGUg cG9wcGVkIHVwIHBhZ2UgYmFzaWNhbGx5IGp1c3QgbG9hZGVkIGludG8gdGhlIGN1cnJlbnQgd2lu ZG93KS4gaW4NCg0KUG9wdXBzIGFyZSByZWFsbHkgdXNlZnVsIGluIHNpbmdsZS1wYWdlIGFwcHMg YXMgeW91IHdhbnQgdG8ga2VlcCB0aGUgY29udGV4dCBhbmQgbm90IHJlbG9hZCB0aGUgcGFnZS4N Cg0KQWdyZWUgdGhhdCBwb3B1cHMgZG9uJ3QgbWFrZSBzZW5zZSBpbiBtb2JpbGUuIEEgZnVsbCBy ZWRpcmVjdCBkb2VzIG9mIGNvdXJzZS4gQSBzaW5nbGUtcGFnZSBhcHAgb24gbW9iaWxlIHdvdWxk IG9wZW4gYSBuZXcgdGFiIHdoaWNoIHdvdWxkIGJlIGEgc2VwYXJhdGUgY29udGV4dCByYXRoZXIg dGhhbiBhIHJlZGlyZWN0Lg0KDQpbcmljaGFubmFdDQpQb3B1cHMgYXJlIGJyb2tlbiBhbmQvb3Ig ZGlzYWJsZWQgaW4gZW5vdWdoIGluc3RhbmNlcyB0aGF0IHdlIHNob3VsZCBub3QgZW5jb3VyYWdl IHRoZWlyIHVzYWdlIGJ5IGluY2x1ZGluZyBleHBsaWNpdCBzdXBwb3J0IGZvciB0aGVtIGluIHRo ZSBwcm90b2NvbC4gTm9yIGFyZSB0aGV5IG5lY2Vzc2FyeSBmb3IgU1BBcyBpbiBvcmRlciB0byBy ZXN0b3JlIHRoZSBzdGF0ZSBvZiB0aGVpciBhcHAgYWZ0ZXIgdGhlIHJlZGlyZWN0LiBBbmQgYWdh aW4sIGEgQ2xpZW50IHRoYXQgcmVhbGx5IHdhbnRzIHRvIGdpdmUgdGhlbXNlbHZlcyBhIGhlYWRh Y2hlIHdpdGggcG9wdXBzIGNhbiBkbyB0aGF0IHRoZW1zZWx2ZXMgdXNpbmcg4oCccmVkaXJlY3Ti gJ0gbW9kZS4gVGhleSBqdXN0IGhhdmUgdG8gcHJvdmlkZSBhIGxhbmRpbmcgcGFnZSBmb3IgdGhl IEdTIHRvIHJlZGlyZWN0IGJhY2sgdG8gdGhhdCBwYXJzZXMgdGhlIHJlc3BvbnNlLCBwYXNzZXMg aXQgYmFjayB0byB0aGUgbWFpbiB3aW5kb3csIGFuZCBjbG9zZXMgaXRzZWxmLiBJIGRvbuKAmXQg c2VlIHdoeSB0aGUgcHJvdG9jb2wgd291bGQgbmVlZCB0byBleHBsaWNpdGx5IGRlc2NyaWJlIHRo aXMgbWVjaGFuaXNtLg0KWy9yaWNoYW5uYV0NCg0KU2VjdGlvbiAxMi42Og0KDQogICAgICAgIFtF ZGl0b3I6IGlzIHRoZXJlIHNvbWUgb3RoZXIgcmVhc29uIHRvIGhhdmUgdGhlIFVzZXJJbmZvDQoN CiAgICAgICAgZW5kcG9pbnQ/XQ0KDQpJIG1heSB3YW50IHRvIGhvc3QgbXkgVXNlckluZm8gZW5k cG9pbnQgb24gYSBzZXBhcmF0ZSBtaWNyb3NlcnZpY2UgZnJvbSBteSB0b2tlbiBlbmRwb2ludCAo aW4gT0F1dGggMi4wL09JREMgdGVybXMpLiBUaGUgZm9ybWVyIG1pZ2h0IGJlIHBhcnQgb2YgbXkg dXNlciBwcm9maWxlL2RpcmVjdG9yeSBzdGFjaywgd2hpbGUgdGhlIGxhdHRlciBpcyBwYXJ0IG9m IHRoZSBoaWdobHkgcHJpdmlsZWdlZCBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHN0YWNr Lg0KDQoNClRoZSB0b2tlbiBlbmRwb2ludCBoYXMgdGhlIGFjY2VzcyB0b2tlbiBhbnl3YXksIHNv IGl0IGNhbiBmZXRjaCB0aGUgZGF0YSBmcm9tIHRoZSBvdGhlciBlbmRwb2ludCBpdHNlbGYgaWYg aXQgd2FudGVkIHRvLiBJRSwgdGhlcmUgaXMgbm8gc2VwYXJhdGlvbiBvZiBkdXRpZXMuDQoNCldo YXQgYXJlIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBVc2VySW5mbyBlbmRwb2ludCB0byB0aGUgVXNl ciBvciBDbGllbnQ/DQoNClRoZSBVc2VySW5mbyBlbmRwb2ludCBzZWVtcyB0byBqdXN0IGFkZCBt b3JlIGNvbXBsZXhpdHksIHdpdGggbm8gYWJpbGl0eSB0byBzdGFydCBhIFVzZXIgaW50ZXJhY3Rp b24gaWYgYWRkaXRpb25hbCBjb25zZW50IGlzIG5lZWRlZC4NCg0KW3JpY2hhbm5hXQ0KSWYgdGhl IGFjY2VzcyB0b2tlbiBpcyBzZW5kZXItY29uc3RyYWluZWQsIHRoZW4gbm8sIHRoZSB0b2tlbiBl bmRwb2ludCBjYW7igJl0IGZldGNoIHRoZSBkYXRhIGl0c2VsZi4gQnV0IGV2ZW4gd2l0aG91dCB0 aGUgc2VjdXJpdHkgYW5nbGUsIHRoZXJlIGlzIHZhbHVlIGluIHNlcGFyYXRpbmcgb3V0IHRoZSBm dW5jdGlvbmFsaXR5IGFzIGl0IGFsbG93cyB0aGUgR1MgdG8gZGlzdHJpYnV0ZSBpdCBhY3Jvc3Mg c3lzdGVtcyB3aXRoIGRpZmZlcmVudCBvd25lcnMuIEUuZy4sIHRoZXJlIG1pZ2h0IGJlIGEgZGly ZWN0b3J5IEFQSSB0ZWFtIHRoYXQgYWxzbyBvd25zIHRoZSBTQ0lNIGludGVyZmFjZSBhbmQgVXNl ckluZm8gZW5kcG9pbnQuDQoNClRoZSBhZHZhbnRhZ2UgZm9yIHRoZSBDbGllbnQgaXMgdGhhdCB0 aGV5IGhhdmUgYW4gZW5kcG9pbnQgdGhleSBjYW4gY2FsbCB0byBnZXQgdXAtdG8tZGF0ZSBkZXRh aWxzIGFib3V0IHRoZSBlbmQgdXNlciwgZXZlbiBvdXRzaWRlIHRoZSBjb250ZXh0IG9mIGFuIGFj dGl2ZSBzZXNzaW9uLg0KDQpUaGUgVXNlckluZm8gZW5kcG9pbnQgY2FuIGluZGljYXRlIHRoZSBu ZWVkIGZvciBhZGRpdGlvbmFsIGNvbnNlbnQgdmlhIGEgNDAxIGFuZCBXV1ctQXV0aGVudGljYXRl LCBqdXN0IGxpa2UgYW55IG90aGVyIHJlc291cmNlIGVuZHBvaW50Lg0KWy9yaWNoYW5uYV0NCg0K DQpTZWN0aW9uIDEyLjg6DQoNCiAgICAgICAgKldoeSBoYXZlIGJvdGggY2xhaW1zIGFuZCBhdXRo b3JpemF0aW9ucz8qDQoNCg0KDQogICAgICAgIFRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIGVhY2gg dGhhdCBhcmUgaW5kZXBlbmRlbnQ6DQoNCiAgICAgICAgYXV0aGVudGljYXRpbmcgYSB1c2VyIHZz IGdyYW50aW5nIGFjY2VzcyB0byBhIHJlc291cmNlLiAgQQ0KDQogICAgICAgIHJlcXVlc3QgZm9y IGFuIGF1dGhvcml6YXRpb24gcmV0dXJucyBhbiBhY2Nlc3MgdG9rZW4gb3IgaGFuZGxlLA0KDQog ICAgICAgIHdoaWxlIGEgcmVxdWVzdCBmb3IgYSBjbGFpbSByZXR1cm5zIHRoZSBjbGFpbS4NCg0K SSBkb27igJl0IGFncmVlIHRoYXQgdGhlIHVzZSBjYXNlcyBhcmUgZGlzdGluY3QuIFRoZSBvbmx5 IGNsYWltIHRoYXQgaXMgc3RyaWN0bHkgbmVjZXNzYXJ5IGZvciBhdXRoZW50aWNhdGlvbiBpcyB0 aGUgdXNlciBpZGVudGlmaWVyLiBPdGhlciBjbGFpbXMgbGlrZSBlbWFpbCBhbmQgcGhvbmVfbnVt YmVyIGFyZSBvZnRlbiB1c2VkIHRvIGFpZCBpbiBsb2NhbCBhY2NvdW50IGlkZW50aWZpY2F0aW9u IChpLmUuLCBhY2NvdW50IGxpbmtpbmcpLCBidXQgYXJlIHVzZWZ1bCBhbmQgaW50ZXJlc3Rpbmcg YmV5b25kIHRoaXMgdXNlIGNhc2UuDQoNClNvbWUgQ2xpZW50cyB1c2UgZW1haWwgYW5kIHBob25l X251bWJlciBhcyB0aGUgaWRlbnRpZmllciBhbmQgZG9uJ3QgcGF5IGF0dGVudGlvbiB0byB0aGUg ZGlyZWN0ZWQgaWRlbnRpZmllci4gTm90IHRoZSBiZXN0IHByYWN0aWNlLCBidXQgaXQgaXMgd2hh dCBwZW9wbGUgZG8uDQoNCltyaWNoYW5uYV0NClRoYXQgaXMgbGl0ZXJhbGx5IHRoZSBzY2VuYXJp byBJIGRlc2NyaWJlZCBpbiB0aGUgZmlyc3QgcGFydCBvZiB0aGUgc2Vjb25kIHNlbnRlbmNlLiBU aGUgbGF0dGVyIHBhcnQgb2YgdGhhdCBzYW1lIHNlbnRlbmNlIG5vdGVzIHRoYXQgdGhvc2UgY2xh aW1zIGFyZSB1c2VmdWwgYmV5b25kIHRoYXQgdXNlIGNhc2UsIGkuZS4sIHRoZXkgY2FuIGJlIHVz ZWZ1bCBldmVuIHdoZW4gdGhlIGNsaWVudCBpcyBub3QgdXNpbmcgdGhlbSBmb3IgYXV0aGVudGlj YXRpb24uIEkgYW0gZGVtb25zdHJhdGluZyB0aGF0IHlvdXIg4oCcYXV0aGVudGljYXRpbmcgYSB1 c2VyIHZzIGdyYW50aW5nIGFjY2VzcyB0byBhIHJlc291cmNl4oCdIGRpY2hvdG9teSBpcyBmbGF3 ZWQgYnkgc2hvd2luZyB0aGF0IGNsYWltcyBkbyBub3Qgc3RyaWN0bHkgYmVsb25nIHRvIHRoZSBm b3JtZXIsIGFuZCBzb21lIHRoaW5ncyB0aGF0IGFyZSBkZWZpbmVkIGFzIGNsYWltcyBoYXZlIG5v dGhpbmcgYXQgYWxsIHRvIGRvIHdpdGggYXV0aGVudGljYXRpb24uDQpbL3JpY2hhbm5hXQ0KDQo8 c25pcD4NCg0KSSBzdHJvbmdseSB0aGluayBpdCBpcyBhIGRpc3NlcnZpY2UgdG8gb3VyIGF1ZGll bmNlIHRvIGNvbmZsYXRlIGNsYWltcyBhbmQgcmVzb3VyY2VzLiBDbGFpbXMgYXJlIHN0YXRlbWVu dHMgYWJvdXQgdGhlIFVzZXIgYW5kIHJlYWQtb25seS4NCg0KW3JpY2hhbm5hXQ0KQ2xhaW1zIGFy ZSBhIHN1YnNldCBvZiByZXNvdXJjZXMgdGhhdCBPSURDIGJ1aWx0IHNvbWUgZXh0cmEgZmVhdHVy ZXMgZm9yLCBpbmNsdWRpbmcgYSByZWFkLW9ubHkgaW50ZXJmYWNlIHRvIGFjY2VzcyB0aGVtLiBI b3dldmVyLCBjbGFpbXMgYXJlIG5vdCBpbmhlcmVudGx5IHJlYWQtb25seSwgbm9yIGFyZSB0aGV5 IHRoZSBvbmx5IHJlc291cmNlcyBmb3Igd2hpY2ggYSByZWFkLW9ubHkgaW50ZXJmYWNlcyBtYXkg YmUgYnVpbHQgZm9yLg0KWy9yaWNoYW5uYV0NCg0KPHNuaXA+DQpJIHVuZGVyc3RhbmQgdGhlIHVz ZSBjYXNlIHlvdeKAmXJlIHRyeWluZyB0byBzdXBwb3J0IGhlcmUsIGJ1dCBJIHRoaW5rIHRoZSBw cm9wb3NhbCBpcyB0b28gY29tcGxpY2F0ZWQgdG8gaW1wbGVtZW50LiBGcm9tIHRoZSBzZXF1ZW5j ZXMsIGl0IGxvb2tzIGxpa2UgdGhlIENsaWVudCBpcyBleHBlY3RlZCB0byBpc3N1ZSBhIFJlYWQg R3JhbnQgcmVxdWVzdCwgYW5kIHRoYXQgY29ubmVjdGlvbiB3aWxsIGJlIGtlcHQgb3BlbiB3aGls ZSB0aGUgVXNlciBpcyByZWRpcmVjdGVkIHRvIHRoZSBHUyBhbmQgZ29lcyB0aHJvdWdoIHRoZSBh dXRoZW50aWNhdGlvbiB3b3JrZmxvdyAoYW5kIHBvc3NpYmx5IHBhcnQgb2YgdGhlIGF1dGhvcml6 YXRpb24gd29ya2Zsb3cpLiBPbmx5IHRoZW4gd291bGQgdGhlIEdTIHJldHVybiB0aGUgUmVhZCBH cmFudCByZXNwb25zZS4gSXMgdGhpcyBjb3JyZWN0Pw0KDQpUbyBpbXBsZW1lbnQgdGhpcywgdGhl IENsaWVudCBoYXMgdG8gbGF1bmNoIGFuIGFzeW5jaHJvbm91cyB0aHJlYWQgdG8gZXhlY3V0ZSB0 aGF0IHJlcXVlc3QgYW5kIGF3YWl0aW5nIHRoZSByZXNwb25zZS4NClBvc3NpYmxlLCBidXQgc3Vz Y2VwdGlibGUgdG8gZmFpbHVyZXMuIFdoYXQgaGFwcGVucyBpZiB0aGF0IHRocmVhZCBjcmFzaGVz PyBPciBmYWlscyB0byBzZW5kIHRoZSBVcGRhdGUgR3JhbnQgcmVxdWVzdCB0byBmbGlwIGludGVy YWN0aW9uLmtlZXAgdG8gZmFsc2U/IFdoYXQgaXMgdGhlIEdTIGRvaW5nIGluIHRoZSBtZWFudGlt ZT8gSXMgaXQganVzdCBzaG93aW5nIHRoZSBVc2VyIGEg4oCcbG9hZGluZ+KAnSB3aWRnZXQgYXMg aXQgd2FpdHMgZm9yIHRoZSBDbGllbnQgdG8gdXBkYXRlIHRoZSBncmFudD8gSG93IGxvbmcgZG9l cyBpdCB3YWl0IGZvcj8gRm9yIG1vYmlsZSBhcHBzLCB0aGF0IGJhY2tncm91bmQgdGhyZWFkIG1h eSBnZXQga2lsbGVkIG9yIGxvc2UgbmV0d29yayBjb25uZWN0aXZpdHkgYXMgc29vbiBhcyB0aGUg dXNlciBnZXRzIHN3aXRjaGVkIG92ZXIgdG8gdGhlIHN5c3RlbSBicm93c2VyIHRvIGxvYWQgdGhl IEdTIHNpZ24gaW4gcGFnZS4gRm9yIGEgcHVyZS1KUyBhcHAgdGhhdCByZWRpcmVjdHMsIEkgZG9u 4oCZdCB0aGluayB0aGlzIGlzIHBvc3NpYmxlIGF0IGFsbC4gKHVubGVzcyB3ZWIgd29ya2VycyBj YW4gc3Vydml2ZSBwYWdlIHVubG9hZHM/KQ0KDQpUaGlzIGlzIGFuIGludGVyZXN0aW5nIHVzZSBj YXNlIGZvciB1cyB0byB0aGluayBhYm91dCwgYnV0IGl0IG5lZWRzIGEgbG90IG9mIHdvcmsgYW5k IG1heSBub3QgYmUgc29tZXRoaW5nIHdlIHNob3VsZCB0cnkgdG8gYmFrZSBpbnRvIHRoZSBjb3Jl IHByb3RvY29sIGlmIHdlIGRvbuKAmXQgbmVlZCB0by4NCg0KSXQgbWlnaHQgbm90IGhhdmUgYmVl biBvYnZpb3VzLCBidXQgdGhlIENsaWVudCBjYWxsaW5nIHRoZSBHUyB0byBnZXQgYSByZXN1bHQg d2hpbGUgdGhlIGludGVyYWN0aW9uIGlzIGhhcHBlbmluZyBpcyB3aGF0IGhhcHBlbnMgaW4gYW55 IGZsb3cgd2l0aCBhbiBpbnRlcmFjdGlvbiBzdGFydGVkIGJ5IHRoZSBDbGllbnQuIEl0IGlzIG5v dCB1bmlxdWUgdG8gImludGVyYWN0aW9uIi4ia2VlcCIgLS0gd2UgYXJlIGp1c3QgYWRkaW5nIGFk ZGl0aW9uYWwgYmFjayBhbmQgZm9ydGhzIGJldHdlZW4gdGhlIENsaWVudCBhbmQgR1MuDQoNCkEg UVIgQ29kZSBleGFtcGxlIEhBUyB0byB3b3JrIHRoaXMgd2F5LCBhcyB0aGVyZSBpcyBubyBvdGhl ciB3YXkgZm9yIHRoZSBDbGllbnQgdG8ga25vdyB0aGUgaW50ZXJhY3Rpb24gaGFzIGNvbXBsZXRl ZC4NCg0KR29vZ2xlIGFuZCBNaWNyb3NvZnQgYm90aCBoYXZlIGEgc2ltaWxhciB1c2VyIGV4cGVy aWVuY2UuIFRoZSBVc2VyIHdhbnRzIHRvIGxvZyBpbnRvIGFuIGFwcCAtLSB0aGV5IGFyZSBpbnN0 cnVjdGVkIHRvIGdvIHRvIHRoZSByZXNwZWN0aXZlIG1vYmlsZSBhcHAgdG8gYXBwcm92ZSB0aGUg YXV0aGVudGljYXRpb24gLS0gYW5kIHRoZW4gdGhlIFVzZXIgcmV0dXJucyB0byB0aGUgYXBwIHdo aWNoIGNoYW5nZXMgdG8gYSBsb2dnZWQgaW4gc3RhdGUuICBBbiBhdXRoZW50aWNhdGlvbiBvbmx5 IGZsb3cgdXNpbmcgWEF1dGggd291bGQgd29yayB0aGUgc2FtZSB3YXkuDQoNCltyaWNoYW5uYV0N ClRoZXJlIGFyZSB0d28gYmlnIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhvc2UgZXhhbXBsZXMgKGUu Zy4sIFFSIENvZGUsIGFwcC1iYXNlZCBsb2dpbiBhcHByb3ZhbHMpIGFuZCB0aGlzIG1lY2hhbmlz bSBpbiBYQXV0aDoNCg0KICAxLiAgSW4geW91ciBleGFtcGxlcyBvZiB0aGlzIGJlaGF2aW9yIHRv ZGF5LCB0aGUgcmVhc29uIGZvciB0aGUgd2FpdCBpcyBjbGVhciBhbmQgb2J2aW91cywgYW5kIGRy aXZlbiBieSB0aGUgdXNlci4gRS5nLiwgbXkgcHJpbnRlciBpcyB3YWl0aW5nIGZvciBtZSB0byBn byBlbnRlciB0aGlzIGNvZGUgYW5kIGxvZyBpbjsgR29vZ2xlIHNpZ24gaW4gaXMgd2FpdGluZyBm b3IgbWUgdG8gdGFwIHRoaXMgYnV0dG9uIG9uIG15IHBob25lLiBUaGF0IGlzIG5vdCB0aGUgY2Fz ZSBpbiB0aGUgWEF1dGggcHJvdG9jb2wuIFRoZSB1c2VyIGlzIGxlZnQgc2l0dGluZyBvbiBhIGxv YWRpbmcgc2NyZWVuIHdhaXRpbmcgZm9yIGEgYmVoaW5kLXRoZS1zY2VuZXMgaW50ZXJhY3Rpb24g YmV0d2VlbiBjbGllbnQgYW5kIEdTIHRoYXQgbWF5IG5vdCBldmVuIGhhcHBlbi4NCiAgMi4gIFVu bGlrZSB3aXRoIGNvZGUvUVIgZmxvd3Mgb3Igc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZXJlIGlz IG5vIGFjdGl2ZSBwcm9jZXNzIG9uIHRoZSBjbGllbnQgc2lkZSB0byBrZWVwIHRoaXMgYXN5bmMg cmVxdWVzdCBvcGVuLiBBIHdlYiBhcHAgY2xpZW50IHdvdWxkIGhhdmUgdG8gaW50cm9kdWNlIGEg c2VydmVyLXNpZGUgYXN5bmMgcHJvY2VzcyB0byBtYW5hZ2UgdGhpcyBhc3BlY3Qgb2YgdGhlIHBy b3RvY29sLiBUaGF04oCZcyBub3QgZWFzeS4NCiAgMy4gIFRoZSBmYWlsdXJlIG1vZGVzIHNob3cg dXAgaW4gbW9yZSBhcHByb3ByaWF0ZSBjb250ZXh0cywgd2hlcmUgdGhlcmUgYXJlIGNsZWFyIHBh dGhzIGZvcndhcmQgZm9yIHRoZSBlbmQgdXNlci4gSW4gY29kZS9RUi1iYXNlZCBmbG93cywgaXTi gJlzIGRldGVjdGVkIG9uIHRoZSBjbGllbnQgc2lkZSwgaW4gdGhlIGZvcm0gb2YgYW4gQVMgdGhh dCBuZXZlciBwcm92aWRlcyBhIHJlc3BvbnNlLiBJbiB0aGF0IHNjZW5hcmlvLCB0aGUgY2xpZW50 IGNhbiByZXRyeSB0aGUgcHJvY2Vzcy4gSW4gc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZSBwcm9i bGVtIG9jY3VycyBiZXR3ZWVuIHR3byBwYXJ0cyBvZiB0aGUgQVMsIGFuZCB0aGUgQVMgY2FuIGFs bG93IHRoZSBlbmQgdXNlciB0byByZXRyeSBvciB0byB1c2UgYSBkaWZmZXJlbnQgYXV0aGVudGlj YXRpb24gbWV0aG9kLiBJbiB0aGUgWEF1dGggQ3JlYXRlK1VwZGF0ZSBzY2VuYXJpbywgdGhlIGZh aWx1cmUgaXMgZGV0ZWN0ZWQgb24gdGhlIEdTLCBhbmQgdGhlcmUgaXMgbm8gY2xlYXIgcGF0aCBm b3J3YXJkLiBJZiB0aGUgQ2xpZW50IG5ldmVyIGNhbGxzIFVwZGF0ZSBHcmFudCB0byBmbGlwIGlu dGVyYWN0aW9uLmtlZXAgdG8gZmFsc2UsIHdoYXQgc2hvdWxkIHRoZSBHUyBkbz8gSG93IGxvbmcg c2hvdWxkIGl0IHdhaXQ/IFNob3VsZCBpdCBpc3N1ZSB0aGUgYXV0aG9yaXphdGlvbiBhbnl3YXks IGFzc3VtaW5nIHRoZSBDbGllbnQgd2lsbCBjb21lIGJhY2sgYW5kIGFzayBmb3IgaXQgYXQgc29t ZSBwb2ludD8gU2hvdWxkIGl0IHJlZGlyZWN0IHRoZSBlbmQgdXNlciBiYWNrIHRvIHRoZSBDbGll bnQgYW55d2F5LCBvciBkcm9wIHRoZW0gb24gYSBsYW5kaW5nIHBhZ2U/IFNob3VsZCBpdCBmbGFn IHRoaXMgYXMgYW4gZXJyb3IsIG9yIGlzIHRoaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGZvciB0 aGUgQ2xpZW50Pw0KDQpJIHJlYWxseSB0aGluayB0aGlzIGlzIG92ZXJjb21wbGljYXRpbmcgdGhl IHByb3RvY29sIHRvIGFuIGV4dGVudCB0aGF0IG5vIG9uZSB3aWxsIGFjdHVhbGx5IGltcGxlbWVu dCBpdC4NClsvcmljaGFubmFdDQoNCltwYXN0aW5nIGluIGZyb20geW91ciBsYXRlciBlbWFpbF0N CldoaWxlIGEgc2luZ2xlIHN0YWdlIEdyYW50IHJlcXVlc3QgKDMuMSkgaW4gYSBtb2JpbGUgYXBw IHRoYXQgaGFzIGJlZW4gcHV0IHRvIHNsZWVwIHdpbGwgcmVjb3ZlciBmaW5lLCBhIG11bHRpLXN0 ZXAgKDMuNCkgd2lsbCBmYWlsLiBTaW5jZSAzLjQgb25seSBtYWtlcyBzZW5zZSBpZiB0aGUgQ2xp ZW50IGlzIGNoZWNraW5nIGEgZGF0YWJhc2UgYWxvbmcgdGhlIHdheSwgSSB3b3VsZCBleHBlY3Qg dGhlIENsaWVudCB0byBoYXZlIGEgc2VydmVyIHNpZGUsIGFuZCB0aGUgc2VydmVyIGNvdWxkIHRh a2UgZWFjaCBzdGVwLg0KWy9lbmQgcGFzdGVdDQoNCltyaWNoYW5uYV0NCkhhdmluZyBhIHJlbW90 ZSBkYXRhYmFzZSBhbmQgaGF2aW5nIGEgcmVtb3RlIHNlcnZlciBhcmUgbm90IHRoZSBzYW1lIHRo aW5nLiBUaGlzIGFkZHMgYSBsb3Qgb2YgY29tcGxleGl0eSB0byBzZXJ2ZXJsZXNzIGFwcHMuDQpb L3JpY2hhbm5hXVtodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGph eTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9N2NkMThlYTYt OGM1MC00NmRjLWJlMjUtZTk5ZjYxNGRhYjgyXeGQpw0K --_000_5F770E76D07D4464A6AE2442AE055B43amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7E1380341091FE438A4A42D50BE7489D@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFz IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjIxMDg0NjQ1MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTIzODI5ODg2 MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjYxMDY3MTE2NTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTk5NDY5MDAzODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0 LWlkOjgyOTM2NzQ0NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTc0MjUyNjg3Njt9DQpAbGlz dCBsMw0KCXttc28tbGlzdC1pZDo5MTEzMDgzNDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjMz OTEzMTc0ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDo5NTgyOTY5OTU7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02MTEwMjkxMDg7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDQ6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsMw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw4 DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDo5NzM3NTAwMjI7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MDAyNDU3NDt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2DQoJe21z by1saXN0LWlkOjE0MDQ0NTM0NDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjgyNTk0ODU5ODt9 DQpAbGlzdCBsNw0KCXttc28tbGlzdC1pZDoxNzk2MzYxNTcyOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMzYyNjUwODU2O30NCkBsaXN0IGw4DQoJe21zby1saXN0LWlkOjE4MjM0Mjc2MDU7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwMDYwMzM1NDI7fQ0KQGxpc3QgbDkNCgl7bXNvLWxpc3Qt aWQ6MTk1ODc1MDM0MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDY4NzIyNDYwO30NCkBsaXN0 IGw5OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDk6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDk6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDEwDQoJe21zby1saXN0LWlkOjIwMjg4Mjc1NTc7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NjkzMjkxMjQgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTU7fQ0KQGxpc3QgbDEwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwxMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDEwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDEwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDExDQoJe21zby1saXN0 LWlkOjIxMDEwMjc2ODc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE4MjYxMDE2NjQgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDExOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxMTpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDExOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDExOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlcGxp ZXMgaW5saW5lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL3JpY2hhbm5h XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPuKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9 Imh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1 NjNDMSI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS88L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkRpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5XZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDIwIGF0IDY6MzUgUE08YnI+DQo8Yj5U bzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5u YUBhbWF6b24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1 b3Q7ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhh dXRoXSBYQXV0aCAtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZsdDtzbmlwJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClNlY3Rpb24gNS41LjI6PG86cD48 L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgaW50ZXJhY3Rpb24gb2JqZWN0IGNvbnRhaW5zIHRo ZSB0eXBlIG9mIGludGVyYWN0aW9uIHRoZSBDbGllbnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHdpbGwgcHJvdmlkZSB0aGUgVXNlci4mbmJzcDsgT3RoZXIgYXR0cmlidXRl czwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtJm5ic3A7ICp0eXBlKiAtIGNvbnRhaW5zIG9uZSBvZiB0 aGUgZm9sbG93aW5nIHZhbHVlczogJnF1b3Q7cG9wdXAmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmcXVvdDtyZWRpcmVjdCZxdW90Oywgb3IgJnF1b3Q7cXJjb2RlJnF1b3Q7Li4u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQozIGlzc3VlcyB3aXRoIHRoaXM6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0Omw2IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PkhvdyB3b3VsZCBJIGRvIGEgdXNlciBjb2RlLWJhc2VkIGludGVyYWN0aW9uPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VG8gY2xhcmlmeSwgdGhlIFVzZXIgaXMg ZW50ZXJpbmcgYSBjb2RlIGluIHRoZSBDbGllbnQgaW50byB0aGUgR1MsIG9yIHRoZSBVc2VyIGlz IGVudGVyaW5nIGEgY29kZSBpbnRvIHRoZSBDbGllbnQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SWYgdGhlIHByaW9yLCB0aGUgUVIgY29kZSBh bHNvIGFsbG93cyBhIG1lc3NhZ2UuIEknbSBlbnZpc2lvbmluZyBhIFVzZXIgd2l0aCBhIG1vYmls ZSBwaG9uZSBjYW4gc2NhbiB0aGUgUVIgY29kZSB3aGljaCBjb250YWlucyBhIFVSTCBhdCB0aGUg R1MsIGFuZCBpbmNsdWRlcyB0aGUgY29kZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgbWVzc2FnZSB3b3VsZCBkZXNjcmliZSB3aGF0IHRv IGRvIGFuZCBpbmNsdWRlIHRoZSBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bcmljaGFu bmFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CeSB1c2VyIGNvZGUtYmFz ZWQgaW50ZXJhY3Rpb24sIEkgbWVhbiB0aGUga2luZCBkZXNjcmliZWQgaW4gdGhlDQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NjI4Ij5PQXV0aCAyLjAgRGV2aWNlIEF1 dGhvcml6YXRpb24gR3JhbnQ8L2E+LCB3aGVyZSB0aGUgdXNlciByZWNlaXZlcyBhIGNvZGUgYW5k IHNob3J0IFVSTCBmcm9tIHRoZSBjbGllbnQsIG5hdmlnYXRlcyB0byB0aGF0IFVSTCBpbiBhIGJy b3dzZXIsIGFuZCBlbnRlcnMgdGhlIGNvZGUuIFdoaWxlIHRoaXMgY291bGQgYmUgcGFja2VkIGlu dG8gaW50ZXJhY3Rpb24ubWVzc2FnZSwNCiB0aGlzIHdpbGwgbGVhZCB0byBjbHVua2llciB1c2Vy IGV4cGVyaWVuY2VzOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg c3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxMCBsZXZlbDEgbGZvOSI+VGhlIEdTIG1heSBub3Qg YmUgYWJsZSB0byBwcm92aWRlIGxvY2FsaXplZCBpbnN0cnVjdGlvbnMgdGhhdCBtYXRjaCB0aGUg bG9jYWxlIG9uIHRoZSBDbGllbnQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMTAgbGV2ZWwxIGxmbzki PlN1cHBvc2UgdGhlIEdTIHNlbmRzIGEgbWVzc2FnZSB0aGF0IHJlYWRzOiDigJxTY2FuIHRoZSBR UiBjb2RlIG9yIG9wZW4gYSBicm93c2VyIHRvDQo8YSBocmVmPSJodHRwOi8vY29kZS5leGFtcGxl LyI+aHR0cDovL2NvZGUuZXhhbXBsZS88L2E+IGFuZCBlbnRlciB0aGUgY29kZTogMTIzNDUu4oCd PG86cD48L286cD48L2xpPjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0i MiIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i YSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDEwIGxldmVsMiBsZm85Ij5UaGF0IGluc3RydWN0aW9uIGRvZXMgbm90IG1ha2Ug c2Vuc2Ugb24gYSBkZXZpY2UgdGhhdCBkb2VzIG5vdCBwcmVzZW50IGEgUVIgY29kZS4gSW1hZ2lu ZSBoZWFyaW5nIHRoYXQgZnJvbSBhIHNtYXJ0IHNwZWFrZXIuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MTAgbGV2ZWwyIGxmbzkiPlRoYXQgaW5zdHJ1Y3Rpb24gaXMgY29uZnVzaW5nbHkgcmVkdW5kYW50 IGlmIHRoZSBDbGllbnQgZGlzcGxheXMgdGhlIFFSIGNvZGUgYWxvbmcgd2l0aCBpdHMgb3duIGlu c3RydWN0aW9ucywgbGlrZTog4oCcU2NhbiB0aGUgUVIgY29kZSBvciBmb2xsb3cgdGhlIGluc3Ry dWN0aW9ucyBiZWxvdy7igJ08bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8b2wgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEwIGxldmVsMSBsZm85 Ij5XaWxsIOKAnGVtYmVkIHRoZSBzaG9ydCBVUkwgYW5kIGNvZGUgaW4gdGhlIG1lc3NhZ2Ugc3Ry aW5n4oCdIGJlIE1UST8gSWYgbm90LCB0ZXh0LW9ubHkgY2xpZW50cyB3b3VsZCBoYXZlIGEgYnJv a2VuIGV4cGVyaWVuY2UuPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDox LjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Q2xpZW50cyBzdXBwb3J0IG11bHRpcGxlIGludGVyYWN0 aW9uIG1vZGVzIGFuZCBtYXkgbm90IGFsd2F5cyBrbm93IHdoYXQgdGhlIEdTIHN1cHBvcnRzIChh bmQgdmljZS12ZXJzYSkuIEZvciBhIG11bHRpLXRlbmFudCBHUywgaXQgbWF5IHZhcnkgYnkgdGVu YW50IGNvbmZpZ3VyYXRpb24uIENsaWVudHMgc2hvdWxkIGJlIGFibGUgdG8gc2F5IHdoYXQgdGhl eSBjYW4gZG8sIGFuZCB0aGUgR1Mgc2hvdWxkIGJlDQogYWJsZSB0byB0ZWxsIHRoZW0gd2hpY2gg b25lIHRvIHVzZS4gSXTigJlzIGEgdmVyeSBzaW1wbGUgYnV0IHBvd2VyZnVsIGlubGluZSBuZWdv dGlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYXQgaXMgd2hhdCBpcyBpbiBUeEF1dGguIFdvdWxkIHlv dSBlbGFib3JhdGUgb24gaG93IHRoZSBHUyBtaWdodCBiZSBjb25zdHJhaW5lZD8gV2h5IHdvdWxk IHRoZSBHUyBub3QgYmUgYWJsZSB0byBkbyBhbGw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3b3VsZCB0aGluayBhbGwgY29uc3RyYWludHMgd291bGQg YmUgYXQgdGhlIENsaWVudC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2xpZW50cyBtYXkgc3VwcG9ydCBjdXN0b21lci1kZWZpbmVkIEdTZXMgKGUuZy4sIGVudGVycHJp c2UgSWRQcyksIHdoaWNoIHdpbGwgdmFyeSBpbiB0ZXJtcyBvZiB3aGljaCBpbnRlcmFjdGlvbiBt b2RlcyB0aGV5IHN1cHBvcnQuIFdoaWxlIHRoZSBzZXQgb2YgaW50ZXJhY3Rpb25zIGRlZmluZWQg aW4gWEF1dGggbWlnaHQgYWxsIGJlIE1USSBmb3IgYSBHUywgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0 IGV4dGVuc2lvbnMNCiB3aWxsIGludHJvZHVjZSBuZXcgaW50ZXJhY3Rpb25zIHdoaWNoIHdpbGwg bm90IGJlIHVuaXZlcnNhbGx5IHN1cHBvcnRlZC4gQW4gaW50ZXJhY3Rpb24gbWVjaGFuaXNtIG1p Z2h0IGhhdmUgcHJvcGVydGllcyB0aGF0IGNhdXNlIHNvbWUgYWRtaW5pc3RyYXRvcnMgdG8gd2Fu dCB0byBkaXNhYmxlIGl0LCBvciB0byByZXN0cmljdCBDbGllbnRzIHRvIGFsd2F5cyB1c2UgaXQu IEFyZSB5b3UgYXNzdW1pbmcgdGhhdCBhIENsaWVudCB3aWxsIGFsd2F5cw0KIG1ha2UgYW4gT1BU SU9OUyBkaXNjb3ZlcnkgcmVxdWVzdCBmaXJzdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlsvcmljaGFubmFdJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5JIGRvbuKAmXQgc2VlIHRoZSB2YWx1ZSBvZiB0aGUg4oCccG9wdXDigJ0gaW50 ZXJhY3Rpb24gbW9kZS4gQ2xpZW50cyBjYW4gdXNlIOKAnHJlZGlyZWN04oCdIG1vZGUgd2l0aGlu IHBvcHVwcy4gSG93ZXZlciwgc3BlYWtpbmcgYXMgc29tZW9uZSB3aG8gaGFzIGRvbmUgdGhhdCwg SSByZWFsbHkgZG9u4oCZdCByZWNvbW1lbmQgaXQuIFBvcHVwcyBhcmUgaW5jcmVhc2luZ2x5IHVu c3VwcG9ydGVkLCBhbmQgcHJvbmUgdG8gd2VpcmQNCiBiZWhhdmlvcmFsIGlzc3Vlcy4gSW4tYXBw IGJyb3dzZXJzIGluIEZhY2Vib29rLCBUd2l0dGVyLCBldGMuIHRlbmQgdG8gaGF2ZSBwb3B1cHMg ZGlzYWJsZWQuIFRoZSBsYXN0IHZlcnNpb25zIG9mIElFIE1vYmlsZSBkaWRu4oCZdCBzdXBwb3J0 IHRoZW0gYXQgYWxsICh0aGUgcG9wcGVkIHVwIHBhZ2UgYmFzaWNhbGx5IGp1c3QgbG9hZGVkIGlu dG8gdGhlIGN1cnJlbnQgd2luZG93KS4gaW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBvcHVwcyBhcmUg cmVhbGx5IHVzZWZ1bCBpbiBzaW5nbGUtcGFnZSBhcHBzIGFzIHlvdSB3YW50IHRvIGtlZXAgdGhl IGNvbnRleHQgYW5kIG5vdCByZWxvYWQgdGhlIHBhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWdyZWUgdGhhdCBwb3B1cHMgZG9uJ3QgbWFrZSBzZW5z ZSBpbiBtb2JpbGUuIEEgZnVsbCByZWRpcmVjdCBkb2VzIG9mIGNvdXJzZS4gQSBzaW5nbGUtcGFn ZSBhcHAgb24gbW9iaWxlIHdvdWxkIG9wZW4gYSBuZXcgdGFiIHdoaWNoIHdvdWxkIGJlIGEgc2Vw YXJhdGUgY29udGV4dCByYXRoZXIgdGhhbiBhIHJlZGlyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3JpY2hhbm5hXTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UG9wdXBzIGFyZSBicm9rZW4gYW5k L29yIGRpc2FibGVkIGluIGVub3VnaCBpbnN0YW5jZXMgdGhhdCB3ZSBzaG91bGQgbm90IGVuY291 cmFnZSB0aGVpciB1c2FnZSBieSBpbmNsdWRpbmcgZXhwbGljaXQgc3VwcG9ydCBmb3IgdGhlbSBp biB0aGUgcHJvdG9jb2wuIE5vciBhcmUgdGhleSBuZWNlc3NhcnkgZm9yIFNQQXMgaW4gb3JkZXIg dG8gcmVzdG9yZSB0aGUgc3RhdGUgb2YgdGhlaXIgYXBwIGFmdGVyIHRoZQ0KIHJlZGlyZWN0LiBB bmQgYWdhaW4sIGEgQ2xpZW50IHRoYXQgcmVhbGx5IHdhbnRzIHRvIGdpdmUgdGhlbXNlbHZlcyBh IGhlYWRhY2hlIHdpdGggcG9wdXBzIGNhbiBkbyB0aGF0IHRoZW1zZWx2ZXMgdXNpbmcg4oCccmVk aXJlY3TigJ0gbW9kZS4gVGhleSBqdXN0IGhhdmUgdG8gcHJvdmlkZSBhIGxhbmRpbmcgcGFnZSBm b3IgdGhlIEdTIHRvIHJlZGlyZWN0IGJhY2sgdG8gdGhhdCBwYXJzZXMgdGhlIHJlc3BvbnNlLCBw YXNzZXMgaXQgYmFjayB0byB0aGUNCiBtYWluIHdpbmRvdywgYW5kIGNsb3NlcyBpdHNlbGYuIEkg ZG9u4oCZdCBzZWUgd2h5IHRoZSBwcm90b2NvbCB3b3VsZCBuZWVkIHRvIGV4cGxpY2l0bHkgZGVz Y3JpYmUgdGhpcyBtZWNoYW5pc20uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClNlY3Rpb24gMTIuNjo8bzpwPjwv bzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1tFZGl0 b3I6IGlzIHRoZXJlIHNvbWUgb3RoZXIgcmVhc29uIHRvIGhhdmUgdGhlIFVzZXJJbmZvPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBlbmRwb2ludD9dPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkkgbWF5IHdhbnQgdG8gaG9zdCBteSBV c2VySW5mbyBlbmRwb2ludCBvbiBhIHNlcGFyYXRlIG1pY3Jvc2VydmljZSBmcm9tIG15IHRva2Vu IGVuZHBvaW50IChpbiBPQXV0aCAyLjAvT0lEQyB0ZXJtcykuIFRoZSBmb3JtZXIgbWlnaHQgYmUg cGFydCBvZiBteSB1c2VyIHByb2ZpbGUvZGlyZWN0b3J5IHN0YWNrLCB3aGlsZSB0aGUgbGF0dGVy IGlzIHBhcnQgb2YgdGhlIGhpZ2hseSBwcml2aWxlZ2VkIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6 YXRpb24NCiBzdGFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRo ZSB0b2tlbiBlbmRwb2ludCBoYXMgdGhlIGFjY2VzcyB0b2tlbiBhbnl3YXksIHNvIGl0IGNhbiBm ZXRjaCB0aGUgZGF0YSBmcm9tIHRoZSBvdGhlciBlbmRwb2ludCBpdHNlbGYgaWYgaXQgd2FudGVk IHRvLiBJRSwgdGhlcmUgaXMgbm8gc2VwYXJhdGlvbiBvZiBkdXRpZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hhdCBhcmUgdGhlIGFkdmFudGFnZXMg b2YgdGhlIFVzZXJJbmZvIGVuZHBvaW50IHRvIHRoZSBVc2VyIG9yIENsaWVudD8mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgVXNlckluZm8g ZW5kcG9pbnQgc2VlbXMgdG8ganVzdCBhZGQgbW9yZSBjb21wbGV4aXR5LCB3aXRoIG5vIGFiaWxp dHkgdG8gc3RhcnQgYSBVc2VyIGludGVyYWN0aW9uIGlmIGFkZGl0aW9uYWwgY29uc2VudCBpcyBu ZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5bcmljaGFubmFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiB0aGUgYWNjZXNzIHRva2VuIGlzIHNlbmRlci1jb25zdHJhaW5lZCwgdGhlbiBubywg dGhlIHRva2VuIGVuZHBvaW50IGNhbuKAmXQgZmV0Y2ggdGhlIGRhdGEgaXRzZWxmLiBCdXQgZXZl biB3aXRob3V0IHRoZSBzZWN1cml0eSBhbmdsZSwgdGhlcmUgaXMgdmFsdWUgaW4gc2VwYXJhdGlu ZyBvdXQgdGhlIGZ1bmN0aW9uYWxpdHkgYXMgaXQgYWxsb3dzIHRoZSBHUyB0byBkaXN0cmlidXRl IGl0IGFjcm9zcyBzeXN0ZW1zDQogd2l0aCBkaWZmZXJlbnQgb3duZXJzLiBFLmcuLCB0aGVyZSBt aWdodCBiZSBhIGRpcmVjdG9yeSBBUEkgdGVhbSB0aGF0IGFsc28gb3ducyB0aGUgU0NJTSBpbnRl cmZhY2UgYW5kIFVzZXJJbmZvIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg YWR2YW50YWdlIGZvciB0aGUgQ2xpZW50IGlzIHRoYXQgdGhleSBoYXZlIGFuIGVuZHBvaW50IHRo ZXkgY2FuIGNhbGwgdG8gZ2V0IHVwLXRvLWRhdGUgZGV0YWlscyBhYm91dCB0aGUgZW5kIHVzZXIs IGV2ZW4gb3V0c2lkZSB0aGUgY29udGV4dCBvZiBhbiBhY3RpdmUgc2Vzc2lvbi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIFVzZXJJbmZvIGVuZHBvaW50IGNhbiBpbmRpY2F0ZSB0aGUgbmVl ZCBmb3IgYWRkaXRpb25hbCBjb25zZW50IHZpYSBhIDQwMSBhbmQgV1dXLUF1dGhlbnRpY2F0ZSwg anVzdCBsaWtlIGFueSBvdGhlciByZXNvdXJjZSBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlsvcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KU2VjdGlvbiAxMi44 OjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKldoeSBoYXZlIGJvdGggY2xhaW1zIGFuZCBhdXRob3JpemF0aW9ucz8qPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUgYXJlIHVzZSBjYXNlcyBmb3IgZWFj aCB0aGF0IGFyZSBpbmRlcGVuZGVudDo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0aW5nIGEgdXNlciB2 cyBncmFudGluZyBhY2Nlc3MgdG8gYSByZXNvdXJjZS4mbmJzcDsgQTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVz dCBmb3IgYW4gYXV0aG9yaXphdGlvbiByZXR1cm5zIGFuIGFjY2VzcyB0b2tlbiBvciBoYW5kbGUs PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB3aGlsZSBhIHJlcXVlc3QgZm9yIGEgY2xhaW0gcmV0dXJucyB0aGUgY2xhaW0u PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCkkgZG9u4oCZdCBhZ3JlZSB0aGF0IHRoZSB1c2UgY2FzZXMgYXJl IGRpc3RpbmN0LiBUaGUgb25seSBjbGFpbSB0aGF0IGlzIHN0cmljdGx5IG5lY2Vzc2FyeSBmb3Ig YXV0aGVudGljYXRpb24gaXMgdGhlIHVzZXIgaWRlbnRpZmllci4gT3RoZXIgY2xhaW1zIGxpa2Ug ZW1haWwgYW5kIHBob25lX251bWJlciBhcmUgb2Z0ZW4gdXNlZCB0byBhaWQgaW4gbG9jYWwgYWNj b3VudCBpZGVudGlmaWNhdGlvbiAoaS5lLiwgYWNjb3VudCBsaW5raW5nKSwgYnV0IGFyZQ0KIHVz ZWZ1bCBhbmQgaW50ZXJlc3RpbmcgYmV5b25kIHRoaXMgdXNlIGNhc2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5T b21lIENsaWVudHMgdXNlIGVtYWlsIGFuZCBwaG9uZV9udW1iZXIgYXMgdGhlIGlkZW50aWZpZXIg YW5kIGRvbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIGRpcmVjdGVkIGlkZW50aWZpZXIuIE5vdCB0 aGUgYmVzdCBwcmFjdGljZSwgYnV0IGl0IGlzIHdoYXQgcGVvcGxlIGRvLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3JpY2hh bm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBsaXRlcmFs bHkgdGhlIHNjZW5hcmlvIEkgZGVzY3JpYmVkIGluIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzZWNv bmQgc2VudGVuY2UuIFRoZSBsYXR0ZXIgcGFydCBvZiB0aGF0IHNhbWUgc2VudGVuY2Ugbm90ZXMg dGhhdCB0aG9zZSBjbGFpbXMgYXJlIHVzZWZ1bA0KPGk+YmV5b25kIHRoYXQgdXNlIGNhc2U8L2k+ LCBpLmUuLCB0aGV5IGNhbiBiZSB1c2VmdWwgZXZlbiB3aGVuIHRoZSBjbGllbnQgaXMgbm90IHVz aW5nIHRoZW0gZm9yIGF1dGhlbnRpY2F0aW9uLiBJIGFtIGRlbW9uc3RyYXRpbmcgdGhhdCB5b3Vy IOKAnGF1dGhlbnRpY2F0aW5nIGEgdXNlciB2cyBncmFudGluZyBhY2Nlc3MgdG8gYSByZXNvdXJj ZeKAnSBkaWNob3RvbXkgaXMgZmxhd2VkIGJ5IHNob3dpbmcgdGhhdCBjbGFpbXMgZG8gbm90IHN0 cmljdGx5DQogYmVsb25nIHRvIHRoZSBmb3JtZXIsIGFuZCBzb21lIHRoaW5ncyB0aGF0IGFyZSBk ZWZpbmVkIGFzIGNsYWltcyBoYXZlIG5vdGhpbmcgYXQgYWxsIHRvIGRvIHdpdGggYXV0aGVudGlj YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL3JpY2hhbm5hXTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7c25pcCZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pkkgc3Ryb25nbHkgdGhpbmsgaXQgaXMgYSBkaXNzZXJ2aWNlIHRvIG91ciBhdWRpZW5jZSB0byBj b25mbGF0ZSBjbGFpbXMgYW5kIHJlc291cmNlcy4gQ2xhaW1zIGFyZSBzdGF0ZW1lbnRzIGFib3V0 IHRoZSBVc2VyIGFuZCByZWFkLW9ubHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bcmljaGFubmFdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DbGFpbXMgYXJlIGEgc3Vic2V0IG9mIHJlc291cmNlcyB0 aGF0IE9JREMgYnVpbHQgc29tZSBleHRyYSBmZWF0dXJlcyBmb3IsIGluY2x1ZGluZyBhIHJlYWQt b25seSBpbnRlcmZhY2UgdG8gYWNjZXNzIHRoZW0uIEhvd2V2ZXIsIGNsYWltcyBhcmUgbm90IGlu aGVyZW50bHkgcmVhZC1vbmx5LCBub3IgYXJlIHRoZXkgdGhlIG9ubHkgcmVzb3VyY2VzIGZvciB3 aGljaCBhIHJlYWQtb25seSBpbnRlcmZhY2VzIG1heQ0KIGJlIGJ1aWx0IGZvci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsvcmljaGFubmFdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZsdDtzbmlwJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpJ IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHlvdeKAmXJlIHRyeWluZyB0byBzdXBwb3J0IGhlcmUs IGJ1dCBJIHRoaW5rIHRoZSBwcm9wb3NhbCBpcyB0b28gY29tcGxpY2F0ZWQgdG8gaW1wbGVtZW50 LiBGcm9tIHRoZSBzZXF1ZW5jZXMsIGl0IGxvb2tzIGxpa2UgdGhlIENsaWVudCBpcyBleHBlY3Rl ZCB0byBpc3N1ZSBhIFJlYWQgR3JhbnQgcmVxdWVzdCwgYW5kIHRoYXQgY29ubmVjdGlvbiB3aWxs IGJlIGtlcHQgb3BlbiB3aGlsZSB0aGUgVXNlciBpcw0KIHJlZGlyZWN0ZWQgdG8gdGhlIEdTIGFu ZCBnb2VzIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIHdvcmtmbG93IChhbmQgcG9zc2libHkg cGFydCBvZiB0aGUgYXV0aG9yaXphdGlvbiB3b3JrZmxvdykuIE9ubHkgdGhlbiB3b3VsZCB0aGUg R1MgcmV0dXJuIHRoZSBSZWFkIEdyYW50IHJlc3BvbnNlLiBJcyB0aGlzIGNvcnJlY3Q/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NClRvIGltcGxlbWVudCB0aGlzLCB0aGUgQ2xpZW50IGhhcyB0byBsYXVuY2ggYW4gYXN5bmNo cm9ub3VzIHRocmVhZCB0byBleGVjdXRlIHRoYXQgcmVxdWVzdCBhbmQgYXdhaXRpbmcgdGhlIHJl c3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NClBvc3NpYmxlLCBidXQgc3VzY2VwdGlibGUgdG8gZmFpbHVyZXMuIFdoYXQgaGFw cGVucyBpZiB0aGF0IHRocmVhZCBjcmFzaGVzPyBPciBmYWlscyB0byBzZW5kIHRoZSBVcGRhdGUg R3JhbnQgcmVxdWVzdCB0byBmbGlwIGludGVyYWN0aW9uLmtlZXAgdG8gZmFsc2U/IFdoYXQgaXMg dGhlIEdTIGRvaW5nIGluIHRoZSBtZWFudGltZT8gSXMgaXQganVzdCBzaG93aW5nIHRoZSBVc2Vy IGEg4oCcbG9hZGluZ+KAnSB3aWRnZXQgYXMgaXQgd2FpdHMgZm9yIHRoZQ0KIENsaWVudCB0byB1 cGRhdGUgdGhlIGdyYW50PyBIb3cgbG9uZyBkb2VzIGl0IHdhaXQgZm9yPyBGb3IgbW9iaWxlIGFw cHMsIHRoYXQgYmFja2dyb3VuZCB0aHJlYWQgbWF5IGdldCBraWxsZWQgb3IgbG9zZSBuZXR3b3Jr IGNvbm5lY3Rpdml0eSBhcyBzb29uIGFzIHRoZSB1c2VyIGdldHMgc3dpdGNoZWQgb3ZlciB0byB0 aGUgc3lzdGVtIGJyb3dzZXIgdG8gbG9hZCB0aGUgR1Mgc2lnbiBpbiBwYWdlLiBGb3IgYSBwdXJl LUpTIGFwcCB0aGF0IHJlZGlyZWN0cywNCiBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBwb3NzaWJs ZSBhdCBhbGwuICh1bmxlc3Mgd2ViIHdvcmtlcnMgY2FuIHN1cnZpdmUgcGFnZSB1bmxvYWRzPyk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0KVGhpcyBpcyBhbiBpbnRlcmVzdGluZyB1c2UgY2FzZSBmb3IgdXMgdG8gdGhpbmsg YWJvdXQsIGJ1dCBpdCBuZWVkcyBhIGxvdCBvZiB3b3JrIGFuZCBtYXkgbm90IGJlIHNvbWV0aGlu ZyB3ZSBzaG91bGQgdHJ5IHRvIGJha2UgaW50byB0aGUgY29yZSBwcm90b2NvbCBpZiB3ZSBkb27i gJl0IG5lZWQgdG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCBtaWdodCBub3QgaGF2ZSBiZWVuIG9idmlvdXMs IGJ1dCB0aGUgQ2xpZW50IGNhbGxpbmcgdGhlIEdTIHRvIGdldCBhIHJlc3VsdCB3aGlsZSB0aGUg aW50ZXJhY3Rpb24gaXMgaGFwcGVuaW5nIGlzIHdoYXQgaGFwcGVucyBpbiBhbnkgZmxvdyB3aXRo IGFuIGludGVyYWN0aW9uIHN0YXJ0ZWQgYnkgdGhlIENsaWVudC4gSXQgaXMgbm90IHVuaXF1ZSB0 byAmcXVvdDtpbnRlcmFjdGlvbiZxdW90Oy4mcXVvdDtrZWVwJnF1b3Q7DQogLS0gd2UgYXJlIGp1 c3QgYWRkaW5nIGFkZGl0aW9uYWwgYmFjayBhbmQgZm9ydGhzIGJldHdlZW4gdGhlIENsaWVudCBh bmQgR1MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QSBR UiBDb2RlIGV4YW1wbGUgSEFTIHRvIHdvcmsgdGhpcyB3YXksIGFzIHRoZXJlIGlzIG5vIG90aGVy IHdheSBmb3IgdGhlIENsaWVudCB0byBrbm93IHRoZSBpbnRlcmFjdGlvbiBoYXMgY29tcGxldGVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkdvb2dsZSBh bmQgTWljcm9zb2Z0IGJvdGggaGF2ZSBhIHNpbWlsYXIgdXNlciBleHBlcmllbmNlLiBUaGUgVXNl ciB3YW50cyB0byBsb2cgaW50byBhbiBhcHAgLS0gdGhleSBhcmUgaW5zdHJ1Y3RlZCB0byBnbyB0 byB0aGUgcmVzcGVjdGl2ZSBtb2JpbGUgYXBwIHRvIGFwcHJvdmUgdGhlIGF1dGhlbnRpY2F0aW9u IC0tIGFuZCB0aGVuIHRoZSBVc2VyIHJldHVybnMgdG8NCiB0aGUgYXBwIHdoaWNoIGNoYW5nZXMg dG8gYSBsb2dnZWQgaW4gc3RhdGUuJm5ic3A7IEFuIGF1dGhlbnRpY2F0aW9uIG9ubHkgZmxvdyB1 c2luZyBYQXV0aCB3b3VsZCB3b3JrIHRoZSBzYW1lIHdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlcmUgYXJlIHR3byBiaWcgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aG9zZSBleGFt cGxlcyAoZS5nLiwgUVIgQ29kZSwgYXBwLWJhc2VkIGxvZ2luIGFwcHJvdmFscykgYW5kIHRoaXMg bWVjaGFuaXNtIGluIFhBdXRoOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxMSBsZXZlbDEgbGZvMTIiPkluIHlvdXIg ZXhhbXBsZXMgb2YgdGhpcyBiZWhhdmlvciB0b2RheSwgdGhlIHJlYXNvbiBmb3IgdGhlIHdhaXQg aXMgY2xlYXIgYW5kIG9idmlvdXMsIGFuZCBkcml2ZW4gYnkgdGhlIHVzZXIuIEUuZy4sIG15IHBy aW50ZXIgaXMgd2FpdGluZyBmb3IgbWUgdG8gZ28gZW50ZXIgdGhpcyBjb2RlIGFuZCBsb2cgaW47 DQogR29vZ2xlIHNpZ24gaW4gaXMgd2FpdGluZyBmb3IgbWUgdG8gdGFwIHRoaXMgYnV0dG9uIG9u IG15IHBob25lLiBUaGF0IGlzIG5vdCB0aGUgY2FzZSBpbiB0aGUgWEF1dGggcHJvdG9jb2wuIFRo ZSB1c2VyIGlzIGxlZnQgc2l0dGluZyBvbiBhIGxvYWRpbmcgc2NyZWVuIHdhaXRpbmcgZm9yIGEg YmVoaW5kLXRoZS1zY2VuZXMgaW50ZXJhY3Rpb24gYmV0d2VlbiBjbGllbnQgYW5kIEdTIHRoYXQg bWF5IG5vdCBldmVuIGhhcHBlbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxMSBsZXZlbDEgbGZvMTIi PlVubGlrZSB3aXRoIGNvZGUvUVIgZmxvd3Mgb3Igc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZXJl IGlzIG5vIGFjdGl2ZSBwcm9jZXNzIG9uIHRoZSBjbGllbnQgc2lkZSB0byBrZWVwIHRoaXMgYXN5 bmMgcmVxdWVzdCBvcGVuLiBBIHdlYiBhcHAgY2xpZW50IHdvdWxkIGhhdmUgdG8gaW50cm9kdWNl IGEgc2VydmVyLXNpZGUNCiBhc3luYyBwcm9jZXNzIHRvIG1hbmFnZSB0aGlzIGFzcGVjdCBvZiB0 aGUgcHJvdG9jb2wuIFRoYXTigJlzIG5vdCBlYXN5LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDExIGxl dmVsMSBsZm8xMiI+VGhlIGZhaWx1cmUgbW9kZXMgc2hvdyB1cCBpbiBtb3JlIGFwcHJvcHJpYXRl IGNvbnRleHRzLCB3aGVyZSB0aGVyZSBhcmUgY2xlYXIgcGF0aHMgZm9yd2FyZCBmb3IgdGhlIGVu ZCB1c2VyLiBJbiBjb2RlL1FSLWJhc2VkIGZsb3dzLCBpdOKAmXMgZGV0ZWN0ZWQgb24gdGhlIGNs aWVudCBzaWRlLCBpbiB0aGUgZm9ybQ0KIG9mIGFuIEFTIHRoYXQgbmV2ZXIgcHJvdmlkZXMgYSBy ZXNwb25zZS4gSW4gdGhhdCBzY2VuYXJpbywgdGhlIGNsaWVudCBjYW4gcmV0cnkgdGhlIHByb2Nl c3MuIEluIHNpZ24taW4gdmVyaWZpY2F0aW9uLCB0aGUgcHJvYmxlbSBvY2N1cnMgYmV0d2VlbiB0 d28gcGFydHMgb2YgdGhlIEFTLCBhbmQgdGhlIEFTIGNhbiBhbGxvdyB0aGUgZW5kIHVzZXIgdG8g cmV0cnkgb3IgdG8gdXNlIGEgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4gSW4NCiB0 aGUgWEF1dGggQ3JlYXRlJiM0MztVcGRhdGUgc2NlbmFyaW8sIHRoZSBmYWlsdXJlIGlzIGRldGVj dGVkIG9uIHRoZSBHUywgYW5kIHRoZXJlIGlzIG5vIGNsZWFyIHBhdGggZm9yd2FyZC4gSWYgdGhl IENsaWVudCBuZXZlciBjYWxscyBVcGRhdGUgR3JhbnQgdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVw IHRvIGZhbHNlLCB3aGF0IHNob3VsZCB0aGUgR1MgZG8/IEhvdyBsb25nIHNob3VsZCBpdCB3YWl0 PyBTaG91bGQgaXQgaXNzdWUgdGhlIGF1dGhvcml6YXRpb24NCiBhbnl3YXksIGFzc3VtaW5nIHRo ZSBDbGllbnQgd2lsbCBjb21lIGJhY2sgYW5kIGFzayBmb3IgaXQgYXQgc29tZSBwb2ludD8gU2hv dWxkIGl0IHJlZGlyZWN0IHRoZSBlbmQgdXNlciBiYWNrIHRvIHRoZSBDbGllbnQgYW55d2F5LCBv ciBkcm9wIHRoZW0gb24gYSBsYW5kaW5nIHBhZ2U/IFNob3VsZCBpdCBmbGFnIHRoaXMgYXMgYW4g ZXJyb3IsIG9yIGlzIHRoaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGZvciB0aGUgQ2xpZW50Pzxv OnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWxseSB0aGluayB0aGlzIGlzIG92ZXJj b21wbGljYXRpbmcgdGhlIHByb3RvY29sIHRvIGFuIGV4dGVudCB0aGF0IG5vIG9uZSB3aWxsIGFj dHVhbGx5IGltcGxlbWVudCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlsvcmljaGFubmFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltwYXN0aW5nIGluIGZyb20geW91 ciBsYXRlciBlbWFpbF08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5XaGlsZSBhIHNpbmdsZSBzdGFnZSBHcmFudCByZXF1ZXN0ICgz LjEpIGluIGEgbW9iaWxlIGFwcCB0aGF0IGhhcyBiZWVuIHB1dCB0byBzbGVlcCB3aWxsIHJlY292 ZXIgZmluZSwgYSBtdWx0aS1zdGVwICgzLjQpIHdpbGwgZmFpbC4gU2luY2UgMy40IG9ubHkgbWFr ZXMgc2Vuc2UgaWYgdGhlIENsaWVudCBpcyBjaGVja2luZyBhIGRhdGFiYXNlIGFsb25nIHRoZSB3 YXksDQogSSB3b3VsZCZuYnNwO2V4cGVjdCB0aGUgQ2xpZW50IHRvIGhhdmUgYSBzZXJ2ZXIgc2lk ZSwgYW5kIHRoZSBzZXJ2ZXIgY291bGQgdGFrZSBlYWNoIHN0ZXAuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5bL2VuZCBwYXN0ZV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5nIGEg cmVtb3RlIGRhdGFiYXNlIGFuZCBoYXZpbmcgYSByZW1vdGUgc2VydmVyIGFyZSBub3QgdGhlIHNh bWUgdGhpbmcuIFRoaXMgYWRkcyBhIGxvdCBvZiBjb21wbGV4aXR5IHRvIHNlcnZlcmxlc3MgYXBw cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsvcmljaGFubmFdPGltZyBi b3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNw b3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9 emVyb2NvbnRlbnQmYW1wO2d1aWQ9N2NkMThlYTYtOGM1MC00NmRjLWJlMjUtZTk5ZjYxNGRhYjgy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F770E76D07D4464A6AE2442AE055B43amazoncom_-- From nobody Fri Feb 14 01:25:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4742F1200E7 for ; Fri, 14 Feb 2020 01:24:59 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 (1024-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cy8lqicF-Kx for ; Fri, 14 Feb 2020 01:24:55 -0800 (PST) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7BF1200A3 for ; Fri, 14 Feb 2020 01:24:54 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 14D303853D4; Fri, 14 Feb 2020 09:24:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1581672292; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zPE9A2aX8aTS8YDBIS5bDZTrs2KxPt5uaFXJ8XCElXE=; b=TmibgjigDa/7MhDnZT2OEy7kHcFH/wIeN+ZY4vvq5VUmy+aUrt5htWfgNacqRB23PthyN0 O/37DXnrecVe+UJlH2tfJGhXYpPHBQlcBzeh9zAOpZlXOwz318sUI8+WfP+q16FujxeG8A yU5/1BNVudqUCGYNC+SmV1GF/NOepUo= From: David Waite Message-Id: <22536DE3-E90E-4543-A668-D89054D2401C@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F23D8783-650A-450C-B63C-17440977E3E8" Mime-Version: 1.0 Date: Fri, 14 Feb 2020 02:24:50 -0700 In-Reply-To: Cc: Justin Richer , txauth@ietf.org To: Dick Hardt References: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1581672293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zPE9A2aX8aTS8YDBIS5bDZTrs2KxPt5uaFXJ8XCElXE=; b=XmJlfSwEoSEuAuVE1OB2UJnvAZAIsRZyy7Jl1ovawb+rVC/NBXY14HgEjYJVFAqd2hHTYS b7Whuc1PYfT6JRFihj4R+3jTjSb7rqEHxVRJC2LrfEERivK3Z7X6PNtW76TK5F5I7gOvp7 LFRuqDd6uDncoPtGiD2StVUaftiBNYw= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1581672293; a=rsa-sha256; cv=none; b=QPiIMw3o8TU7+vTcUCvS+R2aFAPKkoDP0uGCtfkTpc+aVFhpYf28jcS72wz4Yx3HqHUedH 9RFEMvZ3lp8uVV/A7vwhlX/r4K/PZwafixwvQYm5kY5hUsxebc45PyS6G8CMJlJfXw2TvY 1x2P9ytthLQJKLOI1QWrxxj0wpROBx8= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: + Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 09:24:59 -0000 --Apple-Mail=_F23D8783-650A-450C-B63C-17440977E3E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 13, 2020, at 9:35 AM, Dick Hardt wrote: >=20 >=20 >=20 > On Thu, Feb 13, 2020 at 8:00 AM Justin Richer > wrote: > I=E2=80=99ve been doing some implementation of OIDC session management = lately, and I had a realization that the pattern in TxAuth can give us a = chance to do something a lot better. >=20 > In OIDC, you use the ID token as a secondary artifact to indicate = which client you are and which session you=E2=80=99re talking about. = This is used as a drive-by client authentication (even though it=E2=80=99s= really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers internally, >=20 > Is carrying the session identifiers specified somewhere, or is this an = implementation decision? TL;DR - redirect-based logout flows are not only brittle (and becoming = more brittle over time as browsers change their policies) but also = growing out of fashion, outside of =E2=80=98aggregate=E2=80=99 = applications where the different components are integrated via a single = user agent and redirect-based SSO. We get far more value treating = identity/authentication tokens similarly to access tokens - that they = may have a defined lifetime, and may also be revoked via some = back-channel mechanism, then we get by assuming there is some sort of = common concept of authentication session. I personally prefer to think of the =E2=80=9Csingle logout=E2=80=9D = being revocation of an authentication token, rather than being related = to any concept of distributed session. The security recommendations = indicate you should not evaluate local access based on an expired or = revoked authentication token.=20 The relying party does not know the reasons behind the business policies = for setting a token lifetime or for doing revocation, nor do they know = up-front whether the process of getting a new authentication token can = be done back-channel with no interaction, nor whether active user = interaction (such as authentication) is required to succeed. They just = know they shouldn=E2=80=99t rely on an invalidated token. Traditional redirect-based SSO works because the same user agent is = involved and serves as bearer for messages between the RP and IDP. SLO = exists to serve two needs here: 1. User expectation is that within the same user agent, access as a user = is either universally available or universally denied. The =E2=80=9CLogout= =E2=80=9D button in this scenario is a signal from the user that they = may not be the next entity that interacts with the system, and that = authentication should be reacquired. 2. The user or an operation may expect the ability to revoke consent = (and associated access) to users/clients/relying parties/user agents on = demand. Much of the SLO deployment today is to satisfy the first case, and will = rely on the fact that authentication took place via redirects on the = same user agent in order to delete artifacts of the original SSO, such = as session cookies.=20 The redirect-based technique used to implement SLO today however does = not serve the needs of the second case, and even with the first case its = usability is being eroded by privacy efforts in browsers destabilizing = cookie usage in multi-party scenarios. For TXAuth, the IDP interaction may be entirely on some other user = agent, such as via the device flow or a CIBA-like flow. Once you = abstract out the mechanism of interaction to this extent, the use of = redirect-based flows becomes untenable. You also have a changing user expectation that the authentication serves = merely as a linking of personas between the two parties, and that each = will do their own access management after that point. For example, an = application like Slack (whether in web or native app user deployment) = does not log the user out merely because the backing Google/GSuite = account logged out. IMHO this expectation is even stronger in cases = where you are using multiple user agents, possibly spanning multiple = devices.=20 Some of this has been served by the mobile initiative over the last = dozen years or so pushing for devices to be treated as being single user = and/or managed access - the authentication security policy has gone in = many places from being implemented within the browser to being = implemented at the device level. An enterprise application may use = identity tokens to determine that it is in compliance, but the actual = tokens themselves may come from the managed device policy. In both of these cases, scenario 2 is more likely - that the user = consent for an app has gone away, or that access is being revoked = because a device has gone out of compliance. The case where scenario 1 is still most needed is consumer web = applications developed with delegated authentication (SAML, OIDC) as the = integration between components. I believe this is possible to support, = although the components would be limited to integration via the = interaction endpoint. IMHO the only reason this would need some sort of = signed message or identifier would be to prevent XSRF abuse. =20 > - When the user wants to log out, client can send that back to the AS = in the back channel, and get back an interaction mechanism that the = client can use to interact with the AS for determining if they want to = kill the session there as well.=20 > - The AS can group together different clients into a =E2=80=9Csingle = sign out=E2=80=9D cluster=20 Note that for many applications, it does not make sense that the client = would (to try to stay closer to my earlier parlance) signal that the AS = should revoke other authentications, as the client does not dictate nor = understand AS policy nor the policy or user expectations of other = applications. User-initiated logout on a managed device for example = would likely be a no-op. As you say, the only sort of application I have seen where this makes = sense is the previously mentioned aggregate of web applications via = delegated authentication. GSuite, for example, adds a two-click method = to cancel access to every GSuite application - but they do not expose = any logout mechanism to third party applications (at least via their = metadata.) It is also worth noting that this is done via embedded = frames, as a redirect-based mechanism would be insufficient. If a client has the capability to revoke different kinds of tokens, then = the revocation of an authentication token within a client could be taken = as a signal to revoke multiple tokens based on some grouping. This could = leverage something like OIDC=E2=80=99s sector identifier uri, although = the issuer of the tokens would still need to have some sort of dynamic = correlation to only revoke tokens issued to those clients on the same = device or within the same user agent. This is usually implemented today = via web redirects and IDP state stored within cookies - but this = approach has begun to break down with browser efforts to limit = cross-site cookie abuses. > - When the AS learns that the user wants to log out, it might be able = to push messages out to other clients =E2=80=94 maybe they register back = channel callback endpoints, or maybe a push message over http/2 or 3 or = COAP, or some other mechanism. But the client can push that information = in the initial request, and it can be user- and session- specific.=20 With externally revoked access tokens, the client does not need a signal = since the protected resources should be evaluating validity. With = authentication tokens, the client needs to have a way to check validity. The center of TXAuth is likely to be an interactor that coordinates with = the various parties. I expect numerous extensions to define particular = interaction strategies for all the parties involved, and not just the = authorizing/authenticating user agent as we have today with multiple = OAuth grant types/=E2=80=9Cflows=E2=80=9D. So a client might get revocation messages via web push, via SET = mechanisms, or do so via polling. I proposed an API for poliing a while = back for OIDC which may be repurposed (the API was designed with some = additional complexity under the assumption that there may be multiple = providers for the token revocation information). = https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6= d08fe79/distributed-token-validity-api.txt > Mapping this to XAuth, a Client could update the Grant URI with a PUT = to logout all sessions, and as you mention, the GS could respond with an = interaction object for the Client to transfer interaction to the GS. >=20 > Other Clients could regularly read the Grant URI, and the logged in = status can be returned, or it could be a long lasting connection that = returns a logged out response if the User is logged out somewhere else. > =20 >=20 > These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me = that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before. >=20 > Agreed. Neither is what I wrote above -- but with an established back = channel from Client to GS, there are interesting things that can be = done.. > =20 >=20 > To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.=20 >=20 > Agreed > =20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_F23D8783-650A-450C-B63C-17440977E3E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Feb 13, 2020, at 9:35 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Feb 13, 2020 at 8:00 AM Justin Richer = <jricher@mit.edu> wrote:
I=E2=80=99ve been doing some = implementation of OIDC session management lately, and I had a = realization that the pattern in TxAuth can give us a chance to do = something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which = client you are and which session you=E2=80=99re talking about. This is = used as a drive-by client authentication (even though it=E2=80=99s = really another bearer token sent through the front channel), which is = what lets you do a post-logout redirect in a somewhat safe manner. The = ID token is also used to carry session identifiers = internally,

Is carrying the session identifiers specified somewhere, or = is this an implementation = decision?

TL;DR - redirect-based logout flows are not only = brittle (and becoming more brittle over time as browsers change their = policies) but also growing out of fashion, outside of =E2=80=98aggregate=E2= =80=99 applications where the different components are integrated via a = single user agent and redirect-based SSO. We get far more value treating = identity/authentication tokens similarly to access tokens - that they = may have a defined lifetime, and may also be revoked via some = back-channel mechanism, then we get by assuming there is some sort of = common concept of authentication session.

I personally prefer to think of the =E2=80=9Csingle = logout=E2=80=9D being revocation of an authentication token, rather than = being related to any concept of distributed session. The security = recommendations indicate you should not evaluate local access based on = an expired or revoked authentication token. 

The relying party does not know the reasons behind = the business policies for setting a token lifetime or for doing = revocation, nor do they know up-front whether the process of getting a = new authentication token can be done back-channel with no interaction, = nor whether active user interaction (such as authentication) is required = to succeed. They just know they shouldn=E2=80=99t rely on an invalidated = token.

Traditional redirect-based = SSO works because the same user agent is involved and serves as bearer = for messages between the RP and IDP. SLO exists to serve two needs = here:
1. User expectation is that within the same user agent, = access as a user is either universally available or universally denied. = The =E2=80=9CLogout=E2=80=9D button in this scenario is a signal from = the user that they may not be the next entity that interacts with the = system, and that authentication should be reacquired.
2. The = user or an operation may expect the ability to revoke consent (and = associated access) to users/clients/relying parties/user agents on = demand.

Much of the SLO deployment = today is to satisfy the first case, and will rely on the fact that = authentication took place via redirects on the same user agent in order = to delete artifacts of the original SSO, such as session = cookies. 

The redirect-based = technique used to implement SLO today however does not serve the needs = of the second case, and even with the first case its usability is being = eroded by privacy efforts in browsers destabilizing cookie usage in = multi-party scenarios.

For TXAuth, = the IDP interaction may be entirely on some other user agent, such as = via the device flow or a CIBA-like flow. Once you abstract out the = mechanism of interaction to this extent, the use of redirect-based flows = becomes untenable.

You also have = a changing user expectation that the authentication serves merely as a = linking of personas between the two parties, and that each will do their = own access management after that point. For example, an application like = Slack (whether in web or native app user deployment) does not log the = user out merely because the backing Google/GSuite account logged out. =  IMHO this expectation is even stronger in cases where you are = using multiple user agents, possibly spanning multiple = devices. 

Some of this has been served by the mobile initiative = over the last dozen years or so pushing for devices to be treated as = being single user and/or managed access - the authentication security = policy has gone in many places from being implemented within the browser = to being implemented at the device level. An enterprise application may = use identity tokens to determine that it is in compliance, but the = actual tokens themselves may come from the managed device = policy.

In both of these cases, scenario 2 is more likely - that = the user consent for an app has gone away, or that access is being = revoked because a device has gone out of compliance.

The case where scenario 1 is = still most needed is consumer web applications developed with delegated = authentication (SAML, OIDC) as the integration between components. I = believe this is possible to support, although the components would be = limited to integration via the interaction endpoint. IMHO the only = reason this would need some sort of signed message or identifier would = be to prevent XSRF = abuse.
 
<snip>

- When the user wants to log = out, client can send that back to the AS in the back channel, and get = back an interaction mechanism that the client can use to interact with = the AS for determining if they want to kill the session there as well. =
- The AS can = group together different clients into a =E2=80=9Csingle sign out=E2=80=9D = cluster 

Note that for many applications, it does not make sense = that the client would (to try to stay closer to my earlier parlance) = signal that the AS should revoke other authentications, as the client = does not dictate nor understand AS policy nor the policy or user = expectations of other applications. User-initiated logout on a managed = device for example would likely be a no-op.

As you say, the only sort of application I have = seen where this makes sense is the previously mentioned aggregate of web = applications via delegated authentication. GSuite, for example, adds a = two-click method to cancel access to every GSuite application - but they = do not expose any logout mechanism to third party applications (at least = via their metadata.) It is also worth noting that this is done via = embedded frames, as a redirect-based mechanism would be = insufficient.

If a client has the = capability to revoke different kinds of tokens, then the revocation of = an authentication token within a client could be taken as a signal to = revoke multiple tokens based on some grouping. This could leverage = something like OIDC=E2=80=99s sector identifier uri, although the issuer = of the tokens would still need to have some sort of dynamic correlation = to only revoke tokens issued to those clients on the same device or = within the same user agent. This is usually implemented today via web = redirects and IDP state stored within cookies - but this approach has = begun to break down with browser efforts to limit cross-site cookie = abuses.

- When the AS learns that the user = wants to log out, it might be able to push messages out to other clients = =E2=80=94 maybe they register back channel callback endpoints, or maybe = a push message over http/2 or 3 or COAP, or some other mechanism. But = the client can push that information in the initial request, and it can = be user- and session- specific.

With externally revoked access tokens, the client = does not need a signal since the protected resources should be = evaluating validity. With authentication tokens, the client needs to = have a way to check validity.

The = center of TXAuth is likely to be an interactor that coordinates with the = various parties. I expect numerous extensions to define particular = interaction strategies for all the parties involved, and not just the = authorizing/authenticating user agent as we have today with multiple = OAuth grant types/=E2=80=9Cflows=E2=80=9D.

So a client might get revocation messages via web = push, via SET mechanisms, or do so via polling. I proposed an API for = poliing a while back for OIDC which may be repurposed   (the API = was designed with some additional complexity under the assumption that = there may be multiple providers for the token revocation = information). https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b088= 72ddd73cea6d08fe79/distributed-token-validity-api.txt

Mapping this to = XAuth, a Client could update the Grant URI with a PUT to logout all = sessions, and as you mention, the GS could respond with an interaction = object for the Client to transfer interaction to the GS.

Other Clients could = regularly read the Grant URI, and the logged in status can be returned, = or it could be a long lasting connection that returns a logged out = response if the User is logged out somewhere else.
 

These ideas aren=E2=80=99t fully baked, but it=E2=80=99s seeming to me = that with this new pattern we=E2=80=99ve got a chance to make a much = cleaner take on sessions than we were able to do before.

Agreed. Neither is what I wrote above -- but with an = established back channel from Client to GS, there are interesting things = that can be done..
 

To be clear, I=E2=80=99m not saying any of this belongs explicitly in = the charter, or that this is something that we need to tackle right now, = but I think that addressing this eventually will make sense as part of = the identity work as we move forward.

Agreed
 

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_F23D8783-650A-450C-B63C-17440977E3E8-- From nobody Fri Feb 14 07:15:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B911200B3 for ; Fri, 14 Feb 2020 07:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 apl2nlt2uU92 for ; Fri, 14 Feb 2020 07:15:47 -0800 (PST) Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.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 1101E120041 for ; Fri, 14 Feb 2020 07:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1581693346; bh=5yUHwPplqjGjmdbGueQViu7SL1BSxfUii1gbNZwv9S4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=OHNizj1TdeyVtcrlqyia1tnfbfKoPSFK5GY36NGs4PVMxImUSLTWwJDF9XV/v/owhmFhG2HOLbpCOuXcjvMCQt61sjAoLa6qcDPMwbsDVJUvVHsZLurwKp/bCJd8RLih3Eya4bQXPCKNrFeRfBNYC0Hxyayl/6LnNsC5ila9TWntwg9JhOIFNmY4TZNBYqBh+jC+04X7ycEZU9hoD316EpV+BAWcBHVqt4+YJi0KLwByNZOm+9FD9aDu0wiukgj7RI7zwUu9U8WR1BRjFEbGcU8pDE+bfuCcFMyZJkrQVOd01ZTuqwr55Yq+JHxbvPq1l0km2N60V76Yw/kNnR8IuA== X-YMail-OSG: 77ZGFjcVM1kRXuqU4Pjp7VfewPcr7JTLRVA7QKBVfh.qftUmRTzo7CAuv0pHZSk HVxILglO4PMggWZtVetTPOn3xpZeTmqC.QBUIafUbuPySPQUPDoAItTn_ez2vJ8pjYAfR8bYY2zi hry4qkMrkL0_pyfD.JaxFvxgn.jqNxAasj61K9Z3PAwE4T6WiqXuAdttIw7qxMPR34dLIZVvQZfF XSDOne8EG0RcLE6Yrsgf_fPh0rtGgA4MSH58F0stcUSM0A7gRTOOMXyWkUcyMz9hULD4tXMbXDkk Kf0ER86OYHdrqoIrSBCsoCWzCKfSRBscYzimcZaPeCwEfmTAEt9qXP0b1A6Sz_PZBfw0DgsjpXqP gLCFTp1c4Ygh5WNTJrP_nhx4Udi4Adnjz_AEIsmjA6NA9sx_srYKGRqV53oBCfFM.VaNBU_Q8OrL Cc4fd4ryl5NoDJRvQVaQpgu.pYg5D_8nVyFBVGRA2j7V8dUXH6_ujOyoYnSOMtZ4_zJnp_.kyuvD jYRT.vXUB3Kuld.alm1YSyFs4SjW6m.f2aQYOKQjQbEcCKIY4wVDO_RtRWE_7j0c4aE8buDTx_T9 AaPght20P4hAv4XIw1VcVOHOObOnO1yvt81NkuICJ29SM1.tGhzyhimQWO.kUoDpTCyi49xleJ3H YLff.hEC4Ugro51LTW5yflppVLSlzPuVZHNhrd8jUBSARcPM2.PTwkjQIVfWwuY_lF8FchKzduFR El5bgN699vYkVXgiFGGnNsU_AAz28Sxn_XgzSCEjQ7BC6IKZGzloxzs0AJVM4tATZaXAkryLUS54 pK8H4DlFJuU0sUdVRZBRieQEUpd1zGuCfmTBt2MdkZAvykiMj9zYvIFppozwi8vs0r2kYf1BJZRE Pdw7gu8EviMU0wOqncCdHGCP0GWcnld2ceBTzMpNcjCahp21D5rOLp_etXdMSrI1dnd09Ui0hYlH HjF8DuiP5Y.1lxgloGtXFehiE5lCYy_fOTXPtsfbBKd2GBJep1CUax9E4IT4eMHDsbc5.Gs9DpRF 3p0YrmuPjHePTJ_0TYjjcBZPTHVEXeDhcBTFT8CmWrpdoReZ2QisWRLIaHOfEQEWBLkmMlzEmwJg ._lIo2WJHX.47nXvfVtcULOcMfj1FQRReJXSdsy4je84oBfFhCfCc1b3mqAfXqetqavC7t_bgvle nBxj4lBX5vh2R7AAf.lwhxXpLAhU8DU1jJnthNudAxrhOfvNNaizaVQ3MehpNCeuqPQ.aU4EQFCw ZPOaLDmD2mXWvJHNTwHIJWRFUMeXhopS6efxgicg8apGe3T9ATlXkzZ1UTpQrsFTQg1wKHQBLpEz uDaEmiO5j4hDivIi_orL464v4HLRngH.dUqtY8b4rsFKC4FmBbUYWtly2M5R5xao02Qp1wA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Fri, 14 Feb 2020 15:15:46 +0000 Received: by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b6e2c32b2ccab527c736e21f755afb72; Fri, 14 Feb 2020 15:15:44 +0000 (UTC) To: David Waite , Dick Hardt Cc: txauth@ietf.org, Justin Richer References: <22536DE3-E90E-4543-A668-D89054D2401C@alkaline-solutions.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 14 Feb 2020 10:15:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <22536DE3-E90E-4543-A668-D89054D2401C@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="------------01F2B891934679AC2849CD4D" Content-Language: en-US X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 15:15:50 -0000 This is a multi-part message in MIME format. --------------01F2B891934679AC2849CD4D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I think there are multiple use cases and perspectives when it comes to session management and usability on the web. As for perspectives, we have: 1. The user and the experience they are expecting 2. The relying party and how they are viewing authentication and session management As for use cases, we have: 1. Relying parties that support Federated Authentication and then manage the resulting session themselves. In this context the session is really an RP session and NOT and IDP session. 2. Relying parties that want to be tightly bound to the IDP session. This is often true of services that are "1st party" to the domain of the IDP (e.g. Yahoo services and the Yahoo IDP). Let's call use case (1) RP-Bound Session management and use case (2) IDP-Bound session management. From the users perspective, the "order of operations" also matters. Take the following scenarios. 1. User goes to hikingtrail.example and clicks the "Sign in with Google" button. The user is both SSO'd into Google properties and also logged into hikingtrail.example. The user only has one tab open for hikingtrail.example and when the user is finished with their activities at hikingtrail.example, they click the logout button. 1. If hikingtrail.example is using the RP-Bound session model, they log the user out of hikingtrail.example but the user is still logged in at Google. If the user were to click the signin button, they would be silently signed in with a new RP-Bound session. This can be confusing to users because they may have expected to be logged out of Google as the only open tab was for hikingtrail.example. 2. If hikingtrail.example is using the IDP-Bound session model, then it needs a way to signal to Google that the user wants the IDP session to be revoked when the user clicks the logout button on hikingtrail.example. From an IDP with "1st party" services perspective, it's "dangerous" to provide this mechanism to relying parties. 2. User goes to Google and logs in to read their mail. The user then opens a second tab and navigates to hikingtrail.example and clicks the "Sign in with Google" button and is seamlessly logged in. When the user finishes and clicks the "logout" button on hikingtrail.example they are logged out of the site. 1. If hikingtrail.example is using the RP-Bound session model, the site clears it's session and displays the logged out version of the site. This is exactly what the user expects. If the user clicks the "Sign in with Google" button they will be seamlessly logged in and that is also what the user expects because they still have tab open for gmail. 2. If hikingtrail.example is using the IDP-Bound session model, the user gets logged out of their gmail experience as well as hikingtrail.example. This is something the IDP (if it provides 1st party services) does not want to happen. Today, many of the SaaS products we use in the enterprise use a RB-Bound session model.  We seem to manage. However, there are some services that require an IDP-Bound session model and those are at times annoying because I get logged out of the enterprise IDP just be logging out of the SaaS tool. Maybe one option that could be explored is allowing an RP to indicate to the IDP that it does not want an IDP-Session to be created for this user/device if one doesn't currently exist. Today this would manifest as the IDP NOT setting SSO cookies on it's own domain and just returning the federated authentication tokens. Hopefully that is helpful in some way :) On 2/14/20 4:24 AM, David Waite wrote: >> On Feb 13, 2020, at 9:35 AM, Dick Hardt > > wrote: >> >> >> >> On Thu, Feb 13, 2020 at 8:00 AM Justin Richer > > wrote: >> >> I’ve been doing some implementation of OIDC session management >> lately, and I had a realization that the pattern in TxAuth can >> give us a chance to do something a lot better. >> >> In OIDC, you use the ID token as a secondary artifact to indicate >> which client you are and which session you’re talking about. This >> is used as a drive-by client authentication (even though it’s >> really another bearer token sent through the front channel), >> which is what lets you do a post-logout redirect in a somewhat >> safe manner. The ID token is also used to carry session >> identifiers internally, >> >> >> Is carrying the session identifiers specified somewhere, or is this >> an implementation decision? > > TL;DR - redirect-based logout flows are not only brittle (and becoming > more brittle over time as browsers change their policies) but also > growing out of fashion, outside of ‘aggregate’ applications where the > different components are integrated via a single user agent and > redirect-based SSO. We get far more value treating > identity/authentication tokens similarly to access tokens - that they > may have a defined lifetime, and may also be revoked via some > back-channel mechanism, then we get by assuming there is some sort of > common concept of authentication session. > > I personally prefer to think of the “single logout” being revocation > of an authentication token, rather than being related to any concept > of distributed session. The security recommendations indicate you > should not evaluate local access based on an expired or revoked > authentication token. > > The relying party does not know the reasons behind the business > policies for setting a token lifetime or for doing revocation, nor do > they know up-front whether the process of getting a new authentication > token can be done back-channel with no interaction, nor whether active > user interaction (such as authentication) is required to succeed. They > just know they shouldn’t rely on an invalidated token. > > Traditional redirect-based SSO works because the same user agent is > involved and serves as bearer for messages between the RP and IDP. SLO > exists to serve two needs here: > 1. User expectation is that within the same user agent, access as a > user is either universally available or universally denied. The > “Logout” button in this scenario is a signal from the user that they > may not be the next entity that interacts with the system, and that > authentication should be reacquired. > 2. The user or an operation may expect the ability to revoke consent > (and associated access) to users/clients/relying parties/user agents > on demand. > > Much of the SLO deployment today is to satisfy the first case, and > will rely on the fact that authentication took place via redirects on > the same user agent in order to delete artifacts of the original SSO, > such as session cookies. > > The redirect-based technique used to implement SLO today however does > not serve the needs of the second case, and even with the first case > its usability is being eroded by privacy efforts in browsers > destabilizing cookie usage in multi-party scenarios. > > For TXAuth, the IDP interaction may be entirely on some other user > agent, such as via the device flow or a CIBA-like flow. Once you > abstract out the mechanism of interaction to this extent, the use of > redirect-based flows becomes untenable. > > You also have a changing user expectation that the authentication > serves merely as a linking of personas between the two parties, and > that each will do their own access management after that point. For > example, an application like Slack (whether in web or native app user > deployment) does not log the user out merely because the backing > Google/GSuite account logged out.  IMHO this expectation is even > stronger in cases where you are using multiple user agents, possibly > spanning multiple devices. > > Some of this has been served by the mobile initiative over the last > dozen years or so pushing for devices to be treated as being single > user and/or managed access - the authentication security policy has > gone in many places from being implemented within the browser to being > implemented at the device level. An enterprise application may use > identity tokens to determine that it is in compliance, but the actual > tokens themselves may come from the managed device policy. > > In both of these cases, scenario 2 is more likely - that the user > consent for an app has gone away, or that access is being revoked > because a device has gone out of compliance. > > The case where scenario 1 is still most needed is consumer web > applications developed with delegated authentication (SAML, OIDC) as > the integration between components. I believe this is possible to > support, although the components would be limited to integration via > the interaction endpoint. IMHO the only reason this would need some > sort of signed message or identifier would be to prevent XSRF abuse. > > >> - When the user wants to log out, client can send that back to >> the AS in the back channel, and get back an interaction mechanism >> that the client can use to interact with the AS for determining >> if they want to kill the session there as well. >> >> - The AS can group together different clients into a “single sign >> out” cluster >> > > Note that for many applications, it does not make sense that the > client would (to try to stay closer to my earlier parlance) signal > that the AS should revoke other authentications, as the client does > not dictate nor understand AS policy nor the policy or user > expectations of other applications. User-initiated logout on a managed > device for example would likely be a no-op. > > As you say, the only sort of application I have seen where this makes > sense is the previously mentioned aggregate of web applications via > delegated authentication. GSuite, for example, adds a two-click method > to cancel access to every GSuite application - but they do not expose > any logout mechanism to third party applications (at least via their > metadata.) It is also worth noting that this is done via embedded > frames, as a redirect-based mechanism would be insufficient. > > If a client has the capability to revoke different kinds of tokens, > then the revocation of an authentication token within a client could > be taken as a signal to revoke multiple tokens based on some grouping. > This could leverage something like OIDC’s sector identifier uri, > although the issuer of the tokens would still need to have some sort > of dynamic correlation to only revoke tokens issued to those clients > on the same device or within the same user agent. This is usually > implemented today via web redirects and IDP state stored within > cookies - but this approach has begun to break down with browser > efforts to limit cross-site cookie abuses. > >> - When the AS learns that the user wants to log out, it might be >> able to push messages out to other clients — maybe they register >> back channel callback endpoints, or maybe a push message over >> http/2 or 3 or COAP, or some other mechanism. But the client can >> push that information in the initial request, and it can be user- >> and session- specific. >> > > With externally revoked access tokens, the client does not need a > signal since the protected resources should be evaluating validity. > With authentication tokens, the client needs to have a way to check > validity. > > The center of TXAuth is likely to be an interactor that coordinates > with the various parties. I expect numerous extensions to define > particular interaction strategies for all the parties involved, and > not just the authorizing/authenticating user agent as we have today > with multiple OAuth grant types/“flows”. > > So a client might get revocation messages via web push, via SET > mechanisms, or do so via polling. I proposed an API for poliing a > while back for OIDC which may be repurposed   (the API was designed > with some additional complexity under the assumption that there may be > multiple providers for the token revocation information). > https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6d08fe79/distributed-token-validity-api.txt > >> Mapping this to XAuth, a Client could update the Grant URI with a PUT >> to logout all sessions, and as you mention, the GS could respond with >> an interaction object for the Client to transfer interaction to the GS. >> >> Other Clients could regularly read the Grant URI, and the logged in >> status can be returned, or it could be a long lasting connection that >> returns a logged out response if the User is logged out somewhere else. >> >> >> These ideas aren’t fully baked, but it’s seeming to me that with >> this new pattern we’ve got a chance to make a much cleaner take >> on sessions than we were able to do before. >> >> >> Agreed. Neither is what I wrote above -- but with an established back >> channel from Client to GS, there are interesting things that can be >> done.. >> >> >> To be clear, I’m not saying any of this belongs explicitly in the >> charter, or that this is something that we need to tackle right >> now, but I think that addressing this eventually will make sense >> as part of the identity work as we move forward. >> >> >> Agreed >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > --------------01F2B891934679AC2849CD4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think there are multiple use cases and perspectives when it comes to session management and usability on the web.

As for perspectives, we have:
1. The user and the experience they are expecting
2. The relying party and how they are viewing authentication and session management

As for use cases, we have:
1. Relying parties that support Federated Authentication and then manage the resulting session themselves. In this context the session is really an RP session and NOT and IDP session.
2. Relying parties that want to be tightly bound to the IDP session. This is often true of services that are "1st party" to the domain of the IDP (e.g. Yahoo services and the Yahoo IDP).

Let's call use case (1) RP-Bound Session management and use case (2) IDP-Bound session management.

From the users perspective, the "order of operations" also matters. Take the following scenarios.
  1. User goes to hikingtrail.example and clicks the "Sign in with Google" button. The user is both SSO'd into Google properties and also logged into hikingtrail.example. The user only has one tab open for hikingtrail.example and when the user is finished with their activities at hikingtrail.example, they click the logout button.
    1. If hikingtrail.example is using the RP-Bound session model, they log the user out of hikingtrail.example but the user is still logged in at Google. If the user were to click the signin button, they would be silently signed in with a new RP-Bound session. This can be confusing to users because they may have expected to be logged out of Google as the only open tab was for hikingtrail.example.
    2. If hikingtrail.example is using the IDP-Bound session model, then it needs a way to signal to Google that the user wants the IDP session to be revoked when the user clicks the logout button on hikingtrail.example. From an IDP with "1st party" services perspective, it's "dangerous" to provide this mechanism to relying parties.
  2. User goes to Google and logs in to read their mail. The user then opens a second tab and navigates to hikingtrail.example and clicks the "Sign in with Google" button and is seamlessly logged in. When the user finishes and clicks the "logout" button on hikingtrail.example they are logged out of the site.
    1. If hikingtrail.example is using the RP-Bound session model, the site clears it's session and displays the logged out version of the site. This is exactly what the user expects. If the user clicks the "Sign in with Google" button they will be seamlessly logged in and that is also what the user expects because they still have tab open for gmail.
    2. If hikingtrail.example is using the IDP-Bound session model, the user gets logged out of their gmail experience as well as hikingtrail.example. This is something the IDP (if it provides 1st party services) does not want to happen.

Today, many of the SaaS products we use in the enterprise use a RB-Bound session model.  We seem to manage. However, there are some services that require an IDP-Bound session model and those are at times annoying because I get logged out of the enterprise IDP just be logging out of the SaaS tool.

Maybe one option that could be explored is allowing an RP to indicate to the IDP that it does not want an IDP-Session to be created for this user/device if one doesn't currently exist. Today this would manifest as the IDP NOT setting SSO cookies on it's own domain and just returning the federated authentication tokens.

Hopefully that is helpful in some way :)

On 2/14/20 4:24 AM, David Waite wrote:
On Feb 13, 2020, at 9:35 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Feb 13, 2020 at 8:00 AM Justin Richer <jricher@mit.edu> wrote:
I’ve been doing some implementation of OIDC session management lately, and I had a realization that the pattern in TxAuth can give us a chance to do something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which client you are and which session you’re talking about. This is used as a drive-by client authentication (even though it’s really another bearer token sent through the front channel), which is what lets you do a post-logout redirect in a somewhat safe manner. The ID token is also used to carry session identifiers internally,

Is carrying the session identifiers specified somewhere, or is this an implementation decision?

TL;DR - redirect-based logout flows are not only brittle (and becoming more brittle over time as browsers change their policies) but also growing out of fashion, outside of ‘aggregate’ applications where the different components are integrated via a single user agent and redirect-based SSO. We get far more value treating identity/authentication tokens similarly to access tokens - that they may have a defined lifetime, and may also be revoked via some back-channel mechanism, then we get by assuming there is some sort of common concept of authentication session.

I personally prefer to think of the “single logout” being revocation of an authentication token, rather than being related to any concept of distributed session. The security recommendations indicate you should not evaluate local access based on an expired or revoked authentication token. 

The relying party does not know the reasons behind the business policies for setting a token lifetime or for doing revocation, nor do they know up-front whether the process of getting a new authentication token can be done back-channel with no interaction, nor whether active user interaction (such as authentication) is required to succeed. They just know they shouldn’t rely on an invalidated token.

Traditional redirect-based SSO works because the same user agent is involved and serves as bearer for messages between the RP and IDP. SLO exists to serve two needs here:
1. User expectation is that within the same user agent, access as a user is either universally available or universally denied. The “Logout” button in this scenario is a signal from the user that they may not be the next entity that interacts with the system, and that authentication should be reacquired.
2. The user or an operation may expect the ability to revoke consent (and associated access) to users/clients/relying parties/user agents on demand.

Much of the SLO deployment today is to satisfy the first case, and will rely on the fact that authentication took place via redirects on the same user agent in order to delete artifacts of the original SSO, such as session cookies. 

The redirect-based technique used to implement SLO today however does not serve the needs of the second case, and even with the first case its usability is being eroded by privacy efforts in browsers destabilizing cookie usage in multi-party scenarios.

For TXAuth, the IDP interaction may be entirely on some other user agent, such as via the device flow or a CIBA-like flow. Once you abstract out the mechanism of interaction to this extent, the use of redirect-based flows becomes untenable.

You also have a changing user expectation that the authentication serves merely as a linking of personas between the two parties, and that each will do their own access management after that point. For example, an application like Slack (whether in web or native app user deployment) does not log the user out merely because the backing Google/GSuite account logged out.  IMHO this expectation is even stronger in cases where you are using multiple user agents, possibly spanning multiple devices. 

Some of this has been served by the mobile initiative over the last dozen years or so pushing for devices to be treated as being single user and/or managed access - the authentication security policy has gone in many places from being implemented within the browser to being implemented at the device level. An enterprise application may use identity tokens to determine that it is in compliance, but the actual tokens themselves may come from the managed device policy.

In both of these cases, scenario 2 is more likely - that the user consent for an app has gone away, or that access is being revoked because a device has gone out of compliance.

The case where scenario 1 is still most needed is consumer web applications developed with delegated authentication (SAML, OIDC) as the integration between components. I believe this is possible to support, although the components would be limited to integration via the interaction endpoint. IMHO the only reason this would need some sort of signed message or identifier would be to prevent XSRF abuse.
 
<snip>

- When the user wants to log out, client can send that back to the AS in the back channel, and get back an interaction mechanism that the client can use to interact with the AS for determining if they want to kill the session there as well.
- The AS can group together different clients into a “single sign out” cluster 

Note that for many applications, it does not make sense that the client would (to try to stay closer to my earlier parlance) signal that the AS should revoke other authentications, as the client does not dictate nor understand AS policy nor the policy or user expectations of other applications. User-initiated logout on a managed device for example would likely be a no-op.

As you say, the only sort of application I have seen where this makes sense is the previously mentioned aggregate of web applications via delegated authentication. GSuite, for example, adds a two-click method to cancel access to every GSuite application - but they do not expose any logout mechanism to third party applications (at least via their metadata.) It is also worth noting that this is done via embedded frames, as a redirect-based mechanism would be insufficient.

If a client has the capability to revoke different kinds of tokens, then the revocation of an authentication token within a client could be taken as a signal to revoke multiple tokens based on some grouping. This could leverage something like OIDC’s sector identifier uri, although the issuer of the tokens would still need to have some sort of dynamic correlation to only revoke tokens issued to those clients on the same device or within the same user agent. This is usually implemented today via web redirects and IDP state stored within cookies - but this approach has begun to break down with browser efforts to limit cross-site cookie abuses.

- When the AS learns that the user wants to log out, it might be able to push messages out to other clients — maybe they register back channel callback endpoints, or maybe a push message over http/2 or 3 or COAP, or some other mechanism. But the client can push that information in the initial request, and it can be user- and session- specific.

With externally revoked access tokens, the client does not need a signal since the protected resources should be evaluating validity. With authentication tokens, the client needs to have a way to check validity.

The center of TXAuth is likely to be an interactor that coordinates with the various parties. I expect numerous extensions to define particular interaction strategies for all the parties involved, and not just the authorizing/authenticating user agent as we have today with multiple OAuth grant types/“flows”.

So a client might get revocation messages via web push, via SET mechanisms, or do so via polling. I proposed an API for poliing a while back for OIDC which may be repurposed   (the API was designed with some additional complexity under the assumption that there may be multiple providers for the token revocation information). https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6d08fe79/distributed-token-validity-api.txt

Mapping this to XAuth, a Client could update the Grant URI with a PUT to logout all sessions, and as you mention, the GS could respond with an interaction object for the Client to transfer interaction to the GS.

Other Clients could regularly read the Grant URI, and the logged in status can be returned, or it could be a long lasting connection that returns a logged out response if the User is logged out somewhere else.
 

These ideas aren’t fully baked, but it’s seeming to me that with this new pattern we’ve got a chance to make a much cleaner take on sessions than we were able to do before.

Agreed. Neither is what I wrote above -- but with an established back channel from Client to GS, there are interesting things that can be done..
 

To be clear, I’m not saying any of this belongs explicitly in the charter, or that this is something that we need to tackle right now, but I think that addressing this eventually will make sense as part of the identity work as we move forward.

Agreed
 

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth



--------------01F2B891934679AC2849CD4D-- From nobody Fri Feb 14 07:25:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0FC120100 for ; Fri, 14 Feb 2020 07:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 yWmSMJzTcrMA for ; Fri, 14 Feb 2020 07:25:48 -0800 (PST) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (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 95FED1200B4 for ; Fri, 14 Feb 2020 07:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1581693947; bh=5yUHwPplqjGjmdbGueQViu7SL1BSxfUii1gbNZwv9S4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=rYgEPwJpp3v89OUTa1wIWUxfWRSBcfnO3GMAP3paWlPzIPN0T7f3iebNlUjtYvh9ICcynTOUZFe22yukDCf0zcbwLESuX0pPU6UWEzu7jKcB7qrSZGhu8W4NuF3iEGqha74HLDheaCekaCEs/LbQI8sFNR417H9nNXgMKd+O9hyA0XHGHR05Je5VDrL11g440Of7ffsb/52ihhZ3M8BVdTa1m6FnPX/6nEw8SRmPcKCNzhHHM2aptythYAt7XyuKu/ke6tmXcAZuQu6ueGSwx4E4A4DnQlW6bZzwIlq9fuUpLPEIFsSGYh1/3jawRro90U+G3kJQKgeTBNaHx/NhpA== X-YMail-OSG: 77ZGFjcVM1kRXuqU4Pjp7VfewPcr7JTLRVA7QKBVfh.qftUmRTzo7CAuv0pHZSk HVxILglO4PMggWZtVetTPOn3xpZeTmqC.QBUIafUbuPySPQUPDoAItTn_ez2vJ8pjYAfR8bYY2zi hry4qkMrkL0_pyfD.JaxFvxgn.jqNxAasj61K9Z3PAwE4T6WiqXuAdttIw7qxMPR34dLIZVvQZfF XSDOne8EG0RcLE6Yrsgf_fPh0rtGgA4MSH58F0stcUSM0A7gRTOOMXyWkUcyMz9hULD4tXMbXDkk Kf0ER86OYHdrqoIrSBCsoCWzCKfSRBscYzimcZaPeCwEfmTAEt9qXP0b1A6Sz_PZBfw0DgsjpXqP gLCFTp1c4Ygh5WNTJrP_nhx4Udi4Adnjz_AEIsmjA6NA9sx_srYKGRqV53oBCfFM.VaNBU_Q8OrL Cc4fd4ryl5NoDJRvQVaQpgu.pYg5D_8nVyFBVGRA2j7V8dUXH6_ujOyoYnSOMtZ4_zJnp_.kyuvD jYRT.vXUB3Kuld.alm1YSyFs4SjW6m.f2aQYOKQjQbEcCKIY4wVDO_RtRWE_7j0c4aE8buDTx_T9 AaPght20P4hAv4XIw1VcVOHOObOnO1yvt81NkuICJ29SM1.tGhzyhimQWO.kUoDpTCyi49xleJ3H YLff.hEC4Ugro51LTW5yflppVLSlzPuVZHNhrd8jUBSARcPM2.PTwkjQIVfWwuY_lF8FchKzduFR El5bgN699vYkVXgiFGGnNsU_AAz28Sxn_XgzSCEjQ7BC6IKZGzloxzs0AJVM4tATZaXAkryLUS54 pK8H4DlFJuU0sUdVRZBRieQEUpd1zGuCfmTBt2MdkZAvykiMj9zYvIFppozwi8vs0r2kYf1BJZRE Pdw7gu8EviMU0wOqncCdHGCP0GWcnld2ceBTzMpNcjCahp21D5rOLp_etXdMSrI1dnd09Ui0hYlH HjF8DuiP5Y.1lxgloGtXFehiE5lCYy_fOTXPtsfbBKd2GBJep1CUax9E4IT4eMHDsbc5.Gs9DpRF 3p0YrmuPjHePTJ_0TYjjcBZPTHVEXeDhcBTFT8CmWrpdoReZ2QisWRLIaHOfEQEWBLkmMlzEmwJg ._lIo2WJHX.47nXvfVtcULOcMfj1FQRReJXSdsy4je84oBfFhCfCc1b3mqAfXqetqavC7t_bgvle nBxj4lBX5vh2R7AAf.lwhxXpLAhU8DU1jJnthNudAxrhOfvNNaizaVQ3MehpNCeuqPQ.aU4EQFCw ZPOaLDmD2mXWvJHNTwHIJWRFUMeXhopS6efxgicg8apGe3T9ATlXkzZ1UTpQrsFTQg1wKHQBLpEz uDaEmiO5j4hDivIi_orL464v4HLRngH.dUqtY8b4rsFKC4FmBbUYWtly2M5R5xao02Qp1wA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 14 Feb 2020 15:25:47 +0000 Received: by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b6e2c32b2ccab527c736e21f755afb72; Fri, 14 Feb 2020 15:15:44 +0000 (UTC) To: David Waite , Dick Hardt Cc: txauth@ietf.org, Justin Richer References: <22536DE3-E90E-4543-A668-D89054D2401C@alkaline-solutions.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 14 Feb 2020 10:15:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <22536DE3-E90E-4543-A668-D89054D2401C@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="------------01F2B891934679AC2849CD4D" Content-Language: en-US X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 15:25:52 -0000 This is a multi-part message in MIME format. --------------01F2B891934679AC2849CD4D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I think there are multiple use cases and perspectives when it comes to session management and usability on the web. As for perspectives, we have: 1. The user and the experience they are expecting 2. The relying party and how they are viewing authentication and session management As for use cases, we have: 1. Relying parties that support Federated Authentication and then manage the resulting session themselves. In this context the session is really an RP session and NOT and IDP session. 2. Relying parties that want to be tightly bound to the IDP session. This is often true of services that are "1st party" to the domain of the IDP (e.g. Yahoo services and the Yahoo IDP). Let's call use case (1) RP-Bound Session management and use case (2) IDP-Bound session management. From the users perspective, the "order of operations" also matters. Take the following scenarios. 1. User goes to hikingtrail.example and clicks the "Sign in with Google" button. The user is both SSO'd into Google properties and also logged into hikingtrail.example. The user only has one tab open for hikingtrail.example and when the user is finished with their activities at hikingtrail.example, they click the logout button. 1. If hikingtrail.example is using the RP-Bound session model, they log the user out of hikingtrail.example but the user is still logged in at Google. If the user were to click the signin button, they would be silently signed in with a new RP-Bound session. This can be confusing to users because they may have expected to be logged out of Google as the only open tab was for hikingtrail.example. 2. If hikingtrail.example is using the IDP-Bound session model, then it needs a way to signal to Google that the user wants the IDP session to be revoked when the user clicks the logout button on hikingtrail.example. From an IDP with "1st party" services perspective, it's "dangerous" to provide this mechanism to relying parties. 2. User goes to Google and logs in to read their mail. The user then opens a second tab and navigates to hikingtrail.example and clicks the "Sign in with Google" button and is seamlessly logged in. When the user finishes and clicks the "logout" button on hikingtrail.example they are logged out of the site. 1. If hikingtrail.example is using the RP-Bound session model, the site clears it's session and displays the logged out version of the site. This is exactly what the user expects. If the user clicks the "Sign in with Google" button they will be seamlessly logged in and that is also what the user expects because they still have tab open for gmail. 2. If hikingtrail.example is using the IDP-Bound session model, the user gets logged out of their gmail experience as well as hikingtrail.example. This is something the IDP (if it provides 1st party services) does not want to happen. Today, many of the SaaS products we use in the enterprise use a RB-Bound session model.  We seem to manage. However, there are some services that require an IDP-Bound session model and those are at times annoying because I get logged out of the enterprise IDP just be logging out of the SaaS tool. Maybe one option that could be explored is allowing an RP to indicate to the IDP that it does not want an IDP-Session to be created for this user/device if one doesn't currently exist. Today this would manifest as the IDP NOT setting SSO cookies on it's own domain and just returning the federated authentication tokens. Hopefully that is helpful in some way :) On 2/14/20 4:24 AM, David Waite wrote: >> On Feb 13, 2020, at 9:35 AM, Dick Hardt > > wrote: >> >> >> >> On Thu, Feb 13, 2020 at 8:00 AM Justin Richer > > wrote: >> >> I’ve been doing some implementation of OIDC session management >> lately, and I had a realization that the pattern in TxAuth can >> give us a chance to do something a lot better. >> >> In OIDC, you use the ID token as a secondary artifact to indicate >> which client you are and which session you’re talking about. This >> is used as a drive-by client authentication (even though it’s >> really another bearer token sent through the front channel), >> which is what lets you do a post-logout redirect in a somewhat >> safe manner. The ID token is also used to carry session >> identifiers internally, >> >> >> Is carrying the session identifiers specified somewhere, or is this >> an implementation decision? > > TL;DR - redirect-based logout flows are not only brittle (and becoming > more brittle over time as browsers change their policies) but also > growing out of fashion, outside of ‘aggregate’ applications where the > different components are integrated via a single user agent and > redirect-based SSO. We get far more value treating > identity/authentication tokens similarly to access tokens - that they > may have a defined lifetime, and may also be revoked via some > back-channel mechanism, then we get by assuming there is some sort of > common concept of authentication session. > > I personally prefer to think of the “single logout” being revocation > of an authentication token, rather than being related to any concept > of distributed session. The security recommendations indicate you > should not evaluate local access based on an expired or revoked > authentication token. > > The relying party does not know the reasons behind the business > policies for setting a token lifetime or for doing revocation, nor do > they know up-front whether the process of getting a new authentication > token can be done back-channel with no interaction, nor whether active > user interaction (such as authentication) is required to succeed. They > just know they shouldn’t rely on an invalidated token. > > Traditional redirect-based SSO works because the same user agent is > involved and serves as bearer for messages between the RP and IDP. SLO > exists to serve two needs here: > 1. User expectation is that within the same user agent, access as a > user is either universally available or universally denied. The > “Logout” button in this scenario is a signal from the user that they > may not be the next entity that interacts with the system, and that > authentication should be reacquired. > 2. The user or an operation may expect the ability to revoke consent > (and associated access) to users/clients/relying parties/user agents > on demand. > > Much of the SLO deployment today is to satisfy the first case, and > will rely on the fact that authentication took place via redirects on > the same user agent in order to delete artifacts of the original SSO, > such as session cookies. > > The redirect-based technique used to implement SLO today however does > not serve the needs of the second case, and even with the first case > its usability is being eroded by privacy efforts in browsers > destabilizing cookie usage in multi-party scenarios. > > For TXAuth, the IDP interaction may be entirely on some other user > agent, such as via the device flow or a CIBA-like flow. Once you > abstract out the mechanism of interaction to this extent, the use of > redirect-based flows becomes untenable. > > You also have a changing user expectation that the authentication > serves merely as a linking of personas between the two parties, and > that each will do their own access management after that point. For > example, an application like Slack (whether in web or native app user > deployment) does not log the user out merely because the backing > Google/GSuite account logged out.  IMHO this expectation is even > stronger in cases where you are using multiple user agents, possibly > spanning multiple devices. > > Some of this has been served by the mobile initiative over the last > dozen years or so pushing for devices to be treated as being single > user and/or managed access - the authentication security policy has > gone in many places from being implemented within the browser to being > implemented at the device level. An enterprise application may use > identity tokens to determine that it is in compliance, but the actual > tokens themselves may come from the managed device policy. > > In both of these cases, scenario 2 is more likely - that the user > consent for an app has gone away, or that access is being revoked > because a device has gone out of compliance. > > The case where scenario 1 is still most needed is consumer web > applications developed with delegated authentication (SAML, OIDC) as > the integration between components. I believe this is possible to > support, although the components would be limited to integration via > the interaction endpoint. IMHO the only reason this would need some > sort of signed message or identifier would be to prevent XSRF abuse. > > >> - When the user wants to log out, client can send that back to >> the AS in the back channel, and get back an interaction mechanism >> that the client can use to interact with the AS for determining >> if they want to kill the session there as well. >> >> - The AS can group together different clients into a “single sign >> out” cluster >> > > Note that for many applications, it does not make sense that the > client would (to try to stay closer to my earlier parlance) signal > that the AS should revoke other authentications, as the client does > not dictate nor understand AS policy nor the policy or user > expectations of other applications. User-initiated logout on a managed > device for example would likely be a no-op. > > As you say, the only sort of application I have seen where this makes > sense is the previously mentioned aggregate of web applications via > delegated authentication. GSuite, for example, adds a two-click method > to cancel access to every GSuite application - but they do not expose > any logout mechanism to third party applications (at least via their > metadata.) It is also worth noting that this is done via embedded > frames, as a redirect-based mechanism would be insufficient. > > If a client has the capability to revoke different kinds of tokens, > then the revocation of an authentication token within a client could > be taken as a signal to revoke multiple tokens based on some grouping. > This could leverage something like OIDC’s sector identifier uri, > although the issuer of the tokens would still need to have some sort > of dynamic correlation to only revoke tokens issued to those clients > on the same device or within the same user agent. This is usually > implemented today via web redirects and IDP state stored within > cookies - but this approach has begun to break down with browser > efforts to limit cross-site cookie abuses. > >> - When the AS learns that the user wants to log out, it might be >> able to push messages out to other clients — maybe they register >> back channel callback endpoints, or maybe a push message over >> http/2 or 3 or COAP, or some other mechanism. But the client can >> push that information in the initial request, and it can be user- >> and session- specific. >> > > With externally revoked access tokens, the client does not need a > signal since the protected resources should be evaluating validity. > With authentication tokens, the client needs to have a way to check > validity. > > The center of TXAuth is likely to be an interactor that coordinates > with the various parties. I expect numerous extensions to define > particular interaction strategies for all the parties involved, and > not just the authorizing/authenticating user agent as we have today > with multiple OAuth grant types/“flows”. > > So a client might get revocation messages via web push, via SET > mechanisms, or do so via polling. I proposed an API for poliing a > while back for OIDC which may be repurposed   (the API was designed > with some additional complexity under the assumption that there may be > multiple providers for the token revocation information). > https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6d08fe79/distributed-token-validity-api.txt > >> Mapping this to XAuth, a Client could update the Grant URI with a PUT >> to logout all sessions, and as you mention, the GS could respond with >> an interaction object for the Client to transfer interaction to the GS. >> >> Other Clients could regularly read the Grant URI, and the logged in >> status can be returned, or it could be a long lasting connection that >> returns a logged out response if the User is logged out somewhere else. >> >> >> These ideas aren’t fully baked, but it’s seeming to me that with >> this new pattern we’ve got a chance to make a much cleaner take >> on sessions than we were able to do before. >> >> >> Agreed. Neither is what I wrote above -- but with an established back >> channel from Client to GS, there are interesting things that can be >> done.. >> >> >> To be clear, I’m not saying any of this belongs explicitly in the >> charter, or that this is something that we need to tackle right >> now, but I think that addressing this eventually will make sense >> as part of the identity work as we move forward. >> >> >> Agreed >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > --------------01F2B891934679AC2849CD4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think there are multiple use cases and perspectives when it comes to session management and usability on the web.

As for perspectives, we have:
1. The user and the experience they are expecting
2. The relying party and how they are viewing authentication and session management

As for use cases, we have:
1. Relying parties that support Federated Authentication and then manage the resulting session themselves. In this context the session is really an RP session and NOT and IDP session.
2. Relying parties that want to be tightly bound to the IDP session. This is often true of services that are "1st party" to the domain of the IDP (e.g. Yahoo services and the Yahoo IDP).

Let's call use case (1) RP-Bound Session management and use case (2) IDP-Bound session management.

From the users perspective, the "order of operations" also matters. Take the following scenarios.
  1. User goes to hikingtrail.example and clicks the "Sign in with Google" button. The user is both SSO'd into Google properties and also logged into hikingtrail.example. The user only has one tab open for hikingtrail.example and when the user is finished with their activities at hikingtrail.example, they click the logout button.
    1. If hikingtrail.example is using the RP-Bound session model, they log the user out of hikingtrail.example but the user is still logged in at Google. If the user were to click the signin button, they would be silently signed in with a new RP-Bound session. This can be confusing to users because they may have expected to be logged out of Google as the only open tab was for hikingtrail.example.
    2. If hikingtrail.example is using the IDP-Bound session model, then it needs a way to signal to Google that the user wants the IDP session to be revoked when the user clicks the logout button on hikingtrail.example. From an IDP with "1st party" services perspective, it's "dangerous" to provide this mechanism to relying parties.
  2. User goes to Google and logs in to read their mail. The user then opens a second tab and navigates to hikingtrail.example and clicks the "Sign in with Google" button and is seamlessly logged in. When the user finishes and clicks the "logout" button on hikingtrail.example they are logged out of the site.
    1. If hikingtrail.example is using the RP-Bound session model, the site clears it's session and displays the logged out version of the site. This is exactly what the user expects. If the user clicks the "Sign in with Google" button they will be seamlessly logged in and that is also what the user expects because they still have tab open for gmail.
    2. If hikingtrail.example is using the IDP-Bound session model, the user gets logged out of their gmail experience as well as hikingtrail.example. This is something the IDP (if it provides 1st party services) does not want to happen.

Today, many of the SaaS products we use in the enterprise use a RB-Bound session model.  We seem to manage. However, there are some services that require an IDP-Bound session model and those are at times annoying because I get logged out of the enterprise IDP just be logging out of the SaaS tool.

Maybe one option that could be explored is allowing an RP to indicate to the IDP that it does not want an IDP-Session to be created for this user/device if one doesn't currently exist. Today this would manifest as the IDP NOT setting SSO cookies on it's own domain and just returning the federated authentication tokens.

Hopefully that is helpful in some way :)

On 2/14/20 4:24 AM, David Waite wrote:
On Feb 13, 2020, at 9:35 AM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Feb 13, 2020 at 8:00 AM Justin Richer <jricher@mit.edu> wrote:
I’ve been doing some implementation of OIDC session management lately, and I had a realization that the pattern in TxAuth can give us a chance to do something a lot better.

In OIDC, you use the ID token as a secondary artifact to indicate which client you are and which session you’re talking about. This is used as a drive-by client authentication (even though it’s really another bearer token sent through the front channel), which is what lets you do a post-logout redirect in a somewhat safe manner. The ID token is also used to carry session identifiers internally,

Is carrying the session identifiers specified somewhere, or is this an implementation decision?

TL;DR - redirect-based logout flows are not only brittle (and becoming more brittle over time as browsers change their policies) but also growing out of fashion, outside of ‘aggregate’ applications where the different components are integrated via a single user agent and redirect-based SSO. We get far more value treating identity/authentication tokens similarly to access tokens - that they may have a defined lifetime, and may also be revoked via some back-channel mechanism, then we get by assuming there is some sort of common concept of authentication session.

I personally prefer to think of the “single logout” being revocation of an authentication token, rather than being related to any concept of distributed session. The security recommendations indicate you should not evaluate local access based on an expired or revoked authentication token. 

The relying party does not know the reasons behind the business policies for setting a token lifetime or for doing revocation, nor do they know up-front whether the process of getting a new authentication token can be done back-channel with no interaction, nor whether active user interaction (such as authentication) is required to succeed. They just know they shouldn’t rely on an invalidated token.

Traditional redirect-based SSO works because the same user agent is involved and serves as bearer for messages between the RP and IDP. SLO exists to serve two needs here:
1. User expectation is that within the same user agent, access as a user is either universally available or universally denied. The “Logout” button in this scenario is a signal from the user that they may not be the next entity that interacts with the system, and that authentication should be reacquired.
2. The user or an operation may expect the ability to revoke consent (and associated access) to users/clients/relying parties/user agents on demand.

Much of the SLO deployment today is to satisfy the first case, and will rely on the fact that authentication took place via redirects on the same user agent in order to delete artifacts of the original SSO, such as session cookies. 

The redirect-based technique used to implement SLO today however does not serve the needs of the second case, and even with the first case its usability is being eroded by privacy efforts in browsers destabilizing cookie usage in multi-party scenarios.

For TXAuth, the IDP interaction may be entirely on some other user agent, such as via the device flow or a CIBA-like flow. Once you abstract out the mechanism of interaction to this extent, the use of redirect-based flows becomes untenable.

You also have a changing user expectation that the authentication serves merely as a linking of personas between the two parties, and that each will do their own access management after that point. For example, an application like Slack (whether in web or native app user deployment) does not log the user out merely because the backing Google/GSuite account logged out.  IMHO this expectation is even stronger in cases where you are using multiple user agents, possibly spanning multiple devices. 

Some of this has been served by the mobile initiative over the last dozen years or so pushing for devices to be treated as being single user and/or managed access - the authentication security policy has gone in many places from being implemented within the browser to being implemented at the device level. An enterprise application may use identity tokens to determine that it is in compliance, but the actual tokens themselves may come from the managed device policy.

In both of these cases, scenario 2 is more likely - that the user consent for an app has gone away, or that access is being revoked because a device has gone out of compliance.

The case where scenario 1 is still most needed is consumer web applications developed with delegated authentication (SAML, OIDC) as the integration between components. I believe this is possible to support, although the components would be limited to integration via the interaction endpoint. IMHO the only reason this would need some sort of signed message or identifier would be to prevent XSRF abuse.
 
<snip>

- When the user wants to log out, client can send that back to the AS in the back channel, and get back an interaction mechanism that the client can use to interact with the AS for determining if they want to kill the session there as well.
- The AS can group together different clients into a “single sign out” cluster 

Note that for many applications, it does not make sense that the client would (to try to stay closer to my earlier parlance) signal that the AS should revoke other authentications, as the client does not dictate nor understand AS policy nor the policy or user expectations of other applications. User-initiated logout on a managed device for example would likely be a no-op.

As you say, the only sort of application I have seen where this makes sense is the previously mentioned aggregate of web applications via delegated authentication. GSuite, for example, adds a two-click method to cancel access to every GSuite application - but they do not expose any logout mechanism to third party applications (at least via their metadata.) It is also worth noting that this is done via embedded frames, as a redirect-based mechanism would be insufficient.

If a client has the capability to revoke different kinds of tokens, then the revocation of an authentication token within a client could be taken as a signal to revoke multiple tokens based on some grouping. This could leverage something like OIDC’s sector identifier uri, although the issuer of the tokens would still need to have some sort of dynamic correlation to only revoke tokens issued to those clients on the same device or within the same user agent. This is usually implemented today via web redirects and IDP state stored within cookies - but this approach has begun to break down with browser efforts to limit cross-site cookie abuses.

- When the AS learns that the user wants to log out, it might be able to push messages out to other clients — maybe they register back channel callback endpoints, or maybe a push message over http/2 or 3 or COAP, or some other mechanism. But the client can push that information in the initial request, and it can be user- and session- specific.

With externally revoked access tokens, the client does not need a signal since the protected resources should be evaluating validity. With authentication tokens, the client needs to have a way to check validity.

The center of TXAuth is likely to be an interactor that coordinates with the various parties. I expect numerous extensions to define particular interaction strategies for all the parties involved, and not just the authorizing/authenticating user agent as we have today with multiple OAuth grant types/“flows”.

So a client might get revocation messages via web push, via SET mechanisms, or do so via polling. I proposed an API for poliing a while back for OIDC which may be repurposed   (the API was designed with some additional complexity under the assumption that there may be multiple providers for the token revocation information). https://bitbucket.org/openid/connect/raw/c9ac167e35e5d09b39b08872ddd73cea6d08fe79/distributed-token-validity-api.txt

Mapping this to XAuth, a Client could update the Grant URI with a PUT to logout all sessions, and as you mention, the GS could respond with an interaction object for the Client to transfer interaction to the GS.

Other Clients could regularly read the Grant URI, and the logged in status can be returned, or it could be a long lasting connection that returns a logged out response if the User is logged out somewhere else.
 

These ideas aren’t fully baked, but it’s seeming to me that with this new pattern we’ve got a chance to make a much cleaner take on sessions than we were able to do before.

Agreed. Neither is what I wrote above -- but with an established back channel from Client to GS, there are interesting things that can be done..
 

To be clear, I’m not saying any of this belongs explicitly in the charter, or that this is something that we need to tackle right now, but I think that addressing this eventually will make sense as part of the identity work as we move forward.

Agreed
 

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth



--------------01F2B891934679AC2849CD4D-- From nobody Fri Feb 14 09:09:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB4B120910 for ; Fri, 14 Feb 2020 09:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 heLbYT3Pr41y for ; Fri, 14 Feb 2020 09:09:40 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450: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 C52511208F8 for ; Fri, 14 Feb 2020 09:09:38 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id n25so7261898lfl.0 for ; Fri, 14 Feb 2020 09:09:38 -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=4+gBtOKdnv7+2twL0ng/gz6Ai+rtSLjHzBvwhrLalew=; b=lCxUHxNuGJUWrELWnoWG/NgNBdCc52uT153UJHRyvfo9rbRbswuD9iO+kiiLTch4ZT r3iBzeTvqI22HzvI9/lUZ9O76/KN0z6frvh7r0ugALcbr8PZjPJVfCjadyLB0nx87BDU psBS5xNd8yrGvk4w6KC/OY6hX+RK0obtboYi//sd4zw3hj+Jr6XySRKuA2OT6gwhYlz9 JL/KsSNr46vUhqAjw3zaGcf1cz1IracBrcmrKdhavyCYkh2Sb1Gm2EjzrBqOI+aJyrRS FuJOyGdzhQ4lyu0xJZnOuXQXgb85UX1KzI/9nrN4I9lEOvtgqp/xKHJUGAAayKObUIQ3 cAkg== 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=4+gBtOKdnv7+2twL0ng/gz6Ai+rtSLjHzBvwhrLalew=; b=R/Lf94fhdDvDFySyxke4DZbw7UPD/3+dssjQaBEswLMnrCYJw6Mi7cK5Cg3fr21xYn VYSOrxAm/gJ6pdH8Txv6NdPQA1xlEAci9Vir+D2v57Wcrqgfk/nERN1RcdZWdBXLz9ey qdYRLOcLhXaDeyytoGRNuhTDMNn+crYofZ1z7+McfDdxnTk1McZX8BYkC7oJRI0Scmx3 toUzAQm3z8k9pJjY3uW0/M1wvA69POgveYRT8jaVcVYxMcMjjxFGf1c5WKvBTo5iGGqK iebvHpVDGIY2c3eCCh9zt2dzcElrrqCyLbf1uDywh/YKEs0uB2mXQWME662SD4GVd+kg aA7g== X-Gm-Message-State: APjAAAXeasDvVNsTzwxyXwOckJh1G3rcT5AaOYpH6dfzmGY6pccC0nUH 8t7DaKWOLC0F/TkFK9WagIzFZRroIplCUAWFgYTteirxVP4= X-Google-Smtp-Source: APXvYqxgTunW9v2nTlBe8MeExkIkaW00EXk9LUeYwxj3Y5t7c+j9lolrrS3zCn+AckjGQVxmCOzBWGUvrSXDPGLwOmQ= X-Received: by 2002:a05:6512:4c6:: with SMTP id w6mr2110959lfq.157.1581700176823; Fri, 14 Feb 2020 09:09:36 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> In-Reply-To: <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> From: Dick Hardt Date: Fri, 14 Feb 2020 09:09:09 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002e4c0b059e8c4590" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 17:09:44 -0000 --0000000000002e4c0b059e8c4590 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle wrote: > [richanna] > > Replies inline > > [/richanna] > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Dick Hardt > *Date: *Wednesday, February 12, 2020 at 6:35 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] XAuth -02 > > > > > > > > Section 5.5.2: > > The interaction object contains the type of interaction the Client > > will provide the User. Other attributes > > > > - *type* - contains one of the following values: "popup", > > "redirect", or "qrcode".... > > > > 3 issues with this: > > 1. How would I do a user code-based interaction? > > To clarify, the User is entering a code in the Client into the GS, or the > User is entering a code into the Client? > > > > If the prior, the QR code also allows a message. I'm envisioning a User > with a mobile phone can scan the QR code which contains a URL at the GS, > and includes the code. > > > > The message would describe what to do and include the code. > > > > [richanna] > > By user code-based interaction, I mean the kind described in the OAuth > 2.0 Device Authorization Grant , > where the user receives a code and short URL from the client, navigates t= o > that URL in a browser, and enters the code. While this could be packed in= to > interaction.message, this will lead to clunkier user experiences: > > 1. The GS may not be able to provide localized instructions that match > the locale on the Client. > 2. Suppose the GS sends a message that reads: =E2=80=9CScan the QR cod= e or > open a browser to http://code.example/ and enter the code: 12345.=E2= =80=9D > > > 1. That instruction does not make sense on a device that does not > present a QR code. Imagine hearing that from a smart speaker. > 2. That instruction is confusingly redundant if the Client displays > the QR code along with its own instructions, like: =E2=80=9CScan th= e QR code or > follow the instructions below.=E2=80=9D > > > 1. Will =E2=80=9Cembed the short URL and code in the message string=E2= =80=9D be MTI? > If not, text-only clients would have a broken experience. > > [/richanna] > Sounds like a text only interaction type should be added per my note in the draft. Perhaps even one that is focused on the code flow, where the parameters are the code and the URI to enter the code, letting the Client present the parameters with localized content? > > > > > 2. Clients support multiple interaction modes and may not always know > what the GS supports (and vice-versa). For a multi-tenant GS, it may vary > by tenant configuration. Clients should be able to say what they can do, > and the GS should be able to tell them which one to use. It=E2=80=99s a v= ery simple > but powerful inline negotiation. > > > > That is what is in TxAuth. Would you elaborate on how the GS might be > constrained? Why would the GS not be able to do all? > > > > I would think all constraints would be at the Client. Am I missing > something? > > > > [richanna] > > Clients may support customer-defined GSes (e.g., enterprise IdPs), which > will vary in terms of which interaction modes they support. While the set > of interactions defined in XAuth might all be MTI for a GS, we should > assume that extensions will introduce new interactions which will not be > universally supported. An interaction mechanism might have properties tha= t > cause some administrators to want to disable it, or to restrict Clients t= o > always use it. Are you assuming that a Client will always make an OPTIONS > discovery request first? > > [/richanna] > An example of why a given GS may not support a mode would be helpful. I was envisioning that if an optional to support interaction mode was not supported at the GS, that it would return an error. The Client would then try a different one. Alternatively, the Client could start with an OPTIONS call in cases where the GS is dynamicly chosen. > > > 3. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D interac= tion mode. Clients can > use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking as s= omeone who has > done that, I really don=E2=80=99t recommend it. Popups are increasingly > unsupported, and prone to weird behavioral issues. In-app browsers in > Facebook, Twitter, etc. tend to have popups disabled. The last versions o= f > IE Mobile didn=E2=80=99t support them at all (the popped up page basicall= y just > loaded into the current window). in > > > > Popups are really useful in single-page apps as you want to keep the > context and not reload the page. > > > > Agree that popups don't make sense in mobile. A full redirect does of > course. A single-page app on mobile would open a new tab which would be a > separate context rather than a redirect. > > > > [richanna] > > Popups are broken and/or disabled in enough instances that we should not > encourage their usage by including explicit support for them in the > protocol. Nor are they necessary for SPAs in order to restore the state o= f > their app after the redirect. > Are they really that broken in desktop? I've used them extensively myself in the past as it was a better user experience, but that was a few years ago. > And again, a Client that really wants to give themselves a headache with > popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They= just have to > provide a landing page for the GS to redirect back to that parses the > response, passes it back to the main window, and closes itself. I don=E2= =80=99t see > why the protocol would need to explicitly describe this mechanism. > [/richanna] > I think it is a useful signal for the GS in the experience it wants to show the user. > > > Section 12.6: > > [Editor: is there some other reason to have the UserInfo > > endpoint?] > > > > I may want to host my UserInfo endpoint on a separate microservice from m= y > token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my > user profile/directory stack, while the latter is part of the highly > privileged authentication/authorization stack. > > > > > > The token endpoint has the access token anyway, so it can fetch the data > from the other endpoint itself if it wanted to. IE, there is no separatio= n > of duties. > > > > What are the advantages of the UserInfo endpoint to the User or Client? > > > > The UserInfo endpoint seems to just add more complexity, with no ability > to start a User interaction if additional consent is needed. > > > > [richanna] > > If the access token is sender-constrained, then no, the token endpoint > can=E2=80=99t fetch the data itself. But even without the security angle,= there is > value in separating out the functionality as it allows the GS to distribu= te > it across systems with different owners. E.g., there might be a directory > API team that also owns the SCIM interface and UserInfo endpoint. > An implementation can also route calls to different internal systems while keeping the same endpoint. I also think of SCiM and UserInfo as very different endpoints. I would consider SCIM a resource, and UserInfo claims. I appreciate those are similar in enterprise, but they are not in consumer contexts. > > > The advantage for the Client is that they have an endpoint they can call > to get up-to-date details about the end user, even outside the context of > an active session. > In enterprise use cases, getting up-to-date information details is fine, as consent is obtained somewhere else. In the consumer use case, getting new data about the user without consent is problematic. > > > The UserInfo endpoint can indicate the need for additional consent via a > 401 and WWW-Authenticate, just like any other resource endpoint. > Per above, I don't think of claims as being a resource. For consumer use cases, the UserInfo adds more moving pieces for the Client, particularly one that only needs claims. There is an access token, and an additional endpoint, with potentially different access control. I think one of our tenets should be to push complexity to the GS vs the Client. [/richanna] > > > > > > Section 12.8: > > *Why have both claims and authorizations?* > > > > There are use cases for each that are independent: > > authenticating a user vs granting access to a resource. A > > request for an authorization returns an access token or handle, > > while a request for a claim returns the claim. > > > > I don=E2=80=99t agree that the use cases are distinct. The only claim tha= t is > strictly necessary for authentication is the user identifier. Other claim= s > like email and phone_number are often used to aid in local account > identification (i.e., account linking), but are useful and interesting > beyond this use case. > > > > Some Clients use email and phone_number as the identifier and don't pay > attention to the directed identifier. Not the best practice, but it is wh= at > people do. > > > > [richanna] > > That is literally the scenario I described in the first part of the secon= d > sentence. The latter part of that same sentence notes that those claims a= re > useful *beyond that use case*, i.e., they can be useful even when the > client is not using them for authentication. I am demonstrating that your > =E2=80=9Cauthenticating a user vs granting access to a resource=E2=80=9D = dichotomy is > flawed by showing that claims do not strictly belong to the former, and > some things that are defined as claims have nothing at all to do with > authentication. > > [/richanna] > Account linking and authentication are not the same. I was clarifying that. Sorry I was not clear on the purpose of my comment. Agreed, as noted, my phrasing was not accurate as claims are for more than authentication. > > > > > > > I strongly think it is a disservice to our audience to conflate claims an= d > resources. Claims are statements about the User and read-only. > > > > [richanna] > > Claims are a subset of resources that OIDC built some extra features for, > including a read-only interface to access them. However, claims are not > inherently read-only, nor are they the only resources for which a read-on= ly > interfaces may be built for. > > [/richanna] > Sure, there are always exceptions, but the UserInfo endpoint is read-only. If there is a SCIM endpoint, then as stated above, that is a resource. > > > > > I understand the use case you=E2=80=99re trying to support here, but I th= ink the > proposal is too complicated to implement. From the sequences, it looks li= ke > the Client is expected to issue a Read Grant request, and that connection > will be kept open while the User is redirected to the GS and goes through > the authentication workflow (and possibly part of the authorization > workflow). Only then would the GS return the Read Grant response. Is this > correct? > > > > To implement this, the Client has to launch an asynchronous thread to > execute that request and awaiting the response. > > Possible, but susceptible to failures. What happens if that thread > crashes? Or fails to send the Update Grant request to flip interaction.ke= ep > to false? What is the GS doing in the meantime? Is it just showing the Us= er > a =E2=80=9Cloading=E2=80=9D widget as it waits for the Client to update t= he grant? How long > does it wait for? For mobile apps, that background thread may get killed = or > lose network connectivity as soon as the user gets switched over to the > system browser to load the GS sign in page. For a pure-JS app that > redirects, I don=E2=80=99t think this is possible at all. (unless web wor= kers can > survive page unloads?) > > > > This is an interesting use case for us to think about, but it needs a lot > of work and may not be something we should try to bake into the core > protocol if we don=E2=80=99t need to. > > > > It might not have been obvious, but the Client calling the GS to get a > result while the interaction is happening is what happens in any flow wit= h > an interaction started by the Client. It is not unique to > "interaction"."keep" -- we are just adding additional back and forths > between the Client and GS. > > > > A QR Code example HAS to work this way, as there is no other way for the > Client to know the interaction has completed. > > > > Google and Microsoft both have a similar user experience. The User wants > to log into an app -- they are instructed to go to the respective mobile > app to approve the authentication -- and then the User returns to the app > which changes to a logged in state. An authentication only flow using > XAuth would work the same way. > > > > [richanna] > > There are two big differences between those examples (e.g., QR Code, > app-based login approvals) and this mechanism in XAuth: > > 1. In your examples of this behavior today, the reason for the wait is > clear and obvious, and driven by the user. E.g., my printer is waiting= for > me to go enter this code and log in; Google sign in is waiting for me = to > tap this button on my phone. That is not the case in the XAuth protoco= l. > The user is left sitting on a loading screen waiting for a > behind-the-scenes interaction between client and GS that may not even > happen. > 2. Unlike with code/QR flows or sign-in verification, there is no > active process on the client side to keep this async request open. A w= eb > app client would have to introduce a server-side async process to mana= ge > this aspect of the protocol. That=E2=80=99s not easy. > 3. The failure modes show up in more appropriate contexts, where there > are clear paths forward for the end user. In code/QR-based flows, it= =E2=80=99s > detected on the client side, in the form of an AS that never provides = a > response. In that scenario, the client can retry the process. In sign-= in > verification, the problem occurs between two parts of the AS, and the = AS > can allow the end user to retry or to use a different authentication > method. In the XAuth Create+Update scenario, the failure is detected o= n the > GS, and there is no clear path forward. If the Client never calls Upda= te > Grant to flip interaction.keep to false, what should the GS do? How lo= ng > should it wait? Should it issue the authorization anyway, assuming the > Client will come back and ask for it at some point? Should it redirect= the > end user back to the Client anyway, or drop them on a landing page? Sh= ould > it flag this as an error, or is this the expected behavior for the Cli= ent? > > > > I really think this is overcomplicating the protocol to an extent that no > one will actually implement it. > > [/richanna] > The flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 is EXACTLY the same as the Google and Microsoft flows. While the flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 has additional steps, it is not fundamentally any different except the Client is making another call to the GS after the first one returns. The risk of the Client not making the second call and leaving the User hanging is not really any different of the Client not making the first call. Besides the situation where the mobile device that MAY not be able to make the second call might put to sleep, I don't see any implementation issues. TxAuth works the same way as 3.1 as I understand it for non-redirect flows. > > > [pasting in from your later email] > > While a single stage Grant request (3.1) in a mobile app that has been pu= t > to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only > makes sense if the Client is checking a database along the way, I > would expect the Client to have a server side, and the server could take > each step. > > [/end paste] > > > > [richanna] > > Having a remote database and having a remote server are not the same > thing. This adds a lot of complexity to serverless apps. > > [/richanna]=E1=90=A7 > Which aspect adds complexity? The added complexity in keeping an interaction is making an additional API call after the first API call. > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000002e4c0b059e8c4590 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 13, 2020 at 6:08 PM Richa= rd Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

[richanna]

Replies inline

[/richanna]

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

=C2=A0

<snip>

=C2=A0

Section 5.5.2:

=C2=A0=C2=A0 T=
he interaction object contains the type of interaction the Client=

=C2=A0=C2=A0 w=
ill provide the User.=C2=A0 Other attributes
<snip>
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 *type* - contains one of the followi=
ng values: "popup",
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0"redirect", or &=
quot;qrcode"....

=C2=A0

3 issues with this:

1.=C2=A0= =C2=A0 How would I do a user code-based interaction?

To clarify, the User is = entering a code in the Client into the GS, or the User is entering a code i= nto the Client?=C2=A0

=C2=A0

If the prior, the QR cod= e also allows a message. I'm envisioning a User with a mobile phone can= scan the QR code which contains a URL at the GS, and includes the code.=C2= =A0

=C2=A0

The message would descri= be what to do and include the code.

=C2=A0

[richanna]

By user code-based interaction, I mean the kind desc= ribed in the OAuth 2.0 = Device Authorization Grant, where the user receives a code and short UR= L from the client, navigates to that URL in a browser, and enters the code.= While this could be packed into interaction.message, this will lead to clunkier user experiences:

  1. The GS may not be able to provide localized instructions that mat= ch the locale on the Client.
  2. Suppose the GS sen= ds a message that reads: =E2=80=9CScan the QR code or open a browser to http://code.example/= and enter the code: 12345.=E2=80=9D
    1. That instruction does not make sense on a device that does not pr= esent a QR code. Imagine hearing that from a smart speaker.
    2. That instruction is confusingly redundant if the Client displa= ys the QR code along with its own instructions, like: =E2=80=9CScan the QR = code or follow the instructions below.=E2=80=9D
  1. Will =E2=80=9Cembed the short URL and code in the message string= =E2=80=9D be MTI? If not, text-only clients would have a broken experience.=

[/richanna]


Sounds like a text only interaction type should b= e added per my note in the draft. Perhaps even one that is focused on the c= ode flow, where the parameters are the code and the URI to enter the code, = letting the Client present the parameters with localized content?

=C2=A0

=C2=A0

=C2=A0

2.=C2=A0= =C2=A0 Clients support multiple interaction modes and may not= always know what the GS supports (and vice-versa). For a multi-tenant GS, = it may vary by tenant configuration. Clients should be able to say what the= y can do, and the GS should be able to tell them which one to use. It=E2=80=99s a very simple but powerfu= l inline negotiation.

=C2=A0

That is what is in TxAut= h. Would you elaborate on how the GS might be constrained? Why would the GS= not be able to do all?

=C2=A0

I would think all constr= aints would be at the Client. Am I missing something?

=C2=A0

[richanna]

Clients may support customer-defined GSes (e.g., ent= erprise IdPs), which will vary in terms of which interaction modes they sup= port. While the set of interactions defined in XAuth might all be MTI for a= GS, we should assume that extensions will introduce new interactions which will not be universally supported. A= n interaction mechanism might have properties that cause some administrator= s to want to disable it, or to restrict Clients to always use it. Are you a= ssuming that a Client will always make an OPTIONS discovery request first?

[/richanna]=C2=A0

<= /blockquote>

An example of why a given GS may not suppor= t a mode would be helpful.

I was envisioning that = if an optional to support interaction mode was not supported at the GS, tha= t it would return an error. The Client would then try a different one. Alte= rnatively, the Client could start with an OPTIONS call in cases where the G= S is dynamicly chosen.
=C2=A0

=C2=A0

3.=C2=A0= =C2=A0 I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2= =80=9D interaction mode. Clients can use =E2=80=9Credirect=E2=80=9D mode wi= thin popups. However, speaking as someone who has done that, I really don= =E2=80=99t recommend it. Popups are increasingly unsupported, and prone to = weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have= popups disabled. The last versions of IE Mobile didn=E2=80=99t support the= m at all (the popped up page basically just loaded into the current window)= . in=C2=A0

=C2=A0

Popups are really useful= in single-page apps as you want to keep the context and not reload the pag= e.

=C2=A0

Agree that popups don= 9;t make sense in mobile. A full redirect does of course. A single-page app= on mobile would open a new tab which would be a separate context rather th= an a redirect.

=C2=A0

[richanna]

Popups are broken and/or disabled in enough instance= s that we should not encourage their usage by including explicit support fo= r them in the protocol. Nor are they necessary for SPAs in order to restore= the state of their app after the redirect.


Are they really that broken in desktop? I've used them extensively m= yself in the past as it was a better user experience, but that was a few ye= ars ago.
=C2=A0

And again, a Client that reall= y wants to give themselves a headache with popups can do that themselves us= ing =E2=80=9Credirect=E2=80=9D mode. They just have to provide a landing pa= ge for the GS to redirect back to that parses the response, passes it back = to the main window, and closes itself. I don=E2=80=99t see why the protocol would= need to explicitly describe this mechanism.=C2=A0

[/richanna]


I think it is a useful signal for the GS in the e= xperience it wants to show the user.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=C2=A0

Section 12.6:

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[Editor: is there some other reason to have =
the UserInfo
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoint?]

=C2=A0

I may want to host my UserInfo endpoint on a separate microservice from my = token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my us= er profile/directory stack, while the latter is part of the highly privileg= ed authentication/authorization stack.

=C2=A0

=C2=A0

The token endpoint has t= he access token anyway, so it can fetch the data from the other endpoint it= self if it wanted to. IE, there is no separation of duties.

=C2=A0

What are the advantages = of the UserInfo endpoint to the User or Client?=C2=A0

=C2=A0

The UserInfo endpoint se= ems to just add more complexity, with no ability to start a User interactio= n if additional consent is needed.

=C2=A0

[richanna]

If the access token is sender-constrained, then no, = the token endpoint can=E2=80=99t fetch the data itself. But even without th= e security angle, there is value in separating out the functionality as it = allows the GS to distribute it across systems with different owners. E.g., there might be a directory API team that also= owns the SCIM interface and UserInfo endpoint.

=

An implementation can also route cal= ls to different internal systems while keeping the same endpoint.

I also think of SCiM and UserInfo as very different endpoin= ts. I would consider SCIM a resource, and UserInfo claims. I appreciate tho= se are similar in enterprise, but they are not in consumer contexts.
<= div>=C2=A0

=C2=A0

The advantage for the Client is that they have an en= dpoint they can call to get up-to-date details about the end user, even out= side the context of an active session.


In enterprise use cases, getting up-to-date i= nformation details is fine, as consent is obtained somewhere else. In the c= onsumer use case, getting new data about the user without consent is proble= matic.
=C2=A0

=C2=A0

The UserInfo endpoint can indicate the need for addi= tional consent via a 401 and WWW-Authenticate, just like any other resource= endpoint.


Per above, I don't think of claims as being a resource.
For consumer use cases, the UserInfo adds more moving pieces fo= r the Client, particularly one that only needs claims. There is an access t= oken, and an additional endpoint, with potentially different access control= .

I think one of our tenets should be to push comp= lexity to the GS vs the Client.

[/richanna]


=C2=A0

=C2=A0

=C2=A0

Section 12.8:

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Why have both claims and authorizations?*
=C2=A0<=
u>
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are use cases for each that are indepe=
ndent:
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authenticating a user vs granting access to =
a resource.=C2=A0 A
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 request for an authorization returns an acce=
ss token or handle,
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 while a request for a claim returns the clai=
m.

=C2=A0

I don=E2=80=99t agree that the use cases are distinct. The only claim that = is strictly necessary for authentication is the user identifier. Other clai= ms like email and phone_number are often used to aid in local account ident= ification (i.e., account linking), but are useful and interesting beyond this use case.

=C2=A0

Some Clients use email a= nd phone_number as the identifier and don't pay attention to the direct= ed identifier. Not the best practice, but it is what people do.

=C2=A0

[richanna]

That is literally the scenario I described in the fi= rst part of the second sentence. The latter part of that same sentence note= s that those claims are useful beyond that use case, i.e., they can be useful even when the client = is not using them for authentication. I am demonstrating that your =E2=80= =9Cauthenticating a user vs granting access to a resource=E2=80=9D dichotom= y is flawed by showing that claims do not strictly belong to the former, and some things that are defined as claims have noth= ing at all to do with authentication.

[/richanna]


Account linking and authentication are not the sa= me. I was clarifying that. Sorry I was not clear on the purpose of my comme= nt.=C2=A0

Agreed, as noted, my phrasing was not ac= curate as claims are for more than authentication.=C2=A0
=C2=A0
<= div class=3D"gmail-m_-1391366828367422330WordSection1">

=C2=A0

<snip>

=C2=A0

I strongly think it is a= disservice to our audience to conflate claims and resources. Claims are st= atements about the User and read-only.

=C2=A0

[richanna]

Claims are a subset of resources that OIDC built som= e extra features for, including a read-only interface to access them. Howev= er, claims are not inherently read-only, nor are they the only resources fo= r which a read-only interfaces may be built for.

[/richanna]


Sure, there are always exceptions, but the UserIn= fo endpoint is read-only.

If there is a SCIM endpo= int, then as stated above, that is a resource.
=C2=A0

=C2=A0

<snip>

I understand the use case you=E2=80=99re trying to support here, but I thin= k the proposal is too complicated to implement. From the sequences, it look= s like the Client is expected to issue a Read Grant request, and that conne= ction will be kept open while the User is redirected to the GS and goes through the authentication workflow (and pos= sibly part of the authorization workflow). Only then would the GS return th= e Read Grant response. Is this correct?

=C2=A0

To implement this, the Client has to launch an asynchronous thread to execu= te that request and awaiting the response.

Possible, but susceptible to failures. What happens if that thread crashes?= Or fails to send the Update Grant request to flip interaction.keep to fals= e? What is the GS doing in the meantime? Is it just showing the User a =E2= =80=9Cloading=E2=80=9D widget as it waits for the Client to update the grant? How long does it wait for? For mobile apps, th= at background thread may get killed or lose network connectivity as soon as= the user gets switched over to the system browser to load the GS sign in p= age. For a pure-JS app that redirects, I don=E2=80=99t think this is possible at all. (unless web workers can sur= vive page unloads?)

=C2=A0

This is an interesting use case for us to think about, but it needs a lot o= f work and may not be something we should try to bake into the core protoco= l if we don=E2=80=99t need to.

=C2=A0

It might not have been o= bvious, but the Client calling the GS to get a result while the interaction= is happening is what happens in any flow with an interaction started by th= e Client. It is not unique to "interaction"."keep" -- we are just adding additional back and forths between the Client and GS= .

=C2=A0

A QR Code example HAS to= work this way, as there is no other way for the Client to know the interac= tion has completed.

=C2=A0

Google and Microsoft bot= h have a similar user experience. The User wants to log into an app -- they= are instructed to go to the respective mobile app to approve the authentic= ation -- and then the User returns to the app which changes to a logged in state.=C2=A0 An authentication only f= low using XAuth would work the same way.

=C2=A0

[richanna]

There are two big differences between those examples= (e.g., QR Code, app-based login approvals) and this mechanism in XAuth:=

  1. In your examples of this behavior today, the reason for the wait = is clear and obvious, and driven by the user. E.g., my printer is waiting f= or me to go enter this code and log in; Google sign in is waiting for me to tap this button on my phone. That is n= ot the case in the XAuth protocol. The user is left sitting on a loading sc= reen waiting for a behind-the-scenes interaction between client and GS that= may not even happen.
  2. Unlike with code/QR flows= or sign-in verification, there is no active process on the client side to = keep this async request open. A web app client would have to introduce a se= rver-side async process to manage this aspect of the protocol. That=E2=80=99s not ea= sy.
  3. The failure modes show up in more appropria= te contexts, where there are clear paths forward for the end user. In code/= QR-based flows, it=E2=80=99s detected on the client side, in the form of an AS that never provides a response. In that scenario, the client can = retry the process. In sign-in verification, the problem occurs between two = parts of the AS, and the AS can allow the end user to retry or to use a dif= ferent authentication method. In the XAuth Create+Update scenario, the failure is detected on the GS, and t= here is no clear path forward. If the Client never calls Update Grant to fl= ip interaction.keep to false, what should the GS do? How long should it wai= t? Should it issue the authorization anyway, assuming the Client will come back and ask for it at some point? S= hould it redirect the end user back to the Client anyway, or drop them on a= landing page? Should it flag this as an error, or is this the expected beh= avior for the Client?

=C2=A0

I really think this is overcomplicating the protocol= to an extent that no one will actually implement it.

[/richanna]


The flow in=C2=A0https://tools.ietf.org/ht= ml/draft-hardt-xauth-protocol-02#section-3.1=C2=A0is EXACTLY the same a= s the Google and Microsoft flows.=C2=A0

While the = flow in=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-= 02#section-3.4=C2=A0has additional steps, it is not fundamentally any d= ifferent except the Client is making another call to the GS after the first= one returns. The risk of the Client not making the second call and leaving= the User hanging is not really any different of the Client not making the = first call.

Besides the situation where the mobile= device that MAY not be able to make the second call might put to sleep, I = don't see any implementation issues. TxAuth works the same way as 3.1 a= s I understand it for non-redirect flows.
=C2=A0

=C2=A0

[pasting in from your later email]

While a single stage Gra= nt request (3.1) in a mobile app that has been put to sleep will recover fi= ne, a multi-step (3.4) will fail. Since 3.4 only makes sense if the Client = is checking a database along the way, I would=C2=A0expect the Client to have a server side, and the server could= take each step.

[/end paste]

=C2=A0

[richanna]

Having a remote database and having a remote server = are not the same thing. This adds a lot of complexity to serverless apps.

[/richanna]=E1=90=A7


Which aspect adds complexity?
=
The added complexity in keeping an interaction is making an = additional API call after the first API call.

=C2= =A0
=

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000002e4c0b059e8c4590-- From nobody Fri Feb 14 12:17:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4912022C for ; Fri, 14 Feb 2020 12:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 KbOm7SZosynY for ; Fri, 14 Feb 2020 12:17:07 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A819C120A99 for ; Fri, 14 Feb 2020 12:17:04 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01EKH0wp005264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Feb 2020 15:17:01 -0500 From: Justin Richer Message-Id: <41E1A1E6-46B0-4F80-A040-D9C215E65636@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_73C09309-631B-49F5-9E77-4C28201F78B2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 14 Feb 2020 15:17:00 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" To: Dick Hardt References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 20:17:09 -0000 --Apple-Mail=_73C09309-631B-49F5-9E77-4C28201F78B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > =20 >=20 > =20 >=20 > 2. Clients support multiple interaction modes and may not always = know what the GS supports (and vice-versa). For a multi-tenant GS, it = may vary by tenant configuration. Clients should be able to say what = they can do, and the GS should be able to tell them which one to use. = It=E2=80=99s a very simple but powerful inline negotiation. >=20 > =20 >=20 > That is what is in TxAuth. Would you elaborate on how the GS might be = constrained? Why would the GS not be able to do all? >=20 > =20 >=20 > I would think all constraints would be at the Client. Am I missing = something? >=20 > =20 >=20 > [richanna] >=20 > Clients may support customer-defined GSes (e.g., enterprise IdPs), = which will vary in terms of which interaction modes they support. While = the set of interactions defined in XAuth might all be MTI for a GS, we = should assume that extensions will introduce new interactions which will = not be universally supported. An interaction mechanism might have = properties that cause some administrators to want to disable it, or to = restrict Clients to always use it. Are you assuming that a Client will = always make an OPTIONS discovery request first? >=20 > [/richanna]=20 >=20 >=20 > An example of why a given GS may not support a mode would be helpful. >=20 > I was envisioning that if an optional to support interaction mode was = not supported at the GS, that it would return an error. The Client would = then try a different one. Alternatively, the Client could start with an = OPTIONS call in cases where the GS is dynamicly chosen. > =20 This is pretty simple: I buy my GS from one vendor and download my = Client library from another vendor. Both of them support different sets = of multiple interaction modes, and they have a non-zero overlap of = commonality that neither implementor knows ahead of time. It sounds like = your assumption is that clients will be built to talk to a specific GS = at all times, that they=E2=80=99re made in pairs tightly coupled to each = other. While that was true in the distant past, I don=E2=80=99t think = that model holds today. Otherwise they=E2=80=99d always do a discovery = step (using OPTIONS here) before talking to the GS.=20 In XYZ=E2=80=99s interaction model, the client simply sets up whatever = options it can handle, and the AS responds with whatever ones it = supports. If that ends up being a zero-set, then the user can=E2=80=99t = interact and, most likely, the request fails. This kind of single-step = inline negotiation is incredibly powerful. For the cases where it=E2=80=99s statically known by the developer which = modes the server supports, they can send only one. For dynamic cases, = you don=E2=80=99t need an extra round trip. And for the complex cases = where you could have the user interact in multiple ways (IE, scan a QR = code :or: type in a short user code), you don=E2=80=99t have to define a = new =E2=80=9Ctype=E2=80=9D for each possible combination.=20 =E2=80=94 Justin= --Apple-Mail=_73C09309-631B-49F5-9E77-4C28201F78B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

 

 

2.   Clients support multiple interaction modes and may not = always know what the GS supports (and vice-versa). For a multi-tenant = GS, it may vary by tenant configuration. Clients should be able to say = what they can do, and the GS should be able to tell them which one to = use. It=E2=80=99s a very simple but powerful inline negotiation.

 

That is what is in = TxAuth. Would you elaborate on how the GS might be constrained? Why = would the GS not be able to do all?

 

I would think all constraints would be at = the Client. Am I missing something?

 

[richanna]

Clients may support = customer-defined GSes (e.g., enterprise IdPs), which will vary in terms = of which interaction modes they support. While the set of interactions = defined in XAuth might all be MTI for a GS, we should assume that = extensions will introduce new interactions which will not be universally = supported. An interaction mechanism might have properties that cause = some administrators to want to disable it, or to restrict Clients to = always use it. Are you assuming that a Client will always make an = OPTIONS discovery request first?

[/richanna] 


An = example of why a given GS may not support a mode would be = helpful.

I was = envisioning that if an optional to support interaction mode was not = supported at the GS, that it would return an error. The Client would = then try a different one. Alternatively, the Client could start with an = OPTIONS call in cases where the GS is dynamicly chosen.
 

This is pretty simple: I buy my GS from one vendor = and download my Client library from another vendor. Both of them support = different sets of multiple interaction modes, and they have a non-zero = overlap of commonality that neither implementor knows ahead of time. It = sounds like your assumption is that clients will be built to talk to a = specific GS at all times, that they=E2=80=99re made in pairs tightly = coupled to each other. While that was true in the distant past, I = don=E2=80=99t think that model holds today. Otherwise they=E2=80=99d = always do a discovery step (using OPTIONS here) before talking to the = GS. 

In XYZ=E2=80=99s = interaction model, the client simply sets up whatever options it can = handle, and the AS responds with whatever ones it supports. If that ends = up being a zero-set, then the user can=E2=80=99t interact and, most = likely, the request fails. This kind of single-step inline negotiation = is incredibly powerful.

For the = cases where it=E2=80=99s statically known by the developer which modes = the server supports, they can send only one. For dynamic cases, you = don=E2=80=99t need an extra round trip. And for the complex cases where = you could have the user interact in multiple ways (IE, scan a QR code = :or: type in a short user code), you don=E2=80=99t have to define a new = =E2=80=9Ctype=E2=80=9D for each possible = combination. 

 =E2=80=94 = Justin
= --Apple-Mail=_73C09309-631B-49F5-9E77-4C28201F78B2-- From nobody Fri Feb 14 13:40:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4E1200C1 for ; Fri, 14 Feb 2020 13:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 TdWQ1_OU9JcH for ; Fri, 14 Feb 2020 13:40:02 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981821200EC for ; Fri, 14 Feb 2020 13:40:01 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id w1so12287725ljh.5 for ; Fri, 14 Feb 2020 13:40: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=GjoHN3LUGO07mFWYNt6ygkmqDNje1+K9LJKdz+IzYUs=; b=SFBY3hmciyuZoDo1wzqxSCpzaaDXwUOyqmmzAhEgj28uine1CU3bcp6+WQQ5cWC7UY zyL/iZUxsiTJ/RTryWx9MlW0GkDOWPqrki0edorcivVCgQBBRMcDV4FrtJDkXfqzgsyJ Gp0wG5Ywdek2ItdFvBR78E1aQtD3/PvoowD7noaKannxqRB63Y5Clgbh9V3iJskQZUeM byfKxn1RXaS9HU95UBZK8Bto7MVg6izfkrEaEHzD8641Cl9dOtxxO0tCcWjXEGsgjIBb 8DhcDipluux28+avP1y8+Mhdo0iNE6fghIOKa+05ydVKf+JF0OmU9SMyOpsRHioyqla9 g4Og== 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=GjoHN3LUGO07mFWYNt6ygkmqDNje1+K9LJKdz+IzYUs=; b=Q4AaqzrpV0TQSvsoZGwvvjB5nId7g9VEYrA2nHFQv9ZdrJj5uOz0pTjula4aBaX81z qZxVdWt/Si5aj9eP++BDl67aSh4HiLSOcNFikIggf4vUTLDNkIxQkaIJJMLptSJhqi/Y 9uEYqsuH4KLjJqfy8B/ad0aXXf9Xo6bMf/f3P4mBr+RQ6Q8lkBlH6+v2yAJYj1ZSwyLg uZLCwQFk/l/Wjx4v7p0IhJHnW2KAD6RJBUjWaQ1X7Tazk2/37UnR/kowPdKhANIq201R SIP9oFcouniAcdaELSidWl4kXqRUtw2hTWbxmAIiqyaH8QNPuJ/VJ5Mr+gBRPSVXjbz2 J+QA== X-Gm-Message-State: APjAAAVE3gf3DzvUJbl2LSHwOTw5ifqyvyy6Qi4MK5kCI7na2I6UeSnF hT4sQXEO8wAB2VYJzuPzh5vVO0rF+RAZNOvQm9G8slDu X-Google-Smtp-Source: APXvYqy7PJG7Bo+dsoF7lHdoGA/K0TVIwKAamZYPeR9ZFGevsGaXb2ILFa2nAmklgqsddR3BOxd6RPAZxsRv/OnF034= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr3358267ljj.212.1581716399708; Fri, 14 Feb 2020 13:39:59 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <41E1A1E6-46B0-4F80-A040-D9C215E65636@mit.edu> In-Reply-To: <41E1A1E6-46B0-4F80-A040-D9C215E65636@mit.edu> From: Dick Hardt Date: Fri, 14 Feb 2020 13:39:33 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000023df52059e900c18" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 21:40:06 -0000 --00000000000023df52059e900c18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I am not expecting Clients to always be built to a specific GS, but that is the common case today. What has you think that model does not hold true today? Your example is a hypothetical that seems very unlikely. Why would a GS from a vendor not support all defined interaction modes? The constraints of what is available are at the Client. We could have XAuth provide a list of types of modes it can support in preferential order -- but I would prefer to not add complexity unless there is a clear use case for it. =E1=90=A7 On Fri, Feb 14, 2020 at 12:17 PM Justin Richer wrote: > > >> >> >> >> 2. Clients support multiple interaction modes and may not always know >> what the GS supports (and vice-versa). For a multi-tenant GS, it may var= y >> by tenant configuration. Clients should be able to say what they can do, >> and the GS should be able to tell them which one to use. It=E2=80=99s a = very simple >> but powerful inline negotiation. >> >> >> >> That is what is in TxAuth. Would you elaborate on how the GS might be >> constrained? Why would the GS not be able to do all? >> >> >> >> I would think all constraints would be at the Client. Am I missing >> something? >> >> >> >> [richanna] >> >> Clients may support customer-defined GSes (e.g., enterprise IdPs), which >> will vary in terms of which interaction modes they support. While the se= t >> of interactions defined in XAuth might all be MTI for a GS, we should >> assume that extensions will introduce new interactions which will not be >> universally supported. An interaction mechanism might have properties th= at >> cause some administrators to want to disable it, or to restrict Clients = to >> always use it. Are you assuming that a Client will always make an OPTION= S >> discovery request first? >> >> [/richanna] >> > > An example of why a given GS may not support a mode would be helpful. > > I was envisioning that if an optional to support interaction mode was not > supported at the GS, that it would return an error. The Client would then > try a different one. Alternatively, the Client could start with an OPTION= S > call in cases where the GS is dynamicly chosen. > > > > This is pretty simple: I buy my GS from one vendor and download my Client > library from another vendor. Both of them support different sets of > multiple interaction modes, and they have a non-zero overlap of commonali= ty > that neither implementor knows ahead of time. It sounds like your > assumption is that clients will be built to talk to a specific GS at all > times, that they=E2=80=99re made in pairs tightly coupled to each other. = While that > was true in the distant past, I don=E2=80=99t think that model holds toda= y. > Otherwise they=E2=80=99d always do a discovery step (using OPTIONS here) = before > talking to the GS. > > In XYZ=E2=80=99s interaction model, the client simply sets up whatever op= tions it > can handle, and the AS responds with whatever ones it supports. If that > ends up being a zero-set, then the user can=E2=80=99t interact and, most = likely, > the request fails. This kind of single-step inline negotiation is > incredibly powerful. > > For the cases where it=E2=80=99s statically known by the developer which = modes the > server supports, they can send only one. For dynamic cases, you don=E2=80= =99t need > an extra round trip. And for the complex cases where you could have the > user interact in multiple ways (IE, scan a QR code :or: type in a short > user code), you don=E2=80=99t have to define a new =E2=80=9Ctype=E2=80=9D= for each possible > combination. > > =E2=80=94 Justin > --00000000000023df52059e900c18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, I am not expecting Clients to always be built to = a specific GS, but that is the common case today. What has you think that m= odel does not hold true today?=C2=A0

Your example is a = hypothetical that seems very unlikely. Why would a GS from a vendor not sup= port all defined interaction modes?=C2=A0

The const= raints of what is available are at the Client.=C2=A0

We could have XAuth provide a list of types of modes it can support in p= referential order -- but I would prefer to not add complexity unless there = is a clear use case for it.








=E1=90=A7

On Fri, Feb 14, 2020 at 12:17 PM Ju= stin Richer <jricher@mit.edu> = wrote:

=C2=A0

=C2=A0<= u>

2.=C2=A0=C2=A0=C2=A0Clients support multiple interaction modes and may = not always know what the GS supports (and vice-versa). For a multi-tenant G= S, it may vary by tenant configuration. Clients should be able to say what = they can do, and the GS should be able to tell them which one to use. It=E2= =80=99s a very simple but powerful inline negotiation.

=C2=A0

That is what is in TxAuth. Would you elaborate on how the GS = might be constrained? Why would the GS not be able to do all?=

= =C2=A0

I would think all constraints would be at the Client. Am I missing some= thing?

=C2=A0

[richanna]

Clien= ts may support customer-defined GSes (e.g., enterprise IdPs), which will va= ry in terms of which interaction modes they support. While the set of inter= actions defined in XAuth might all be MTI for a GS, we should assume that e= xtensions will introduce new interactions which will not be universally sup= ported. An interaction mechanism might have properties that cause some admi= nistrators to want to disable it, or to restrict Clients to always use it. = Are you assuming that a Client will always make an OPTIONS discovery reques= t first?

[/richanna]=C2=A0


An example of why= a given GS may not support a mode would be helpful.

I was envisioning that if an optional to support interaction mode was no= t supported at the GS, that it would return an error. The Client would then= try a different one. Alternatively, the Client could start with an OPTIONS= call in cases where the GS is dynamicly chosen.
=C2=A0

This is pretty simple: I buy my GS from= one vendor and download my Client library from another vendor. Both of the= m support different sets of multiple interaction modes, and they have a non= -zero overlap of commonality that neither implementor knows ahead of time. = It sounds like your assumption is that clients will be built to talk to a s= pecific GS at all times, that they=E2=80=99re made in pairs tightly coupled= to each other. While that was true in the distant past, I don=E2=80=99t th= ink that model holds today. Otherwise they=E2=80=99d always do a discovery = step (using OPTIONS here) before talking to the GS.=C2=A0

In XYZ=E2=80=99s interaction model, the client simply sets up whate= ver options it can handle, and the AS responds with whatever ones it suppor= ts. If that ends up being a zero-set, then the user can=E2=80=99t interact = and, most likely, the request fails. This kind of single-step inline negoti= ation is incredibly powerful.

For the cases where = it=E2=80=99s statically known by the developer which modes the server suppo= rts, they can send only one. For dynamic cases, you don=E2=80=99t need an e= xtra round trip. And for the complex cases where you could have the user in= teract in multiple ways (IE, scan a QR code :or: type in a short user code)= , you don=E2=80=99t have to define a new =E2=80=9Ctype=E2=80=9D for each po= ssible combination.=C2=A0

=C2=A0=E2=80=94 Justin
--00000000000023df52059e900c18-- From nobody Fri Feb 14 13:51:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDB51200C1 for ; Fri, 14 Feb 2020 13:51:54 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 (1024-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVidlKJUVYPZ for ; Fri, 14 Feb 2020 13:51:52 -0800 (PST) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778811200EC for ; Fri, 14 Feb 2020 13:51:44 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 313013853D4; Fri, 14 Feb 2020 21:51:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1581717103; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ukbwLsLZQznbSInsssv7pUM2uZwHHArzloKqpuiutys=; b=fZMIXHbHCISzEUwQy8ua/IizfE1xwzQLJ2usexoa5v+A90vqQoDTcLWs6WQTkwwNdmoHrf jcLvNVRSXxuwwyWrzI4BdhULMRWH3q+IJhx45yjuVSMe7OZ6QhzPGdff/F1aVCElKdD5tt vfRZQPcNwPlmbL5nIG0/FyzoTqoqu9A= From: David Waite Message-Id: <77F37F28-FB89-4F5A-B273-110653FAFCDC@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E63D403A-071D-4C9E-9620-3C3092D2E2BE" Mime-Version: 1.0 Date: Fri, 14 Feb 2020 14:51:39 -0700 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org, Justin Richer To: George Fletcher References: <22536DE3-E90E-4543-A668-D89054D2401C@alkaline-solutions.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1581717103; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ukbwLsLZQznbSInsssv7pUM2uZwHHArzloKqpuiutys=; b=NEpt3USd2egzoe4eYw2CEKOEcc2+Ac1JNrxzHD2gXtWa4e61S27rHB3T2Oht61xxXv87xN hJlF1rkpH1aXgThNKYaHbN7J2yXrJqMrhDgnFzih+ddFIvHktpK1EPrboBo+44uPUWpc8l Ba/x/wvl/cTHW8RZyrtkm5vz2q6ra2I= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1581717103; a=rsa-sha256; cv=none; b=DpGzVpP9ACCoK0yE5l2zy/EPeCCIafD95zCCUxAHflRINNz9OFHOTIgalZDHY7VWHaTcUL 4wUR9MVKHgfCMFbuoqF2qsuY+mvFj8ZBCmUi4eBCjNjiUcfMh1be92rfyt3SE9k+CFvtMq AC2vMPbfULIbnwo2PLTmcCjkDYzXz/Y= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [Txauth] Identity and session management X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 21:51:55 -0000 --Apple-Mail=_E63D403A-071D-4C9E-9620-3C3092D2E2BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 14, 2020, at 8:15 AM, George Fletcher = wrote: >=20 > I think there are multiple use cases and perspectives when it comes to = session management and usability on the web.=20 >=20 > As for perspectives, we have: > 1. The user and the experience they are expecting > 2. The relying party and how they are viewing authentication and = session management >=20 > As for use cases, we have: > 1. Relying parties that support Federated Authentication and then = manage the resulting session themselves. In this context the session is = really an RP session and NOT and IDP session.=20 > 2. Relying parties that want to be tightly bound to the IDP session. = This is often true of services that are "1st party" to the domain of the = IDP (e.g. Yahoo services and the Yahoo IDP). Yes, an id_token exchange in OpenID Connect could be considered to be = three things: 1. A mechanism for correlation between accounts/personas of two parties 2. A mechanism to convey authentication events by that persona on the = IDP/OP, for dependence by the RP, in the context of a particular user = agent 3. Claims about that persona on the IDP/OP, to enrich or enable policy = decisions by the RP Many/most RPs either do not care about #2, or only care about = authentication in the context of their own initiation of SSO. They do = not attempt to track ongoing authentication events by the IDP/OP to = control local access by the user agent. Arguably one of the values of OAuth and delegated authorization is that = the enforcement of authorization is often under the control of the same = parties as the AS. However with authentication scenarios, the = authorization decisions and enforcement are made by the RP. > User goes to hikingtrail.example and clicks the "Sign in with Google" = button. The user is both SSO'd into Google properties and also logged = into hikingtrail.example. The user only has one tab open for = hikingtrail.example and when the user is finished with their activities = at hikingtrail.example, they click the logout button. > If hikingtrail.example is using the RP-Bound session model, they log = the user out of hikingtrail.example but the user is still logged in at = Google. If the user were to click the signin button, they would be = silently signed in with a new RP-Bound session. This can be confusing to = users because they may have expected to be logged out of Google as the = only open tab was for hikingtrail.example. > If hikingtrail.example is using the IDP-Bound session model, then it = needs a way to signal to Google that the user wants the IDP session to = be revoked when the user clicks the logout button on = hikingtrail.example. =46rom an IDP with "1st party" services = perspective, it's "dangerous" to provide this mechanism to relying = parties. My expectation (principal of least surprise), would be that for a third = party application like hikingtrail, =E2=80=98Sign in with Google=E2=80=99 = or =E2=80=98Log in with Facebook=E2=80=99 does just that - it gives = access based on Google. I would not expect the sessions of two = completely separate applications to be bound. If anything, I would expect that the OP would indicate better that the = user may be creating a second authentication session with the OP as a = side effect. This could even result in a =E2=80=9Cremember me=E2=80=9D = or =E2=80=9Cpersonal machine=E2=80=9D sort of checkbox, where the = checked box is what enables SSO. Unchecked, each authentication request = by a third-party RP would require new authentication. I don=E2=80=99t know of a concise and obvious way to indicate to the = user that the sessions of two applications are being bound - I don=E2=80=99= t think changing the verbiage of the button to something like =E2=80=9CCon= nect with Google=E2=80=9D is sufficient. I suspect this winds up needing = holistic cues of deeper integration - for instance this might be ideal = with third party =E2=80=98editors=E2=80=99 for Google Drive. > User goes to Google and logs in to read their mail. The user then = opens a second tab and navigates to hikingtrail.example and clicks the = "Sign in with Google" button and is seamlessly logged in. When the user = finishes and clicks the "logout" button on hikingtrail.example they are = logged out of the site. > If hikingtrail.example is using the RP-Bound session model, the site = clears it's session and displays the logged out version of the site. = This is exactly what the user expects. If the user clicks the "Sign in = with Google" button they will be seamlessly logged in and that is also = what the user expects because they still have tab open for gmail. > If hikingtrail.example is using the IDP-Bound session model, the user = gets logged out of their gmail experience as well as = hikingtrail.example. This is something the IDP (if it provides 1st party = services) does not want to happen. > Today, many of the SaaS products we use in the enterprise use a = RB-Bound session model. We seem to manage. However, there are some = services that require an IDP-Bound session model and those are at times = annoying because I get logged out of the enterprise IDP just be logging = out of the SaaS tool. >=20 I don=E2=80=99t believe best practices of distributed sessions are = anywhere close to being documented or understood by developers or = integrators. In some enterprise applications I see any =E2=80=98logout=E2=80= =99 button disconnected. In others, I see it going to a protocol or = other endpoint to revoke as much access as possible. If I=E2=80=99ve seen patterns here, it is that a working logout button = is either connected merely because it is possible, or because the RP = application has a certain level of access to sensitive data.=20 > Maybe one option that could be explored is allowing an RP to indicate = to the IDP that it does not want an IDP-Session to be created for this = user/device if one doesn't currently exist. Today this would manifest as = the IDP NOT setting SSO cookies on it's own domain and just returning = the federated authentication tokens. >=20 Yes, although I think the typical user has more exposure to understand = the ramifications of a =E2=80=98remember me=E2=80=99 checkboxes, so this = may (like most request parameters) only serve as a hint. > Hopefully that is helpful in some way :) >=20 Of course! -DW --Apple-Mail=_E63D403A-071D-4C9E-9620-3C3092D2E2BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 14, 2020, at 8:15 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20
I think there are multiple use cases and perspectives when it comes to session management and usability on the web.

As for perspectives, we have:
1. The user and the experience they are expecting
2. The relying party and how they are viewing authentication and session management

As for use cases, we have:
1. Relying parties that support Federated Authentication and then manage the resulting session themselves. In this context the session is really an RP session and NOT and IDP session.
2. Relying parties that want to be tightly bound to the IDP session. This is often true of services that are "1st party" to the domain of the IDP (e.g. Yahoo services and the Yahoo IDP).

Yes, an = id_token exchange in OpenID Connect could be considered to be three = things:

1. A mechanism for = correlation between accounts/personas of two parties
2. A = mechanism to convey authentication events by that persona on the IDP/OP, = for dependence by the RP, in the context of a particular user = agent
3. Claims about that persona on the IDP/OP, to enrich or = enable policy decisions by the RP

Many/most RPs either do not care about #2, or only = care about authentication in the context of their own initiation of SSO. = They do not attempt to track ongoing authentication events by the IDP/OP = to control local access by the user agent.

Arguably one of the values of OAuth and delegated = authorization is that the enforcement of authorization is often under = the control of the same parties as the AS. However with authentication = scenarios, the authorization decisions and enforcement are made by the = RP.

  1. User goes to hikingtrail.example and clicks the "Sign in with Google" button. The user is both SSO'd into Google properties and also logged into hikingtrail.example. The user only has one tab open for hikingtrail.example and when the user is finished with their activities at hikingtrail.example, they click the logout button.
    1. If hikingtrail.example is using the RP-Bound = session model, they log the user out of hikingtrail.example but the user is still logged in at Google. If the user were to click the signin button, they would be silently signed in with a new RP-Bound session. This can be confusing to users because they may have expected to be logged out of Google as the only open tab was for hikingtrail.example.
    2. If hikingtrail.example is using the IDP-Bound = session model, then it needs a way to signal to Google that the user wants the IDP session to be revoked when the user clicks the logout button on hikingtrail.example. =46rom an IDP with "1st party" services perspective, it's "dangerous" to provide this mechanism to relying = parties.
My expectation = (principal of least surprise), would be that for a third party = application like hikingtrail, =E2=80=98Sign in with Google=E2=80=99 or = =E2=80=98Log in with Facebook=E2=80=99 does just that - it gives access = based on Google. I would not expect the sessions of two completely = separate applications to be bound.

If = anything, I would expect that the OP would indicate better that the user = may be creating a second authentication session with the OP as a side = effect. This could even result in a =E2=80=9Cremember me=E2=80=9D or = =E2=80=9Cpersonal machine=E2=80=9D sort of checkbox, where the checked = box is what enables SSO. Unchecked, each authentication request by a = third-party RP would require new authentication.

I don=E2=80=99t know of a concise and obvious way = to indicate to the user that the sessions of two applications are being = bound - I don=E2=80=99t think changing the verbiage of the button to = something like =E2=80=9CConnect with Google=E2=80=9D is sufficient. I = suspect this winds up needing holistic cues of deeper integration - for = instance this might be ideal with third party =E2=80=98editors=E2=80=99 = for Google Drive.
  1. User goes to Google and logs in to read their mail. = The user then opens a second tab and navigates to hikingtrail.example and clicks the "Sign in with Google" button and is seamlessly logged in. When the user finishes and clicks the "logout" button on hikingtrail.example they are logged out of the site.
    1. If hikingtrail.example is using the RP-Bound = session model, the site clears it's session and displays the logged out version of the site. This is exactly what the user expects. If the user clicks the "Sign in with Google" button they will be seamlessly logged in and that is also what the user expects because they still have tab open for gmail.
    2. If hikingtrail.example is using the IDP-Bound = session model, the user gets logged out of their gmail experience as well as hikingtrail.example. This is something the IDP (if it provides 1st party services) does not want to happen.

Today, many of the SaaS products we use in the = enterprise use a RB-Bound session model.  We seem to manage. However, there = are some services that require an IDP-Bound session model and those are at times annoying because I get logged out of the enterprise IDP just be logging out of the SaaS = tool.

I don=E2=80=99t believe best practices = of distributed sessions are anywhere close to being documented or = understood by developers or integrators. In some enterprise applications = I see any =E2=80=98logout=E2=80=99 button disconnected. In others, I see = it going to a protocol or other endpoint to revoke as much access as = possible.

If I=E2=80=99ve seen = patterns here, it is that a working logout button is either connected = merely because it is possible, or because the RP application has a = certain level of access to sensitive data. 

Maybe one option that could be explored is allowing an RP to indicate to the IDP that it does not want an IDP-Session to be created for this user/device if one doesn't currently exist. Today this would manifest as the IDP NOT setting SSO cookies on it's own domain and just returning the federated authentication tokens.

Yes, although I think the = typical user has more exposure to understand the ramifications of a = =E2=80=98remember me=E2=80=99 checkboxes, so this may (like most request = parameters) only serve as a hint.

Hopefully that is helpful in some way = :)

Of course!

-DW

= --Apple-Mail=_E63D403A-071D-4C9E-9620-3C3092D2E2BE-- From nobody Fri Feb 14 18:29:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50FB1200B8 for ; Fri, 14 Feb 2020 18:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJZoZNEVGIuB for ; Fri, 14 Feb 2020 18:29:46 -0800 (PST) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 0E76512002F for ; Fri, 14 Feb 2020 18:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1581733784; x=1613269784; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=453ZNEjbJ1Em3e/HOJWFTR5wVq7YI1svb44dYaVxokk=; b=IbgRh/RKp8FaHZSg6wxyo+EvBj3KagHXxbxi6iawNtL003VkAsGG7uQ+ WOonmn+kP62ORSGgw5nM6OY0beIWhNKlHYsp1hLsrHzne1+RenXd02y7z cWMO0ty6z5podMX2TObn0A6FL9CvYCiiYQcaMvtvF5g8JyL9ocSybmB8J s=; IronPort-SDR: x8Qbh854DXcVCNlFBg1Hpa7V/fDhpwxUR/GVGTyUzVEviWbxMA+TV88oUSEIQbF4s6ZLn4HoVf UlKszxppl+SQ== X-IronPort-AV: E=Sophos; i="5.70,442,1574121600"; d="scan'208,217"; a="16402470" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-859fe132.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 15 Feb 2020 02:29:31 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-859fe132.us-west-2.amazon.com (Postfix) with ESMTPS id 4405422405A for ; Sat, 15 Feb 2020 02:29:30 +0000 (UTC) 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; Sat, 15 Feb 2020 02:29:29 +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; Sat, 15 Feb 2020 02:29:29 +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, 15 Feb 2020 02:29:29 +0000 From: "Richard Backman, Annabelle" To: "txauth@ietf.org" Thread-Topic: [Txauth] XAuth -02 Thread-Index: AQHV3jRcCsQaXzP9e0Gex6TsPtSqQKgUiKoAgAPnIYCAAQUDgIABgbqAgAAWcoA= Date: Sat, 15 Feb 2020 02:29:29 +0000 Message-ID: <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@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.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.233] Content-Type: multipart/alternative; boundary="_000_0092A517C90B41A68272D779E84E10C9amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 02:29:51 -0000 --_000_0092A517C90B41A68272D779E84E10C9amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W3JpY2hhbm5hXQ0KUmVwbGllcyBpbmxpbmUuDQpbL3JpY2hhbm5hXQ0KDQrigJMNCkFubmFiZWxs ZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5hbWF6b24uY29t L2lkZW50aXR5Lw0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRh eSwgRmVicnVhcnkgMTQsIDIwMjAgYXQgOToxMCBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiAidHhh dXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFhB dXRoIC0wMg0KDQoNCg0KT24gVGh1LCBGZWIgMTMsIDIwMjAgYXQgNjowOCBQTSBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCltyaWNoYW5uYV0NClJl cGxpZXMgaW5saW5lDQpbL3JpY2hhbm5hXQ0KPHNuaXA+DQpbcmljaGFubmFdDQpCeSB1c2VyIGNv ZGUtYmFzZWQgaW50ZXJhY3Rpb24sIEkgbWVhbiB0aGUga2luZCBkZXNjcmliZWQgaW4gdGhlIE9B dXRoIDIuMCBEZXZpY2UgQXV0aG9yaXphdGlvbiBHcmFudDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM4NjI4Piwgd2hlcmUgdGhlIHVzZXIgcmVjZWl2ZXMgYSBjb2RlIGFuZCBzaG9ydCBV UkwgZnJvbSB0aGUgY2xpZW50LCBuYXZpZ2F0ZXMgdG8gdGhhdCBVUkwgaW4gYSBicm93c2VyLCBh bmQgZW50ZXJzIHRoZSBjb2RlLiBXaGlsZSB0aGlzIGNvdWxkIGJlIHBhY2tlZCBpbnRvIGludGVy YWN0aW9uLm1lc3NhZ2UsIHRoaXMgd2lsbCBsZWFkIHRvIGNsdW5raWVyIHVzZXIgZXhwZXJpZW5j ZXM6DQoNCjEuICAgVGhlIEdTIG1heSBub3QgYmUgYWJsZSB0byBwcm92aWRlIGxvY2FsaXplZCBp bnN0cnVjdGlvbnMgdGhhdCBtYXRjaCB0aGUgbG9jYWxlIG9uIHRoZSBDbGllbnQuDQoNCjIuICAg U3VwcG9zZSB0aGUgR1Mgc2VuZHMgYSBtZXNzYWdlIHRoYXQgcmVhZHM6IOKAnFNjYW4gdGhlIFFS IGNvZGUgb3Igb3BlbiBhIGJyb3dzZXIgdG8gaHR0cDovL2NvZGUuZXhhbXBsZS8gYW5kIGVudGVy IHRoZSBjb2RlOiAxMjM0NS7igJ0NCg0KYS4gICAgVGhhdCBpbnN0cnVjdGlvbiBkb2VzIG5vdCBt YWtlIHNlbnNlIG9uIGEgZGV2aWNlIHRoYXQgZG9lcyBub3QgcHJlc2VudCBhIFFSIGNvZGUuIElt YWdpbmUgaGVhcmluZyB0aGF0IGZyb20gYSBzbWFydCBzcGVha2VyLg0KDQpiLiAgIFRoYXQgaW5z dHJ1Y3Rpb24gaXMgY29uZnVzaW5nbHkgcmVkdW5kYW50IGlmIHRoZSBDbGllbnQgZGlzcGxheXMg dGhlIFFSIGNvZGUgYWxvbmcgd2l0aCBpdHMgb3duIGluc3RydWN0aW9ucywgbGlrZTog4oCcU2Nh biB0aGUgUVIgY29kZSBvciBmb2xsb3cgdGhlIGluc3RydWN0aW9ucyBiZWxvdy7igJ0NCg0KMy4g ICBXaWxsIOKAnGVtYmVkIHRoZSBzaG9ydCBVUkwgYW5kIGNvZGUgaW4gdGhlIG1lc3NhZ2Ugc3Ry aW5n4oCdIGJlIE1UST8gSWYgbm90LCB0ZXh0LW9ubHkgY2xpZW50cyB3b3VsZCBoYXZlIGEgYnJv a2VuIGV4cGVyaWVuY2UuDQpbL3JpY2hhbm5hXQ0KDQpTb3VuZHMgbGlrZSBhIHRleHQgb25seSBp bnRlcmFjdGlvbiB0eXBlIHNob3VsZCBiZSBhZGRlZCBwZXIgbXkgbm90ZSBpbiB0aGUgZHJhZnQu IFBlcmhhcHMgZXZlbiBvbmUgdGhhdCBpcyBmb2N1c2VkIG9uIHRoZSBjb2RlIGZsb3csIHdoZXJl IHRoZSBwYXJhbWV0ZXJzIGFyZSB0aGUgY29kZSBhbmQgdGhlIFVSSSB0byBlbnRlciB0aGUgY29k ZSwgbGV0dGluZyB0aGUgQ2xpZW50IHByZXNlbnQgdGhlIHBhcmFtZXRlcnMgd2l0aCBsb2NhbGl6 ZWQgY29udGVudD8NCg0KW3JpY2hhbm5hXQ0KSSB0aGluayB3ZeKAmXJlIGFwcHJvYWNoaW5nIHRo ZSDigJxpbnRlcmFjdGlvbuKAnSBjb25jZXB0IHdyb25nLiBXZeKAmXJlIGNvbmZsYXRpbmcgdGhy ZWUgZGlmZmVyZW50IHRoaW5ncyB0b2dldGhlcjoNCg0KICAqICAgV2hhdCBkb2VzIHRoZSBDbGll bnQgbmVlZCB0byBzZW5kIHRoZSBlbmQgdXNlciB0byB0aGUgR1M/DQoNCiAgICAgKiAgIEEgaHVt YW4tZnJpZW5kbHkgc2hvcnQgVVJMIGFuZCBjb2RlLg0KICAgICAqICAgQW55IGtpbmQgb2YgVVJM LCBhcyBsb25nIGFuZCB1Z2x5IGFzIGl0IG5lZWRzIHRvIGJlLg0KDQogICogICBIb3cgd2lsbCB0 aGUgQ2xpZW50IHJlY2VpdmUgdGhlIHJlc3BvbnNlIGZyb20gdGhlIEdTPw0KDQogICAgICogICBD bGllbnQgd2lsbCBtYWtlIGEgcmVxdWVzdCB0byB0aGUgR1MuDQogICAgICogICBHUyB3aWxsIG1h a2UgYSByZXF1ZXN0IHRvIHRoZSBDbGllbnQuIChJ4oCZdmUgaGFkIHRvIGltcGxlbWVudCB0aGlz IGZvciBhIGN1c3RvbSBpbnRlZ3JhdGlvbiwgaW5jbHVkaW5nIGl0IHRvIGRlbW9uc3RyYXRlIHRo YXQgb3RoZXIgb3B0aW9ucyBleGlzdCkNCg0KICAqICAgV2lsbCB0aGUgR1MgcmV0dXJuIHRoZSBl bmQgdXNlciB0byB0aGUgQ2xpZW50LCBhbmQgaWYgc28gaG93Pw0KDQogICAgICogICBZZXMsIGJ5 IFVSTCByZWRpcmVjdC4NCiAgICAgKiAgIE5vLg0KDQpIZXJlIGlzIGEgdmVyeSBub24tbm9ybWF0 aXZlIGV4YW1wbGUgcmVxdWVzdCBmcmFnbWVudCwgZm9yIGEgY2xpZW50IHRoYXQgd2FudHMgYm90 aCBhIHNob3J0IFVSTCBwbHVzIGNvZGUgYW5kIGEgZnVsbCBVUkwgc28gdGhleSBjYW4gb3Bwb3J0 dW5pc3RpY2FsbHkgdXNlIG9uZSBvciB0aGUgb3RoZXIgKEFXUyBDTEkgdjIgZG9lcyB0aGlzKSwg d2lsbCBxdWVyeSB0aGUgR1MgZm9yIHRoZSByZXNwb25zZSwgYW5kIHdhbnRzIHRoZSBHUyB0byBy ZWRpcmVjdCB0byBhIHB1YmxpY2x5IGFjY2Vzc2libGUgVVJMIG9uIHRoZSBDbGllbnTigJlzIHdl YnNpdGUgYWZ0ZXIgdGhlIGZsb3cgKGUuZy4sIHRvIHNob3cgZnVydGhlciBkb2N1bWVudGF0aW9u L2JyYW5kZWQgY29udGVudCB0byB0aGUgZW5kIHVzZXIpOg0Kew0KImludGVyYWN0Ijogew0KICAi Y29kZSI6IHsgIm1heCI6IDggfSwNCiAgInVybCI6IHRydWUNCn0sDQoicmVzcG9uc2UiOiB7DQog ICJwb2xsIjogdHJ1ZQ0KfSwNCiJyZXR1cm4iOiB7DQogICJ1cmwiOiAiaHR0cHM6Ly9oZWxwLnNt YXJ0ZGV2aWNlLmV4YW1wbGUvcG9zdC1zZXR1cCINCn0NCn0NCg0KQW5kIGhlcmUgaXMgYW4gZXF1 YWxseSBub24tbm9ybWF0aXZlIGV4YW1wbGUgcmVzcG9uc2UgZnJhZ21lbnQ6DQp7DQoiaW50ZXJh Y3QiOiB7DQogICJjb2RlIjogIjEyMzQ1NiIsDQogICJjb2RlX3VybCI6ICJodHRwczovL2dzLmV4 YW1wbGUvY29kZSIsDQogICJ1cmwiOiAiaHR0cHM6Ly9ncy5leGFtcGxlL3hhdXRoLzEyMzQzNTY3 ODkwYWJjZGVmMTIzNDU2Nzg5MGFiY2RlZiINCn0NCn0NCg0KKFNlcmlvdXNseSBkbyBub3QgcmVh ZCB0b28gbXVjaCBpbnRvIHRoZXNlIHBhcmFtZXRlciBuYW1lcyBvciBzeW50YXgsIHRoaXMgaXMg anVzdCB0byBnaXZlIGEgcm91Z2ggc2Vuc2Ugb2YgaG93IEnigJltIHRoaW5raW5nIGFib3V0IHRo aXMuIEFueW9uZSB3aG8gdHJpZXMgdG8gcGljayBhcGFydCB0aGlzIGV4YW1wbGUgd2lsbCBiZSBy ZXNwb25kZWQgdG8gd2l0aCBtb2NraW5nIG1lbWVzLikNClsvcmljaGFubmFdDQoNCg0KMi4gICBD bGllbnRzIHN1cHBvcnQgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZXMgYW5kIG1heSBub3QgYWx3 YXlzIGtub3cgd2hhdCB0aGUgR1Mgc3VwcG9ydHMgKGFuZCB2aWNlLXZlcnNhKS4gRm9yIGEgbXVs dGktdGVuYW50IEdTLCBpdCBtYXkgdmFyeSBieSB0ZW5hbnQgY29uZmlndXJhdGlvbi4gQ2xpZW50 cyBzaG91bGQgYmUgYWJsZSB0byBzYXkgd2hhdCB0aGV5IGNhbiBkbywgYW5kIHRoZSBHUyBzaG91 bGQgYmUgYWJsZSB0byB0ZWxsIHRoZW0gd2hpY2ggb25lIHRvIHVzZS4gSXTigJlzIGEgdmVyeSBz aW1wbGUgYnV0IHBvd2VyZnVsIGlubGluZSBuZWdvdGlhdGlvbi4NCg0KVGhhdCBpcyB3aGF0IGlz IGluIFR4QXV0aC4gV291bGQgeW91IGVsYWJvcmF0ZSBvbiBob3cgdGhlIEdTIG1pZ2h0IGJlIGNv bnN0cmFpbmVkPyBXaHkgd291bGQgdGhlIEdTIG5vdCBiZSBhYmxlIHRvIGRvIGFsbD8NCg0KSSB3 b3VsZCB0aGluayBhbGwgY29uc3RyYWludHMgd291bGQgYmUgYXQgdGhlIENsaWVudC4gQW0gSSBt aXNzaW5nIHNvbWV0aGluZz8NCg0KW3JpY2hhbm5hXQ0KQ2xpZW50cyBtYXkgc3VwcG9ydCBjdXN0 b21lci1kZWZpbmVkIEdTZXMgKGUuZy4sIGVudGVycHJpc2UgSWRQcyksIHdoaWNoIHdpbGwgdmFy eSBpbiB0ZXJtcyBvZiB3aGljaCBpbnRlcmFjdGlvbiBtb2RlcyB0aGV5IHN1cHBvcnQuIFdoaWxl IHRoZSBzZXQgb2YgaW50ZXJhY3Rpb25zIGRlZmluZWQgaW4gWEF1dGggbWlnaHQgYWxsIGJlIE1U SSBmb3IgYSBHUywgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IGV4dGVuc2lvbnMgd2lsbCBpbnRyb2R1 Y2UgbmV3IGludGVyYWN0aW9ucyB3aGljaCB3aWxsIG5vdCBiZSB1bml2ZXJzYWxseSBzdXBwb3J0 ZWQuIEFuIGludGVyYWN0aW9uIG1lY2hhbmlzbSBtaWdodCBoYXZlIHByb3BlcnRpZXMgdGhhdCBj YXVzZSBzb21lIGFkbWluaXN0cmF0b3JzIHRvIHdhbnQgdG8gZGlzYWJsZSBpdCwgb3IgdG8gcmVz dHJpY3QgQ2xpZW50cyB0byBhbHdheXMgdXNlIGl0LiBBcmUgeW91IGFzc3VtaW5nIHRoYXQgYSBD bGllbnQgd2lsbCBhbHdheXMgbWFrZSBhbiBPUFRJT05TIGRpc2NvdmVyeSByZXF1ZXN0IGZpcnN0 Pw0KWy9yaWNoYW5uYV0NCg0KQW4gZXhhbXBsZSBvZiB3aHkgYSBnaXZlbiBHUyBtYXkgbm90IHN1 cHBvcnQgYSBtb2RlIHdvdWxkIGJlIGhlbHBmdWwuDQoNCkkgd2FzIGVudmlzaW9uaW5nIHRoYXQg aWYgYW4gb3B0aW9uYWwgdG8gc3VwcG9ydCBpbnRlcmFjdGlvbiBtb2RlIHdhcyBub3Qgc3VwcG9y dGVkIGF0IHRoZSBHUywgdGhhdCBpdCB3b3VsZCByZXR1cm4gYW4gZXJyb3IuIFRoZSBDbGllbnQg d291bGQgdGhlbiB0cnkgYSBkaWZmZXJlbnQgb25lLiBBbHRlcm5hdGl2ZWx5LCB0aGUgQ2xpZW50 IGNvdWxkIHN0YXJ0IHdpdGggYW4gT1BUSU9OUyBjYWxsIGluIGNhc2VzIHdoZXJlIHRoZSBHUyBp cyBkeW5hbWljbHkgY2hvc2VuLg0KDQpbcmljaGFubmFdDQpMb3RzIG9mIEFTZXMgZG9u4oCZdCBz dXBwb3J0IERldmljZSBBdXRob3JpemF0aW9uIEdyYW50LiBJIHRoaW5rIGl04oCZcyBzYWZlIHRv IGFzc3VtZSB0aGF0IGludGVyYWN0aW9uIG1vZGUgc3VwcG9ydCB3aWxsIHZhcnkgZm9yIFhBdXRo IGFzIHdlbGwuIOKAnEtlZXAgdHJ5aW5nIHVudGlsIHlvdSBmaW5kIG9uZSB0aGF0IHdvcmtz4oCd IHNvdW5kcyBwcmV0dHkgcGFpbmZ1bCBmb3IgdGhlIGNsaWVudCwgYW5kIGRvZXNu4oCZdCBhbGxv dyB0aGUgY2xpZW50IHRvIHVzZSBtdWx0aXBsZSBpbnRlcmFjdGlvbiBtb2RlcywgYXMgZGVtb25z dHJhdGVkIGluIG15IGV4YW1wbGUgYWJvdmUuDQoNClRoZXJlIGFyZSBsb3RzIG9mIHJlYXNvbnMg Zm9yIHdhbnRpbmcgdG8gc3VwcG9ydCBtdWx0aXBsZSBtb2RlczoNCg0KICAqICAgU29tZSBwZW9w bGUgYXJlIGNvbWZvcnRhYmxlIHdpdGggUVIgY29kZXMsIHNvbWUgYXJlbuKAmXQuDQogICogICBT b21lIHBlb3BsZSBoYXZlIHNtYXJ0IHBob25lcyB0aGF0IGNhbiBzY2FuIHRoZW0sIHNvbWUgZG9u 4oCZdC4NCiAgKiAgIFBlb3BsZSB3aXRoIHNtYXJ0IHBob25lcyBtYXkgd2FudCB0byBnbyB0aHJv dWdoIHRoZSBhdXRoZW50aWNhdGlvbiBmbG93IG9uIHRoZWlyIGRlc2t0b3AgaW5zdGVhZC4NCiAg KiAgIFNvbWUgcGVvcGxlIG1heSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9u IGZsb3cgb24gdGhlaXIgZGVza3RvcCwgYmVjYXVzZSB0aGUgR1MgdGhpbmtzIGlQaG9uZXMgb25s eSBzdXBwb3J0IEJsdWV0b290aC1iYXNlZCBzZWN1cml0eSBrZXlzIGFuZCBpbnNpc3RzIHRoZXkg Y2Fubm90IGNvbXBsZXRlIHRoZSBsb2dpbiBmbG93IGV2ZW4gdGhvdWdoIHRoZXkgaGF2ZSB0d28g WXViaUtleSA1Q2kga2V5cyBvbiB0aGVpciBhY2NvdW50LiAoSEksIEdPT0dMRSBBQ0NPVU5UIFBS T1RFQ1RJT04gUFJPR1JBTSkNClsvcmljaGFubmFdDQoNCjMuICAgSSBkb27igJl0IHNlZSB0aGUg dmFsdWUgb2YgdGhlIOKAnHBvcHVw4oCdIGludGVyYWN0aW9uIG1vZGUuIENsaWVudHMgY2FuIHVz ZSDigJxyZWRpcmVjdOKAnSBtb2RlIHdpdGhpbiBwb3B1cHMuIEhvd2V2ZXIsIHNwZWFraW5nIGFz IHNvbWVvbmUgd2hvIGhhcyBkb25lIHRoYXQsIEkgcmVhbGx5IGRvbuKAmXQgcmVjb21tZW5kIGl0 LiBQb3B1cHMgYXJlIGluY3JlYXNpbmdseSB1bnN1cHBvcnRlZCwgYW5kIHByb25lIHRvIHdlaXJk IGJlaGF2aW9yYWwgaXNzdWVzLiBJbi1hcHAgYnJvd3NlcnMgaW4gRmFjZWJvb2ssIFR3aXR0ZXIs IGV0Yy4gdGVuZCB0byBoYXZlIHBvcHVwcyBkaXNhYmxlZC4gVGhlIGxhc3QgdmVyc2lvbnMgb2Yg SUUgTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwgKHRoZSBwb3BwZWQgdXAgcGFn ZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVudCB3aW5kb3cpLi4gaW4NCg0K UG9wdXBzIGFyZSByZWFsbHkgdXNlZnVsIGluIHNpbmdsZS1wYWdlIGFwcHMgYXMgeW91IHdhbnQg dG8ga2VlcCB0aGUgY29udGV4dCBhbmQgbm90IHJlbG9hZCB0aGUgcGFnZS4NCg0KQWdyZWUgdGhh dCBwb3B1cHMgZG9uJ3QgbWFrZSBzZW5zZSBpbiBtb2JpbGUuIEEgZnVsbCByZWRpcmVjdCBkb2Vz IG9mIGNvdXJzZS4gQSBzaW5nbGUtcGFnZSBhcHAgb24gbW9iaWxlIHdvdWxkIG9wZW4gYSBuZXcg dGFiIHdoaWNoIHdvdWxkIGJlIGEgc2VwYXJhdGUgY29udGV4dCByYXRoZXIgdGhhbiBhIHJlZGly ZWN0Lg0KDQpbcmljaGFubmFdDQpQb3B1cHMgYXJlIGJyb2tlbiBhbmQvb3IgZGlzYWJsZWQgaW4g ZW5vdWdoIGluc3RhbmNlcyB0aGF0IHdlIHNob3VsZCBub3QgZW5jb3VyYWdlIHRoZWlyIHVzYWdl IGJ5IGluY2x1ZGluZyBleHBsaWNpdCBzdXBwb3J0IGZvciB0aGVtIGluIHRoZSBwcm90b2NvbC4g Tm9yIGFyZSB0aGV5IG5lY2Vzc2FyeSBmb3IgU1BBcyBpbiBvcmRlciB0byByZXN0b3JlIHRoZSBz dGF0ZSBvZiB0aGVpciBhcHAgYWZ0ZXIgdGhlIHJlZGlyZWN0Lg0KDQpBcmUgdGhleSByZWFsbHkg dGhhdCBicm9rZW4gaW4gZGVza3RvcD8gSSd2ZSB1c2VkIHRoZW0gZXh0ZW5zaXZlbHkgbXlzZWxm IGluIHRoZSBwYXN0IGFzIGl0IHdhcyBhIGJldHRlciB1c2VyIGV4cGVyaWVuY2UsIGJ1dCB0aGF0 IHdhcyBhIGZldyB5ZWFycyBhZ28uDQoNCltyaWNoYW5uYV0NClBvcHVwIGJsb2NrZXJzIGFyZSBi dWlsdCBpbiBhbmQgYWdncmVzc2l2ZWx5IGVuYWJsZWQgYnkgZGVmYXVsdCBvbiBhbGwgbWFqb3Ig YnJvd3NlcnMuIENvbW11bmljYXRpbmcgc2VjdXJlbHkgYmV0d2VlbiB3aW5kb3dzIGlzIG5vdCBl YXN5LCBhbmQgZnJvbSBwYXN0IGV4cGVyaWVuY2UgcHJvbmUgdG8gZmFpbHVyZSB0aGFua3MgdG8g d2VpcmQgYnJvd3NlciBidWdzLiBUcnVzdGVkIFNpdGUgc2V0dGluZ3MgaW4gSUUgYW5kIEVkZ2Ug Y2FuIGJsb3cgdGhlIHdob2xlIHRoaW5nIHVwIGluIHdlaXJkIHdheXMgKHNwZWFraW5nIGFnYWlu IGZyb20gZXhwZXJpZW5jZSkuDQoNCkFsc28sIGl04oCZcyAyMDIwLiBTdG9wIGJyYW5jaGluZyBv biBtb2JpbGUgdnMuIGRlc2t0b3AuIEkgZ2V0IHRoYXQgbG90cyBvZiBwZW9wbGUgc3RpbGwgZG8g dGhhdCwgYnV0IHRoYXQgZG9lc27igJl0IG1lYW4gdGhlIHByb3RvY29sIHNob3VsZCBjYXRlciB0 byBpdC4NClsvcmljaGFubmFdDQpBbmQgYWdhaW4sIGEgQ2xpZW50IHRoYXQgcmVhbGx5IHdhbnRz IHRvIGdpdmUgdGhlbXNlbHZlcyBhIGhlYWRhY2hlIHdpdGggcG9wdXBzIGNhbiBkbyB0aGF0IHRo ZW1zZWx2ZXMgdXNpbmcg4oCccmVkaXJlY3TigJ0gbW9kZS4gVGhleSBqdXN0IGhhdmUgdG8gcHJv dmlkZSBhIGxhbmRpbmcgcGFnZSBmb3IgdGhlIEdTIHRvIHJlZGlyZWN0IGJhY2sgdG8gdGhhdCBw YXJzZXMgdGhlIHJlc3BvbnNlLCBwYXNzZXMgaXQgYmFjayB0byB0aGUgbWFpbiB3aW5kb3csIGFu ZCBjbG9zZXMgaXRzZWxmLiBJIGRvbuKAmXQgc2VlIHdoeSB0aGUgcHJvdG9jb2wgd291bGQgbmVl ZCB0byBleHBsaWNpdGx5IGRlc2NyaWJlIHRoaXMgbWVjaGFuaXNtLg0KWy9yaWNoYW5uYV0NCg0K SSB0aGluayBpdCBpcyBhIHVzZWZ1bCBzaWduYWwgZm9yIHRoZSBHUyBpbiB0aGUgZXhwZXJpZW5j ZSBpdCB3YW50cyB0byBzaG93IHRoZSB1c2VyLg0KDQpbcmljaGFubmFdDQpVc2VmdWwgaG93PyBU aGUgd2luZG93IGRpbWVuc2lvbnMgYXJlIGEgYmV0dGVyIHNpZ25hbCBmb3IgaG93IHRvIHByZXNl bnQgdGhlIHVzZXIgZXhwZXJpZW5jZS4gKCpjb3VnaCogcmVzcG9uc2l2ZSBkZXNpZ24gKmNvdWdo KikNClsvcmljaGFubmFdDQoNClNlY3Rpb24gMTIuNjoNCg0KICAgICAgICBbRWRpdG9yOiBpcyB0 aGVyZSBzb21lIG90aGVyIHJlYXNvbiB0byBoYXZlIHRoZSBVc2VySW5mbw0KDQogICAgICAgIGVu ZHBvaW50P10NCg0KSSBtYXkgd2FudCB0byBob3N0IG15IFVzZXJJbmZvIGVuZHBvaW50IG9uIGEg c2VwYXJhdGUgbWljcm9zZXJ2aWNlIGZyb20gbXkgdG9rZW4gZW5kcG9pbnQgKGluIE9BdXRoIDIu MC9PSURDIHRlcm1zKS4gVGhlIGZvcm1lciBtaWdodCBiZSBwYXJ0IG9mIG15IHVzZXIgcHJvZmls ZS9kaXJlY3Rvcnkgc3RhY2ssIHdoaWxlIHRoZSBsYXR0ZXIgaXMgcGFydCBvZiB0aGUgaGlnaGx5 IHByaXZpbGVnZWQgYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzdGFjay4NCg0KDQpUaGUg dG9rZW4gZW5kcG9pbnQgaGFzIHRoZSBhY2Nlc3MgdG9rZW4gYW55d2F5LCBzbyBpdCBjYW4gZmV0 Y2ggdGhlIGRhdGEgZnJvbSB0aGUgb3RoZXIgZW5kcG9pbnQgaXRzZWxmIGlmIGl0IHdhbnRlZCB0 by4gSUUsIHRoZXJlIGlzIG5vIHNlcGFyYXRpb24gb2YgZHV0aWVzLg0KDQpXaGF0IGFyZSB0aGUg YWR2YW50YWdlcyBvZiB0aGUgVXNlckluZm8gZW5kcG9pbnQgdG8gdGhlIFVzZXIgb3IgQ2xpZW50 Pw0KDQpUaGUgVXNlckluZm8gZW5kcG9pbnQgc2VlbXMgdG8ganVzdCBhZGQgbW9yZSBjb21wbGV4 aXR5LCB3aXRoIG5vIGFiaWxpdHkgdG8gc3RhcnQgYSBVc2VyIGludGVyYWN0aW9uIGlmIGFkZGl0 aW9uYWwgY29uc2VudCBpcyBuZWVkZWQuDQoNCltyaWNoYW5uYV0NCklmIHRoZSBhY2Nlc3MgdG9r ZW4gaXMgc2VuZGVyLWNvbnN0cmFpbmVkLCB0aGVuIG5vLCB0aGUgdG9rZW4gZW5kcG9pbnQgY2Fu 4oCZdCBmZXRjaCB0aGUgZGF0YSBpdHNlbGYuIEJ1dCBldmVuIHdpdGhvdXQgdGhlIHNlY3VyaXR5 IGFuZ2xlLCB0aGVyZSBpcyB2YWx1ZSBpbiBzZXBhcmF0aW5nIG91dCB0aGUgZnVuY3Rpb25hbGl0 eSBhcyBpdCBhbGxvd3MgdGhlIEdTIHRvIGRpc3RyaWJ1dGUgaXQgYWNyb3NzIHN5c3RlbXMgd2l0 aCBkaWZmZXJlbnQgb3duZXJzLiBFLmcuLCB0aGVyZSBtaWdodCBiZSBhIGRpcmVjdG9yeSBBUEkg dGVhbSB0aGF0IGFsc28gb3ducyB0aGUgU0NJTSBpbnRlcmZhY2UgYW5kIFVzZXJJbmZvIGVuZHBv aW50Lg0KDQpBbiBpbXBsZW1lbnRhdGlvbiBjYW4gYWxzbyByb3V0ZSBjYWxscyB0byBkaWZmZXJl bnQgaW50ZXJuYWwgc3lzdGVtcyB3aGlsZSBrZWVwaW5nIHRoZSBzYW1lIGVuZHBvaW50Lg0KDQpJ IGFsc28gdGhpbmsgb2YgU0NpTSBhbmQgVXNlckluZm8gYXMgdmVyeSBkaWZmZXJlbnQgZW5kcG9p bnRzLiBJIHdvdWxkIGNvbnNpZGVyIFNDSU0gYSByZXNvdXJjZSwgYW5kIFVzZXJJbmZvIGNsYWlt cy4gSSBhcHByZWNpYXRlIHRob3NlIGFyZSBzaW1pbGFyIGluIGVudGVycHJpc2UsIGJ1dCB0aGV5 IGFyZSBub3QgaW4gY29uc3VtZXIgY29udGV4dHMuDQoNCltyaWNoYW5uYV0NClJvdXRpbmcgY2Fs bHMgdG8gZGlmZmVyZW50IGludGVybmFsIHN5c3RlbXMgc3RpbGwgbWVhbnMgSSBoYXZlIHRvIGhh dmUgc29tZSBzaGFyZWQgaW5mcmFzdHJ1Y3R1cmUgdGhhdCBib3RoIHRlYW1zIG1hbmFnZS4gSXTi gJlzIG1vcmUgY29tcGxleCB0aGFuIGl0IG5lZWRzIHRvIGJlLg0KDQpJ4oCZbSBnb2luZyB0byBz dWdnZXN0IHdlIG1vdmUgdGhpcyBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHRvIGEgc2VwYXJhdGUg dGhyZWFkIGJlY2F1c2UgaXTigJlzIHRvbyBtZXNzeSB0byBrZWVwIGluIHRoaXMgYXdmdWwgYmFj ay1hbmQtZm9ydGguIEnigJlsbCBqdXN0IGFkZCBoZXJlIHRoYXQgSeKAmW0gbm90IHN1Z2dlc3Rp bmcgd2Ugb25seSBoYXZlIGEgVXNlckluZm8gZW5kcG9pbnQuIEnigJltIGFyZ3VpbmcgdHdvIHRo aW5nczoNCg0KICAxLiAgVGhlIFVzZXJJbmZvIGVuZHBvaW50IGlzIGdvb2QsIGFjdHVhbGx5LiBJ dCBkb2VzbuKAmXQgbmVlZCB0byBiZSBNVEksIGJ1dCB3ZSBzaG91bGQgbm90IHByZWNsdWRlIGl0 cyBleGlzdGVuY2UuDQogIDIuICBJZiB3ZSBwcm92aWRlIGEgbWVjaGFuaXNtIGZvciByZXF1ZXN0 aW5nIGFuZCByZWNlaXZpbmcgY2xhaW1zIGluIHRoZSBHUyBSZWFkIEdyYW50IHJlc3BvbnNlLCB0 aGF0IG1lY2hhbmlzbSBzaG91bGQgYXBwbHkgZ2VuZXJpY2FsbHkgdG8gYXJiaXRyYXJ5IHJlc291 cmNlcy4gR1NlcyBjYW4gc3VwcG9ydCBpdCBvciBub3QsIGZvciBhbnkgZ2l2ZW4gcmVzb3VyY2Uu DQpbL3JpY2hhbm5hXQ0KDQo8c25pcD4NCltyaWNoYW5uYV0NClRoZXJlIGFyZSB0d28gYmlnIGRp ZmZlcmVuY2VzIGJldHdlZW4gdGhvc2UgZXhhbXBsZXMgKGUuZy4sIFFSIENvZGUsIGFwcC1iYXNl ZCBsb2dpbiBhcHByb3ZhbHMpIGFuZCB0aGlzIG1lY2hhbmlzbSBpbiBYQXV0aDoNCg0KMS4gICBJ biB5b3VyIGV4YW1wbGVzIG9mIHRoaXMgYmVoYXZpb3IgdG9kYXksIHRoZSByZWFzb24gZm9yIHRo ZSB3YWl0IGlzIGNsZWFyIGFuZCBvYnZpb3VzLCBhbmQgZHJpdmVuIGJ5IHRoZSB1c2VyLiBFLmcu LCBteSBwcmludGVyIGlzIHdhaXRpbmcgZm9yIG1lIHRvIGdvIGVudGVyIHRoaXMgY29kZSBhbmQg bG9nIGluOyBHb29nbGUgc2lnbiBpbiBpcyB3YWl0aW5nIGZvciBtZSB0byB0YXAgdGhpcyBidXR0 b24gb24gbXkgcGhvbmUuIFRoYXQgaXMgbm90IHRoZSBjYXNlIGluIHRoZSBYQXV0aCBwcm90b2Nv bC4gVGhlIHVzZXIgaXMgbGVmdCBzaXR0aW5nIG9uIGEgbG9hZGluZyBzY3JlZW4gd2FpdGluZyBm b3IgYSBiZWhpbmQtdGhlLXNjZW5lcyBpbnRlcmFjdGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQgR1Mg dGhhdCBtYXkgbm90IGV2ZW4gaGFwcGVuLg0KDQoyLiAgIFVubGlrZSB3aXRoIGNvZGUvUVIgZmxv d3Mgb3Igc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZXJlIGlzIG5vIGFjdGl2ZSBwcm9jZXNzIG9u IHRoZSBjbGllbnQgc2lkZSB0byBrZWVwIHRoaXMgYXN5bmMgcmVxdWVzdCBvcGVuLiBBIHdlYiBh cHAgY2xpZW50IHdvdWxkIGhhdmUgdG8gaW50cm9kdWNlIGEgc2VydmVyLXNpZGUgYXN5bmMgcHJv Y2VzcyB0byBtYW5hZ2UgdGhpcyBhc3BlY3Qgb2YgdGhlIHByb3RvY29sLiBUaGF04oCZcyBub3Qg ZWFzeS4NCg0KMy4gICBUaGUgZmFpbHVyZSBtb2RlcyBzaG93IHVwIGluIG1vcmUgYXBwcm9wcmlh dGUgY29udGV4dHMsIHdoZXJlIHRoZXJlIGFyZSBjbGVhciBwYXRocyBmb3J3YXJkIGZvciB0aGUg ZW5kIHVzZXIuIEluIGNvZGUvUVItYmFzZWQgZmxvd3MsIGl04oCZcyBkZXRlY3RlZCBvbiB0aGUg Y2xpZW50IHNpZGUsIGluIHRoZSBmb3JtIG9mIGFuIEFTIHRoYXQgbmV2ZXIgcHJvdmlkZXMgYSBy ZXNwb25zZS4gSW4gdGhhdCBzY2VuYXJpbywgdGhlIGNsaWVudCBjYW4gcmV0cnkgdGhlIHByb2Nl c3MuIEluIHNpZ24taW4gdmVyaWZpY2F0aW9uLCB0aGUgcHJvYmxlbSBvY2N1cnMgYmV0d2VlbiB0 d28gcGFydHMgb2YgdGhlIEFTLCBhbmQgdGhlIEFTIGNhbiBhbGxvdyB0aGUgZW5kIHVzZXIgdG8g cmV0cnkgb3IgdG8gdXNlIGEgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4gSW4gdGhl IFhBdXRoIENyZWF0ZStVcGRhdGUgc2NlbmFyaW8sIHRoZSBmYWlsdXJlIGlzIGRldGVjdGVkIG9u IHRoZSBHUywgYW5kIHRoZXJlIGlzIG5vIGNsZWFyIHBhdGggZm9yd2FyZC4gSWYgdGhlIENsaWVu dCBuZXZlciBjYWxscyBVcGRhdGUgR3JhbnQgdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVwIHRvIGZh bHNlLCB3aGF0IHNob3VsZCB0aGUgR1MgZG8/IEhvdyBsb25nIHNob3VsZCBpdCB3YWl0PyBTaG91 bGQgaXQgaXNzdWUgdGhlIGF1dGhvcml6YXRpb24gYW55d2F5LCBhc3N1bWluZyB0aGUgQ2xpZW50 IHdpbGwgY29tZSBiYWNrIGFuZCBhc2sgZm9yIGl0IGF0IHNvbWUgcG9pbnQ/IFNob3VsZCBpdCBy ZWRpcmVjdCB0aGUgZW5kIHVzZXIgYmFjayB0byB0aGUgQ2xpZW50IGFueXdheSwgb3IgZHJvcCB0 aGVtIG9uIGEgbGFuZGluZyBwYWdlPyBTaG91bGQgaXQgZmxhZyB0aGlzIGFzIGFuIGVycm9yLCBv ciBpcyB0aGlzIHRoZSBleHBlY3RlZCBiZWhhdmlvciBmb3IgdGhlIENsaWVudD8NCg0KSSByZWFs bHkgdGhpbmsgdGhpcyBpcyBvdmVyY29tcGxpY2F0aW5nIHRoZSBwcm90b2NvbCB0byBhbiBleHRl bnQgdGhhdCBubyBvbmUgd2lsbCBhY3R1YWxseSBpbXBsZW1lbnQgaXQuDQpbL3JpY2hhbm5hXQ0K DQpUaGUgZmxvdyBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQteGF1 dGgtcHJvdG9jb2wtMDIjc2VjdGlvbi0zLjEgaXMgRVhBQ1RMWSB0aGUgc2FtZSBhcyB0aGUgR29v Z2xlIGFuZCBNaWNyb3NvZnQgZmxvd3MuDQoNCldoaWxlIHRoZSBmbG93IGluIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMiNzZWN0aW9uLTMu NCBoYXMgYWRkaXRpb25hbCBzdGVwcywgaXQgaXMgbm90IGZ1bmRhbWVudGFsbHkgYW55IGRpZmZl cmVudCBleGNlcHQgdGhlIENsaWVudCBpcyBtYWtpbmcgYW5vdGhlciBjYWxsIHRvIHRoZSBHUyBh ZnRlciB0aGUgZmlyc3Qgb25lIHJldHVybnMuIFRoZSByaXNrIG9mIHRoZSBDbGllbnQgbm90IG1h a2luZyB0aGUgc2Vjb25kIGNhbGwgYW5kIGxlYXZpbmcgdGhlIFVzZXIgaGFuZ2luZyBpcyBub3Qg cmVhbGx5IGFueSBkaWZmZXJlbnQgb2YgdGhlIENsaWVudCBub3QgbWFraW5nIHRoZSBmaXJzdCBj YWxsLg0KDQpCZXNpZGVzIHRoZSBzaXR1YXRpb24gd2hlcmUgdGhlIG1vYmlsZSBkZXZpY2UgdGhh dCBNQVkgbm90IGJlIGFibGUgdG8gbWFrZSB0aGUgc2Vjb25kIGNhbGwgbWlnaHQgcHV0IHRvIHNs ZWVwLCBJIGRvbid0IHNlZSBhbnkgaW1wbGVtZW50YXRpb24gaXNzdWVzLiBUeEF1dGggd29ya3Mg dGhlIHNhbWUgd2F5IGFzIDMuMSBhcyBJIHVuZGVyc3RhbmQgaXQgZm9yIG5vbi1yZWRpcmVjdCBm bG93cy4NCg0KW3JpY2hhbm5hXQ0KSSBkb27igJl0IHRoaW5rIHlvdSBhY3R1YWxseSByZWFkIHdo YXQgSSB3cm90ZS4gSWYgdGhlIGZsb3dzIGFyZSBleGFjdGx5IHRoZSBzYW1lLCB0ZWxsIG1lOg0K DQogIDEuICBXaGF0IGRvZXMgdGhlIHVzZXIgdGhpbmsgaXMgZ29pbmcgb24gd2hpbGUgdGhleeKA mXJlIHNpdHRpbmcgb24gdGhlIEdTLCB3YXRjaGluZyBhIHNwaW5uZXIgYXMgdGhlIEdTIHdhaXRz IGZvciB0aGUgQ2xpZW50IHRvIG1ha2UgYW4gVXBkYXRlIEdyYW50IHJlcXVlc3QgaW4gMy40Pw0K ICAyLiAgV2hhdCBleGlzdGluZyBDbGllbnQgY29tcG9uZW50IGlzIGhvbGRpbmcgb3BlbiB0aGUg UmVhZCBHcmFudCByZXF1ZXN0Pw0KDQogICAgICogICBJZiB5b3VyIGFuc3dlciBpcyDigJxhbiBh c3luYyBwcm9jZXNzIG9uIHRoZSBDbGllbnTigJlzIHNlcnZlcuKAnSB0aGVuIHBsZWFzZSByZS1y ZWFkIHRoZSBzZWNvbmQgd29yZCBvZiB0aGF0IHF1ZXN0aW9uLg0KDQogIDEuICBIb3cgbG9uZyBz aG91bGQgdGhlIEdTIHdhaXQgZm9yIHRoZSBDbGllbnQgdG8gbWFrZSB0aGUgVXBkYXRlIEdyYW50 IHJlcXVlc3QgaW4gMy40PyBXaGF0IHNob3VsZCB0aGUgR1MgZG8gaWYgdGhhdCBuZXZlciBoYXBw ZW5zPyBXaGF0IGlzIHRoZSBwYXRoIGZvcndhcmQgZm9yIHRoZSBlbmQgdXNlciwgYXQgdGhhdCBw b2ludD8NClsvcmljaGFubmFdDQoNCltwYXN0aW5nIGluIGZyb20geW91ciBsYXRlciBlbWFpbF0N CldoaWxlIGEgc2luZ2xlIHN0YWdlIEdyYW50IHJlcXVlc3QgKDMuMSkgaW4gYSBtb2JpbGUgYXBw IHRoYXQgaGFzIGJlZW4gcHV0IHRvIHNsZWVwIHdpbGwgcmVjb3ZlciBmaW5lLCBhIG11bHRpLXN0 ZXAgKDMuNCkgd2lsbCBmYWlsLiBTaW5jZSAzLjQgb25seSBtYWtlcyBzZW5zZSBpZiB0aGUgQ2xp ZW50IGlzIGNoZWNraW5nIGEgZGF0YWJhc2UgYWxvbmcgdGhlIHdheSwgSSB3b3VsZCBleHBlY3Qg dGhlIENsaWVudCB0byBoYXZlIGEgc2VydmVyIHNpZGUsIGFuZCB0aGUgc2VydmVyIGNvdWxkIHRh a2UgZWFjaCBzdGVwLg0KWy9lbmQgcGFzdGVdDQoNCltyaWNoYW5uYV0NCkhhdmluZyBhIHJlbW90 ZSBkYXRhYmFzZSBhbmQgaGF2aW5nIGEgcmVtb3RlIHNlcnZlciBhcmUgbm90IHRoZSBzYW1lIHRo aW5nLiBUaGlzIGFkZHMgYSBsb3Qgb2YgY29tcGxleGl0eSB0byBzZXJ2ZXJsZXNzIGFwcHMuDQpb L3JpY2hhbm5hXVtodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGph eTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9N2NkMThlYTYt OGM1MC00NmRjLWJlMjUtZTk5ZjYxNGRhYjgyXeGQpw0KDQpXaGljaCBhc3BlY3QgYWRkcyBjb21w bGV4aXR5Pw0KDQpUaGUgYWRkZWQgY29tcGxleGl0eSBpbiBrZWVwaW5nIGFuIGludGVyYWN0aW9u IGlzIG1ha2luZyBhbiBhZGRpdGlvbmFsIEFQSSBjYWxsIGFmdGVyIHRoZSBmaXJzdCBBUEkgY2Fs bC4NCg0KW3JpY2hhbm5hXQ0KVGhlIGlzc3VlIGlzbuKAmXQgdGhlIEFQSSBjYWxsIGl0c2VsZiwg aXTigJlzIHRoZSBuZWVkIGZvciB0aGUgQ2xpZW50IHRvIG1haW50YWluIGEgcGVyc2lzdGVudCwg YXN5bmNocm9ub3VzIHByb2Nlc3MgdG8gbWFrZSB0aGF0IEFQSSBjYWxsLg0KDQpJdCBpcyBpbmNv cnJlY3QgdG8gYXNzdW1lIHRoYXQgZXZlcnkgYXBwIHdpdGggYSBkYXRhYmFzZSB3aWxsIG5lY2Vz c2FyaWx5IGhhdmUgYSBzZXJ2ZXIgc2lkZS4gQSBzZXJ2ZXJsZXNzIGFwcCB0aGF0IGRvZXMgYSBy ZWRpcmVjdCB0byB0aGUgR1MsIG9yIHRoYXQgc3dpdGNoZXMgdG8gYW4gZXh0ZXJuYWwgYnJvd3Nl ciAoYW5kIHRodXMgbWF5IGJlIHB1dCB0byBzbGVlcCkgaGFzIG5vIGNvbXBvbmVudCB0aGF0IHdp bGwgcmVsaWFibHkgc3RheSBhbGl2ZSB0byBob2xkIG9wZW4gdGhlIFJlYWQgR3JhbnQgcmVxdWVz dCwgcmVjZWl2ZSB0aGUgcmVzcG9uc2UsIGFuZCBmb2xsb3cgdXAgd2l0aCBhbiBVcGRhdGUgR3Jh bnQgcmVxdWVzdCAoaS5lLiwgZmxvdyAzLjQpLiBBZGRpbmcgYSBzZXJ2ZXItc2lkZSBjb21wb25l bnQgdG8gZG8gdGhpcyBvcmNoZXN0cmF0aW9uIGFkZHMgc2lnbmlmaWNhbnQgY29tcGxleGl0eS4N ClsvcmljaGFubmFdDQoNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8 bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoDQo= --_000_0092A517C90B41A68272D779E84E10C9amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiAwIDUgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAw IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJ cGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2Ut MToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnAuZ21haWwtbS0xMzkxMzY2ODI4 MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIyMzMw bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMzMG1zb2xpc3Rw YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tMTM5MTM2NjgyODM2NzQyMjMzMG1z b2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjQ3NzU3MjIyNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 NTc1OTM3NDE0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxMTYzNjc3NjA0IC0xNzYzODEyODA2IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjc1MzM1NDcwMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTYxMTAyOTEwODt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo3NjY3MzEzNzU7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMjc4ODI5NzggLTE3 NjM4MTI4MDYgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDQNCgl7bXNv LWxpc3QtaWQ6MTM2MDE2MzgzMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTE5NzIxOTQ4ODggMTgyNjAxODM2NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlz dCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiTVMgTWluY2hvIjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDoxNTM2OTY5NDEzOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotNjExMDI5MTA4O30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjE3MTc3 MDExOTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02MTEwMjkxMDg7fQ0KQGxpc3QgbDY6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltyaWNoYW5u YV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlcGxpZXMgaW5saW5lLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy9yaWNoYW5uYV08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2F3 cy5hbWF6b24uY29tL2lkZW50aXR5LyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBz Oi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1 dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJk dCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwg RmVicnVhcnkgMTQsIDIwMjAgYXQgOToxMCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90 OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0 aF0gWEF1dGggLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+T24gVGh1LCBGZWIgMTMsIDIwMjAgYXQgNjowOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSAmbHQ7cmljaGFubmE9PGEgaHJlZj0ibWFpbHRvOjQwYW1hem9uLmNvbUBkbWFyYy5p ZXRmLm9yZyI+NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClJlcGxpZXMgaW5saW5l PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NDcuNTVw dCI+DQpbL3JpY2hhbm5hXSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7c25pcCZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCltyaWNoYW5uYV08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkJ5IHVz ZXIgY29kZS1iYXNlZCBpbnRlcmFjdGlvbiwgSSBtZWFuIHRoZSBraW5kIGRlc2NyaWJlZCBpbiB0 aGUgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODYyOCIgdGFyZ2V0PSJf YmxhbmsiPg0KT0F1dGggMi4wIERldmljZSBBdXRob3JpemF0aW9uIEdyYW50PC9hPiwgd2hlcmUg dGhlIHVzZXIgcmVjZWl2ZXMgYSBjb2RlIGFuZCBzaG9ydCBVUkwgZnJvbSB0aGUgY2xpZW50LCBu YXZpZ2F0ZXMgdG8gdGhhdCBVUkwgaW4gYSBicm93c2VyLCBhbmQgZW50ZXJzIHRoZSBjb2RlLiBX aGlsZSB0aGlzIGNvdWxkIGJlIHBhY2tlZCBpbnRvIGludGVyYWN0aW9uLm1lc3NhZ2UsIHRoaXMg d2lsbCBsZWFkIHRvIGNsdW5raWVyIHVzZXIgZXhwZXJpZW5jZXM6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZl bDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgR1MgbWF5IG5vdCBi ZSBhYmxlIHRvIHByb3ZpZGUgbG9jYWxpemVkIGluc3RydWN0aW9ucyB0aGF0IG1hdGNoIHRoZSBs b2NhbGUgb24gdGhlIENsaWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTEz OTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPlN1cHBvc2UgdGhlIEdTIHNlbmRzIGEgbWVzc2FnZSB0aGF0 IHJlYWRzOiDigJxTY2FuIHRoZSBRUiBjb2RlIG9yIG9wZW4gYSBicm93c2VyIHRvDQo8YSBocmVm PSJodHRwOi8vY29kZS5leGFtcGxlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9jb2RlLmV4YW1w bGUvPC9hPiBhbmQgZW50ZXIgdGhlIGNvZGU6IDEyMzQ1LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMzMG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwy IGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhhdCBpbnN0cnVj dGlvbiBkb2VzIG5vdCBtYWtlIHNlbnNlIG9uIGEgZGV2aWNlIHRoYXQgZG9lcyBub3QgcHJlc2Vu dCBhIFFSIGNvZGUuIEltYWdpbmUgaGVhcmluZyB0aGF0IGZyb20gYSBzbWFydCBzcGVha2VyLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMzMG1zb2xp c3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ VGhhdCBpbnN0cnVjdGlvbiBpcyBjb25mdXNpbmdseSByZWR1bmRhbnQgaWYgdGhlIENsaWVudCBk aXNwbGF5cyB0aGUgUVIgY29kZSBhbG9uZyB3aXRoIGl0cyBvd24gaW5zdHJ1Y3Rpb25zLCBsaWtl OiDigJxTY2FuIHRoZSBRUiBjb2RlIG9yIGZvbGxvdyB0aGUgaW5zdHJ1Y3Rpb25zIGJlbG93LuKA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMzMG1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+V2lsbCDigJxlbWJlZCB0aGUgc2hvcnQgVVJMIGFuZCBjb2RlIGluIHRoZSBtZXNzYWdlIHN0 cmluZ+KAnSBiZSBNVEk/IElmIG5vdCwgdGV4dC1vbmx5IGNsaWVudHMgd291bGQgaGF2ZSBhIGJy b2tlbiBleHBlcmllbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KWy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlNvdW5kcyBsaWtlIGEgdGV4dCBvbmx5IGludGVyYWN0aW9uIHR5cGUgc2hvdWxk IGJlIGFkZGVkIHBlciBteSBub3RlIGluIHRoZSBkcmFmdC4gUGVyaGFwcyBldmVuIG9uZSB0aGF0 IGlzIGZvY3VzZWQgb24gdGhlIGNvZGUgZmxvdywgd2hlcmUgdGhlIHBhcmFtZXRlcnMgYXJlIHRo ZSBjb2RlIGFuZCB0aGUgVVJJIHRvIGVudGVyIHRoZSBjb2RlLCBsZXR0aW5nIHRoZQ0KIENsaWVu dCBwcmVzZW50IHRoZSBwYXJhbWV0ZXJzIHdpdGggbG9jYWxpemVkIGNvbnRlbnQ/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b cmljaGFubmFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHdl 4oCZcmUgYXBwcm9hY2hpbmcgdGhlIOKAnGludGVyYWN0aW9u4oCdIGNvbmNlcHQgd3JvbmcuIFdl 4oCZcmUgY29uZmxhdGluZyB0aHJlZSBkaWZmZXJlbnQgdGhpbmdzIHRvZ2V0aGVyOjxvOnA+PC9v OnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQg bGV2ZWwxIGxmbzUiPldoYXQgZG9lcyB0aGUgQ2xpZW50IG5lZWQgdG8gc2VuZCB0aGUgZW5kIHVz ZXIgdG8gdGhlIEdTPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJjaXJj bGUiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0Omw0IGxldmVsMiBsZm81Ij5BIGh1bWFuLWZyaWVuZGx5IHNob3J0IFVSTCBhbmQg Y29kZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVsMiBsZm81Ij5Bbnkga2luZCBvZiBVUkws IGFzIGxvbmcgYW5kIHVnbHkgYXMgaXQgbmVlZHMgdG8gYmUuPG86cD48L286cD48L2xpPjwvdWw+ DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQg bGV2ZWwxIGxmbzUiPkhvdyB3aWxsIHRoZSBDbGllbnQgcmVjZWl2ZSB0aGUgcmVzcG9uc2UgZnJv bSB0aGUgR1M/PG86cD48L286cD48L2xpPjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImNpcmNsZSI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDQgbGV2ZWwyIGxmbzUiPkNsaWVudCB3aWxsIG1ha2UgYSByZXF1ZXN0IHRvIHRoZSBH Uy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVsMiBsZm81Ij5HUyB3aWxsIG1ha2UgYSByZXF1 ZXN0IHRvIHRoZSBDbGllbnQuIChJ4oCZdmUgaGFkIHRvIGltcGxlbWVudCB0aGlzIGZvciBhIGN1 c3RvbSBpbnRlZ3JhdGlvbiwgaW5jbHVkaW5nIGl0IHRvIGRlbW9uc3RyYXRlIHRoYXQgb3RoZXIg b3B0aW9ucyBleGlzdCk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNSI+V2lsbCB0aGUg R1MgcmV0dXJuIHRoZSBlbmQgdXNlciB0byB0aGUgQ2xpZW50LCBhbmQgaWYgc28gaG93PzxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVs MiBsZm81Ij5ZZXMsIGJ5IFVSTCByZWRpcmVjdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVs MiBsZm81Ij5Oby48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhlcmUgaXMgYSB2ZXJ5IG5vbi1ub3JtYXRpdmUgZXhhbXBsZSByZXF1ZXN0IGZyYWdt ZW50LCBmb3IgYSBjbGllbnQgdGhhdCB3YW50cyBib3RoIGEgc2hvcnQgVVJMIHBsdXMgY29kZSBh bmQgYSBmdWxsIFVSTCBzbyB0aGV5IGNhbiBvcHBvcnR1bmlzdGljYWxseSB1c2Ugb25lIG9yIHRo ZSBvdGhlciAoQVdTIENMSSB2MiBkb2VzIHRoaXMpLCB3aWxsIHF1ZXJ5IHRoZSBHUyBmb3IgdGhl IHJlc3BvbnNlLCBhbmQNCiB3YW50cyB0aGUgR1MgdG8gcmVkaXJlY3QgdG8gYSBwdWJsaWNseSBh Y2Nlc3NpYmxlIFVSTCBvbiB0aGUgQ2xpZW504oCZcyB3ZWJzaXRlIGFmdGVyIHRoZSBmbG93IChl LmcuLCB0byBzaG93IGZ1cnRoZXIgZG9jdW1lbnRhdGlvbi9icmFuZGVkIGNvbnRlbnQgdG8gdGhl IGVuZCB1c2VyKTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj57PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXIiPiZxdW90O2ludGVyYWN0JnF1b3Q7OiB7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjEzLjVwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVvdDtjb2RlJnF1b3Q7 OiB7ICZxdW90O21heCZxdW90OzogOCB9LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJnF1b3Q7dXJsJnF1b3Q7OiB0cnVlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjEzLjVw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn0sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjEzLjVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZxdW90O3Jlc3BvbnNlJnF1b3Q7OiB7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVv dDtwb2xsJnF1b3Q7OiB0cnVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPn0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJp ZXIiPiZxdW90O3JldHVybiZxdW90OzogezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJnF1b3Q7dXJsJnF1b3Q7OiAmcXVvdDtodHRwczovL2hl bHAuc21hcnRkZXZpY2UuZXhhbXBsZS9wb3N0LXNldHVwJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjEzLjVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+fTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmQgaGVyZSBpcyBhbiBlcXVhbGx5IG5vbi1ub3JtYXRpdmUgZXhhbXBs ZSByZXNwb25zZSBmcmFnbWVudDo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXIiPns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q291cmllciI+JnF1b3Q7aW50ZXJhY3QmcXVvdDs6IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZxdW90O2NvZGUmcXVvdDs6ICZxdW90 OzEyMzQ1NiZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291 cmllciI+Jm5ic3A7ICZxdW90O2NvZGVfdXJsJnF1b3Q7OiAmcXVvdDtodHRwczovL2dzLmV4YW1w bGUvY29kZSZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291 cmllciI+Jm5ic3A7ICZxdW90O3VybCZxdW90OzogJnF1b3Q7aHR0cHM6Ly9ncy5leGFtcGxlL3hh dXRoLzEyMzQzNTY3ODkwYWJjZGVmMTIzNDU2Nzg5MGFiY2RlZiZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoxMy41cHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj59PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi Pn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KFNlcmlvdXNseSBkbyBub3QgcmVhZCB0b28gbXVjaCBpbnRvIHRo ZXNlIHBhcmFtZXRlciBuYW1lcyBvciBzeW50YXgsIHRoaXMgaXMganVzdCB0byBnaXZlIGEgcm91 Z2ggc2Vuc2Ugb2YgaG93IEnigJltIHRoaW5raW5nIGFib3V0IHRoaXMuIEFueW9uZSB3aG8gdHJp ZXMgdG8gcGljayBhcGFydCB0aGlzIGV4YW1wbGUgd2lsbCBiZSByZXNwb25kZWQgdG8gd2l0aCBt b2NraW5nIG1lbWVzLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsvcmlj aGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjQuLjhwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjVpbiI+DQoy LjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgPC9zcGFuPkNsaWVudHMgc3VwcG9ydCBt dWx0aXBsZSBpbnRlcmFjdGlvbiBtb2RlcyBhbmQgbWF5IG5vdCBhbHdheXMga25vdyB3aGF0IHRo ZSBHUyBzdXBwb3J0cyAoYW5kIHZpY2UtdmVyc2EpLiBGb3IgYSBtdWx0aS10ZW5hbnQgR1MsIGl0 IG1heSB2YXJ5IGJ5IHRlbmFudCBjb25maWd1cmF0aW9uLiBDbGllbnRzIHNob3VsZA0KIGJlIGFi bGUgdG8gc2F5IHdoYXQgdGhleSBjYW4gZG8sIGFuZCB0aGUgR1Mgc2hvdWxkIGJlIGFibGUgdG8g dGVsbCB0aGVtIHdoaWNoIG9uZSB0byB1c2UuIEl04oCZcyBhIHZlcnkgc2ltcGxlIGJ1dCBwb3dl cmZ1bCBpbmxpbmUgbmVnb3RpYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDox LjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpUaGF0IGlzIHdoYXQgaXMgaW4gVHhBdXRo LiBXb3VsZCB5b3UgZWxhYm9yYXRlIG9uIGhvdyB0aGUgR1MgbWlnaHQgYmUgY29uc3RyYWluZWQ/ IFdoeSB3b3VsZCB0aGUgR1Mgbm90IGJlIGFibGUgdG8gZG8gYWxsPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCkkgd291bGQgdGhpbmsgYWxsIGNvbnN0cmFpbnRzIHdv dWxkIGJlIGF0IHRoZSBDbGllbnQuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClty aWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCkNsaWVudHMgbWF5IHN1cHBvcnQgY3VzdG9tZXItZGVmaW5lZCBHU2VzIChlLmcu LCBlbnRlcnByaXNlIElkUHMpLCB3aGljaCB3aWxsIHZhcnkgaW4gdGVybXMgb2Ygd2hpY2ggaW50 ZXJhY3Rpb24gbW9kZXMgdGhleSBzdXBwb3J0LiBXaGlsZSB0aGUgc2V0IG9mIGludGVyYWN0aW9u cyBkZWZpbmVkIGluIFhBdXRoIG1pZ2h0IGFsbCBiZSBNVEkgZm9yIGEgR1MsIHdlIHNob3VsZCBh c3N1bWUgdGhhdCBleHRlbnNpb25zIHdpbGwgaW50cm9kdWNlIG5ldw0KIGludGVyYWN0aW9ucyB3 aGljaCB3aWxsIG5vdCBiZSB1bml2ZXJzYWxseSBzdXBwb3J0ZWQuIEFuIGludGVyYWN0aW9uIG1l Y2hhbmlzbSBtaWdodCBoYXZlIHByb3BlcnRpZXMgdGhhdCBjYXVzZSBzb21lIGFkbWluaXN0cmF0 b3JzIHRvIHdhbnQgdG8gZGlzYWJsZSBpdCwgb3IgdG8gcmVzdHJpY3QgQ2xpZW50cyB0byBhbHdh eXMgdXNlIGl0LiBBcmUgeW91IGFzc3VtaW5nIHRoYXQgYSBDbGllbnQgd2lsbCBhbHdheXMgbWFr ZSBhbiBPUFRJT05TIGRpc2NvdmVyeQ0KIHJlcXVlc3QgZmlyc3Q/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpbL3JpY2hhbm5hXSZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gZXhhbXBsZSBvZiB3aHkg YSBnaXZlbiBHUyBtYXkgbm90IHN1cHBvcnQgYSBtb2RlIHdvdWxkIGJlIGhlbHBmdWwuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3YXMgZW52aXNpb25p bmcgdGhhdCBpZiBhbiBvcHRpb25hbCB0byBzdXBwb3J0IGludGVyYWN0aW9uIG1vZGUgd2FzIG5v dCBzdXBwb3J0ZWQgYXQgdGhlIEdTLCB0aGF0IGl0IHdvdWxkIHJldHVybiBhbiBlcnJvci4gVGhl IENsaWVudCB3b3VsZCB0aGVuIHRyeSBhIGRpZmZlcmVudCBvbmUuIEFsdGVybmF0aXZlbHksIHRo ZSBDbGllbnQgY291bGQgc3RhcnQgd2l0aA0KIGFuIE9QVElPTlMgY2FsbCBpbiBjYXNlcyB3aGVy ZSB0aGUgR1MgaXMgZHluYW1pY2x5IGNob3Nlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltyaWNoYW5uYV08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvdHMgb2YgQVNlcyBkb27igJl0IHN1cHBvcnQg RGV2aWNlIEF1dGhvcml6YXRpb24gR3JhbnQuIEkgdGhpbmsgaXTigJlzIHNhZmUgdG8gYXNzdW1l IHRoYXQgaW50ZXJhY3Rpb24gbW9kZSBzdXBwb3J0IHdpbGwgdmFyeSBmb3IgWEF1dGggYXMgd2Vs bC4g4oCcS2VlcCB0cnlpbmcgdW50aWwgeW91IGZpbmQgb25lIHRoYXQgd29ya3PigJ0gc291bmRz IHByZXR0eSBwYWluZnVsIGZvciB0aGUgY2xpZW50LCBhbmQgZG9lc27igJl0DQogYWxsb3cgdGhl IGNsaWVudCB0byB1c2UgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZXMsIGFzIGRlbW9uc3RyYXRl ZCBpbiBteSBleGFtcGxlIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUg bG90cyBvZiByZWFzb25zIGZvciB3YW50aW5nIHRvIHN1cHBvcnQgbXVsdGlwbGUgbW9kZXM6PG86 cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsNCBsZXZlbDEgbGZvNSI+U29tZSBwZW9wbGUgYXJlIGNvbWZvcnRhYmxlIHdpdGggUVIgY29k ZXMsIHNvbWUgYXJlbuKAmXQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNSI+U29t ZSBwZW9wbGUgaGF2ZSBzbWFydCBwaG9uZXMgdGhhdCBjYW4gc2NhbiB0aGVtLCBzb21lIGRvbuKA mXQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNSI+UGVvcGxlIHdpdGggc21hcnQg cGhvbmVzIG1heSB3YW50IHRvIGdvIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIGZsb3cgb24g dGhlaXIgZGVza3RvcCBpbnN0ZWFkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzUi PlNvbWUgcGVvcGxlIG1heQ0KPGk+aGF2ZTwvaT4gdG8gZ28gdGhyb3VnaCB0aGUgYXV0aGVudGlj YXRpb24gZmxvdyBvbiB0aGVpciBkZXNrdG9wLCBiZWNhdXNlIHRoZSBHUyB0aGlua3MgaVBob25l cyBvbmx5IHN1cHBvcnQgQmx1ZXRvb3RoLWJhc2VkIHNlY3VyaXR5IGtleXMgYW5kIGluc2lzdHMg dGhleSBjYW5ub3QgY29tcGxldGUgdGhlIGxvZ2luIGZsb3cgZXZlbiB0aG91Z2ggdGhleSBoYXZl IHR3byBZdWJpS2V5IDVDaSBrZXlzIG9uIHRoZWlyIGFjY291bnQuIChISSwgR09PR0xFDQogQUND T1VOVCBQUk9URUNUSU9OIFBST0dSQU0pPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS41aW4iPg0KMy48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JIGRvbuKAmXQgc2VlIHRoZSB2YWx1ZSBv ZiB0aGUg4oCccG9wdXDigJ0gaW50ZXJhY3Rpb24gbW9kZS4gQ2xpZW50cyBjYW4gdXNlIOKAnHJl ZGlyZWN04oCdIG1vZGUgd2l0aGluIHBvcHVwcy4gSG93ZXZlciwgc3BlYWtpbmcgYXMgc29tZW9u ZSB3aG8gaGFzIGRvbmUgdGhhdCwgSSByZWFsbHkgZG9u4oCZdCByZWNvbW1lbmQgaXQuDQogUG9w dXBzIGFyZSBpbmNyZWFzaW5nbHkgdW5zdXBwb3J0ZWQsIGFuZCBwcm9uZSB0byB3ZWlyZCBiZWhh dmlvcmFsIGlzc3Vlcy4gSW4tYXBwIGJyb3dzZXJzIGluIEZhY2Vib29rLCBUd2l0dGVyLCBldGMu IHRlbmQgdG8gaGF2ZSBwb3B1cHMgZGlzYWJsZWQuIFRoZSBsYXN0IHZlcnNpb25zIG9mIElFIE1v YmlsZSBkaWRu4oCZdCBzdXBwb3J0IHRoZW0gYXQgYWxsICh0aGUgcG9wcGVkIHVwIHBhZ2UgYmFz aWNhbGx5IGp1c3QgbG9hZGVkIGludG8gdGhlDQogY3VycmVudCB3aW5kb3cpLi4gaW4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEu MGluIj4NClBvcHVwcyBhcmUgcmVhbGx5IHVzZWZ1bCBpbiBzaW5nbGUtcGFnZSBhcHBzIGFzIHlv dSB3YW50IHRvIGtlZXAgdGhlIGNvbnRleHQgYW5kIG5vdCByZWxvYWQgdGhlIHBhZ2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KQWdyZWUgdGhhdCBwb3B1cHMgZG9u J3QgbWFrZSBzZW5zZSBpbiBtb2JpbGUuIEEgZnVsbCByZWRpcmVjdCBkb2VzIG9mIGNvdXJzZS4g QSBzaW5nbGUtcGFnZSBhcHAgb24gbW9iaWxlIHdvdWxkIG9wZW4gYSBuZXcgdGFiIHdoaWNoIHdv dWxkIGJlIGEgc2VwYXJhdGUgY29udGV4dCByYXRoZXIgdGhhbiBhIHJlZGlyZWN0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KW3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KUG9wdXBzIGFyZSBicm9rZW4gYW5kL29yIGRp c2FibGVkIGluIGVub3VnaCBpbnN0YW5jZXMgdGhhdCB3ZSBzaG91bGQgbm90IGVuY291cmFnZSB0 aGVpciB1c2FnZSBieSBpbmNsdWRpbmcgZXhwbGljaXQgc3VwcG9ydCBmb3IgdGhlbSBpbiB0aGUg cHJvdG9jb2wuIE5vciBhcmUgdGhleSBuZWNlc3NhcnkgZm9yIFNQQXMgaW4gb3JkZXIgdG8gcmVz dG9yZSB0aGUgc3RhdGUgb2YgdGhlaXIgYXBwIGFmdGVyIHRoZSByZWRpcmVjdC4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXJlIHRoZXkgcmVhbGx5IHRoYXQgYnJva2Vu IGluIGRlc2t0b3A/IEkndmUgdXNlZCB0aGVtIGV4dGVuc2l2ZWx5IG15c2VsZiBpbiB0aGUgcGFz dCBhcyBpdCB3YXMgYSBiZXR0ZXIgdXNlciBleHBlcmllbmNlLCBidXQgdGhhdCB3YXMgYSBmZXcg eWVhcnMgYWdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UG9wdXAgYmxvY2tlcnMgYXJlIGJ1aWx0IGluIGFuZCBhZ2dyZXNzaXZlbHkgZW5h YmxlZCBieSBkZWZhdWx0IG9uIGFsbCBtYWpvciBicm93c2Vycy4gQ29tbXVuaWNhdGluZyBzZWN1 cmVseSBiZXR3ZWVuIHdpbmRvd3MgaXMgbm90IGVhc3ksIGFuZCBmcm9tIHBhc3QgZXhwZXJpZW5j ZSBwcm9uZSB0byBmYWlsdXJlIHRoYW5rcyB0byB3ZWlyZCBicm93c2VyIGJ1Z3MuIFRydXN0ZWQg U2l0ZSBzZXR0aW5ncyBpbg0KIElFIGFuZCBFZGdlIGNhbiBibG93IHRoZSB3aG9sZSB0aGluZyB1 cCBpbiB3ZWlyZCB3YXlzIChzcGVha2luZyBhZ2FpbiBmcm9tIGV4cGVyaWVuY2UpLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBpdOKAmXMgMjAyMC4gU3RvcCBicmFuY2hpbmcgb24gbW9i aWxlIHZzLiBkZXNrdG9wLiBJIGdldCB0aGF0IGxvdHMgb2YgcGVvcGxlIHN0aWxsIGRvIHRoYXQs IGJ1dCB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoZSBwcm90b2NvbCBzaG91bGQgY2F0ZXIgdG8gaXQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL3JpY2hhbm5hXTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpBbmQgYWdh aW4sIGEgQ2xpZW50IHRoYXQgcmVhbGx5IHdhbnRzIHRvIGdpdmUgdGhlbXNlbHZlcyBhIGhlYWRh Y2hlIHdpdGggcG9wdXBzIGNhbiBkbyB0aGF0IHRoZW1zZWx2ZXMgdXNpbmcg4oCccmVkaXJlY3Ti gJ0gbW9kZS4gVGhleSBqdXN0IGhhdmUgdG8gcHJvdmlkZSBhIGxhbmRpbmcgcGFnZSBmb3IgdGhl IEdTIHRvIHJlZGlyZWN0IGJhY2sgdG8gdGhhdCBwYXJzZXMgdGhlIHJlc3BvbnNlLCBwYXNzZXMg aXQgYmFjayB0byB0aGUgbWFpbiB3aW5kb3csDQogYW5kIGNsb3NlcyBpdHNlbGYuIEkgZG9u4oCZ dCBzZWUgd2h5IHRoZSBwcm90b2NvbCB3b3VsZCBuZWVkIHRvIGV4cGxpY2l0bHkgZGVzY3JpYmUg dGhpcyBtZWNoYW5pc20uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KWy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkkgdGhpbmsgaXQgaXMgYSB1c2VmdWwgc2lnbmFsIGZvciB0aGUgR1MgaW4gdGhlIGV4cGVy aWVuY2UgaXQgd2FudHMgdG8gc2hvdyB0aGUgdXNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltyaWNoYW5uYV08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVzZWZ1bCBob3c/ IFRoZSB3aW5kb3cgZGltZW5zaW9ucyBhcmUgYSBiZXR0ZXIgc2lnbmFsIGZvciBob3cgdG8gcHJl c2VudCB0aGUgdXNlciBleHBlcmllbmNlLiAoKmNvdWdoKiByZXNwb25zaXZlIGRlc2lnbiAqY291 Z2gqKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy9yaWNoYW5uYV08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7 bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjEuMGluIj4NClNlY3Rpb24gMTIuNjo8bzpwPjwvbzpwPjwvcD4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtbRWRpdG9yOiBpcyB0aGVyZSBz b21lIG90aGVyIHJlYXNvbiB0byBoYXZlIHRoZSBVc2VySW5mbzwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50 P108L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpJIG1heSB3YW50IHRvIGhvc3QgbXkgVXNlckluZm8gZW5k cG9pbnQgb24gYSBzZXBhcmF0ZSBtaWNyb3NlcnZpY2UgZnJvbSBteSB0b2tlbiBlbmRwb2ludCAo aW4gT0F1dGggMi4wL09JREMgdGVybXMpLiBUaGUgZm9ybWVyIG1pZ2h0IGJlIHBhcnQgb2YgbXkg dXNlciBwcm9maWxlL2RpcmVjdG9yeSBzdGFjaywgd2hpbGUgdGhlIGxhdHRlciBpcyBwYXJ0IG9m IHRoZSBoaWdobHkgcHJpdmlsZWdlZCBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uDQogc3Rh Y2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpUaGUgdG9rZW4gZW5kcG9pbnQgaGFz IHRoZSBhY2Nlc3MgdG9rZW4gYW55d2F5LCBzbyBpdCBjYW4gZmV0Y2ggdGhlIGRhdGEgZnJvbSB0 aGUgb3RoZXIgZW5kcG9pbnQgaXRzZWxmIGlmIGl0IHdhbnRlZCB0by4gSUUsIHRoZXJlIGlzIG5v IHNlcGFyYXRpb24gb2YgZHV0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEu MGluIj4NCldoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBVc2VySW5mbyBlbmRwb2ludCB0 byB0aGUgVXNlciBvciBDbGllbnQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW4iPg0KVGhlIFVzZXJJbmZvIGVuZHBvaW50IHNlZW1zIHRvIGp1c3QgYWRkIG1vcmUg Y29tcGxleGl0eSwgd2l0aCBubyBhYmlsaXR5IHRvIHN0YXJ0IGEgVXNlciBpbnRlcmFjdGlvbiBp ZiBhZGRpdGlvbmFsIGNvbnNlbnQgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KSWYgdGhlIGFjY2VzcyB0b2tlbiBpcyBzZW5kZXItY29uc3RyYWluZWQsIHRo ZW4gbm8sIHRoZSB0b2tlbiBlbmRwb2ludCBjYW7igJl0IGZldGNoIHRoZSBkYXRhIGl0c2VsZi4g QnV0IGV2ZW4gd2l0aG91dCB0aGUgc2VjdXJpdHkgYW5nbGUsIHRoZXJlIGlzIHZhbHVlIGluIHNl cGFyYXRpbmcgb3V0IHRoZSBmdW5jdGlvbmFsaXR5IGFzIGl0IGFsbG93cyB0aGUgR1MgdG8gZGlz dHJpYnV0ZSBpdCBhY3Jvc3Mgc3lzdGVtcyB3aXRoIGRpZmZlcmVudCBvd25lcnMuDQogRS5nLiwg dGhlcmUgbWlnaHQgYmUgYSBkaXJlY3RvcnkgQVBJIHRlYW0gdGhhdCBhbHNvIG93bnMgdGhlIFND SU0gaW50ZXJmYWNlIGFuZCBVc2VySW5mbyBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkFuIGltcGxlbWVudGF0aW9uIGNhbiBhbHNvIHJvdXRlIGNhbGxzIHRv IGRpZmZlcmVudCBpbnRlcm5hbCBzeXN0ZW1zIHdoaWxlIGtlZXBpbmcgdGhlIHNhbWUgZW5kcG9p bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBhbHNv IHRoaW5rIG9mIFNDaU0gYW5kIFVzZXJJbmZvIGFzIHZlcnkgZGlmZmVyZW50IGVuZHBvaW50cy4g SSB3b3VsZCBjb25zaWRlciBTQ0lNIGEgcmVzb3VyY2UsIGFuZCBVc2VySW5mbyBjbGFpbXMuIEkg YXBwcmVjaWF0ZSB0aG9zZSBhcmUgc2ltaWxhciBpbiBlbnRlcnByaXNlLCBidXQgdGhleSBhcmUg bm90IGluIGNvbnN1bWVyIGNvbnRleHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um91dGluZyBjYWxscyB0byBkaWZmZXJlbnQgaW50ZXJu YWwgc3lzdGVtcyBzdGlsbCBtZWFucyBJIGhhdmUgdG8gaGF2ZSBzb21lIHNoYXJlZCBpbmZyYXN0 cnVjdHVyZSB0aGF0IGJvdGggdGVhbXMgbWFuYWdlLiBJdOKAmXMgbW9yZSBjb21wbGV4IHRoYW4g aXQgbmVlZHMgdG8gYmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGdvaW5nIHRvIHN1 Z2dlc3Qgd2UgbW92ZSB0aGlzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gdG8gYSBzZXBhcmF0ZSB0 aHJlYWQgYmVjYXVzZSBpdOKAmXMgdG9vIG1lc3N5IHRvIGtlZXAgaW4gdGhpcyBhd2Z1bCBiYWNr LWFuZC1mb3J0aC4gSeKAmWxsIGp1c3QgYWRkIGhlcmUgdGhhdCBJ4oCZbSBub3Qgc3VnZ2VzdGlu ZyB3ZQ0KPGk+b25seTwvaT4gaGF2ZSBhIFVzZXJJbmZvIGVuZHBvaW50LiBJ4oCZbSBhcmd1aW5n IHR3byB0aGluZ3M6PG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBz dGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPlRoZSBVc2VySW5mbyBlbmRw b2ludCBpcyBnb29kLCBhY3R1YWxseS4gSXQgZG9lc27igJl0IG5lZWQgdG8gYmUgTVRJLCBidXQg d2Ugc2hvdWxkIG5vdCBwcmVjbHVkZSBpdHMgZXhpc3RlbmNlLjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzYiPklmIHdlIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHJlcXVlc3Rpbmcg YW5kIHJlY2VpdmluZyBjbGFpbXMgaW4gdGhlIEdTIFJlYWQgR3JhbnQgcmVzcG9uc2UsIHRoYXQg bWVjaGFuaXNtIHNob3VsZCBhcHBseSBnZW5lcmljYWxseSB0byBhcmJpdHJhcnkgcmVzb3VyY2Vz LiBHU2VzIGNhbiBzdXBwb3J0IGl0IG9yDQogbm90LCBmb3IgYW55IGdpdmVuIHJlc291cmNlLjxv OnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy9yaWNoYW5uYV08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCltyaWNoYW5uYV08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClRoZXJlIGFyZSB0 d28gYmlnIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhvc2UgZXhhbXBsZXMgKGUuZy4sIFFSIENvZGUs IGFwcC1iYXNlZCBsb2dpbiBhcHByb3ZhbHMpIGFuZCB0aGlzIG1lY2hhbmlzbSBpbiBYQXV0aDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29s aXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0Omw1IGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PkluIHlvdXIgZXhhbXBsZXMgb2YgdGhpcyBiZWhhdmlvciB0b2RheSwgdGhlIHJlYXNvbiBmb3Ig dGhlIHdhaXQgaXMgY2xlYXIgYW5kIG9idmlvdXMsIGFuZCBkcml2ZW4gYnkgdGhlIHVzZXIuIEUu Zy4sIG15IHByaW50ZXIgaXMgd2FpdGluZyBmb3IgbWUgdG8gZ28gZW50ZXIgdGhpcyBjb2RlIGFu ZCBsb2cgaW47IEdvb2dsZSBzaWduIGluIGlzIHdhaXRpbmcgZm9yIG1lIHRvIHRhcCB0aGlzIGJ1 dHRvbiBvbg0KIG15IHBob25lLiBUaGF0IGlzIG5vdCB0aGUgY2FzZSBpbiB0aGUgWEF1dGggcHJv dG9jb2wuIFRoZSB1c2VyIGlzIGxlZnQgc2l0dGluZyBvbiBhIGxvYWRpbmcgc2NyZWVuIHdhaXRp bmcgZm9yIGEgYmVoaW5kLXRoZS1zY2VuZXMgaW50ZXJhY3Rpb24gYmV0d2VlbiBjbGllbnQgYW5k IEdTIHRoYXQgbWF5IG5vdCBldmVuIGhhcHBlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJn bWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omw1IGxldmVsMSBsZm80Ij4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlVubGlrZSB3aXRoIGNvZGUvUVIgZmxvd3Mg b3Igc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZXJlIGlzIG5vIGFjdGl2ZSBwcm9jZXNzIG9uIHRo ZSBjbGllbnQgc2lkZSB0byBrZWVwIHRoaXMgYXN5bmMgcmVxdWVzdCBvcGVuLiBBIHdlYiBhcHAg Y2xpZW50IHdvdWxkIGhhdmUgdG8gaW50cm9kdWNlIGEgc2VydmVyLXNpZGUgYXN5bmMgcHJvY2Vz cyB0byBtYW5hZ2UgdGhpcyBhc3BlY3Qgb2YgdGhlIHByb3RvY29sLg0KIFRoYXTigJlzIG5vdCBl YXN5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMz MG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+VGhlIGZhaWx1cmUgbW9kZXMgc2hvdyB1cCBpbiBtb3JlIGFwcHJvcHJpYXRlIGNvbnRl eHRzLCB3aGVyZSB0aGVyZSBhcmUgY2xlYXIgcGF0aHMgZm9yd2FyZCBmb3IgdGhlIGVuZCB1c2Vy LiBJbiBjb2RlL1FSLWJhc2VkIGZsb3dzLCBpdOKAmXMgZGV0ZWN0ZWQgb24gdGhlIGNsaWVudCBz aWRlLCBpbiB0aGUgZm9ybSBvZiBhbiBBUyB0aGF0IG5ldmVyIHByb3ZpZGVzIGEgcmVzcG9uc2Uu IEluIHRoYXQgc2NlbmFyaW8sDQogdGhlIGNsaWVudCBjYW4gcmV0cnkgdGhlIHByb2Nlc3MuIElu IHNpZ24taW4gdmVyaWZpY2F0aW9uLCB0aGUgcHJvYmxlbSBvY2N1cnMgYmV0d2VlbiB0d28gcGFy dHMgb2YgdGhlIEFTLCBhbmQgdGhlIEFTIGNhbiBhbGxvdyB0aGUgZW5kIHVzZXIgdG8gcmV0cnkg b3IgdG8gdXNlIGEgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4gSW4gdGhlIFhBdXRo IENyZWF0ZSYjNDM7VXBkYXRlIHNjZW5hcmlvLCB0aGUgZmFpbHVyZSBpcyBkZXRlY3RlZA0KIG9u IHRoZSBHUywgYW5kIHRoZXJlIGlzIG5vIGNsZWFyIHBhdGggZm9yd2FyZC4gSWYgdGhlIENsaWVu dCBuZXZlciBjYWxscyBVcGRhdGUgR3JhbnQgdG8gZmxpcCBpbnRlcmFjdGlvbi5rZWVwIHRvIGZh bHNlLCB3aGF0IHNob3VsZCB0aGUgR1MgZG8/IEhvdyBsb25nIHNob3VsZCBpdCB3YWl0PyBTaG91 bGQgaXQgaXNzdWUgdGhlIGF1dGhvcml6YXRpb24gYW55d2F5LCBhc3N1bWluZyB0aGUgQ2xpZW50 IHdpbGwgY29tZSBiYWNrIGFuZCBhc2sgZm9yDQogaXQgYXQgc29tZSBwb2ludD8gU2hvdWxkIGl0 IHJlZGlyZWN0IHRoZSBlbmQgdXNlciBiYWNrIHRvIHRoZSBDbGllbnQgYW55d2F5LCBvciBkcm9w IHRoZW0gb24gYSBsYW5kaW5nIHBhZ2U/IFNob3VsZCBpdCBmbGFnIHRoaXMgYXMgYW4gZXJyb3Is IG9yIGlzIHRoaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGZvciB0aGUgQ2xpZW50PzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQpJIHJlYWxseSB0aGluayB0aGlzIGlzIG92ZXJjb21wbGljYXRpbmcgdGhlIHByb3RvY29sIHRv IGFuIGV4dGVudCB0aGF0IG5vIG9uZSB3aWxsIGFjdHVhbGx5IGltcGxlbWVudCBpdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClsvcmlj aGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgZmxvdyBpbiZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0 aC1wcm90b2NvbC0wMiNzZWN0aW9uLTMuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAyI3NlY3Rpb24tMy4xPC9hPiZuYnNwO2lzIEVYQUNU TFkgdGhlIHNhbWUgYXMgdGhlIEdvb2dsZSBhbmQgTWljcm9zb2Z0DQogZmxvd3MuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hpbGUgdGhlIGZs b3cgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFy ZHQteGF1dGgtcHJvdG9jb2wtMDIjc2VjdGlvbi0zLjQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMiNzZWN0aW9uLTMuNDwvYT4mbmJzcDto YXMgYWRkaXRpb25hbCBzdGVwcywgaXQgaXMgbm90IGZ1bmRhbWVudGFsbHkNCiBhbnkgZGlmZmVy ZW50IGV4Y2VwdCB0aGUgQ2xpZW50IGlzIG1ha2luZyBhbm90aGVyIGNhbGwgdG8gdGhlIEdTIGFm dGVyIHRoZSBmaXJzdCBvbmUgcmV0dXJucy4gVGhlIHJpc2sgb2YgdGhlIENsaWVudCBub3QgbWFr aW5nIHRoZSBzZWNvbmQgY2FsbCBhbmQgbGVhdmluZyB0aGUgVXNlciBoYW5naW5nIGlzIG5vdCBy ZWFsbHkgYW55IGRpZmZlcmVudCBvZiB0aGUgQ2xpZW50IG5vdCBtYWtpbmcgdGhlIGZpcnN0IGNh bGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmVzaWRl cyB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBtb2JpbGUgZGV2aWNlIHRoYXQgTUFZIG5vdCBiZSBh YmxlIHRvIG1ha2UgdGhlIHNlY29uZCBjYWxsIG1pZ2h0IHB1dCB0byBzbGVlcCwgSSBkb24ndCBz ZWUgYW55IGltcGxlbWVudGF0aW9uIGlzc3Vlcy4gVHhBdXRoIHdvcmtzIHRoZSBzYW1lIHdheSBh cyAzLjEgYXMgSSB1bmRlcnN0YW5kIGl0IGZvciBub24tcmVkaXJlY3QNCiBmbG93cy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZ dCB0aGluayB5b3UgYWN0dWFsbHkgcmVhZCB3aGF0IEkgd3JvdGUuIElmIHRoZSBmbG93cyBhcmUg ZXhhY3RseSB0aGUgc2FtZSwgdGVsbCBtZTo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNyI+V2hh dCBkb2VzIHRoZSB1c2VyIHRoaW5rIGlzIGdvaW5nIG9uIHdoaWxlIHRoZXnigJlyZSBzaXR0aW5n IG9uIHRoZSBHUywgd2F0Y2hpbmcgYSBzcGlubmVyIGFzIHRoZSBHUyB3YWl0cyBmb3IgdGhlIENs aWVudCB0byBtYWtlIGFuIFVwZGF0ZSBHcmFudCByZXF1ZXN0IGluIDMuND88bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwxIGxldmVsMSBsZm83Ij5XaGF0IGV4aXN0aW5nIENsaWVudCBjb21wb25lbnQgaXMg aG9sZGluZyBvcGVuIHRoZSBSZWFkIEdyYW50IHJlcXVlc3Q/PG86cD48L286cD48L2xpPjwvb2w+ DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxm bzciPklmIHlvdXIgYW5zd2VyIGlzIOKAnGFuIGFzeW5jIHByb2Nlc3Mgb24gdGhlIENsaWVudOKA mXMgc2VydmVy4oCdIHRoZW4gcGxlYXNlIHJlLXJlYWQgdGhlIHNlY29uZCB3b3JkIG9mIHRoYXQg cXVlc3Rpb24uPG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm83Ij5Ib3cgbG9u ZyBzaG91bGQgdGhlIEdTIHdhaXQgZm9yIHRoZSBDbGllbnQgdG8gbWFrZSB0aGUgVXBkYXRlIEdy YW50IHJlcXVlc3QgaW4gMy40PyBXaGF0IHNob3VsZCB0aGUgR1MgZG8gaWYgdGhhdCBuZXZlciBo YXBwZW5zPyBXaGF0IGlzIHRoZSBwYXRoIGZvcndhcmQgZm9yIHRoZSBlbmQgdXNlciwgYXQgdGhh dA0KIHBvaW50PzxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy9y aWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjVpbiI+DQpbcGFzdGluZyBpbiBmcm9tIHlvdXIgbGF0ZXIgZW1haWxdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KV2hp bGUgYSBzaW5nbGUgc3RhZ2UgR3JhbnQgcmVxdWVzdCAoMy4xKSBpbiBhIG1vYmlsZSBhcHAgdGhh dCBoYXMgYmVlbiBwdXQgdG8gc2xlZXAgd2lsbCByZWNvdmVyIGZpbmUsIGEgbXVsdGktc3RlcCAo My40KSB3aWxsIGZhaWwuIFNpbmNlIDMuNCBvbmx5IG1ha2VzIHNlbnNlIGlmIHRoZSBDbGllbnQg aXMgY2hlY2tpbmcgYSBkYXRhYmFzZSBhbG9uZyB0aGUgd2F5LCBJIHdvdWxkJm5ic3A7ZXhwZWN0 IHRoZSBDbGllbnQgdG8gaGF2ZSBhIHNlcnZlciBzaWRlLA0KIGFuZCB0aGUgc2VydmVyIGNvdWxk IHRha2UgZWFjaCBzdGVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KWy9lbmQgcGFzdGVdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCltyaWNoYW5uYV08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkhhdmlu ZyBhIHJlbW90ZSBkYXRhYmFzZSBhbmQgaGF2aW5nIGEgcmVtb3RlIHNlcnZlciBhcmUgbm90IHRo ZSBzYW1lIHRoaW5nLiBUaGlzIGFkZHMgYSBsb3Qgb2YgY29tcGxleGl0eSB0byBzZXJ2ZXJsZXNz IGFwcHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQpbL3JpY2hhbm5hXTxpbWcgYm9yZGVyPSIwIiBpZD0iZ21haWwtbV8tMTM5MTM2Njgy ODM2NzQyMjMzMF94MDA1Zl94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBw c3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlw ZT16ZXJvY29udGVudCZhbXA7Z3VpZD03Y2QxOGVhNi04YzUwLTQ2ZGMtYmUyNS1lOTlmNjE0ZGFi ODIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldoaWNoIGFzcGVjdCBhZGRzIGNvbXBsZXhpdHk/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGFkZGVkIGNvbXBs ZXhpdHkgaW4ga2VlcGluZyBhbiBpbnRlcmFjdGlvbiBpcyBtYWtpbmcgYW4gYWRkaXRpb25hbCBB UEkgY2FsbCBhZnRlciB0aGUgZmlyc3QgQVBJIGNhbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpc3N1 ZSBpc27igJl0IHRoZSBBUEkgY2FsbCBpdHNlbGYsIGl04oCZcyB0aGUgbmVlZCBmb3IgdGhlIENs aWVudCB0byBtYWludGFpbiBhIHBlcnNpc3RlbnQsIGFzeW5jaHJvbm91cyBwcm9jZXNzIHRvIG1h a2UgdGhhdCBBUEkgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgaW5jb3JyZWN0 IHRvIGFzc3VtZSB0aGF0IGV2ZXJ5IGFwcCB3aXRoIGEgZGF0YWJhc2Ugd2lsbCBuZWNlc3Nhcmls eSBoYXZlIGEgc2VydmVyIHNpZGUuIEEgc2VydmVybGVzcyBhcHAgdGhhdCBkb2VzIGEgcmVkaXJl Y3QgdG8gdGhlIEdTLCBvciB0aGF0IHN3aXRjaGVzIHRvIGFuIGV4dGVybmFsIGJyb3dzZXIgKGFu ZCB0aHVzIG1heSBiZSBwdXQgdG8gc2xlZXApIGhhcyBubyBjb21wb25lbnQgdGhhdA0KIHdpbGwg cmVsaWFibHkgc3RheSBhbGl2ZSB0byBob2xkIG9wZW4gdGhlIFJlYWQgR3JhbnQgcmVxdWVzdCwg cmVjZWl2ZSB0aGUgcmVzcG9uc2UsIGFuZCBmb2xsb3cgdXAgd2l0aCBhbiBVcGRhdGUgR3JhbnQg cmVxdWVzdCAoaS5lLiwgZmxvdyAzLjQpLiBBZGRpbmcgYSBzZXJ2ZXItc2lkZSBjb21wb25lbnQg dG8gZG8gdGhpcyBvcmNoZXN0cmF0aW9uIGFkZHMgc2lnbmlmaWNhbnQgY29tcGxleGl0eS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsvcmljaGFu bmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ LS0gPGJyPg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_0092A517C90B41A68272D779E84E10C9amazoncom_-- From nobody Sat Feb 15 14:50:45 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75981200FF for ; Sat, 15 Feb 2020 14:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 bp0wkkq7H5wc for ; Sat, 15 Feb 2020 14:50:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8D1C61200FE for ; Sat, 15 Feb 2020 14:50:39 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01FMoZJJ010738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Feb 2020 17:50:35 -0500 From: Justin Richer Message-Id: <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_4CD1F247-4CDD-4862-8EC8-629980143DAA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 15 Feb 2020 17:50:34 -0500 In-Reply-To: <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> Cc: "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 22:50:44 -0000 --Apple-Mail=_4CD1F247-4CDD-4862-8EC8-629980143DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The interaction model that Annabelle describes below is exactly the kind = of thing that=E2=80=99s in XYZ: https://oauth.xyz/interaction/ An earlier implementation of XYZ had a =E2=80=9Ctype=E2=80=9D field like = XAuth does. You can see that here: = https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2.= 4 We moved away from it for all of the reasons Annabelle is citing, along = with the others I=E2=80=99ve stated previously on the list that I = don=E2=80=99t feel bear repeating again. Having implemented both = patterns directly in the same project, I can attest that the code paths = are significantly simpler for the current XYZ pattern, especially on = the Authorization Server. You can look at our code yourselves, if you = like. And for the =E2=80=9Csimple=E2=80=9D client case that supports only one = type (which I think we all believe will be the overwhelmingly common = case), I want to point out that the XYZ approach and the XAuth approach = are for all intents and purposes identical. The XYZ approach allows for = a lot more flexibility along with a decrease in complexity.=20 =E2=80=94 Justin > On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle = wrote: >=20 > [richanna] > Replies inline. > [/richanna] > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth > on behalf of Dick Hardt = > > Date: Friday, February 14, 2020 at 9:10 AM > To: "Richard Backman, Annabelle" > > Cc: "txauth@ietf.org " > > Subject: Re: [Txauth] XAuth -02 > =20 > =20 > =20 > On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle = > wrote: >> [richanna] >> Replies inline >> [/richanna]=20 >> >> [richanna] >> By user code-based interaction, I mean the kind described in the = OAuth 2.0 Device Authorization Grant = , where the user receives a code and = short URL from the client, navigates to that URL in a browser, and = enters the code. While this could be packed into interaction.message, = this will lead to clunkier user experiences: >> 1. The GS may not be able to provide localized instructions that = match the locale on the Client. >>=20 >> 2. Suppose the GS sends a message that reads: =E2=80=9CScan the QR = code or open a browser to http://code.example/ = and enter the code: 12345.=E2=80=9D >>=20 >> a. That instruction does not make sense on a device that does not = present a QR code. Imagine hearing that from a smart speaker. >>=20 >> b. That instruction is confusingly redundant if the Client displays = the QR code along with its own instructions, like: =E2=80=9CScan the QR = code or follow the instructions below.=E2=80=9D >>=20 >> 3. Will =E2=80=9Cembed the short URL and code in the message = string=E2=80=9D be MTI? If not, text-only clients would have a broken = experience. >>=20 >> [/richanna] > =20 > Sounds like a text only interaction type should be added per my note = in the draft. Perhaps even one that is focused on the code flow, where = the parameters are the code and the URI to enter the code, letting the = Client present the parameters with localized content? > =20 > [richanna] > I think we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80=9D = concept wrong. We=E2=80=99re conflating three different things together: > What does the Client need to send the end user to the GS? > A human-friendly short URL and code. > Any kind of URL, as long and ugly as it needs to be. > How will the Client receive the response from the GS? > Client will make a request to the GS. > GS will make a request to the Client. (I=E2=80=99ve had to implement = this for a custom integration, including it to demonstrate that other = options exist) > Will the GS return the end user to the Client, and if so how? > Yes, by URL redirect. > No. > =20 > Here is a very non-normative example request fragment, for a client = that wants both a short URL plus code and a full URL so they can = opportunistically use one or the other (AWS CLI v2 does this), will = query the GS for the response, and wants the GS to redirect to a = publicly accessible URL on the Client=E2=80=99s website after the flow = (e.g., to show further documentation/branded content to the end user): > { > "interact": { > "code": { "max": 8 }, > "url": true > }, > "response": { > "poll": true > }, > "return": { > "url": "https://help.smartdevice.example/post-setup = " > } > } > =20 > And here is an equally non-normative example response fragment: > { > "interact": { > "code": "123456", > "code_url": "https://gs.example/code ", > "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef = " > } > } > =20 > (Seriously do not read too much into these parameter names or syntax, = this is just to give a rough sense of how I=E2=80=99m thinking about = this. Anyone who tries to pick apart this example will be responded to = with mocking memes.) > [/richanna] >> =20 >> =20 >>> 2. Clients support multiple interaction modes and may not always = know what the GS supports (and vice-versa). For a multi-tenant GS, it = may vary by tenant configuration. Clients should be able to say what = they can do, and the GS should be able to tell them which one to use. = It=E2=80=99s a very simple but powerful inline negotiation. >> =20 >> That is what is in TxAuth. Would you elaborate on how the GS might be = constrained? Why would the GS not be able to do all? >> =20 >> I would think all constraints would be at the Client. Am I missing = something? >> =20 >> [richanna] >> Clients may support customer-defined GSes (e.g., enterprise IdPs), = which will vary in terms of which interaction modes they support. While = the set of interactions defined in XAuth might all be MTI for a GS, we = should assume that extensions will introduce new interactions which will = not be universally supported. An interaction mechanism might have = properties that cause some administrators to want to disable it, or to = restrict Clients to always use it. Are you assuming that a Client will = always make an OPTIONS discovery request first? >> [/richanna]=20 > =20 > An example of why a given GS may not support a mode would be helpful. > =20 > I was envisioning that if an optional to support interaction mode was = not supported at the GS, that it would return an error. The Client would = then try a different one. Alternatively, the Client could start with an = OPTIONS call in cases where the GS is dynamicly chosen. > =20 > [richanna] > Lots of ASes don=E2=80=99t support Device Authorization Grant. I think = it=E2=80=99s safe to assume that interaction mode support will vary for = XAuth as well. =E2=80=9CKeep trying until you find one that works=E2=80=9D= sounds pretty painful for the client, and doesn=E2=80=99t allow the = client to use multiple interaction modes, as demonstrated in my example = above. > =20 > There are lots of reasons for wanting to support multiple modes: > Some people are comfortable with QR codes, some aren=E2=80=99t. > Some people have smart phones that can scan them, some don=E2=80=99t. > People with smart phones may want to go through the authentication = flow on their desktop instead. > Some people may have to go through the authentication flow on their = desktop, because the GS thinks iPhones only support Bluetooth-based = security keys and insists they cannot complete the login flow even = though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE = ACCOUNT PROTECTION PROGRAM) > [/richanna] >> =20 >>> 3. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D = interaction mode. Clients can use =E2=80=9Credirect=E2=80=9D mode within = popups. However, speaking as someone who has done that, I really don=E2=80= =99t recommend it. Popups are increasingly unsupported, and prone to = weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend = to have popups disabled. The last versions of IE Mobile didn=E2=80=99t = support them at all (the popped up page basically just loaded into the = current window).. in=20 >> =20 >> Popups are really useful in single-page apps as you want to keep the = context and not reload the page. >> =20 >> Agree that popups don't make sense in mobile. A full redirect does of = course. A single-page app on mobile would open a new tab which would be = a separate context rather than a redirect. >> =20 >> [richanna] >> Popups are broken and/or disabled in enough instances that we should = not encourage their usage by including explicit support for them in the = protocol. Nor are they necessary for SPAs in order to restore the state = of their app after the redirect. > =20 > Are they really that broken in desktop? I've used them extensively = myself in the past as it was a better user experience, but that was a = few years ago. > =20 > [richanna] > Popup blockers are built in and aggressively enabled by default on all = major browsers. Communicating securely between windows is not easy, and = from past experience prone to failure thanks to weird browser bugs. = Trusted Site settings in IE and Edge can blow the whole thing up in = weird ways (speaking again from experience). > =20 > Also, it=E2=80=99s 2020. Stop branching on mobile vs. desktop. I get = that lots of people still do that, but that doesn=E2=80=99t mean the = protocol should cater to it. > [/richanna] >> And again, a Client that really wants to give themselves a headache = with popups can do that themselves using =E2=80=9Credirect=E2=80=9D = mode. They just have to provide a landing page for the GS to redirect = back to that parses the response, passes it back to the main window, and = closes itself. I don=E2=80=99t see why the protocol would need to = explicitly describe this mechanism.=20 >> [/richanna] > =20 > I think it is a useful signal for the GS in the experience it wants to = show the user. > =20 > [richanna] > Useful how? The window dimensions are a better signal for how to = present the user experience. (*cough* responsive design *cough*) > [/richanna] >> =20 >>> Section 12.6: >>> [Editor: is there some other reason to have the UserInfo >>> endpoint?] >>> =20 >>> I may want to host my UserInfo endpoint on a separate microservice = from my token endpoint (in OAuth 2.0/OIDC terms). The former might be = part of my user profile/directory stack, while the latter is part of the = highly privileged authentication/authorization stack. >> =20 >> =20 >> The token endpoint has the access token anyway, so it can fetch the = data from the other endpoint itself if it wanted to. IE, there is no = separation of duties. >> =20 >> What are the advantages of the UserInfo endpoint to the User or = Client?=20 >> =20 >> The UserInfo endpoint seems to just add more complexity, with no = ability to start a User interaction if additional consent is needed. >> =20 >> [richanna] >> If the access token is sender-constrained, then no, the token = endpoint can=E2=80=99t fetch the data itself. But even without the = security angle, there is value in separating out the functionality as it = allows the GS to distribute it across systems with different owners. = E.g., there might be a directory API team that also owns the SCIM = interface and UserInfo endpoint. > =20 > An implementation can also route calls to different internal systems = while keeping the same endpoint. > =20 > I also think of SCiM and UserInfo as very different endpoints. I would = consider SCIM a resource, and UserInfo claims. I appreciate those are = similar in enterprise, but they are not in consumer contexts. > =20 > [richanna] > Routing calls to different internal systems still means I have to have = some shared infrastructure that both teams manage. It=E2=80=99s more = complex than it needs to be. > =20 > I=E2=80=99m going to suggest we move this part of the discussion to a = separate thread because it=E2=80=99s too messy to keep in this awful = back-and-forth. I=E2=80=99ll just add here that I=E2=80=99m not = suggesting we only have a UserInfo endpoint. I=E2=80=99m arguing two = things: > The UserInfo endpoint is good, actually. It doesn=E2=80=99t need to be = MTI, but we should not preclude its existence. > If we provide a mechanism for requesting and receiving claims in the = GS Read Grant response, that mechanism should apply generically to = arbitrary resources. GSes can support it or not, for any given resource. > [/richanna] > =20 > >> [richanna] >> There are two big differences between those examples (e.g., QR Code, = app-based login approvals) and this mechanism in XAuth: >> 1. In your examples of this behavior today, the reason for the wait = is clear and obvious, and driven by the user. E.g., my printer is = waiting for me to go enter this code and log in; Google sign in is = waiting for me to tap this button on my phone. That is not the case in = the XAuth protocol. The user is left sitting on a loading screen waiting = for a behind-the-scenes interaction between client and GS that may not = even happen. >>=20 >> 2. Unlike with code/QR flows or sign-in verification, there is no = active process on the client side to keep this async request open. A web = app client would have to introduce a server-side async process to manage = this aspect of the protocol. That=E2=80=99s not easy. >>=20 >> 3. The failure modes show up in more appropriate contexts, where = there are clear paths forward for the end user. In code/QR-based flows, = it=E2=80=99s detected on the client side, in the form of an AS that = never provides a response. In that scenario, the client can retry the = process. In sign-in verification, the problem occurs between two parts = of the AS, and the AS can allow the end user to retry or to use a = different authentication method. In the XAuth Create+Update scenario, = the failure is detected on the GS, and there is no clear path forward. = If the Client never calls Update Grant to flip interaction.keep to = false, what should the GS do? How long should it wait? Should it issue = the authorization anyway, assuming the Client will come back and ask for = it at some point? Should it redirect the end user back to the Client = anyway, or drop them on a landing page? Should it flag this as an error, = or is this the expected behavior for the Client? >>=20 >> =20 >> I really think this is overcomplicating the protocol to an extent = that no one will actually implement it. >> [/richanna] > =20 > The flow in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 = = is EXACTLY the same as the Google and Microsoft flows.=20 > =20 > While the flow in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 = = has additional steps, it is not fundamentally any different except the = Client is making another call to the GS after the first one returns. The = risk of the Client not making the second call and leaving the User = hanging is not really any different of the Client not making the first = call. > =20 > Besides the situation where the mobile device that MAY not be able to = make the second call might put to sleep, I don't see any implementation = issues. TxAuth works the same way as 3.1 as I understand it for = non-redirect flows. > =20 > [richanna] > I don=E2=80=99t think you actually read what I wrote. If the flows are = exactly the same, tell me: > What does the user think is going on while they=E2=80=99re sitting on = the GS, watching a spinner as the GS waits for the Client to make an = Update Grant request in 3.4? > What existing Client component is holding open the Read Grant request? > If your answer is =E2=80=9Can async process on the Client=E2=80=99s = server=E2=80=9D then please re-read the second word of that question. > How long should the GS wait for the Client to make the Update Grant = request in 3.4? What should the GS do if that never happens? What is the = path forward for the end user, at that point? > [/richanna] >> =20 >> [pasting in from your later email] >> While a single stage Grant request (3.1) in a mobile app that has = been put to sleep will recover fine, a multi-step (3.4) will fail. Since = 3.4 only makes sense if the Client is checking a database along the way, = I would expect the Client to have a server side, and the server could = take each step. >> [/end paste] >> =20 >> [richanna] >> Having a remote database and having a remote server are not the same = thing. This adds a lot of complexity to serverless apps. >> [/richanna]=E1=90=A7 > =20 > Which aspect adds complexity? > =20 > The added complexity in keeping an interaction is making an additional = API call after the first API call. > =20 > [richanna] > The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for = the Client to maintain a persistent, asynchronous process to make that = API call. > =20 > It is incorrect to assume that every app with a database will = necessarily have a server side. A serverless app that does a redirect to = the GS, or that switches to an external browser (and thus may be put to = sleep) has no component that will reliably stay alive to hold open the = Read Grant request, receive the response, and follow up with an Update = Grant request (i.e., flow 3.4). Adding a server-side component to do = this orchestration adds significant complexity. > [/richanna] > =20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_4CD1F247-4CDD-4862-8EC8-629980143DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = interaction model that Annabelle describes below is exactly the kind of = thing that=E2=80=99s in XYZ:

https://oauth.xyz/interaction/

An earlier implementation of XYZ had a = =E2=80=9Ctype=E2=80=9D field like XAuth does. You can see that = here:

https://tools.ietf.org/html/draft-richer-transactional-authz-00= #section-2.4

We moved away from it for all of the reasons Annabelle is = citing, along with the others I=E2=80=99ve stated previously on the list = that I don=E2=80=99t feel bear repeating again. Having implemented both = patterns directly in the same project, I can attest that the code paths = are significantly simpler  for the current XYZ pattern, especially = on the Authorization Server. You can look at our code yourselves, if you = like.

And for = the =E2=80=9Csimple=E2=80=9D client case that supports only one type = (which I think we all believe will be the overwhelmingly common case), I = want to point out that the XYZ approach and the XAuth approach are for = all intents and purposes identical. The XYZ approach allows for a lot = more flexibility along with a decrease in complexity. 

 =E2=80=94 = Justin


On Feb 14, 2020, at 9:29 PM, = Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

[richanna]
Replies inline.
[/richanna]
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 14, = 2020 at 9:10 AM
To: "Richard Backman, = Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] XAuth = -02
 
 
 
On Thu, Feb 13, 2020 = at 6:08 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
[richanna]
Replies = inline
[/richanna] 
<snip>
[richanna]
By user code-based interaction, I mean = the kind described in the OAuth 2.0 = Device Authorization Grant, where the user receives a code and short = URL from the client, navigates to that URL in a browser, and enters the = code. While this could be packed into interaction.message, this will = lead to clunkier user experiences:

1.   The GS may = not be able to provide localized instructions that match the locale on = the Client.

2.   Suppose the = GS sends a message that reads: =E2=80=9CScan the QR code or open a = browser to http://code.example/ and enter the code: = 12345.=E2=80=9D

a.    That = instruction does not make sense on a device that does not present a QR = code. Imagine hearing that from a smart speaker.

b.   That = instruction is confusingly redundant if the Client displays the QR code = along with its own instructions, like: =E2=80=9CScan the QR code or = follow the instructions below.=E2=80=9D

3.   Will =E2=80=9Ce= mbed the short URL and code in the message string=E2=80=9D be MTI? If = not, text-only clients would have a broken experience.

[/richanna]
 
Sounds like a text only interaction type should = be added per my note in the draft. Perhaps even one that is focused on = the code flow, where the parameters are the code and the URI to enter = the code, letting the Client present the parameters with localized = content?
 
[richanna]
I think = we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80=9D concept = wrong. We=E2=80=99re conflating three different things together:
  • What does the Client need to send the end user to = the GS?
    • A = human-friendly short URL and code.
    • Any kind of URL, as long and = ugly as it needs to be.
  • How will = the Client receive the response from the GS?
    • Client will make a request to = the GS.
    • GS will make a request to the Client. (I=E2=80=99ve = had to implement this for a custom integration, including it to = demonstrate that other options exist)
  • Will the GS return the end user to the Client, and = if so how?
    • Yes, by = URL redirect.
    • No.
 
Here is a = very non-normative example request fragment, for a client that wants = both a short URL plus code and a full URL so they can opportunistically = use one or the other (AWS CLI v2 does this), will query the GS for the = response, and wants the GS to redirect to a publicly accessible URL on = the Client=E2=80=99s website after the flow (e.g., to show further = documentation/branded content to the end user):
{
"interact": = {
  "code": { "max": 8 },
  = "url": true
},
"response": {
  "poll": true
},
"return": = {
  "url": "https://help.smartdevice.example/post-setup"
}
}
 
And here is an equally non-normative example response = fragment:
{
"interact": = {
  "code": "123456",
  "code_url": "https://gs.example/code",
}
}
 
(Seriously do not read too much into these parameter names or = syntax, this is just to give a rough sense of how I=E2=80=99m thinking = about this. Anyone who tries to pick apart this example will be = responded to with mocking memes.)
[/richanna]
 
 
2.   Clients support = multiple interaction modes and may not always know what the GS supports = (and vice-versa). For a multi-tenant GS, it may vary by tenant = configuration. Clients should be able to say what they can do, and the = GS should be able to tell them which one to use. It=E2=80=99s a very = simple but powerful inline negotiation.
 
That is what is in TxAuth. Would you elaborate on how the GS = might be constrained? Why would the GS not be able to do all?
 
I would think all constraints would be = at the Client. Am I missing something?
 
[richanna]
Clients = may support customer-defined GSes (e.g., enterprise IdPs), which will = vary in terms of which interaction modes they support. While the set of = interactions defined in XAuth might all be MTI for a GS, we should = assume that extensions will introduce new interactions which will not be = universally supported. An interaction mechanism might have properties = that cause some administrators to want to disable it, or to restrict = Clients to always use it. Are you assuming that a Client will always = make an OPTIONS discovery request first?
[/richanna] 
 
An example of why a given GS may not support a = mode would be helpful.
 
I was envisioning that if an optional to support = interaction mode was not supported at the GS, that it would return an = error. The Client would then try a different one. Alternatively, the = Client could start with an OPTIONS call in cases where the GS is = dynamicly chosen.
 
[richanna]
Lots of = ASes don=E2=80=99t support Device Authorization Grant. I think it=E2=80=99= s safe to assume that interaction mode support will vary for XAuth as = well. =E2=80=9CKeep trying until you find one that works=E2=80=9D sounds = pretty painful for the client, and doesn=E2=80=99t allow the client to = use multiple interaction modes, as demonstrated in my example above.
 
There are = lots of reasons for wanting to support multiple modes:
  • Some people are comfortable with QR codes, some = aren=E2=80=99t.
  • Some people have smart phones that can scan them, = some don=E2=80=99t.
  • People with smart phones may = want to go through the authentication flow on their desktop instead.
  • Some people may have to go through the = authentication flow on their desktop, because the GS thinks iPhones only = support Bluetooth-based security keys and insists they cannot complete = the login flow even though they have two YubiKey 5Ci keys on their = account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
[/richanna]
 
3.   I don=E2=80=99t see = the value of the =E2=80=9Cpopup=E2=80=9D interaction mode. Clients can = use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking as = someone who has done that, I really don=E2=80=99t recommend it. Popups = are increasingly unsupported, and prone to weird behavioral issues. = In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. = The last versions of IE Mobile didn=E2=80=99t support them at all (the = popped up page basically just loaded into the current window).. = in 
 
Popups are really useful in single-page apps as you want to = keep the context and not reload the page.
 
Agree that popups don't make sense in = mobile. A full redirect does of course. A single-page app on mobile = would open a new tab which would be a separate context rather than a = redirect.
 
[richanna]
Popups = are broken and/or disabled in enough instances that we should not = encourage their usage by including explicit support for them in the = protocol. Nor are they necessary for SPAs in order to restore the state = of their app after the redirect.
 
Are they really that broken in desktop? I've = used them extensively myself in the past as it was a better user = experience, but that was a few years ago.
 
[richanna]
Popup blockers are built in and aggressively enabled by = default on all major browsers. Communicating securely between windows is = not easy, and from past experience prone to failure thanks to weird = browser bugs. Trusted Site settings in IE and Edge can blow the whole = thing up in weird ways (speaking again from experience).
 
Also, = it=E2=80=99s 2020. Stop branching on mobile vs. desktop. I get that lots = of people still do that, but that doesn=E2=80=99t mean the protocol = should cater to it.
[/richanna]
And again, a Client = that really wants to give themselves a headache with popups can do that = themselves using =E2=80=9Credirect=E2=80=9D mode. They just have to = provide a landing page for the GS to redirect back to that parses the = response, passes it back to the main window, and closes itself. I = don=E2=80=99t see why the protocol would need to explicitly describe = this mechanism. 
[/richanna]
 
I think it is a useful signal for the GS in the = experience it wants to show the user.
 
[richanna]
Useful how? The window = dimensions are a better signal for how to present the user experience. = (*cough* responsive design *cough*)
[/richanna]
 
Section 12.6:
        [Editor: is there =
some other reason to have the UserInfo
        =
endpoint?]
 
I may want to host my UserInfo endpoint on a separate = microservice from my token endpoint (in OAuth 2.0/OIDC terms). The = former might be part of my user profile/directory stack, while the = latter is part of the highly privileged authentication/authorization = stack.
 
 
The token endpoint has the access token = anyway, so it can fetch the data from the other endpoint itself if it = wanted to. IE, there is no separation of duties.
 
What are the advantages of the UserInfo = endpoint to the User or Client? 
 
The UserInfo endpoint seems to just add = more complexity, with no ability to start a User interaction if = additional consent is needed.
 
[richanna]
If the access token is sender-constrained, then = no, the token endpoint can=E2=80=99t fetch the data itself. But even = without the security angle, there is value in separating out the = functionality as it allows the GS to distribute it across systems with = different owners. E.g., there might be a directory API team that also = owns the SCIM interface and UserInfo endpoint.
 
An implementation can also route calls to = different internal systems while keeping the same endpoint.
 
I also think of SCiM and UserInfo as = very different endpoints. I would consider SCIM a resource, and UserInfo = claims. I appreciate those are similar in enterprise, but they are not = in consumer contexts.
 
[richanna]
Routing calls to different internal systems still means I = have to have some shared infrastructure that both teams manage. It=E2=80=99= s more complex than it needs to be.
 
I=E2=80=99m going to suggest we move = this part of the discussion to a separate thread because it=E2=80=99s = too messy to keep in this awful back-and-forth. I=E2=80=99ll just add = here that I=E2=80=99m not suggesting we only have a UserInfo endpoint. = I=E2=80=99m arguing two things:
  1. The UserInfo endpoint is good, = actually. It doesn=E2=80=99t need to be MTI, but we should not preclude = its existence.
  2. If we provide a mechanism for requesting and = receiving claims in the GS Read Grant response, that mechanism should = apply generically to arbitrary resources. GSes can support it or not, = for any given resource.
[/richanna]
 
<snip>
[richanna]
There are = two big differences between those examples (e.g., QR Code, app-based = login approvals) and this mechanism in XAuth:

1.   In your = examples of this behavior today, the reason for the wait is clear and = obvious, and driven by the user. E.g., my printer is waiting for me to = go enter this code and log in; Google sign in is waiting for me to tap = this button on my phone. That is not the case in the XAuth protocol. The = user is left sitting on a loading screen waiting for a behind-the-scenes = interaction between client and GS that may not even happen.

2.   Unlike with = code/QR flows or sign-in verification, there is no active process on the = client side to keep this async request open. A web app client would have = to introduce a server-side async process to manage this aspect of the = protocol. That=E2=80=99s not easy.

3.   The failure = modes show up in more appropriate contexts, where there are clear paths = forward for the end user. In code/QR-based flows, it=E2=80=99s detected = on the client side, in the form of an AS that never provides a response. = In that scenario, the client can retry the process. In sign-in = verification, the problem occurs between two parts of the AS, and the AS = can allow the end user to retry or to use a different authentication = method. In the XAuth Create+Update scenario, the failure is detected on = the GS, and there is no clear path forward. If the Client never calls = Update Grant to flip interaction.keep to false, what should the GS do? = How long should it wait? Should it issue the authorization anyway, = assuming the Client will come back and ask for it at some point? Should = it redirect the end user back to the Client anyway, or drop them on a = landing page? Should it flag this as an error, or is this the expected = behavior for the Client?

 
I really think this is overcomplicating = the protocol to an extent that no one will actually implement it.
[/richanna]
 
The flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#secti= on-3.1 is EXACTLY the same as the Google and Microsoft = flows. 
 
While the flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#secti= on-3.4 has additional steps, it is not fundamentally any = different except the Client is making another call to the GS after the = first one returns. The risk of the Client not making the second call and = leaving the User hanging is not really any different of the Client not = making the first call.
 
Besides the situation where the mobile device = that MAY not be able to make the second call might put to sleep, I don't = see any implementation issues. TxAuth works the same way as 3.1 as I = understand it for non-redirect flows.
 
[richanna]
I don=E2=80=99t think you actually read what I wrote. If the = flows are exactly the same, tell me:
  1. What does = the user think is going on while they=E2=80=99re sitting on the GS, = watching a spinner as the GS waits for the Client to make an Update = Grant request in 3.4?
  2. What existing Client component = is holding open the Read Grant request?
  1. If your answer is =E2=80=9Can async process on the = Client=E2=80=99s server=E2=80=9D then please re-read the second word of = that question.
  1. How long should the GS wait for = the Client to make the Update Grant request in 3.4? What should the GS = do if that never happens? What is the path forward for the end user, at = that point?
[/richanna]
 
[pasting = in from your later email]
While a single stage Grant request (3.1) in a = mobile app that has been put to sleep will recover fine, a multi-step = (3.4) will fail. Since 3.4 only makes sense if the Client is checking a = database along the way, I would expect the Client to have a server = side, and the server could take each step.
[/end paste]
 
[richanna]
Having a remote database and having a remote = server are not the same thing. This adds a lot of complexity to = serverless apps.
[/richanna]=E1=90=A7
 
Which aspect adds complexity?
 
The added complexity in keeping an = interaction is making an additional API call after the first API = call.
 
[richanna]
The issue isn=E2=80=99t the API call itself, it=E2=80=99s the = need for the Client to maintain a persistent, asynchronous process to = make that API call.
 
It is incorrect to assume that every app with a database will = necessarily have a server side. A serverless app that does a redirect to = the GS, or that switches to an external browser (and thus may be put to = sleep) has no component that will reliably stay alive to hold open the = Read Grant request, receive the response, and follow up with an Update = Grant request (i.e., flow 3.4). Adding a server-side component to do = this orchestration adds significant complexity.
[/richanna]
 
-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_4CD1F247-4CDD-4862-8EC8-629980143DAA-- From nobody Mon Feb 17 18:45:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0ED120863 for ; Mon, 17 Feb 2020 10:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeLH_mg5TR6c for ; Mon, 17 Feb 2020 10:54:40 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (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 CA74E12012C for ; Mon, 17 Feb 2020 10:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1581965680; x=1613501680; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8Yw/7Fr+jvvcpmpFIQFxYncByU5PgVK1qruTlEdxuVU=; b=PHwrW9GUAH0dhK+ZchoRehyp1QtxVxsXQ7uy0N5KLkFUHRyTiiBBxBor Jjj4JzCnAFbYYS2kh034/wdKGMIRg2u9lXv715mgfkjAkbOXp4aFq8nv/ NUr8Jp0XaFNWn9PWLnarDisSIlTZIu3XFy5nkfxBSPZwRQI7NFiekOyrV c=; IronPort-SDR: 60hX24q+6ppzC6N6pOED4y57m4x0q70gu4y6GheW1WDi4NrXM8vhAh55IZbGwzPLxKJlpc7vyn CHvYrJk4Dzfw== X-IronPort-AV: E=Sophos; i="5.70,453,1574121600"; d="scan'208,217"; a="17383229" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-57e1d233.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 17 Feb 2020 18:54:26 +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-57e1d233.us-east-1.amazon.com (Postfix) with ESMTPS id E9332141A81; Mon, 17 Feb 2020 18:54:25 +0000 (UTC) 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, 17 Feb 2020 18:54:25 +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, 17 Feb 2020 18:54:25 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 17 Feb 2020 18:54:24 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: "txauth@ietf.org" Thread-Topic: [UNVERIFIED SENDER] Re: [Txauth] XAuth -02 Thread-Index: AQHV3jRcCsQaXzP9e0Gex6TsPtSqQKgUiKoAgAPnIYCAAQUDgIABgbqAgAAWcoCAAdtHAIACXJEA Date: Mon, 17 Feb 2020 18:54:24 +0000 Message-ID: References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> In-Reply-To: <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.26] Content-Type: multipart/alternative; boundary="_000_CB00CB6A57454670BE30393824A06D15amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 18:54:46 -0000 --_000_CB00CB6A57454670BE30393824A06D15amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WFlaIGlzIGEgbG90IGNsb3NlciB0byB3aGF0IEnigJltIGRlc2NyaWJpbmcsIGJ1dCBpdCBzdGls bCBjb25mbGF0ZXMg4oCccmVkaXJlY3QgdG8gdGhpcyBVUkwgYWZ0ZXIgdGhlIHdvcmtmbG934oCd IHdpdGgg4oCcc2VuZCB0aGUgcmVzcG9uc2UgdG8gdGhpcyBVUkzigJ0uIEkgKnRoaW5rKiB0aGUg ZHJhZnQgYXMgd3JpdHRlbiB3b3VsZCBhbGxvdyBhIENsaWVudCB0byBwcm92aWRlIGEgY2FsbGJh Y2sgYnV0IGFsc28gcG9sbCBmb3IgdGhlIHJlc3BvbnNlLCBidXQgaXTigJlzIG5vdCB2ZXJ5IGNs ZWFyLiBUaGlzIGtpbmQgb2YgZmxvdyB3aGVyZSB0aGUgQ2xpZW50IGlzIGFjdHVhbGx5IHNwbGl0 IGJldHdlZW4gZGV2aWNlLCBiYWNrZW5kLCBhbmQgd2ViYXBwIHdpdGhpbiBhIHNpbmdsZSB0cmFu c2FjdGlvbiBpcyBvbmUgdGhhdCBkZXNlcnZlcyBtb3JlIGF0dGVudGlvbiwgSU1ITy4NCg0KVGhp cyBub3RlIG9uIGh0dHBzOi8vb2F1dGgueHl6L2ludGVyYWN0aW9uLyBhbHNvIHN1Z2dlc3RzIFhZ WiBpcyBtb3JlIGxpbWl0ZWQgdGhhbiBpdCBuZWVkcyB0byBiZSwgYnV0IHRoZSBkcmFmdCBzZWVt cyB0byBhbGxvdyBmb3IgdGhpcyBhbHJlYWR5IHNvIG1heWJlIHRoaXMgbm90ZSBpcyBqdXN0IGJl IG91dCBvZiBkYXRlPw0KDQpJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBmaWd1cmUgb3V0IGlm IHdlIGNhbiBjb21iaW5lIGJvdGggdGhlIHVzZXIgY29kZSBhbmQgYXJiaXRyYXJ5IHJlZGlyZWN0 IFVSTCBtZXRob2RzLCBnaXZpbmcgdGhlIHVzZXIgYSBmZXcgb3B0aW9ucy4gVGhpcyBzaG91bGQg YmUgYXMgc2ltcGxlIGFzIGFsbG93aW5nIG1vcmUgZmxleGliaWxpdHkgb24gdGhlIGludGVyYWN0 aW9uIHJlcXVlc3QgcG9ydGlvbiBhbmQgaGF2aW5nIHRoZSBzZXJ2ZXIgcmV0dXJuIGFsbCBwb3Nz aWJsZSBvcHRpb25zLg0KDQrigJMNCkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElk ZW50aXR5DQpodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lw0KDQoNCkZyb206IEp1c3Rp biBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkRhdGU6IFNhdHVyZGF5LCBGZWJydWFyeSAxNSwg MjAyMCBhdCAyOjUxIFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFu bmFAYW1hem9uLmNvbT4NCkNjOiAidHhhdXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPg0K U3ViamVjdDogW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogW1R4YXV0aF0gWEF1dGggLTAyDQoNClRo ZSBpbnRlcmFjdGlvbiBtb2RlbCB0aGF0IEFubmFiZWxsZSBkZXNjcmliZXMgYmVsb3cgaXMgZXhh Y3RseSB0aGUga2luZCBvZiB0aGluZyB0aGF04oCZcyBpbiBYWVo6DQoNCmh0dHBzOi8vb2F1dGgu eHl6L2ludGVyYWN0aW9uLw0KDQpBbiBlYXJsaWVyIGltcGxlbWVudGF0aW9uIG9mIFhZWiBoYWQg YSDigJx0eXBl4oCdIGZpZWxkIGxpa2UgWEF1dGggZG9lcy4gWW91IGNhbiBzZWUgdGhhdCBoZXJl Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9u YWwtYXV0aHotMDAjc2VjdGlvbi0yLjQNCg0KV2UgbW92ZWQgYXdheSBmcm9tIGl0IGZvciBhbGwg b2YgdGhlIHJlYXNvbnMgQW5uYWJlbGxlIGlzIGNpdGluZywgYWxvbmcgd2l0aCB0aGUgb3RoZXJz IEnigJl2ZSBzdGF0ZWQgcHJldmlvdXNseSBvbiB0aGUgbGlzdCB0aGF0IEkgZG9u4oCZdCBmZWVs IGJlYXIgcmVwZWF0aW5nIGFnYWluLiBIYXZpbmcgaW1wbGVtZW50ZWQgYm90aCBwYXR0ZXJucyBk aXJlY3RseSBpbiB0aGUgc2FtZSBwcm9qZWN0LCBJIGNhbiBhdHRlc3QgdGhhdCB0aGUgY29kZSBw YXRocyBhcmUgc2lnbmlmaWNhbnRseSBzaW1wbGVyICBmb3IgdGhlIGN1cnJlbnQgWFlaIHBhdHRl cm4sIGVzcGVjaWFsbHkgb24gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiBZb3UgY2FuIGxvb2sg YXQgb3VyIGNvZGUgeW91cnNlbHZlcywgaWYgeW91IGxpa2UuDQoNCkFuZCBmb3IgdGhlIOKAnHNp bXBsZeKAnSBjbGllbnQgY2FzZSB0aGF0IHN1cHBvcnRzIG9ubHkgb25lIHR5cGUgKHdoaWNoIEkg dGhpbmsgd2UgYWxsIGJlbGlldmUgd2lsbCBiZSB0aGUgb3ZlcndoZWxtaW5nbHkgY29tbW9uIGNh c2UpLCBJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIFhZWiBhcHByb2FjaCBhbmQgdGhlIFhB dXRoIGFwcHJvYWNoIGFyZSBmb3IgYWxsIGludGVudHMgYW5kIHB1cnBvc2VzIGlkZW50aWNhbC4g VGhlIFhZWiBhcHByb2FjaCBhbGxvd3MgZm9yIGEgbG90IG1vcmUgZmxleGliaWxpdHkgYWxvbmcg d2l0aCBhIGRlY3JlYXNlIGluIGNvbXBsZXhpdHkuDQoNCiDigJQgSnVzdGluDQoNCg0KDQpPbiBG ZWIgMTQsIDIwMjAsIGF0IDk6MjkgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNo YW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnJpY2hhbm5hPTQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpbcmljaGFubmFdDQpSZXBsaWVzIGlubGlu ZS4NClsvcmljaGFubmFdDQoNCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpDQpBV1Mg SWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvDQoNCg0KRnJvbTogVHhh dXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5v cmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgMTQsIDIwMjAg YXQgOToxMCBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQw YW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBhbWF6b24uY29tQGRt YXJjLmlldGYub3JnPj4NCkNjOiAidHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5v cmc+IiA8dHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtUeGF1dGhdIFhBdXRoIC0wMg0KDQoNCg0KT24gVGh1LCBGZWIgMTMsIDIwMjAgYXQgNjow OCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToN CltyaWNoYW5uYV0NClJlcGxpZXMgaW5saW5lDQpbL3JpY2hhbm5hXQ0KPHNuaXA+DQpbcmljaGFu bmFdDQpCeSB1c2VyIGNvZGUtYmFzZWQgaW50ZXJhY3Rpb24sIEkgbWVhbiB0aGUga2luZCBkZXNj cmliZWQgaW4gdGhlIE9BdXRoIDIuMCBEZXZpY2UgQXV0aG9yaXphdGlvbiBHcmFudDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NjI4Piwgd2hlcmUgdGhlIHVzZXIgcmVjZWl2ZXMgYSBj b2RlIGFuZCBzaG9ydCBVUkwgZnJvbSB0aGUgY2xpZW50LCBuYXZpZ2F0ZXMgdG8gdGhhdCBVUkwg aW4gYSBicm93c2VyLCBhbmQgZW50ZXJzIHRoZSBjb2RlLiBXaGlsZSB0aGlzIGNvdWxkIGJlIHBh Y2tlZCBpbnRvIGludGVyYWN0aW9uLm1lc3NhZ2UsIHRoaXMgd2lsbCBsZWFkIHRvIGNsdW5raWVy IHVzZXIgZXhwZXJpZW5jZXM6DQoNCjEuICAgVGhlIEdTIG1heSBub3QgYmUgYWJsZSB0byBwcm92 aWRlIGxvY2FsaXplZCBpbnN0cnVjdGlvbnMgdGhhdCBtYXRjaCB0aGUgbG9jYWxlIG9uIHRoZSBD bGllbnQuDQoNCjIuICAgU3VwcG9zZSB0aGUgR1Mgc2VuZHMgYSBtZXNzYWdlIHRoYXQgcmVhZHM6 IOKAnFNjYW4gdGhlIFFSIGNvZGUgb3Igb3BlbiBhIGJyb3dzZXIgdG8gaHR0cDovL2NvZGUuZXhh bXBsZS8gYW5kIGVudGVyIHRoZSBjb2RlOiAxMjM0NS7igJ0NCg0KYS4gICAgVGhhdCBpbnN0cnVj dGlvbiBkb2VzIG5vdCBtYWtlIHNlbnNlIG9uIGEgZGV2aWNlIHRoYXQgZG9lcyBub3QgcHJlc2Vu dCBhIFFSIGNvZGUuIEltYWdpbmUgaGVhcmluZyB0aGF0IGZyb20gYSBzbWFydCBzcGVha2VyLg0K DQpiLiAgIFRoYXQgaW5zdHJ1Y3Rpb24gaXMgY29uZnVzaW5nbHkgcmVkdW5kYW50IGlmIHRoZSBD bGllbnQgZGlzcGxheXMgdGhlIFFSIGNvZGUgYWxvbmcgd2l0aCBpdHMgb3duIGluc3RydWN0aW9u cywgbGlrZTog4oCcU2NhbiB0aGUgUVIgY29kZSBvciBmb2xsb3cgdGhlIGluc3RydWN0aW9ucyBi ZWxvdy7igJ0NCg0KMy4gICBXaWxsIOKAnGVtYmVkIHRoZSBzaG9ydCBVUkwgYW5kIGNvZGUgaW4g dGhlIG1lc3NhZ2Ugc3RyaW5n4oCdIGJlIE1UST8gSWYgbm90LCB0ZXh0LW9ubHkgY2xpZW50cyB3 b3VsZCBoYXZlIGEgYnJva2VuIGV4cGVyaWVuY2UuDQpbL3JpY2hhbm5hXQ0KDQpTb3VuZHMgbGlr ZSBhIHRleHQgb25seSBpbnRlcmFjdGlvbiB0eXBlIHNob3VsZCBiZSBhZGRlZCBwZXIgbXkgbm90 ZSBpbiB0aGUgZHJhZnQuIFBlcmhhcHMgZXZlbiBvbmUgdGhhdCBpcyBmb2N1c2VkIG9uIHRoZSBj b2RlIGZsb3csIHdoZXJlIHRoZSBwYXJhbWV0ZXJzIGFyZSB0aGUgY29kZSBhbmQgdGhlIFVSSSB0 byBlbnRlciB0aGUgY29kZSwgbGV0dGluZyB0aGUgQ2xpZW50IHByZXNlbnQgdGhlIHBhcmFtZXRl cnMgd2l0aCBsb2NhbGl6ZWQgY29udGVudD8NCg0KW3JpY2hhbm5hXQ0KSSB0aGluayB3ZeKAmXJl IGFwcHJvYWNoaW5nIHRoZSDigJxpbnRlcmFjdGlvbuKAnSBjb25jZXB0IHdyb25nLiBXZeKAmXJl IGNvbmZsYXRpbmcgdGhyZWUgZGlmZmVyZW50IHRoaW5ncyB0b2dldGhlcjoNCg0KwrcgICAgICAg ICBXaGF0IGRvZXMgdGhlIENsaWVudCBuZWVkIHRvIHNlbmQgdGhlIGVuZCB1c2VyIHRvIHRoZSBH Uz8NCg0KbyAgICBBIGh1bWFuLWZyaWVuZGx5IHNob3J0IFVSTCBhbmQgY29kZS4NCg0KbyAgICBB bnkga2luZCBvZiBVUkwsIGFzIGxvbmcgYW5kIHVnbHkgYXMgaXQgbmVlZHMgdG8gYmUuDQoNCsK3 ICAgICAgICAgSG93IHdpbGwgdGhlIENsaWVudCByZWNlaXZlIHRoZSByZXNwb25zZSBmcm9tIHRo ZSBHUz8NCg0KbyAgICBDbGllbnQgd2lsbCBtYWtlIGEgcmVxdWVzdCB0byB0aGUgR1MuDQoNCm8g ICAgR1Mgd2lsbCBtYWtlIGEgcmVxdWVzdCB0byB0aGUgQ2xpZW50LiAoSeKAmXZlIGhhZCB0byBp bXBsZW1lbnQgdGhpcyBmb3IgYSBjdXN0b20gaW50ZWdyYXRpb24sIGluY2x1ZGluZyBpdCB0byBk ZW1vbnN0cmF0ZSB0aGF0IG90aGVyIG9wdGlvbnMgZXhpc3QpDQoNCsK3ICAgICAgICAgV2lsbCB0 aGUgR1MgcmV0dXJuIHRoZSBlbmQgdXNlciB0byB0aGUgQ2xpZW50LCBhbmQgaWYgc28gaG93Pw0K DQpvICAgIFllcywgYnkgVVJMIHJlZGlyZWN0Lg0KDQpvICAgIE5vLg0KDQpIZXJlIGlzIGEgdmVy eSBub24tbm9ybWF0aXZlIGV4YW1wbGUgcmVxdWVzdCBmcmFnbWVudCwgZm9yIGEgY2xpZW50IHRo YXQgd2FudHMgYm90aCBhIHNob3J0IFVSTCBwbHVzIGNvZGUgYW5kIGEgZnVsbCBVUkwgc28gdGhl eSBjYW4gb3Bwb3J0dW5pc3RpY2FsbHkgdXNlIG9uZSBvciB0aGUgb3RoZXIgKEFXUyBDTEkgdjIg ZG9lcyB0aGlzKSwgd2lsbCBxdWVyeSB0aGUgR1MgZm9yIHRoZSByZXNwb25zZSwgYW5kIHdhbnRz IHRoZSBHUyB0byByZWRpcmVjdCB0byBhIHB1YmxpY2x5IGFjY2Vzc2libGUgVVJMIG9uIHRoZSBD bGllbnTigJlzIHdlYnNpdGUgYWZ0ZXIgdGhlIGZsb3cgKGUuZy4sIHRvIHNob3cgZnVydGhlciBk b2N1bWVudGF0aW9uL2JyYW5kZWQgY29udGVudCB0byB0aGUgZW5kIHVzZXIpOg0Kew0KImludGVy YWN0Ijogew0KICAiY29kZSI6IHsgIm1heCI6IDggfSwNCiAgInVybCI6IHRydWUNCn0sDQoicmVz cG9uc2UiOiB7DQogICJwb2xsIjogdHJ1ZQ0KfSwNCiJyZXR1cm4iOiB7DQogICJ1cmwiOiAiaHR0 cHM6Ly9oZWxwLnNtYXJ0ZGV2aWNlLmV4YW1wbGUvcG9zdC1zZXR1cCINCn0NCn0NCg0KQW5kIGhl cmUgaXMgYW4gZXF1YWxseSBub24tbm9ybWF0aXZlIGV4YW1wbGUgcmVzcG9uc2UgZnJhZ21lbnQ6 DQp7DQoiaW50ZXJhY3QiOiB7DQogICJjb2RlIjogIjEyMzQ1NiIsDQogICJjb2RlX3VybCI6ICJo dHRwczovL2dzLmV4YW1wbGUvY29kZSIsDQogICJ1cmwiOiAiaHR0cHM6Ly9ncy5leGFtcGxlL3hh dXRoLzEyMzQzNTY3ODkwYWJjZGVmMTIzNDU2Nzg5MGFiY2RlZiINCn0NCn0NCg0KKFNlcmlvdXNs eSBkbyBub3QgcmVhZCB0b28gbXVjaCBpbnRvIHRoZXNlIHBhcmFtZXRlciBuYW1lcyBvciBzeW50 YXgsIHRoaXMgaXMganVzdCB0byBnaXZlIGEgcm91Z2ggc2Vuc2Ugb2YgaG93IEnigJltIHRoaW5r aW5nIGFib3V0IHRoaXMuIEFueW9uZSB3aG8gdHJpZXMgdG8gcGljayBhcGFydCB0aGlzIGV4YW1w bGUgd2lsbCBiZSByZXNwb25kZWQgdG8gd2l0aCBtb2NraW5nIG1lbWVzLikNClsvcmljaGFubmFd DQoNCg0KMi4gICBDbGllbnRzIHN1cHBvcnQgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZXMgYW5k IG1heSBub3QgYWx3YXlzIGtub3cgd2hhdCB0aGUgR1Mgc3VwcG9ydHMgKGFuZCB2aWNlLXZlcnNh KS4gRm9yIGEgbXVsdGktdGVuYW50IEdTLCBpdCBtYXkgdmFyeSBieSB0ZW5hbnQgY29uZmlndXJh dGlvbi4gQ2xpZW50cyBzaG91bGQgYmUgYWJsZSB0byBzYXkgd2hhdCB0aGV5IGNhbiBkbywgYW5k IHRoZSBHUyBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIHRoZW0gd2hpY2ggb25lIHRvIHVzZS4gSXTi gJlzIGEgdmVyeSBzaW1wbGUgYnV0IHBvd2VyZnVsIGlubGluZSBuZWdvdGlhdGlvbi4NCg0KVGhh dCBpcyB3aGF0IGlzIGluIFR4QXV0aC4gV291bGQgeW91IGVsYWJvcmF0ZSBvbiBob3cgdGhlIEdT IG1pZ2h0IGJlIGNvbnN0cmFpbmVkPyBXaHkgd291bGQgdGhlIEdTIG5vdCBiZSBhYmxlIHRvIGRv IGFsbD8NCg0KSSB3b3VsZCB0aGluayBhbGwgY29uc3RyYWludHMgd291bGQgYmUgYXQgdGhlIENs aWVudC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KW3JpY2hhbm5hXQ0KQ2xpZW50cyBtYXkg c3VwcG9ydCBjdXN0b21lci1kZWZpbmVkIEdTZXMgKGUuZy4sIGVudGVycHJpc2UgSWRQcyksIHdo aWNoIHdpbGwgdmFyeSBpbiB0ZXJtcyBvZiB3aGljaCBpbnRlcmFjdGlvbiBtb2RlcyB0aGV5IHN1 cHBvcnQuIFdoaWxlIHRoZSBzZXQgb2YgaW50ZXJhY3Rpb25zIGRlZmluZWQgaW4gWEF1dGggbWln aHQgYWxsIGJlIE1USSBmb3IgYSBHUywgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IGV4dGVuc2lvbnMg d2lsbCBpbnRyb2R1Y2UgbmV3IGludGVyYWN0aW9ucyB3aGljaCB3aWxsIG5vdCBiZSB1bml2ZXJz YWxseSBzdXBwb3J0ZWQuIEFuIGludGVyYWN0aW9uIG1lY2hhbmlzbSBtaWdodCBoYXZlIHByb3Bl cnRpZXMgdGhhdCBjYXVzZSBzb21lIGFkbWluaXN0cmF0b3JzIHRvIHdhbnQgdG8gZGlzYWJsZSBp dCwgb3IgdG8gcmVzdHJpY3QgQ2xpZW50cyB0byBhbHdheXMgdXNlIGl0LiBBcmUgeW91IGFzc3Vt aW5nIHRoYXQgYSBDbGllbnQgd2lsbCBhbHdheXMgbWFrZSBhbiBPUFRJT05TIGRpc2NvdmVyeSBy ZXF1ZXN0IGZpcnN0Pw0KWy9yaWNoYW5uYV0NCg0KQW4gZXhhbXBsZSBvZiB3aHkgYSBnaXZlbiBH UyBtYXkgbm90IHN1cHBvcnQgYSBtb2RlIHdvdWxkIGJlIGhlbHBmdWwuDQoNCkkgd2FzIGVudmlz aW9uaW5nIHRoYXQgaWYgYW4gb3B0aW9uYWwgdG8gc3VwcG9ydCBpbnRlcmFjdGlvbiBtb2RlIHdh cyBub3Qgc3VwcG9ydGVkIGF0IHRoZSBHUywgdGhhdCBpdCB3b3VsZCByZXR1cm4gYW4gZXJyb3Iu IFRoZSBDbGllbnQgd291bGQgdGhlbiB0cnkgYSBkaWZmZXJlbnQgb25lLiBBbHRlcm5hdGl2ZWx5 LCB0aGUgQ2xpZW50IGNvdWxkIHN0YXJ0IHdpdGggYW4gT1BUSU9OUyBjYWxsIGluIGNhc2VzIHdo ZXJlIHRoZSBHUyBpcyBkeW5hbWljbHkgY2hvc2VuLg0KDQpbcmljaGFubmFdDQpMb3RzIG9mIEFT ZXMgZG9u4oCZdCBzdXBwb3J0IERldmljZSBBdXRob3JpemF0aW9uIEdyYW50LiBJIHRoaW5rIGl0 4oCZcyBzYWZlIHRvIGFzc3VtZSB0aGF0IGludGVyYWN0aW9uIG1vZGUgc3VwcG9ydCB3aWxsIHZh cnkgZm9yIFhBdXRoIGFzIHdlbGwuIOKAnEtlZXAgdHJ5aW5nIHVudGlsIHlvdSBmaW5kIG9uZSB0 aGF0IHdvcmtz4oCdIHNvdW5kcyBwcmV0dHkgcGFpbmZ1bCBmb3IgdGhlIGNsaWVudCwgYW5kIGRv ZXNu4oCZdCBhbGxvdyB0aGUgY2xpZW50IHRvIHVzZSBtdWx0aXBsZSBpbnRlcmFjdGlvbiBtb2Rl cywgYXMgZGVtb25zdHJhdGVkIGluIG15IGV4YW1wbGUgYWJvdmUuDQoNClRoZXJlIGFyZSBsb3Rz IG9mIHJlYXNvbnMgZm9yIHdhbnRpbmcgdG8gc3VwcG9ydCBtdWx0aXBsZSBtb2RlczoNCg0Kwrcg ICAgICAgICBTb21lIHBlb3BsZSBhcmUgY29tZm9ydGFibGUgd2l0aCBRUiBjb2Rlcywgc29tZSBh cmVu4oCZdC4NCg0KwrcgICAgICAgICBTb21lIHBlb3BsZSBoYXZlIHNtYXJ0IHBob25lcyB0aGF0 IGNhbiBzY2FuIHRoZW0sIHNvbWUgZG9u4oCZdC4NCg0KwrcgICAgICAgICBQZW9wbGUgd2l0aCBz bWFydCBwaG9uZXMgbWF5IHdhbnQgdG8gZ28gdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gZmxv dyBvbiB0aGVpciBkZXNrdG9wIGluc3RlYWQuDQoNCsK3ICAgICAgICAgU29tZSBwZW9wbGUgbWF5 IGhhdmUgdG8gZ28gdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gZmxvdyBvbiB0aGVpciBkZXNr dG9wLCBiZWNhdXNlIHRoZSBHUyB0aGlua3MgaVBob25lcyBvbmx5IHN1cHBvcnQgQmx1ZXRvb3Ro LWJhc2VkIHNlY3VyaXR5IGtleXMgYW5kIGluc2lzdHMgdGhleSBjYW5ub3QgY29tcGxldGUgdGhl IGxvZ2luIGZsb3cgZXZlbiB0aG91Z2ggdGhleSBoYXZlIHR3byBZdWJpS2V5IDVDaSBrZXlzIG9u IHRoZWlyIGFjY291bnQuIChISSwgR09PR0xFIEFDQ09VTlQgUFJPVEVDVElPTiBQUk9HUkFNKQ0K Wy9yaWNoYW5uYV0NCg0KMy4gICBJIGRvbuKAmXQgc2VlIHRoZSB2YWx1ZSBvZiB0aGUg4oCccG9w dXDigJ0gaW50ZXJhY3Rpb24gbW9kZS4gQ2xpZW50cyBjYW4gdXNlIOKAnHJlZGlyZWN04oCdIG1v ZGUgd2l0aGluIHBvcHVwcy4gSG93ZXZlciwgc3BlYWtpbmcgYXMgc29tZW9uZSB3aG8gaGFzIGRv bmUgdGhhdCwgSSByZWFsbHkgZG9u4oCZdCByZWNvbW1lbmQgaXQuIFBvcHVwcyBhcmUgaW5jcmVh c2luZ2x5IHVuc3VwcG9ydGVkLCBhbmQgcHJvbmUgdG8gd2VpcmQgYmVoYXZpb3JhbCBpc3N1ZXMu IEluLWFwcCBicm93c2VycyBpbiBGYWNlYm9vaywgVHdpdHRlciwgZXRjLiB0ZW5kIHRvIGhhdmUg cG9wdXBzIGRpc2FibGVkLiBUaGUgbGFzdCB2ZXJzaW9ucyBvZiBJRSBNb2JpbGUgZGlkbuKAmXQg c3VwcG9ydCB0aGVtIGF0IGFsbCAodGhlIHBvcHBlZCB1cCBwYWdlIGJhc2ljYWxseSBqdXN0IGxv YWRlZCBpbnRvIHRoZSBjdXJyZW50IHdpbmRvdykuLiBpbg0KDQpQb3B1cHMgYXJlIHJlYWxseSB1 c2VmdWwgaW4gc2luZ2xlLXBhZ2UgYXBwcyBhcyB5b3Ugd2FudCB0byBrZWVwIHRoZSBjb250ZXh0 IGFuZCBub3QgcmVsb2FkIHRoZSBwYWdlLg0KDQpBZ3JlZSB0aGF0IHBvcHVwcyBkb24ndCBtYWtl IHNlbnNlIGluIG1vYmlsZS4gQSBmdWxsIHJlZGlyZWN0IGRvZXMgb2YgY291cnNlLiBBIHNpbmds ZS1wYWdlIGFwcCBvbiBtb2JpbGUgd291bGQgb3BlbiBhIG5ldyB0YWIgd2hpY2ggd291bGQgYmUg YSBzZXBhcmF0ZSBjb250ZXh0IHJhdGhlciB0aGFuIGEgcmVkaXJlY3QuDQoNCltyaWNoYW5uYV0N ClBvcHVwcyBhcmUgYnJva2VuIGFuZC9vciBkaXNhYmxlZCBpbiBlbm91Z2ggaW5zdGFuY2VzIHRo YXQgd2Ugc2hvdWxkIG5vdCBlbmNvdXJhZ2UgdGhlaXIgdXNhZ2UgYnkgaW5jbHVkaW5nIGV4cGxp Y2l0IHN1cHBvcnQgZm9yIHRoZW0gaW4gdGhlIHByb3RvY29sLiBOb3IgYXJlIHRoZXkgbmVjZXNz YXJ5IGZvciBTUEFzIGluIG9yZGVyIHRvIHJlc3RvcmUgdGhlIHN0YXRlIG9mIHRoZWlyIGFwcCBh ZnRlciB0aGUgcmVkaXJlY3QuDQoNCkFyZSB0aGV5IHJlYWxseSB0aGF0IGJyb2tlbiBpbiBkZXNr dG9wPyBJJ3ZlIHVzZWQgdGhlbSBleHRlbnNpdmVseSBteXNlbGYgaW4gdGhlIHBhc3QgYXMgaXQg d2FzIGEgYmV0dGVyIHVzZXIgZXhwZXJpZW5jZSwgYnV0IHRoYXQgd2FzIGEgZmV3IHllYXJzIGFn by4NCg0KW3JpY2hhbm5hXQ0KUG9wdXAgYmxvY2tlcnMgYXJlIGJ1aWx0IGluIGFuZCBhZ2dyZXNz aXZlbHkgZW5hYmxlZCBieSBkZWZhdWx0IG9uIGFsbCBtYWpvciBicm93c2Vycy4gQ29tbXVuaWNh dGluZyBzZWN1cmVseSBiZXR3ZWVuIHdpbmRvd3MgaXMgbm90IGVhc3ksIGFuZCBmcm9tIHBhc3Qg ZXhwZXJpZW5jZSBwcm9uZSB0byBmYWlsdXJlIHRoYW5rcyB0byB3ZWlyZCBicm93c2VyIGJ1Z3Mu IFRydXN0ZWQgU2l0ZSBzZXR0aW5ncyBpbiBJRSBhbmQgRWRnZSBjYW4gYmxvdyB0aGUgd2hvbGUg dGhpbmcgdXAgaW4gd2VpcmQgd2F5cyAoc3BlYWtpbmcgYWdhaW4gZnJvbSBleHBlcmllbmNlKS4N Cg0KQWxzbywgaXTigJlzIDIwMjAuIFN0b3AgYnJhbmNoaW5nIG9uIG1vYmlsZSB2cy4gZGVza3Rv cC4gSSBnZXQgdGhhdCBsb3RzIG9mIHBlb3BsZSBzdGlsbCBkbyB0aGF0LCBidXQgdGhhdCBkb2Vz buKAmXQgbWVhbiB0aGUgcHJvdG9jb2wgc2hvdWxkIGNhdGVyIHRvIGl0Lg0KWy9yaWNoYW5uYV0N CkFuZCBhZ2FpbiwgYSBDbGllbnQgdGhhdCByZWFsbHkgd2FudHMgdG8gZ2l2ZSB0aGVtc2VsdmVz IGEgaGVhZGFjaGUgd2l0aCBwb3B1cHMgY2FuIGRvIHRoYXQgdGhlbXNlbHZlcyB1c2luZyDigJxy ZWRpcmVjdOKAnSBtb2RlLiBUaGV5IGp1c3QgaGF2ZSB0byBwcm92aWRlIGEgbGFuZGluZyBwYWdl IGZvciB0aGUgR1MgdG8gcmVkaXJlY3QgYmFjayB0byB0aGF0IHBhcnNlcyB0aGUgcmVzcG9uc2Us IHBhc3NlcyBpdCBiYWNrIHRvIHRoZSBtYWluIHdpbmRvdywgYW5kIGNsb3NlcyBpdHNlbGYuIEkg ZG9u4oCZdCBzZWUgd2h5IHRoZSBwcm90b2NvbCB3b3VsZCBuZWVkIHRvIGV4cGxpY2l0bHkgZGVz Y3JpYmUgdGhpcyBtZWNoYW5pc20uDQpbL3JpY2hhbm5hXQ0KDQpJIHRoaW5rIGl0IGlzIGEgdXNl ZnVsIHNpZ25hbCBmb3IgdGhlIEdTIGluIHRoZSBleHBlcmllbmNlIGl0IHdhbnRzIHRvIHNob3cg dGhlIHVzZXIuDQoNCltyaWNoYW5uYV0NClVzZWZ1bCBob3c/IFRoZSB3aW5kb3cgZGltZW5zaW9u cyBhcmUgYSBiZXR0ZXIgc2lnbmFsIGZvciBob3cgdG8gcHJlc2VudCB0aGUgdXNlciBleHBlcmll bmNlLiAoKmNvdWdoKiByZXNwb25zaXZlIGRlc2lnbiAqY291Z2gqKQ0KWy9yaWNoYW5uYV0NCg0K U2VjdGlvbiAxMi42Og0KDQogICAgICAgIFtFZGl0b3I6IGlzIHRoZXJlIHNvbWUgb3RoZXIgcmVh c29uIHRvIGhhdmUgdGhlIFVzZXJJbmZvDQoNCiAgICAgICAgZW5kcG9pbnQ/XQ0KDQpJIG1heSB3 YW50IHRvIGhvc3QgbXkgVXNlckluZm8gZW5kcG9pbnQgb24gYSBzZXBhcmF0ZSBtaWNyb3NlcnZp Y2UgZnJvbSBteSB0b2tlbiBlbmRwb2ludCAoaW4gT0F1dGggMi4wL09JREMgdGVybXMpLiBUaGUg Zm9ybWVyIG1pZ2h0IGJlIHBhcnQgb2YgbXkgdXNlciBwcm9maWxlL2RpcmVjdG9yeSBzdGFjaywg d2hpbGUgdGhlIGxhdHRlciBpcyBwYXJ0IG9mIHRoZSBoaWdobHkgcHJpdmlsZWdlZCBhdXRoZW50 aWNhdGlvbi9hdXRob3JpemF0aW9uIHN0YWNrLg0KDQoNClRoZSB0b2tlbiBlbmRwb2ludCBoYXMg dGhlIGFjY2VzcyB0b2tlbiBhbnl3YXksIHNvIGl0IGNhbiBmZXRjaCB0aGUgZGF0YSBmcm9tIHRo ZSBvdGhlciBlbmRwb2ludCBpdHNlbGYgaWYgaXQgd2FudGVkIHRvLiBJRSwgdGhlcmUgaXMgbm8g c2VwYXJhdGlvbiBvZiBkdXRpZXMuDQoNCldoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBV c2VySW5mbyBlbmRwb2ludCB0byB0aGUgVXNlciBvciBDbGllbnQ/DQoNClRoZSBVc2VySW5mbyBl bmRwb2ludCBzZWVtcyB0byBqdXN0IGFkZCBtb3JlIGNvbXBsZXhpdHksIHdpdGggbm8gYWJpbGl0 eSB0byBzdGFydCBhIFVzZXIgaW50ZXJhY3Rpb24gaWYgYWRkaXRpb25hbCBjb25zZW50IGlzIG5l ZWRlZC4NCg0KW3JpY2hhbm5hXQ0KSWYgdGhlIGFjY2VzcyB0b2tlbiBpcyBzZW5kZXItY29uc3Ry YWluZWQsIHRoZW4gbm8sIHRoZSB0b2tlbiBlbmRwb2ludCBjYW7igJl0IGZldGNoIHRoZSBkYXRh IGl0c2VsZi4gQnV0IGV2ZW4gd2l0aG91dCB0aGUgc2VjdXJpdHkgYW5nbGUsIHRoZXJlIGlzIHZh bHVlIGluIHNlcGFyYXRpbmcgb3V0IHRoZSBmdW5jdGlvbmFsaXR5IGFzIGl0IGFsbG93cyB0aGUg R1MgdG8gZGlzdHJpYnV0ZSBpdCBhY3Jvc3Mgc3lzdGVtcyB3aXRoIGRpZmZlcmVudCBvd25lcnMu IEUuZy4sIHRoZXJlIG1pZ2h0IGJlIGEgZGlyZWN0b3J5IEFQSSB0ZWFtIHRoYXQgYWxzbyBvd25z IHRoZSBTQ0lNIGludGVyZmFjZSBhbmQgVXNlckluZm8gZW5kcG9pbnQuDQoNCkFuIGltcGxlbWVu dGF0aW9uIGNhbiBhbHNvIHJvdXRlIGNhbGxzIHRvIGRpZmZlcmVudCBpbnRlcm5hbCBzeXN0ZW1z IHdoaWxlIGtlZXBpbmcgdGhlIHNhbWUgZW5kcG9pbnQuDQoNCkkgYWxzbyB0aGluayBvZiBTQ2lN IGFuZCBVc2VySW5mbyBhcyB2ZXJ5IGRpZmZlcmVudCBlbmRwb2ludHMuIEkgd291bGQgY29uc2lk ZXIgU0NJTSBhIHJlc291cmNlLCBhbmQgVXNlckluZm8gY2xhaW1zLiBJIGFwcHJlY2lhdGUgdGhv c2UgYXJlIHNpbWlsYXIgaW4gZW50ZXJwcmlzZSwgYnV0IHRoZXkgYXJlIG5vdCBpbiBjb25zdW1l ciBjb250ZXh0cy4NCg0KW3JpY2hhbm5hXQ0KUm91dGluZyBjYWxscyB0byBkaWZmZXJlbnQgaW50 ZXJuYWwgc3lzdGVtcyBzdGlsbCBtZWFucyBJIGhhdmUgdG8gaGF2ZSBzb21lIHNoYXJlZCBpbmZy YXN0cnVjdHVyZSB0aGF0IGJvdGggdGVhbXMgbWFuYWdlLiBJdOKAmXMgbW9yZSBjb21wbGV4IHRo YW4gaXQgbmVlZHMgdG8gYmUuDQoNCknigJltIGdvaW5nIHRvIHN1Z2dlc3Qgd2UgbW92ZSB0aGlz IHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gdG8gYSBzZXBhcmF0ZSB0aHJlYWQgYmVjYXVzZSBpdOKA mXMgdG9vIG1lc3N5IHRvIGtlZXAgaW4gdGhpcyBhd2Z1bCBiYWNrLWFuZC1mb3J0aC4gSeKAmWxs IGp1c3QgYWRkIGhlcmUgdGhhdCBJ4oCZbSBub3Qgc3VnZ2VzdGluZyB3ZSBvbmx5IGhhdmUgYSBV c2VySW5mbyBlbmRwb2ludC4gSeKAmW0gYXJndWluZyB0d28gdGhpbmdzOg0KDQoxLiAgICAgICBU aGUgVXNlckluZm8gZW5kcG9pbnQgaXMgZ29vZCwgYWN0dWFsbHkuIEl0IGRvZXNu4oCZdCBuZWVk IHRvIGJlIE1USSwgYnV0IHdlIHNob3VsZCBub3QgcHJlY2x1ZGUgaXRzIGV4aXN0ZW5jZS4NCg0K Mi4gICAgICAgSWYgd2UgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgcmVxdWVzdGluZyBhbmQgcmVj ZWl2aW5nIGNsYWltcyBpbiB0aGUgR1MgUmVhZCBHcmFudCByZXNwb25zZSwgdGhhdCBtZWNoYW5p c20gc2hvdWxkIGFwcGx5IGdlbmVyaWNhbGx5IHRvIGFyYml0cmFyeSByZXNvdXJjZXMuIEdTZXMg Y2FuIHN1cHBvcnQgaXQgb3Igbm90LCBmb3IgYW55IGdpdmVuIHJlc291cmNlLg0KWy9yaWNoYW5u YV0NCg0KPHNuaXA+DQpbcmljaGFubmFdDQpUaGVyZSBhcmUgdHdvIGJpZyBkaWZmZXJlbmNlcyBi ZXR3ZWVuIHRob3NlIGV4YW1wbGVzIChlLmcuLCBRUiBDb2RlLCBhcHAtYmFzZWQgbG9naW4gYXBw cm92YWxzKSBhbmQgdGhpcyBtZWNoYW5pc20gaW4gWEF1dGg6DQoNCjEuICAgSW4geW91ciBleGFt cGxlcyBvZiB0aGlzIGJlaGF2aW9yIHRvZGF5LCB0aGUgcmVhc29uIGZvciB0aGUgd2FpdCBpcyBj bGVhciBhbmQgb2J2aW91cywgYW5kIGRyaXZlbiBieSB0aGUgdXNlci4gRS5nLiwgbXkgcHJpbnRl ciBpcyB3YWl0aW5nIGZvciBtZSB0byBnbyBlbnRlciB0aGlzIGNvZGUgYW5kIGxvZyBpbjsgR29v Z2xlIHNpZ24gaW4gaXMgd2FpdGluZyBmb3IgbWUgdG8gdGFwIHRoaXMgYnV0dG9uIG9uIG15IHBo b25lLiBUaGF0IGlzIG5vdCB0aGUgY2FzZSBpbiB0aGUgWEF1dGggcHJvdG9jb2wuIFRoZSB1c2Vy IGlzIGxlZnQgc2l0dGluZyBvbiBhIGxvYWRpbmcgc2NyZWVuIHdhaXRpbmcgZm9yIGEgYmVoaW5k LXRoZS1zY2VuZXMgaW50ZXJhY3Rpb24gYmV0d2VlbiBjbGllbnQgYW5kIEdTIHRoYXQgbWF5IG5v dCBldmVuIGhhcHBlbi4NCg0KMi4gICBVbmxpa2Ugd2l0aCBjb2RlL1FSIGZsb3dzIG9yIHNpZ24t aW4gdmVyaWZpY2F0aW9uLCB0aGVyZSBpcyBubyBhY3RpdmUgcHJvY2VzcyBvbiB0aGUgY2xpZW50 IHNpZGUgdG8ga2VlcCB0aGlzIGFzeW5jIHJlcXVlc3Qgb3Blbi4gQSB3ZWIgYXBwIGNsaWVudCB3 b3VsZCBoYXZlIHRvIGludHJvZHVjZSBhIHNlcnZlci1zaWRlIGFzeW5jIHByb2Nlc3MgdG8gbWFu YWdlIHRoaXMgYXNwZWN0IG9mIHRoZSBwcm90b2NvbC4gVGhhdOKAmXMgbm90IGVhc3kuDQoNCjMu ICAgVGhlIGZhaWx1cmUgbW9kZXMgc2hvdyB1cCBpbiBtb3JlIGFwcHJvcHJpYXRlIGNvbnRleHRz LCB3aGVyZSB0aGVyZSBhcmUgY2xlYXIgcGF0aHMgZm9yd2FyZCBmb3IgdGhlIGVuZCB1c2VyLiBJ biBjb2RlL1FSLWJhc2VkIGZsb3dzLCBpdOKAmXMgZGV0ZWN0ZWQgb24gdGhlIGNsaWVudCBzaWRl LCBpbiB0aGUgZm9ybSBvZiBhbiBBUyB0aGF0IG5ldmVyIHByb3ZpZGVzIGEgcmVzcG9uc2UuIElu IHRoYXQgc2NlbmFyaW8sIHRoZSBjbGllbnQgY2FuIHJldHJ5IHRoZSBwcm9jZXNzLiBJbiBzaWdu LWluIHZlcmlmaWNhdGlvbiwgdGhlIHByb2JsZW0gb2NjdXJzIGJldHdlZW4gdHdvIHBhcnRzIG9m IHRoZSBBUywgYW5kIHRoZSBBUyBjYW4gYWxsb3cgdGhlIGVuZCB1c2VyIHRvIHJldHJ5IG9yIHRv IHVzZSBhIGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QuIEluIHRoZSBYQXV0aCBDcmVh dGUrVXBkYXRlIHNjZW5hcmlvLCB0aGUgZmFpbHVyZSBpcyBkZXRlY3RlZCBvbiB0aGUgR1MsIGFu ZCB0aGVyZSBpcyBubyBjbGVhciBwYXRoIGZvcndhcmQuIElmIHRoZSBDbGllbnQgbmV2ZXIgY2Fs bHMgVXBkYXRlIEdyYW50IHRvIGZsaXAgaW50ZXJhY3Rpb24ua2VlcCB0byBmYWxzZSwgd2hhdCBz aG91bGQgdGhlIEdTIGRvPyBIb3cgbG9uZyBzaG91bGQgaXQgd2FpdD8gU2hvdWxkIGl0IGlzc3Vl IHRoZSBhdXRob3JpemF0aW9uIGFueXdheSwgYXNzdW1pbmcgdGhlIENsaWVudCB3aWxsIGNvbWUg YmFjayBhbmQgYXNrIGZvciBpdCBhdCBzb21lIHBvaW50PyBTaG91bGQgaXQgcmVkaXJlY3QgdGhl IGVuZCB1c2VyIGJhY2sgdG8gdGhlIENsaWVudCBhbnl3YXksIG9yIGRyb3AgdGhlbSBvbiBhIGxh bmRpbmcgcGFnZT8gU2hvdWxkIGl0IGZsYWcgdGhpcyBhcyBhbiBlcnJvciwgb3IgaXMgdGhpcyB0 aGUgZXhwZWN0ZWQgYmVoYXZpb3IgZm9yIHRoZSBDbGllbnQ/DQoNCkkgcmVhbGx5IHRoaW5rIHRo aXMgaXMgb3ZlcmNvbXBsaWNhdGluZyB0aGUgcHJvdG9jb2wgdG8gYW4gZXh0ZW50IHRoYXQgbm8g b25lIHdpbGwgYWN0dWFsbHkgaW1wbGVtZW50IGl0Lg0KWy9yaWNoYW5uYV0NCg0KVGhlIGZsb3cg aW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29s LTAyI3NlY3Rpb24tMy4xIGlzIEVYQUNUTFkgdGhlIHNhbWUgYXMgdGhlIEdvb2dsZSBhbmQgTWlj cm9zb2Z0IGZsb3dzLg0KDQpXaGlsZSB0aGUgZmxvdyBpbiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDIjc2VjdGlvbi0zLjQgaGFzIGFkZGl0 aW9uYWwgc3RlcHMsIGl0IGlzIG5vdCBmdW5kYW1lbnRhbGx5IGFueSBkaWZmZXJlbnQgZXhjZXB0 IHRoZSBDbGllbnQgaXMgbWFraW5nIGFub3RoZXIgY2FsbCB0byB0aGUgR1MgYWZ0ZXIgdGhlIGZp cnN0IG9uZSByZXR1cm5zLiBUaGUgcmlzayBvZiB0aGUgQ2xpZW50IG5vdCBtYWtpbmcgdGhlIHNl Y29uZCBjYWxsIGFuZCBsZWF2aW5nIHRoZSBVc2VyIGhhbmdpbmcgaXMgbm90IHJlYWxseSBhbnkg ZGlmZmVyZW50IG9mIHRoZSBDbGllbnQgbm90IG1ha2luZyB0aGUgZmlyc3QgY2FsbC4NCg0KQmVz aWRlcyB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBtb2JpbGUgZGV2aWNlIHRoYXQgTUFZIG5vdCBi ZSBhYmxlIHRvIG1ha2UgdGhlIHNlY29uZCBjYWxsIG1pZ2h0IHB1dCB0byBzbGVlcCwgSSBkb24n dCBzZWUgYW55IGltcGxlbWVudGF0aW9uIGlzc3Vlcy4gVHhBdXRoIHdvcmtzIHRoZSBzYW1lIHdh eSBhcyAzLjEgYXMgSSB1bmRlcnN0YW5kIGl0IGZvciBub24tcmVkaXJlY3QgZmxvd3MuDQoNClty aWNoYW5uYV0NCkkgZG9u4oCZdCB0aGluayB5b3UgYWN0dWFsbHkgcmVhZCB3aGF0IEkgd3JvdGUu IElmIHRoZSBmbG93cyBhcmUgZXhhY3RseSB0aGUgc2FtZSwgdGVsbCBtZToNCg0KMS4gICAgICAg V2hhdCBkb2VzIHRoZSB1c2VyIHRoaW5rIGlzIGdvaW5nIG9uIHdoaWxlIHRoZXnigJlyZSBzaXR0 aW5nIG9uIHRoZSBHUywgd2F0Y2hpbmcgYSBzcGlubmVyIGFzIHRoZSBHUyB3YWl0cyBmb3IgdGhl IENsaWVudCB0byBtYWtlIGFuIFVwZGF0ZSBHcmFudCByZXF1ZXN0IGluIDMuND8NCg0KMi4gICAg ICAgV2hhdCBleGlzdGluZyBDbGllbnQgY29tcG9uZW50IGlzIGhvbGRpbmcgb3BlbiB0aGUgUmVh ZCBHcmFudCByZXF1ZXN0Pw0KDQphLiAgICAgICBJZiB5b3VyIGFuc3dlciBpcyDigJxhbiBhc3lu YyBwcm9jZXNzIG9uIHRoZSBDbGllbnTigJlzIHNlcnZlcuKAnSB0aGVuIHBsZWFzZSByZS1yZWFk IHRoZSBzZWNvbmQgd29yZCBvZiB0aGF0IHF1ZXN0aW9uLg0KDQozLiAgICAgICBIb3cgbG9uZyBz aG91bGQgdGhlIEdTIHdhaXQgZm9yIHRoZSBDbGllbnQgdG8gbWFrZSB0aGUgVXBkYXRlIEdyYW50 IHJlcXVlc3QgaW4gMy40PyBXaGF0IHNob3VsZCB0aGUgR1MgZG8gaWYgdGhhdCBuZXZlciBoYXBw ZW5zPyBXaGF0IGlzIHRoZSBwYXRoIGZvcndhcmQgZm9yIHRoZSBlbmQgdXNlciwgYXQgdGhhdCBw b2ludD8NClsvcmljaGFubmFdDQoNCltwYXN0aW5nIGluIGZyb20geW91ciBsYXRlciBlbWFpbF0N CldoaWxlIGEgc2luZ2xlIHN0YWdlIEdyYW50IHJlcXVlc3QgKDMuMSkgaW4gYSBtb2JpbGUgYXBw IHRoYXQgaGFzIGJlZW4gcHV0IHRvIHNsZWVwIHdpbGwgcmVjb3ZlciBmaW5lLCBhIG11bHRpLXN0 ZXAgKDMuNCkgd2lsbCBmYWlsLiBTaW5jZSAzLjQgb25seSBtYWtlcyBzZW5zZSBpZiB0aGUgQ2xp ZW50IGlzIGNoZWNraW5nIGEgZGF0YWJhc2UgYWxvbmcgdGhlIHdheSwgSSB3b3VsZCBleHBlY3Qg dGhlIENsaWVudCB0byBoYXZlIGEgc2VydmVyIHNpZGUsIGFuZCB0aGUgc2VydmVyIGNvdWxkIHRh a2UgZWFjaCBzdGVwLg0KWy9lbmQgcGFzdGVdDQoNCltyaWNoYW5uYV0NCkhhdmluZyBhIHJlbW90 ZSBkYXRhYmFzZSBhbmQgaGF2aW5nIGEgcmVtb3RlIHNlcnZlciBhcmUgbm90IHRoZSBzYW1lIHRo aW5nLiBUaGlzIGFkZHMgYSBsb3Qgb2YgY29tcGxleGl0eSB0byBzZXJ2ZXJsZXNzIGFwcHMuDQpb L3JpY2hhbm5hXVtodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGph eTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9N2NkMThlYTYt OGM1MC00NmRjLWJlMjUtZTk5ZjYxNGRhYjgyXeGQpw0KDQpXaGljaCBhc3BlY3QgYWRkcyBjb21w bGV4aXR5Pw0KDQpUaGUgYWRkZWQgY29tcGxleGl0eSBpbiBrZWVwaW5nIGFuIGludGVyYWN0aW9u IGlzIG1ha2luZyBhbiBhZGRpdGlvbmFsIEFQSSBjYWxsIGFmdGVyIHRoZSBmaXJzdCBBUEkgY2Fs bC4NCg0KW3JpY2hhbm5hXQ0KVGhlIGlzc3VlIGlzbuKAmXQgdGhlIEFQSSBjYWxsIGl0c2VsZiwg aXTigJlzIHRoZSBuZWVkIGZvciB0aGUgQ2xpZW50IHRvIG1haW50YWluIGEgcGVyc2lzdGVudCwg YXN5bmNocm9ub3VzIHByb2Nlc3MgdG8gbWFrZSB0aGF0IEFQSSBjYWxsLg0KDQpJdCBpcyBpbmNv cnJlY3QgdG8gYXNzdW1lIHRoYXQgZXZlcnkgYXBwIHdpdGggYSBkYXRhYmFzZSB3aWxsIG5lY2Vz c2FyaWx5IGhhdmUgYSBzZXJ2ZXIgc2lkZS4gQSBzZXJ2ZXJsZXNzIGFwcCB0aGF0IGRvZXMgYSBy ZWRpcmVjdCB0byB0aGUgR1MsIG9yIHRoYXQgc3dpdGNoZXMgdG8gYW4gZXh0ZXJuYWwgYnJvd3Nl ciAoYW5kIHRodXMgbWF5IGJlIHB1dCB0byBzbGVlcCkgaGFzIG5vIGNvbXBvbmVudCB0aGF0IHdp bGwgcmVsaWFibHkgc3RheSBhbGl2ZSB0byBob2xkIG9wZW4gdGhlIFJlYWQgR3JhbnQgcmVxdWVz dCwgcmVjZWl2ZSB0aGUgcmVzcG9uc2UsIGFuZCBmb2xsb3cgdXAgd2l0aCBhbiBVcGRhdGUgR3Jh bnQgcmVxdWVzdCAoaS5lLiwgZmxvdyAzLjQpLiBBZGRpbmcgYSBzZXJ2ZXItc2lkZSBjb21wb25l bnQgdG8gZG8gdGhpcyBvcmNoZXN0cmF0aW9uIGFkZHMgc2lnbmlmaWNhbnQgY29tcGxleGl0eS4N ClsvcmljaGFubmFdDQoNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8 bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1h aWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3R4YXV0aA0KDQo= --_000_CB00CB6A57454670BE30393824A06D15amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6DA4BA1163D2C44C979213CCEE90A9EB@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDAgNSAw IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBh bm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi TVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5j aG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkdhZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAy IDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0KcC5nbWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFp bC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbS0xMzkx MzY2ODI4MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1t LTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29u c29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo2NDY5MTM5MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTAxODk4NjU1Mjt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIyODM0NzUxNjsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzIxNzI3MjY2IC0yMDIzMjE4ODA2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBN aW5jaG8iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk OjkwMzQxNTM5NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzMjIwOTM2NTY7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz DQoJe21zby1saXN0LWlkOjEwODgxNjIzNjQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTA5 MTQzMjIwO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxMjc3NjQwOTczOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTI1MTg2MzM1Njt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTM2MTkzMTEy OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9DQpAbGlzdCBsNTpsZXZlbDEN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsNg0KCXttc28tbGlzdC1pZDoxNjY4MjkyMDA0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot NjExMDI5MTA4O30NCkBsaXN0IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsNw0KCXttc28tbGlzdC1pZDoxODQ4OTgzMjA1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MzgxMDAwMjUyO30NCkBsaXN0IGw3OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDc6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDgNCgl7bXNvLWxpc3QtaWQ6MTg3ODAwODIwNzsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9DQpAbGlzdCBsOQ0KCXttc28tbGlz dC1pZDoxOTE2MjM3NjI0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTA5OTkwMzY4O30NCkBs aXN0IGw5OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDk6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDk6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDEwDQoJe21zby1saXN0LWlkOjE5NzM0Mzk4MjI7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi02MTEwMjkxMDg7fQ0KQGxpc3QgbDExDQoJe21zby1saXN0LWlkOjIxMzAwNzkw MDE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2ODg3MzUxMDQ7fQ0KQGxpc3QgbDExOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTE6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WFlaIGlz IGEgbG90IGNsb3NlciB0byB3aGF0IEnigJltIGRlc2NyaWJpbmcsIGJ1dCBpdCBzdGlsbCBjb25m bGF0ZXMg4oCccmVkaXJlY3QgdG8gdGhpcyBVUkwgYWZ0ZXIgdGhlIHdvcmtmbG934oCdIHdpdGgg 4oCcc2VuZCB0aGUgcmVzcG9uc2UgdG8gdGhpcyBVUkzigJ0uIEkgKjxiPnRoaW5rPC9iPiogdGhl IGRyYWZ0IGFzIHdyaXR0ZW4gd291bGQgYWxsb3cgYSBDbGllbnQgdG8gcHJvdmlkZSBhIGNhbGxi YWNrIGJ1dCBhbHNvDQogcG9sbCBmb3IgdGhlIHJlc3BvbnNlLCBidXQgaXTigJlzIG5vdCB2ZXJ5 IGNsZWFyLiBUaGlzIGtpbmQgb2YgZmxvdyB3aGVyZSB0aGUgQ2xpZW50IGlzIGFjdHVhbGx5IHNw bGl0IGJldHdlZW4gZGV2aWNlLCBiYWNrZW5kLCBhbmQgd2ViYXBwIHdpdGhpbiBhIHNpbmdsZSB0 cmFuc2FjdGlvbiBpcyBvbmUgdGhhdCBkZXNlcnZlcyBtb3JlIGF0dGVudGlvbiwgSU1ITy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBub3RlIG9uIDxhIGhyZWY9Imh0dHBzOi8vb2F1dGgu eHl6L2ludGVyYWN0aW9uLyI+aHR0cHM6Ly9vYXV0aC54eXovaW50ZXJhY3Rpb24vPC9hPiBhbHNv IHN1Z2dlc3RzIFhZWiBpcyBtb3JlIGxpbWl0ZWQgdGhhbiBpdCBuZWVkcyB0byBiZSwgYnV0IHRo ZSBkcmFmdCBzZWVtcyB0byBhbGxvdyBmb3IgdGhpcyBhbHJlYWR5IHNvIG1heWJlIHRoaXMgbm90 ZSBpcyBqdXN0IGJlIG91dCBvZiBkYXRlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+SXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gZmlndXJlIG91dCBp ZiB3ZSBjYW4gY29tYmluZSBib3RoIHRoZSB1c2VyIGNvZGUgYW5kIGFyYml0cmFyeSByZWRpcmVj dCBVUkwgbWV0aG9kcywgZ2l2aW5nIHRoZSB1c2VyIGEgZmV3IG9wdGlvbnMuIFRoaXMgc2hvdWxk IGJlIGFzIHNpbXBsZSBhcyBhbGxvd2luZyBtb3JlIGZsZXhpYmlsaXR5IG9uIHRoZSBpbnRlcmFj dGlvbg0KIHJlcXVlc3QgcG9ydGlvbiBhbmQgaGF2aW5nIHRoZSBzZXJ2ZXIgcmV0dXJuIGFsbCBw b3NzaWJsZSBvcHRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+4oCTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0 cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0Mx Ij5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lzwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5TYXR1cmRheSwgRmVicnVhcnkgMTUsIDIwMjAgYXQgMjo1MSBQTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpv bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0 O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1VOVkVSSUZJRUQgU0VO REVSXSBSZTogW1R4YXV0aF0gWEF1dGggLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGludGVyYWN0aW9uIG1vZGVsIHRoYXQgQW5uYWJlbGxlIGRl c2NyaWJlcyBiZWxvdyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIHRoaW5nIHRoYXTigJlzIGluIFhZ WjoNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJodHRw czovL29hdXRoLnh5ei9pbnRlcmFjdGlvbi8iPmh0dHBzOi8vb2F1dGgueHl6L2ludGVyYWN0aW9u LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbiBl YXJsaWVyIGltcGxlbWVudGF0aW9uIG9mIFhZWiBoYWQgYSDigJx0eXBl4oCdIGZpZWxkIGxpa2Ug WEF1dGggZG9lcy4gWW91IGNhbiBzZWUgdGhhdCBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wMCNzZWN0aW9uLTIuNCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1dGh6 LTAwI3NlY3Rpb24tMi40PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPldlIG1vdmVkIGF3YXkgZnJvbSBpdCBmb3IgYWxsIG9mIHRoZSByZWFzb25zIEFu bmFiZWxsZSBpcyBjaXRpbmcsIGFsb25nIHdpdGggdGhlIG90aGVycyBJ4oCZdmUgc3RhdGVkIHBy ZXZpb3VzbHkgb24gdGhlIGxpc3QgdGhhdCBJIGRvbuKAmXQgZmVlbCBiZWFyIHJlcGVhdGluZyBh Z2Fpbi4gSGF2aW5nIGltcGxlbWVudGVkIGJvdGggcGF0dGVybnMgZGlyZWN0bHkgaW4gdGhlDQog c2FtZSBwcm9qZWN0LCBJIGNhbiBhdHRlc3QgdGhhdCB0aGUgY29kZSBwYXRocyBhcmUgc2lnbmlm aWNhbnRseSBzaW1wbGVyICZuYnNwO2ZvciB0aGUgY3VycmVudCBYWVogcGF0dGVybiwgZXNwZWNp YWxseSBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFlvdSBjYW4gbG9vayBhdCBvdXIgY29k ZSB5b3Vyc2VsdmVzLCBpZiB5b3UgbGlrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5BbmQgZm9yIHRoZSDigJxzaW1wbGXigJ0gY2xpZW50IGNhc2UgdGhh dCBzdXBwb3J0cyBvbmx5IG9uZSB0eXBlICh3aGljaCBJIHRoaW5rIHdlIGFsbCBiZWxpZXZlIHdp bGwgYmUgdGhlIG92ZXJ3aGVsbWluZ2x5IGNvbW1vbiBjYXNlKSwgSSB3YW50IHRvIHBvaW50IG91 dCB0aGF0IHRoZSBYWVogYXBwcm9hY2ggYW5kIHRoZSBYQXV0aCBhcHByb2FjaCBhcmUgZm9yIGFs bCBpbnRlbnRzDQogYW5kIHB1cnBvc2VzIGlkZW50aWNhbC4gVGhlIFhZWiBhcHByb2FjaCBhbGxv d3MgZm9yIGEgbG90IG1vcmUgZmxleGliaWxpdHkgYWxvbmcgd2l0aCBhIGRlY3JlYXNlIGluIGNv bXBsZXhpdHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBGZWIgMTQsIDIwMjAsIGF0IDk6Mjkg UE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFu bmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJlcGxpZXMgaW5saW5lLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlsvcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij7igJM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVm PSJodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5LyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw NTYzQzEiPmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvPC9zcGFuPjwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZy b206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlR4YXV0aCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIj50eGF1dGgtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZg0KIG9mIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRh dGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5G cmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDIwIGF0IDk6MTAgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90O1JpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmE9NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnIj5yaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9y ZyI+dHhhdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBp ZXRmLm9yZyI+dHhhdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtUeGF1dGhd IFhBdXRoIC0wMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBUaHUs IEZlYiAxMywgMjAyMCBhdCA2OjA4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDty aWNoYW5uYT08YSBocmVmPSJtYWlsdG86NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnIj40MGFt YXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZXBsaWVzIGlubGluZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0Ny41NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bL3JpY2hhbm5h XSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZsdDtzbmlw Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bcmljaGFu bmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJ5IHVzZXIg Y29kZS1iYXNlZCBpbnRlcmFjdGlvbiwgSSBtZWFuIHRoZSBraW5kIGRlc2NyaWJlZCBpbiB0aGU8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODYyOCIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo IDIuMCBEZXZpY2UgQXV0aG9yaXphdGlvbiBHcmFudDwvYT4sDQogd2hlcmUgdGhlIHVzZXIgcmVj ZWl2ZXMgYSBjb2RlIGFuZCBzaG9ydCBVUkwgZnJvbSB0aGUgY2xpZW50LCBuYXZpZ2F0ZXMgdG8g dGhhdCBVUkwgaW4gYSBicm93c2VyLCBhbmQgZW50ZXJzIHRoZSBjb2RlLiBXaGlsZSB0aGlzIGNv dWxkIGJlIHBhY2tlZCBpbnRvIGludGVyYWN0aW9uLm1lc3NhZ2UsIHRoaXMgd2lsbCBsZWFkIHRv IGNsdW5raWVyIHVzZXIgZXhwZXJpZW5jZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJnbWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjEuPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+VGhlIEdTIG1heSBub3QgYmUgYWJsZSB0byBwcm92aWRlIGxvY2FsaXpl ZCBpbnN0cnVjdGlvbnMgdGhhdCBtYXRjaCB0aGUgbG9jYWxlIG9uIHRoZSBDbGllbnQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIyMzMwbXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+DQoy LjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlN1cHBvc2UgdGhlIEdTIHNlbmRzIGEgbWVz c2FnZSB0aGF0IHJlYWRzOiDigJxTY2FuIHRoZSBRUiBjb2RlIG9yIG9wZW4gYSBicm93c2VyIHRv PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Imh0dHA6Ly9jb2RlLmV4YW1wbGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2NvZGUuZXhhbXBs ZS88L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFu ZA0KIGVudGVyIHRoZSBjb2RlOiAxMjM0NS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJn bWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6Mi4waW47dGV4dC1pbmRlbnQ6LS4yNWluIj4NCmEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+VGhhdCBpbnN0cnVjdGlvbiBkb2VzIG5vdCBtYWtlIHNlbnNlIG9uIGEg ZGV2aWNlIHRoYXQgZG9lcyBub3QgcHJlc2VudCBhIFFSIGNvZGUuIEltYWdpbmUgaGVhcmluZyB0 aGF0IGZyb20gYSBzbWFydCBzcGVha2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWls LW0tMTM5MTM2NjgyODM2NzQyMjMzMG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDoyLjBpbjt0ZXh0LWluZGVudDotLjI1aW4iPg0KYi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj5UaGF0IGluc3RydWN0aW9uIGlzIGNvbmZ1c2luZ2x5IHJlZHVuZGFudCBpZiB0aGUgQ2xp ZW50IGRpc3BsYXlzIHRoZSBRUiBjb2RlIGFsb25nIHdpdGggaXRzIG93biBpbnN0cnVjdGlvbnMs IGxpa2U6IOKAnFNjYW4gdGhlIFFSIGNvZGUgb3INCiBmb2xsb3cgdGhlIGluc3RydWN0aW9ucyBi ZWxvdy7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTEzOTEzNjY4MjgzNjc0 MjIzMzBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRl bnQ6LS4yNWluIj4NCjMuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+V2lsbCDigJxlbWJl ZCB0aGUgc2hvcnQgVVJMIGFuZCBjb2RlIGluIHRoZSBtZXNzYWdlIHN0cmluZ+KAnSBiZSBNVEk/ IElmIG5vdCwgdGV4dC1vbmx5IGNsaWVudHMgd291bGQgaGF2ZSBhIGJyb2tlbiBleHBlcmllbmNl LjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U291 bmRzIGxpa2UgYSB0ZXh0IG9ubHkgaW50ZXJhY3Rpb24gdHlwZSBzaG91bGQgYmUgYWRkZWQgcGVy IG15IG5vdGUgaW4gdGhlIGRyYWZ0LiBQZXJoYXBzIGV2ZW4gb25lIHRoYXQgaXMgZm9jdXNlZCBv biB0aGUgY29kZSBmbG93LCB3aGVyZSB0aGUgcGFyYW1ldGVycyBhcmUgdGhlIGNvZGUgYW5kIHRo ZSBVUkkgdG8gZW50ZXIgdGhlIGNvZGUsIGxldHRpbmcgdGhlDQogQ2xpZW50IHByZXNlbnQgdGhl IHBhcmFtZXRlcnMgd2l0aCBsb2NhbGl6ZWQgY29udGVudD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhpbmsgd2XigJlyZSBh cHByb2FjaGluZyB0aGUg4oCcaW50ZXJhY3Rpb27igJ0gY29uY2VwdCB3cm9uZy4gV2XigJlyZSBj b25mbGF0aW5nIHRocmVlIGRpZmZlcmVudCB0aGluZ3MgdG9nZXRoZXI6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0 OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2hhdCBkb2VzIHRoZSBDbGllbnQgbmVlZCB0byBz ZW5kIHRoZSBlbmQgdXNlciB0byB0aGUgR1M/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjVpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwzIGxldmVsMiBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5v PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BIGh1bWFuLWZy aWVuZGx5IHNob3J0IFVSTCBhbmQgY29kZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAw MDFwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzIiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFueSBraW5kIG9m IFVSTCwgYXMgbG9uZyBhbmQgdWdseSBhcyBpdCBuZWVkcyB0byBiZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuMGluO21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDkgbGV2ZWwx IGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7Ctzxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+SG93IHdpbGwgdGhlIENsaWVudCByZWNlaXZlIHRoZSByZXNwb25z ZSBmcm9tIHRoZSBHUz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkNsaWVudCB3aWxsIG1ha2UgYSByZXF1 ZXN0IHRvIHRoZSBHUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkdTIHdpbGwgbWFrZSBhIHJlcXVlc3Qg dG8gdGhlIENsaWVudC4gKEnigJl2ZSBoYWQgdG8gaW1wbGVtZW50IHRoaXMgZm9yIGEgY3VzdG9t IGludGVncmF0aW9uLCBpbmNsdWRpbmcgaXQgdG8gZGVtb25zdHJhdGUgdGhhdCBvdGhlciBvcHRp b25zIGV4aXN0KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMTEgbGV2ZWwxIGxmbzUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2lsbCB0aGUgR1Mg cmV0dXJuIHRoZSBlbmQgdXNlciB0byB0aGUgQ2xpZW50LCBhbmQgaWYgc28gaG93PzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 MS41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MiBsZXZlbDIgbGZvNiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+WWVzLCBieSBVUkwgcmVkaXJlY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjVpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMiBsZm82Ij4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Oby48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGVy ZSBpcyBhIHZlcnkgbm9uLW5vcm1hdGl2ZSBleGFtcGxlIHJlcXVlc3QgZnJhZ21lbnQsIGZvciBh IGNsaWVudCB0aGF0IHdhbnRzIGJvdGggYSBzaG9ydCBVUkwgcGx1cyBjb2RlIGFuZCBhIGZ1bGwg VVJMIHNvIHRoZXkgY2FuIG9wcG9ydHVuaXN0aWNhbGx5IHVzZSBvbmUgb3IgdGhlIG90aGVyIChB V1MgQ0xJIHYyIGRvZXMgdGhpcyksIHdpbGwgcXVlcnkgdGhlDQogR1MgZm9yIHRoZSByZXNwb25z ZSwgYW5kIHdhbnRzIHRoZSBHUyB0byByZWRpcmVjdCB0byBhIHB1YmxpY2x5IGFjY2Vzc2libGUg VVJMIG9uIHRoZSBDbGllbnTigJlzIHdlYnNpdGUgYWZ0ZXIgdGhlIGZsb3cgKGUuZy4sIHRvIHNo b3cgZnVydGhlciBkb2N1bWVudGF0aW9uL2JyYW5kZWQgY29udGVudCB0byB0aGUgZW5kIHVzZXIp OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj57 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+JnF1b3Q7aW50ZXJhY3QmcXVvdDs6IHs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyIj4mbmJzcDsgJnF1b3Q7Y29kZSZxdW90OzogeyAmcXVvdDttYXgmcXVvdDs6 IDggfSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJnF1b3Q7dXJsJnF1b3Q7OiB0cnVl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+fSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0 LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mcXVvdDty ZXNwb25zZSZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEz LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVvdDtwb2xs JnF1b3Q7OiB0cnVlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6MTMuNXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+fSw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyIj4mcXVvdDtyZXR1cm4mcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0 LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsg JnF1b3Q7dXJsJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2hlbHAuc21hcnRkZXZpY2Uu ZXhhbXBsZS9wb3N0LXNldHVwIj5odHRwczovL2hlbHAuc21hcnRkZXZpY2UuZXhhbXBsZS9wb3N0 LXNldHVwPC9hPiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEz LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn08L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbmQgaGVyZSBpcyBhbiBlcXVhbGx5IG5vbi1u b3JtYXRpdmUgZXhhbXBsZSByZXNwb25zZSBmcmFnbWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+ezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi PiZxdW90O2ludGVyYWN0JnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1p bmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZx dW90O2NvZGUmcXVvdDs6ICZxdW90OzEyMzQ1NiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVy Ij4mbmJzcDsgJnF1b3Q7Y29kZV91cmwmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZ3Mu ZXhhbXBsZS9jb2RlIj5odHRwczovL2dzLmV4YW1wbGUvY29kZTwvYT4mcXVvdDssPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q291cmllciI+Jm5ic3A7ICZxdW90O3VybCZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0 cHM6Ly9ncy5leGFtcGxlL3hhdXRoLzEyMzQzNTY3ODkwYWJjZGVmMTIzNDU2Nzg5MGFiY2RlZiI+ aHR0cHM6Ly9ncy5leGFtcGxlL3hhdXRoLzEyMzQzNTY3ODkwYWJjZGVmMTIzNDU2Nzg5MGFiY2Rl ZjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDoxMy41cHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj59PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KFNlcmlvdXNseSBkbyBub3QgcmVhZCB0b28gbXVjaCBp bnRvIHRoZXNlIHBhcmFtZXRlciBuYW1lcyBvciBzeW50YXgsIHRoaXMgaXMganVzdCB0byBnaXZl IGEgcm91Z2ggc2Vuc2Ugb2YgaG93IEnigJltIHRoaW5raW5nIGFib3V0IHRoaXMuIEFueW9uZSB3 aG8gdHJpZXMgdG8gcGljayBhcGFydCB0aGlzIGV4YW1wbGUgd2lsbCBiZSByZXNwb25kZWQgdG8g d2l0aCBtb2NraW5nDQogbWVtZXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsvcmljaGFubmFdPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PkNsaWVudHMgc3VwcG9ydCBtdWx0aXBsZSBpbnRlcmFjdGlvbiBtb2RlcyBhbmQgbWF5IG5vdCBh bHdheXMga25vdyB3aGF0IHRoZSBHUyBzdXBwb3J0cyAoYW5kDQogdmljZS12ZXJzYSkuIEZvciBh IG11bHRpLXRlbmFudCBHUywgaXQgbWF5IHZhcnkgYnkgdGVuYW50IGNvbmZpZ3VyYXRpb24uIENs aWVudHMgc2hvdWxkIGJlIGFibGUgdG8gc2F5IHdoYXQgdGhleSBjYW4gZG8sIGFuZCB0aGUgR1Mg c2hvdWxkIGJlIGFibGUgdG8gdGVsbCB0aGVtIHdoaWNoIG9uZSB0byB1c2UuIEl04oCZcyBhIHZl cnkgc2ltcGxlIGJ1dCBwb3dlcmZ1bCBpbmxpbmUgbmVnb3RpYXRpb24uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhdCBpcyB3aGF0IGlzIGluIFR4QXV0aC4gV291bGQg eW91IGVsYWJvcmF0ZSBvbiBob3cgdGhlIEdTIG1pZ2h0IGJlIGNvbnN0cmFpbmVkPyBXaHkgd291 bGQgdGhlIEdTIG5vdCBiZSBhYmxlIHRvIGRvIGFsbD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3b3VsZCB0 aGluayBhbGwgY29uc3RyYWludHMgd291bGQgYmUgYXQgdGhlIENsaWVudC4gQW0gSSBtaXNzaW5n IHNvbWV0aGluZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPltyaWNo YW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2xpZW50 cyBtYXkgc3VwcG9ydCBjdXN0b21lci1kZWZpbmVkIEdTZXMgKGUuZy4sIGVudGVycHJpc2UgSWRQ cyksIHdoaWNoIHdpbGwgdmFyeSBpbiB0ZXJtcyBvZiB3aGljaCBpbnRlcmFjdGlvbiBtb2RlcyB0 aGV5IHN1cHBvcnQuIFdoaWxlIHRoZSBzZXQgb2YgaW50ZXJhY3Rpb25zIGRlZmluZWQgaW4gWEF1 dGggbWlnaHQgYWxsIGJlIE1USSBmb3IgYSBHUywgd2Ugc2hvdWxkDQogYXNzdW1lIHRoYXQgZXh0 ZW5zaW9ucyB3aWxsIGludHJvZHVjZSBuZXcgaW50ZXJhY3Rpb25zIHdoaWNoIHdpbGwgbm90IGJl IHVuaXZlcnNhbGx5IHN1cHBvcnRlZC4gQW4gaW50ZXJhY3Rpb24gbWVjaGFuaXNtIG1pZ2h0IGhh dmUgcHJvcGVydGllcyB0aGF0IGNhdXNlIHNvbWUgYWRtaW5pc3RyYXRvcnMgdG8gd2FudCB0byBk aXNhYmxlIGl0LCBvciB0byByZXN0cmljdCBDbGllbnRzIHRvIGFsd2F5cyB1c2UgaXQuIEFyZSB5 b3UgYXNzdW1pbmcgdGhhdA0KIGEgQ2xpZW50IHdpbGwgYWx3YXlzIG1ha2UgYW4gT1BUSU9OUyBk aXNjb3ZlcnkgcmVxdWVzdCBmaXJzdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gZXhhbXBsZSBvZiB3aHkgYSBnaXZl biBHUyBtYXkgbm90IHN1cHBvcnQgYSBtb2RlIHdvdWxkIGJlIGhlbHBmdWwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JIHdhcyBlbnZpc2lvbmluZyB0aGF0IGlmIGFuIG9wdGlvbmFsIHRvIHN1cHBvcnQgaW50ZXJh Y3Rpb24gbW9kZSB3YXMgbm90IHN1cHBvcnRlZCBhdCB0aGUgR1MsIHRoYXQgaXQgd291bGQgcmV0 dXJuIGFuIGVycm9yLiBUaGUgQ2xpZW50IHdvdWxkIHRoZW4gdHJ5IGEgZGlmZmVyZW50IG9uZS4g QWx0ZXJuYXRpdmVseSwgdGhlIENsaWVudCBjb3VsZCBzdGFydCB3aXRoDQogYW4gT1BUSU9OUyBj YWxsIGluIGNhc2VzIHdoZXJlIHRoZSBHUyBpcyBkeW5hbWljbHkgY2hvc2VuLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5bcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TG90cyBv ZiBBU2VzIGRvbuKAmXQgc3VwcG9ydCBEZXZpY2UgQXV0aG9yaXphdGlvbiBHcmFudC4gSSB0aGlu ayBpdOKAmXMgc2FmZSB0byBhc3N1bWUgdGhhdCBpbnRlcmFjdGlvbiBtb2RlIHN1cHBvcnQgd2ls bCB2YXJ5IGZvciBYQXV0aCBhcyB3ZWxsLiDigJxLZWVwIHRyeWluZyB1bnRpbCB5b3UgZmluZCBv bmUgdGhhdCB3b3Jrc+KAnSBzb3VuZHMgcHJldHR5IHBhaW5mdWwgZm9yDQogdGhlIGNsaWVudCwg YW5kIGRvZXNu4oCZdCBhbGxvdyB0aGUgY2xpZW50IHRvIHVzZSBtdWx0aXBsZSBpbnRlcmFjdGlv biBtb2RlcywgYXMgZGVtb25zdHJhdGVkIGluIG15IGV4YW1wbGUgYWJvdmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlcmUgYXJlIGxvdHMgb2YgcmVh c29ucyBmb3Igd2FudGluZyB0byBzdXBwb3J0IG11bHRpcGxlIG1vZGVzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVm dDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 Omw3IGxldmVsMSBsZm83Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlNvbWUgcGVvcGxlIGFyZSBjb21mb3J0YWJsZSB3 aXRoIFFSIGNvZGVzLCBzb21lIGFyZW7igJl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTou MDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNyBsZXZlbDEgbGZvNyI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5Tb21lIHBlb3BsZSBoYXZlIHNtYXJ0IHBob25lcyB0aGF0IGNhbiBzY2FuIHRoZW0sIHNv bWUgZG9u4oCZdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206MGluO21hcmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzciPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UGVvcGxlIHdpdGgg c21hcnQgcGhvbmVzIG1heSB3YW50IHRvIGdvIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIGZs b3cgb24gdGhlaXIgZGVza3RvcCBpbnN0ZWFkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTou MDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNyBsZXZlbDEgbGZvNyI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5Tb21lIHBlb3BsZSBtYXk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGk+aGF2ZTwvaT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+dG8gZ28gdGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gZmxvdyBvbiB0 aGVpciBkZXNrdG9wLCBiZWNhdXNlIHRoZSBHUyB0aGlua3MgaVBob25lcyBvbmx5IHN1cHBvcnQg Qmx1ZXRvb3RoLWJhc2VkDQogc2VjdXJpdHkga2V5cyBhbmQgaW5zaXN0cyB0aGV5IGNhbm5vdCBj b21wbGV0ZSB0aGUgbG9naW4gZmxvdyBldmVuIHRob3VnaCB0aGV5IGhhdmUgdHdvIFl1YmlLZXkg NUNpIGtleXMgb24gdGhlaXIgYWNjb3VudC4gKEhJLCBHT09HTEUgQUNDT1VOVCBQUk9URUNUSU9O IFBST0dSQU0pPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsvcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+My48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5JIGRvbuKAmXQgc2VlIHRoZSB2YWx1ZSBvZiB0aGUg 4oCccG9wdXDigJ0gaW50ZXJhY3Rpb24gbW9kZS4gQ2xpZW50cyBjYW4gdXNlIOKAnHJlZGlyZWN0 4oCdIG1vZGUgd2l0aGluDQogcG9wdXBzLiBIb3dldmVyLCBzcGVha2luZyBhcyBzb21lb25lIHdo byBoYXMgZG9uZSB0aGF0LCBJIHJlYWxseSBkb27igJl0IHJlY29tbWVuZCBpdC4gUG9wdXBzIGFy ZSBpbmNyZWFzaW5nbHkgdW5zdXBwb3J0ZWQsIGFuZCBwcm9uZSB0byB3ZWlyZCBiZWhhdmlvcmFs IGlzc3Vlcy4gSW4tYXBwIGJyb3dzZXJzIGluIEZhY2Vib29rLCBUd2l0dGVyLCBldGMuIHRlbmQg dG8gaGF2ZSBwb3B1cHMgZGlzYWJsZWQuIFRoZSBsYXN0IHZlcnNpb25zIG9mIElFDQogTW9iaWxl IGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwgKHRoZSBwb3BwZWQgdXAgcGFnZSBiYXNpY2Fs bHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVudCB3aW5kb3cpLi4gaW4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Qb3B1cHMgYXJlIHJlYWxseSB1c2VmdWwg aW4gc2luZ2xlLXBhZ2UgYXBwcyBhcyB5b3Ugd2FudCB0byBrZWVwIHRoZSBjb250ZXh0IGFuZCBu b3QgcmVsb2FkIHRoZSBwYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BZ3JlZSB0aGF0IHBvcHVwcyBkb24n dCBtYWtlIHNlbnNlIGluIG1vYmlsZS4gQSBmdWxsIHJlZGlyZWN0IGRvZXMgb2YgY291cnNlLiBB IHNpbmdsZS1wYWdlIGFwcCBvbiBtb2JpbGUgd291bGQgb3BlbiBhIG5ldyB0YWIgd2hpY2ggd291 bGQgYmUgYSBzZXBhcmF0ZSBjb250ZXh0IHJhdGhlciB0aGFuIGEgcmVkaXJlY3QuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5h XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Qb3B1cHMgYXJl IGJyb2tlbiBhbmQvb3IgZGlzYWJsZWQgaW4gZW5vdWdoIGluc3RhbmNlcyB0aGF0IHdlIHNob3Vs ZCBub3QgZW5jb3VyYWdlIHRoZWlyIHVzYWdlIGJ5IGluY2x1ZGluZyBleHBsaWNpdCBzdXBwb3J0 IGZvciB0aGVtIGluIHRoZSBwcm90b2NvbC4gTm9yIGFyZSB0aGV5IG5lY2Vzc2FyeSBmb3IgU1BB cyBpbiBvcmRlciB0byByZXN0b3JlIHRoZSBzdGF0ZQ0KIG9mIHRoZWlyIGFwcCBhZnRlciB0aGUg cmVkaXJlY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkFyZSB0aGV5IHJlYWxseSB0aGF0IGJyb2tlbiBpbiBkZXNrdG9wPyBJJ3Zl IHVzZWQgdGhlbSBleHRlbnNpdmVseSBteXNlbGYgaW4gdGhlIHBhc3QgYXMgaXQgd2FzIGEgYmV0 dGVyIHVzZXIgZXhwZXJpZW5jZSwgYnV0IHRoYXQgd2FzIGEgZmV3IHllYXJzIGFnby48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBv cHVwIGJsb2NrZXJzIGFyZSBidWlsdCBpbiBhbmQgYWdncmVzc2l2ZWx5IGVuYWJsZWQgYnkgZGVm YXVsdCBvbiBhbGwgbWFqb3IgYnJvd3NlcnMuIENvbW11bmljYXRpbmcgc2VjdXJlbHkgYmV0d2Vl biB3aW5kb3dzIGlzIG5vdCBlYXN5LCBhbmQgZnJvbSBwYXN0IGV4cGVyaWVuY2UgcHJvbmUgdG8g ZmFpbHVyZSB0aGFua3MgdG8gd2VpcmQgYnJvd3NlciBidWdzLg0KIFRydXN0ZWQgU2l0ZSBzZXR0 aW5ncyBpbiBJRSBhbmQgRWRnZSBjYW4gYmxvdyB0aGUgd2hvbGUgdGhpbmcgdXAgaW4gd2VpcmQg d2F5cyAoc3BlYWtpbmcgYWdhaW4gZnJvbSBleHBlcmllbmNlKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbHNvLCBpdOKAmXMgMjAyMC4gU3RvcCBicmFu Y2hpbmcgb24gbW9iaWxlIHZzLiBkZXNrdG9wLiBJIGdldCB0aGF0IGxvdHMgb2YgcGVvcGxlIHN0 aWxsIGRvIHRoYXQsIGJ1dCB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoZSBwcm90b2NvbCBzaG91bGQg Y2F0ZXIgdG8gaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+QW5kIGFnYWluLCBhIENsaWVudCB0aGF0IHJlYWxseSB3YW50cyB0byBnaXZl IHRoZW1zZWx2ZXMgYSBoZWFkYWNoZSB3aXRoIHBvcHVwcyBjYW4gZG8gdGhhdCB0aGVtc2VsdmVz IHVzaW5nIOKAnHJlZGlyZWN04oCdIG1vZGUuIFRoZXkganVzdCBoYXZlIHRvIHByb3ZpZGUgYSBs YW5kaW5nIHBhZ2UgZm9yIHRoZSBHUyB0byByZWRpcmVjdCBiYWNrIHRvIHRoYXQgcGFyc2VzIHRo ZQ0KIHJlc3BvbnNlLCBwYXNzZXMgaXQgYmFjayB0byB0aGUgbWFpbiB3aW5kb3csIGFuZCBjbG9z ZXMgaXRzZWxmLiBJIGRvbuKAmXQgc2VlIHdoeSB0aGUgcHJvdG9jb2wgd291bGQgbmVlZCB0byBl eHBsaWNpdGx5IGRlc2NyaWJlIHRoaXMgbWVjaGFuaXNtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsv cmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkkgdGhpbmsgaXQgaXMgYSB1c2VmdWwgc2lnbmFsIGZvciB0aGUgR1MgaW4g dGhlIGV4cGVyaWVuY2UgaXQgd2FudHMgdG8gc2hvdyB0aGUgdXNlci48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPlVzZWZ1bCBob3c/IFRoZSB3aW5kb3cgZGltZW5zaW9ucyBhcmUgYSBiZXR0ZXIgc2lnbmFs IGZvciBob3cgdG8gcHJlc2VudCB0aGUgdXNlciBleHBlcmllbmNlLiAoKmNvdWdoKiByZXNwb25z aXZlIGRlc2lnbiAqY291Z2gqKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsvcmljaGFubmFdPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+U2VjdGlvbiAxMi42OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwO1tFZGl0b3I6IGlzIHRoZXJlIHNvbWUgb3RoZXIgcmVhc29uIHRvIGhhdmUgdGhl IFVzZXJJbmZvPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5kcG9pbnQ/XTxv OnA+PC9vOnA+PC9wcmU+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIG1heSB3YW50IHRvIGhvc3QgbXkg VXNlckluZm8gZW5kcG9pbnQgb24gYSBzZXBhcmF0ZSBtaWNyb3NlcnZpY2UgZnJvbSBteSB0b2tl biBlbmRwb2ludCAoaW4gT0F1dGggMi4wL09JREMgdGVybXMpLiBUaGUgZm9ybWVyIG1pZ2h0IGJl IHBhcnQgb2YgbXkgdXNlciBwcm9maWxlL2RpcmVjdG9yeSBzdGFjaywgd2hpbGUgdGhlIGxhdHRl ciBpcyBwYXJ0IG9mIHRoZSBoaWdobHkNCiBwcml2aWxlZ2VkIGF1dGhlbnRpY2F0aW9uL2F1dGhv cml6YXRpb24gc3RhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5UaGUgdG9rZW4gZW5kcG9pbnQgaGFzIHRoZSBhY2Nlc3MgdG9rZW4gYW55d2F5LCBz byBpdCBjYW4gZmV0Y2ggdGhlIGRhdGEgZnJvbSB0aGUgb3RoZXIgZW5kcG9pbnQgaXRzZWxmIGlm IGl0IHdhbnRlZCB0by4gSUUsIHRoZXJlIGlzIG5vIHNlcGFyYXRpb24gb2YgZHV0aWVzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5XaGF0IGFyZSB0aGUgYWR2YW50YWdlcyBvZiB0aGUgVXNlckluZm8gZW5kcG9p bnQgdG8gdGhlIFVzZXIgb3IgQ2xpZW50PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgVXNlcklu Zm8gZW5kcG9pbnQgc2VlbXMgdG8ganVzdCBhZGQgbW9yZSBjb21wbGV4aXR5LCB3aXRoIG5vIGFi aWxpdHkgdG8gc3RhcnQgYSBVc2VyIGludGVyYWN0aW9uIGlmIGFkZGl0aW9uYWwgY29uc2VudCBp cyBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JZiB0aGUgYWNjZXNzIHRva2VuIGlzIHNlbmRlci1jb25zdHJhaW5lZCwgdGhlbiBu bywgdGhlIHRva2VuIGVuZHBvaW50IGNhbuKAmXQgZmV0Y2ggdGhlIGRhdGEgaXRzZWxmLiBCdXQg ZXZlbiB3aXRob3V0IHRoZSBzZWN1cml0eSBhbmdsZSwgdGhlcmUgaXMgdmFsdWUgaW4gc2VwYXJh dGluZyBvdXQgdGhlIGZ1bmN0aW9uYWxpdHkgYXMgaXQgYWxsb3dzIHRoZSBHUyB0bw0KIGRpc3Ry aWJ1dGUgaXQgYWNyb3NzIHN5c3RlbXMgd2l0aCBkaWZmZXJlbnQgb3duZXJzLiBFLmcuLCB0aGVy ZSBtaWdodCBiZSBhIGRpcmVjdG9yeSBBUEkgdGVhbSB0aGF0IGFsc28gb3ducyB0aGUgU0NJTSBp bnRlcmZhY2UgYW5kIFVzZXJJbmZvIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbiBpbXBsZW1lbnRhdGlvbiBjYW4g YWxzbyByb3V0ZSBjYWxscyB0byBkaWZmZXJlbnQgaW50ZXJuYWwgc3lzdGVtcyB3aGlsZSBrZWVw aW5nIHRoZSBzYW1lIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBhbHNvIHRoaW5rIG9mIFNDaU0g YW5kIFVzZXJJbmZvIGFzIHZlcnkgZGlmZmVyZW50IGVuZHBvaW50cy4gSSB3b3VsZCBjb25zaWRl ciBTQ0lNIGEgcmVzb3VyY2UsIGFuZCBVc2VySW5mbyBjbGFpbXMuIEkgYXBwcmVjaWF0ZSB0aG9z ZSBhcmUgc2ltaWxhciBpbiBlbnRlcnByaXNlLCBidXQgdGhleSBhcmUgbm90IGluIGNvbnN1bWVy IGNvbnRleHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bcmljaGFubmFdPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Um91dGluZyBjYWxscyB0byBkaWZmZXJlbnQgaW50ZXJuYWwgc3lzdGVt cyBzdGlsbCBtZWFucyBJIGhhdmUgdG8gaGF2ZSBzb21lIHNoYXJlZCBpbmZyYXN0cnVjdHVyZSB0 aGF0IGJvdGggdGVhbXMgbWFuYWdlLiBJdOKAmXMgbW9yZSBjb21wbGV4IHRoYW4gaXQgbmVlZHMg dG8gYmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SeKA mW0gZ29pbmcgdG8gc3VnZ2VzdCB3ZSBtb3ZlIHRoaXMgcGFydCBvZiB0aGUgZGlzY3Vzc2lvbiB0 byBhIHNlcGFyYXRlIHRocmVhZCBiZWNhdXNlIGl04oCZcyB0b28gbWVzc3kgdG8ga2VlcCBpbiB0 aGlzIGF3ZnVsIGJhY2stYW5kLWZvcnRoLiBJ4oCZbGwganVzdCBhZGQgaGVyZSB0aGF0IEnigJlt IG5vdCBzdWdnZXN0aW5nIHdlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxpPm9ubHk8L2k+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPmhhdmUNCiBhIFVzZXJJbmZvIGVuZHBvaW50LiBJ4oCZbSBhcmd1aW5nIHR3 byB0aGluZ3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDggbGV2ZWwxIGxmbzgiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIFVzZXJJbmZvIGVuZHBv aW50IGlzIGdvb2QsIGFjdHVhbGx5LiBJdCBkb2VzbuKAmXQgbmVlZCB0byBiZSBNVEksIGJ1dCB3 ZSBzaG91bGQgbm90IHByZWNsdWRlIGl0cyBleGlzdGVuY2UuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omw4IGxldmVsMSBsZm84 Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PklmIHdlIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHJlcXVlc3RpbmcgYW5kIHJlY2VpdmluZyBj bGFpbXMgaW4gdGhlIEdTIFJlYWQgR3JhbnQgcmVzcG9uc2UsIHRoYXQgbWVjaGFuaXNtIHNob3Vs ZCBhcHBseSBnZW5lcmljYWxseSB0byBhcmJpdHJhcnkgcmVzb3VyY2VzLiBHU2VzIGNhbiBzdXBw b3J0IGl0IG9yIG5vdCwgZm9yIGFueSBnaXZlbiByZXNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNo YW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbHQ7 c25pcCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVyZSBhcmUgdHdvIGJpZyBkaWZmZXJl bmNlcyBiZXR3ZWVuIHRob3NlIGV4YW1wbGVzIChlLmcuLCBRUiBDb2RlLCBhcHAtYmFzZWQgbG9n aW4gYXBwcm92YWxzKSBhbmQgdGhpcyBtZWNoYW5pc20gaW4gWEF1dGg6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJnbWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjEu PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+SW4geW91ciBleGFtcGxlcyBvZiB0aGlzIGJl aGF2aW9yIHRvZGF5LCB0aGUgcmVhc29uIGZvciB0aGUgd2FpdCBpcyBjbGVhciBhbmQgb2J2aW91 cywgYW5kIGRyaXZlbiBieSB0aGUgdXNlci4gRS5nLiwgbXkgcHJpbnRlciBpcyB3YWl0aW5nDQog Zm9yIG1lIHRvIGdvIGVudGVyIHRoaXMgY29kZSBhbmQgbG9nIGluOyBHb29nbGUgc2lnbiBpbiBp cyB3YWl0aW5nIGZvciBtZSB0byB0YXAgdGhpcyBidXR0b24gb24gbXkgcGhvbmUuIFRoYXQgaXMg bm90IHRoZSBjYXNlIGluIHRoZSBYQXV0aCBwcm90b2NvbC4gVGhlIHVzZXIgaXMgbGVmdCBzaXR0 aW5nIG9uIGEgbG9hZGluZyBzY3JlZW4gd2FpdGluZyBmb3IgYSBiZWhpbmQtdGhlLXNjZW5lcyBp bnRlcmFjdGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQNCiBHUyB0aGF0IG1heSBub3QgZXZlbiBoYXBw ZW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIyMzMw bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0u MjVpbiI+DQoyLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlVubGlrZSB3aXRoIGNvZGUv UVIgZmxvd3Mgb3Igc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZXJlIGlzIG5vIGFjdGl2ZSBwcm9j ZXNzIG9uIHRoZSBjbGllbnQgc2lkZSB0byBrZWVwIHRoaXMgYXN5bmMgcmVxdWVzdCBvcGVuLiBB IHdlYg0KIGFwcCBjbGllbnQgd291bGQgaGF2ZSB0byBpbnRyb2R1Y2UgYSBzZXJ2ZXItc2lkZSBh c3luYyBwcm9jZXNzIHRvIG1hbmFnZSB0aGlzIGFzcGVjdCBvZiB0aGUgcHJvdG9jb2wuIFRoYXTi gJlzIG5vdCBlYXN5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMTM5MTM2Njgy ODM2NzQyMjMzMG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0 LWluZGVudDotLjI1aW4iPg0KMy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5UaGUgZmFp bHVyZSBtb2RlcyBzaG93IHVwIGluIG1vcmUgYXBwcm9wcmlhdGUgY29udGV4dHMsIHdoZXJlIHRo ZXJlIGFyZSBjbGVhciBwYXRocyBmb3J3YXJkIGZvciB0aGUgZW5kIHVzZXIuIEluIGNvZGUvUVIt YmFzZWQgZmxvd3MsIGl04oCZcw0KIGRldGVjdGVkIG9uIHRoZSBjbGllbnQgc2lkZSwgaW4gdGhl IGZvcm0gb2YgYW4gQVMgdGhhdCBuZXZlciBwcm92aWRlcyBhIHJlc3BvbnNlLiBJbiB0aGF0IHNj ZW5hcmlvLCB0aGUgY2xpZW50IGNhbiByZXRyeSB0aGUgcHJvY2Vzcy4gSW4gc2lnbi1pbiB2ZXJp ZmljYXRpb24sIHRoZSBwcm9ibGVtIG9jY3VycyBiZXR3ZWVuIHR3byBwYXJ0cyBvZiB0aGUgQVMs IGFuZCB0aGUgQVMgY2FuIGFsbG93IHRoZSBlbmQgdXNlciB0byByZXRyeSBvciB0bw0KIHVzZSBh IGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QuIEluIHRoZSBYQXV0aCBDcmVhdGUmIzQz O1VwZGF0ZSBzY2VuYXJpbywgdGhlIGZhaWx1cmUgaXMgZGV0ZWN0ZWQgb24gdGhlIEdTLCBhbmQg dGhlcmUgaXMgbm8gY2xlYXIgcGF0aCBmb3J3YXJkLiBJZiB0aGUgQ2xpZW50IG5ldmVyIGNhbGxz IFVwZGF0ZSBHcmFudCB0byBmbGlwIGludGVyYWN0aW9uLmtlZXAgdG8gZmFsc2UsIHdoYXQgc2hv dWxkIHRoZSBHUyBkbz8gSG93IGxvbmcgc2hvdWxkDQogaXQgd2FpdD8gU2hvdWxkIGl0IGlzc3Vl IHRoZSBhdXRob3JpemF0aW9uIGFueXdheSwgYXNzdW1pbmcgdGhlIENsaWVudCB3aWxsIGNvbWUg YmFjayBhbmQgYXNrIGZvciBpdCBhdCBzb21lIHBvaW50PyBTaG91bGQgaXQgcmVkaXJlY3QgdGhl IGVuZCB1c2VyIGJhY2sgdG8gdGhlIENsaWVudCBhbnl3YXksIG9yIGRyb3AgdGhlbSBvbiBhIGxh bmRpbmcgcGFnZT8gU2hvdWxkIGl0IGZsYWcgdGhpcyBhcyBhbiBlcnJvciwgb3IgaXMgdGhpcyB0 aGUgZXhwZWN0ZWQNCiBiZWhhdmlvciBmb3IgdGhlIENsaWVudD88bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5JIHJlYWxseSB0aGluayB0aGlzIGlzIG92ZXJjb21wbGljYXRpbmcgdGhl IHByb3RvY29sIHRvIGFuIGV4dGVudCB0aGF0IG5vIG9uZSB3aWxsIGFjdHVhbGx5IGltcGxlbWVu dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNo YW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+VGhlIGZsb3cgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDIjc2VjdGlvbi0zLjEiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMiNzZWN0aW9u LTMuMTwvYT4mbmJzcDtpcyBFWEFDVExZIHRoZSBzYW1lIGFzIHRoZSBHb29nbGUgYW5kIE1pY3Jv c29mdA0KIGZsb3dzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hpbGUgdGhlIGZsb3cgaW4mbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJv dG9jb2wtMDIjc2VjdGlvbi0zLjQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJkdC14YXV0aC1wcm90b2NvbC0wMiNzZWN0aW9uLTMuNDwvYT4mbmJzcDtoYXMgYWRkaXRpb25h bCBzdGVwcywgaXQgaXMgbm90IGZ1bmRhbWVudGFsbHkNCiBhbnkgZGlmZmVyZW50IGV4Y2VwdCB0 aGUgQ2xpZW50IGlzIG1ha2luZyBhbm90aGVyIGNhbGwgdG8gdGhlIEdTIGFmdGVyIHRoZSBmaXJz dCBvbmUgcmV0dXJucy4gVGhlIHJpc2sgb2YgdGhlIENsaWVudCBub3QgbWFraW5nIHRoZSBzZWNv bmQgY2FsbCBhbmQgbGVhdmluZyB0aGUgVXNlciBoYW5naW5nIGlzIG5vdCByZWFsbHkgYW55IGRp ZmZlcmVudCBvZiB0aGUgQ2xpZW50IG5vdCBtYWtpbmcgdGhlIGZpcnN0IGNhbGwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5CZXNpZGVzIHRoZSBzaXR1YXRpb24gd2hlcmUgdGhlIG1vYmlsZSBkZXZpY2UgdGhhdCBN QVkgbm90IGJlIGFibGUgdG8gbWFrZSB0aGUgc2Vjb25kIGNhbGwgbWlnaHQgcHV0IHRvIHNsZWVw LCBJIGRvbid0IHNlZSBhbnkgaW1wbGVtZW50YXRpb24gaXNzdWVzLiBUeEF1dGggd29ya3MgdGhl IHNhbWUgd2F5IGFzIDMuMSBhcyBJIHVuZGVyc3RhbmQgaXQgZm9yIG5vbi1yZWRpcmVjdA0KIGZs b3dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bcmljaGFubmFdPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+SSBkb27igJl0IHRoaW5rIHlvdSBhY3R1YWxseSByZWFkIHdoYXQgSSB3cm90ZS4g SWYgdGhlIGZsb3dzIGFyZSBleGFjdGx5IHRoZSBzYW1lLCB0ZWxsIG1lOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVm dDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwxMCBsZXZlbDEgbGZvOSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5XaGF0IGRvZXMgdGhlIHVzZXIgdGhpbmsgaXMgZ29pbmcgb24gd2hp bGUgdGhleeKAmXJlIHNpdHRpbmcgb24gdGhlIEdTLCB3YXRjaGluZyBhIHNwaW5uZXIgYXMgdGhl IEdTIHdhaXRzIGZvciB0aGUgQ2xpZW50IHRvIG1ha2UgYW4gVXBkYXRlIEdyYW50IHJlcXVlc3Qg aW4gMy40PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMTAgbGV2ZWwxIGxmbzkiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2hhdCBleGlzdGluZyBDbGllbnQgY29tcG9u ZW50IGlzIGhvbGRpbmcgb3BlbiB0aGUgUmVhZCBHcmFudCByZXF1ZXN0PzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS41aW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNiBsZXZl bDIgbGZvMTAiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+SWYgeW91ciBhbnN3ZXIgaXMg4oCcYW4gYXN5bmMgcHJvY2VzcyBvbiB0aGUgQ2xp ZW504oCZcyBzZXJ2ZXLigJ0gdGhlbiBwbGVhc2UgcmUtcmVhZCB0aGUgc2Vjb25kIHdvcmQgb2Yg dGhhdCBxdWVzdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MGluO21hcmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzExIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkhvdyBsb25nIHNob3VsZCB0aGUg R1Mgd2FpdCBmb3IgdGhlIENsaWVudCB0byBtYWtlIHRoZSBVcGRhdGUgR3JhbnQgcmVxdWVzdCBp biAzLjQ/IFdoYXQgc2hvdWxkIHRoZSBHUyBkbyBpZiB0aGF0IG5ldmVyIGhhcHBlbnM/IFdoYXQg aXMgdGhlIHBhdGggZm9yd2FyZCBmb3IgdGhlIGVuZCB1c2VyLCBhdCB0aGF0IHBvaW50PzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3Bhc3RpbmcgaW4gZnJvbSB5 b3VyIGxhdGVyIGVtYWlsXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+V2hpbGUgYSBzaW5nbGUgc3RhZ2UgR3JhbnQgcmVxdWVzdCAoMy4xKSBpbiBhIG1vYmls ZSBhcHAgdGhhdCBoYXMgYmVlbiBwdXQgdG8gc2xlZXAgd2lsbCByZWNvdmVyIGZpbmUsIGEgbXVs dGktc3RlcCAoMy40KSB3aWxsIGZhaWwuIFNpbmNlIDMuNCBvbmx5IG1ha2VzIHNlbnNlIGlmIHRo ZSBDbGllbnQgaXMgY2hlY2tpbmcgYSBkYXRhYmFzZSBhbG9uZyB0aGUgd2F5LA0KIEkgd291bGQm bmJzcDtleHBlY3QgdGhlIENsaWVudCB0byBoYXZlIGEgc2VydmVyIHNpZGUsIGFuZCB0aGUgc2Vy dmVyIGNvdWxkIHRha2UgZWFjaCBzdGVwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5bL2VuZCBwYXN0ZV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+SGF2aW5nIGEgcmVtb3RlIGRhdGFiYXNlIGFuZCBoYXZpbmcgYSByZW1vdGUgc2Vy dmVyIGFyZSBub3QgdGhlIHNhbWUgdGhpbmcuIFRoaXMgYWRkcyBhIGxvdCBvZiBjb21wbGV4aXR5 IHRvIHNlcnZlcmxlc3MgYXBwcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Wy9yaWNoYW5uYV08aW1nIGJvcmRlcj0iMCIgaWQ9ImdtYWlsLW1fLTEzOTEzNjY4 MjgzNjc0MjIzMzBfeDAwNWZfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFw cHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5 cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9N2NkMThlYTYtOGM1MC00NmRjLWJlMjUtZTk5ZjYxNGRh YjgyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVn aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldoaWNoIGFzcGVj dCBhZGRzIGNvbXBsZXhpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgYWRkZWQgY29tcGxleGl0eSBpbiBr ZWVwaW5nIGFuIGludGVyYWN0aW9uIGlzIG1ha2luZyBhbiBhZGRpdGlvbmFsIEFQSSBjYWxsIGFm dGVyIHRoZSBmaXJzdCBBUEkgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5bcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGlzc3VlIGlz buKAmXQgdGhlIEFQSSBjYWxsIGl0c2VsZiwgaXTigJlzIHRoZSBuZWVkIGZvciB0aGUgQ2xpZW50 IHRvIG1haW50YWluIGEgcGVyc2lzdGVudCwgYXN5bmNocm9ub3VzIHByb2Nlc3MgdG8gbWFrZSB0 aGF0IEFQSSBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkl0IGlzIGluY29ycmVjdCB0byBhc3N1bWUgdGhhdCBldmVyeSBhcHAgd2l0aCBhIGRhdGFi YXNlIHdpbGwgbmVjZXNzYXJpbHkgaGF2ZSBhIHNlcnZlciBzaWRlLiBBIHNlcnZlcmxlc3MgYXBw IHRoYXQgZG9lcyBhIHJlZGlyZWN0IHRvIHRoZSBHUywgb3IgdGhhdCBzd2l0Y2hlcyB0byBhbiBl eHRlcm5hbCBicm93c2VyIChhbmQgdGh1cyBtYXkgYmUgcHV0IHRvIHNsZWVwKQ0KIGhhcyBubyBj b21wb25lbnQgdGhhdCB3aWxsIHJlbGlhYmx5IHN0YXkgYWxpdmUgdG8gaG9sZCBvcGVuIHRoZSBS ZWFkIEdyYW50IHJlcXVlc3QsIHJlY2VpdmUgdGhlIHJlc3BvbnNlLCBhbmQgZm9sbG93IHVwIHdp dGggYW4gVXBkYXRlIEdyYW50IHJlcXVlc3QgKGkuZS4sIGZsb3cgMy40KS4gQWRkaW5nIGEgc2Vy dmVyLXNpZGUgY29tcG9uZW50IHRvIGRvIHRoaXMgb3JjaGVzdHJhdGlvbiBhZGRzIHNpZ25pZmlj YW50IGNvbXBsZXhpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNo YW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4tLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4tLTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5UeGF1dGhAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90eGF1dGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CB00CB6A57454670BE30393824A06D15amazoncom_-- From nobody Mon Feb 17 18:47:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06107120871 for ; Mon, 17 Feb 2020 12:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 wRWFAVfZCaIb for ; Mon, 17 Feb 2020 12:28:29 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6FE7A12086D for ; Mon, 17 Feb 2020 12:28:28 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01HKSO7V021930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 15:28:24 -0500 From: Justin Richer Message-Id: <69ED9ADA-BFAB-458D-AFA2-CCCEAFDCBC88@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B61BB7D-2B26-4A07-A402-66321B432E3C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 17 Feb 2020 15:28:24 -0500 In-Reply-To: Cc: "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 20:28:34 -0000 --Apple-Mail=_1B61BB7D-2B26-4A07-A402-66321B432E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ah yes, looks like the website is out of date =E2=80=94 that note dates = to a previous iteration where we had an explicit =E2=80=9Ctype=E2=80=9D = field and we were already seeing the limitations of that style. You=E2=80=99= re right that the spec, the actual text on the website=E2=80=99s = examples, and our implementation all allow combining these two. In fact, = there=E2=80=99s an example of it on that page! You can absolutely poll = and wait for a callback, both use a transaction continuation request. = I=E2=80=99ll clean that up, thanks!=20 And in the XYZ model, =E2=80=9Csend the response to this URL=E2=80=9D = would be a different interaction type to be requested from the client if = it=E2=80=99s got a different set of considerations than the callback = URL. However, I=E2=80=99m curious what =E2=80=9Cthe response=E2=80=9D = would be in that case. Are we talking a front-channel response, still, = like the implicit flow? Or are we looking for a way to push information = back to the client in the back channel? If it=E2=80=99s the latter, then = that=E2=80=99s definitely a different interaction style. And one of the = good things in XYZ is that getting info back to the client is now = decoupled from how you get the user involved, so the user could enter a = code or go to a long (or short) arbitrary URL, and the client=E2=80=99s = means of getting to the next step are the same menu of options = regardless.=20 =E2=80=94 Justin > On Feb 17, 2020, at 1:54 PM, Richard Backman, Annabelle = wrote: >=20 > XYZ is a lot closer to what I=E2=80=99m describing, but it still = conflates =E2=80=9Credirect to this URL after the workflow=E2=80=9D with = =E2=80=9Csend the response to this URL=E2=80=9D. I *think* the draft as = written would allow a Client to provide a callback but also poll for the = response, but it=E2=80=99s not very clear. This kind of flow where the = Client is actually split between device, backend, and webapp within a = single transaction is one that deserves more attention, IMHO. > =20 > This note on https://oauth.xyz/interaction/ = also suggests XYZ is more limited than = it needs to be, but the draft seems to allow for this already so maybe = this note is just be out of date? > =20 > It would be interesting to figure out if we can combine both the user = code and arbitrary redirect URL methods, giving the user a few options. = This should be as simple as allowing more flexibility on the interaction = request portion and having the server return all possible options. > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Justin Richer > > Date: Saturday, February 15, 2020 at 2:51 PM > To: "Richard Backman, Annabelle" > > Cc: "txauth@ietf.org " > > Subject: [UNVERIFIED SENDER] Re: [Txauth] XAuth -02 > =20 > The interaction model that Annabelle describes below is exactly the = kind of thing that=E2=80=99s in XYZ: > =20 > https://oauth.xyz/interaction/ > =20 > An earlier implementation of XYZ had a =E2=80=9Ctype=E2=80=9D field = like XAuth does. You can see that here: > =20 > = https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2.= 4 = > =20 > We moved away from it for all of the reasons Annabelle is citing, = along with the others I=E2=80=99ve stated previously on the list that I = don=E2=80=99t feel bear repeating again. Having implemented both = patterns directly in the same project, I can attest that the code paths = are significantly simpler for the current XYZ pattern, especially on = the Authorization Server. You can look at our code yourselves, if you = like. > =20 > And for the =E2=80=9Csimple=E2=80=9D client case that supports only = one type (which I think we all believe will be the overwhelmingly common = case), I want to point out that the XYZ approach and the XAuth approach = are for all intents and purposes identical. The XYZ approach allows for = a lot more flexibility along with a decrease in complexity.=20 > =20 > =E2=80=94 Justin > =20 >=20 >=20 >> On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle = > wrote: >> =20 >> [richanna] >> Replies inline. >> [/richanna] >> =20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> =20 >> =20 >> From: Txauth > on behalf of Dick Hardt = > >> Date: Friday, February 14, 2020 at 9:10 AM >> To: "Richard Backman, Annabelle" = > >> Cc: "txauth@ietf.org " > >> Subject: Re: [Txauth] XAuth -02 >> =20 >> =20 >> =20 >> On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle = > wrote: >>> [richanna] >>> Replies inline >>> [/richanna]=20 >>> >>> [richanna] >>> By user code-based interaction, I mean the kind described in the = OAuth 2.0 Device Authorization Grant = , where the user receives a code and = short URL from the client, navigates to that URL in a browser, and = enters the code. While this could be packed into interaction.message, = this will lead to clunkier user experiences: >>> 1. The GS may not be able to provide localized instructions that = match the locale on the Client. >>>=20 >>> 2. Suppose the GS sends a message that reads: =E2=80=9CScan the QR = code or open a browser to http://code.example/ = and enter the code: 12345.=E2=80=9D >>>=20 >>> a. That instruction does not make sense on a device that does not = present a QR code. Imagine hearing that from a smart speaker. >>>=20 >>> b. That instruction is confusingly redundant if the Client = displays the QR code along with its own instructions, like: =E2=80=9CScan = the QR code or follow the instructions below.=E2=80=9D >>>=20 >>> 3. Will =E2=80=9Cembed the short URL and code in the message = string=E2=80=9D be MTI? If not, text-only clients would have a broken = experience. >>>=20 >>> [/richanna] >> =20 >> Sounds like a text only interaction type should be added per my note = in the draft. Perhaps even one that is focused on the code flow, where = the parameters are the code and the URI to enter the code, letting the = Client present the parameters with localized content? >> =20 >> [richanna] >> I think we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80=9D = concept wrong. We=E2=80=99re conflating three different things together: >> =C2=B7 What does the Client need to send the end user to the = GS? >> o A human-friendly short URL and code. >> o Any kind of URL, as long and ugly as it needs to be. >> =C2=B7 How will the Client receive the response from the GS? >> o Client will make a request to the GS. >> o GS will make a request to the Client. (I=E2=80=99ve had to = implement this for a custom integration, including it to demonstrate = that other options exist) >> =C2=B7 Will the GS return the end user to the Client, and if = so how? >> o Yes, by URL redirect. >> o No. >> =20 >> Here is a very non-normative example request fragment, for a client = that wants both a short URL plus code and a full URL so they can = opportunistically use one or the other (AWS CLI v2 does this), will = query the GS for the response, and wants the GS to redirect to a = publicly accessible URL on the Client=E2=80=99s website after the flow = (e.g., to show further documentation/branded content to the end user): >> { >> "interact": { >> "code": { "max": 8 }, >> "url": true >> }, >> "response": { >> "poll": true >> }, >> "return": { >> "url": "https://help.smartdevice.example/post-setup = " >> } >> } >> =20 >> And here is an equally non-normative example response fragment: >> { >> "interact": { >> "code": "123456", >> "code_url": "https://gs.example/code ", >> "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef = " >> } >> } >> =20 >> (Seriously do not read too much into these parameter names or syntax, = this is just to give a rough sense of how I=E2=80=99m thinking about = this. Anyone who tries to pick apart this example will be responded to = with mocking memes.) >> [/richanna] >>> =20 >>> =20 >>>> 2. Clients support multiple interaction modes and may not always = know what the GS supports (and vice-versa). For a multi-tenant GS, it = may vary by tenant configuration. Clients should be able to say what = they can do, and the GS should be able to tell them which one to use. = It=E2=80=99s a very simple but powerful inline negotiation. >>> =20 >>> That is what is in TxAuth. Would you elaborate on how the GS might = be constrained? Why would the GS not be able to do all? >>> =20 >>> I would think all constraints would be at the Client. Am I missing = something? >>> =20 >>> [richanna] >>> Clients may support customer-defined GSes (e.g., enterprise IdPs), = which will vary in terms of which interaction modes they support. While = the set of interactions defined in XAuth might all be MTI for a GS, we = should assume that extensions will introduce new interactions which will = not be universally supported. An interaction mechanism might have = properties that cause some administrators to want to disable it, or to = restrict Clients to always use it. Are you assuming that a Client will = always make an OPTIONS discovery request first? >>> [/richanna]=20 >> =20 >> An example of why a given GS may not support a mode would be helpful. >> =20 >> I was envisioning that if an optional to support interaction mode was = not supported at the GS, that it would return an error. The Client would = then try a different one. Alternatively, the Client could start with an = OPTIONS call in cases where the GS is dynamicly chosen. >> =20 >> [richanna] >> Lots of ASes don=E2=80=99t support Device Authorization Grant. I = think it=E2=80=99s safe to assume that interaction mode support will = vary for XAuth as well. =E2=80=9CKeep trying until you find one that = works=E2=80=9D sounds pretty painful for the client, and doesn=E2=80=99t = allow the client to use multiple interaction modes, as demonstrated in = my example above. >> =20 >> There are lots of reasons for wanting to support multiple modes: >> =C2=B7 Some people are comfortable with QR codes, some = aren=E2=80=99t. >> =C2=B7 Some people have smart phones that can scan them, some = don=E2=80=99t. >> =C2=B7 People with smart phones may want to go through the = authentication flow on their desktop instead. >> =C2=B7 Some people may have to go through the authentication = flow on their desktop, because the GS thinks iPhones only support = Bluetooth-based security keys and insists they cannot complete the login = flow even though they have two YubiKey 5Ci keys on their account. (HI, = GOOGLE ACCOUNT PROTECTION PROGRAM) >> [/richanna] >>> =20 >>>> 3. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D = interaction mode. Clients can use =E2=80=9Credirect=E2=80=9D mode within = popups. However, speaking as someone who has done that, I really don=E2=80= =99t recommend it. Popups are increasingly unsupported, and prone to = weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend = to have popups disabled. The last versions of IE Mobile didn=E2=80=99t = support them at all (the popped up page basically just loaded into the = current window).. in=20 >>> =20 >>> Popups are really useful in single-page apps as you want to keep the = context and not reload the page. >>> =20 >>> Agree that popups don't make sense in mobile. A full redirect does = of course. A single-page app on mobile would open a new tab which would = be a separate context rather than a redirect. >>> =20 >>> [richanna] >>> Popups are broken and/or disabled in enough instances that we should = not encourage their usage by including explicit support for them in the = protocol. Nor are they necessary for SPAs in order to restore the state = of their app after the redirect. >> =20 >> Are they really that broken in desktop? I've used them extensively = myself in the past as it was a better user experience, but that was a = few years ago. >> =20 >> [richanna] >> Popup blockers are built in and aggressively enabled by default on = all major browsers. Communicating securely between windows is not easy, = and from past experience prone to failure thanks to weird browser bugs. = Trusted Site settings in IE and Edge can blow the whole thing up in = weird ways (speaking again from experience). >> =20 >> Also, it=E2=80=99s 2020. Stop branching on mobile vs. desktop. I get = that lots of people still do that, but that doesn=E2=80=99t mean the = protocol should cater to it. >> [/richanna] >>> And again, a Client that really wants to give themselves a headache = with popups can do that themselves using =E2=80=9Credirect=E2=80=9D = mode. They just have to provide a landing page for the GS to redirect = back to that parses the response, passes it back to the main window, and = closes itself. I don=E2=80=99t see why the protocol would need to = explicitly describe this mechanism.=20 >>> [/richanna] >> =20 >> I think it is a useful signal for the GS in the experience it wants = to show the user. >> =20 >> [richanna] >> Useful how? The window dimensions are a better signal for how to = present the user experience. (*cough* responsive design *cough*) >> [/richanna] >>> =20 >>>> Section 12.6: >>>> [Editor: is there some other reason to have the UserInfo >>>> endpoint?] >>>> =20 >>>> I may want to host my UserInfo endpoint on a separate microservice = from my token endpoint (in OAuth 2.0/OIDC terms). The former might be = part of my user profile/directory stack, while the latter is part of the = highly privileged authentication/authorization stack. >>> =20 >>> =20 >>> The token endpoint has the access token anyway, so it can fetch the = data from the other endpoint itself if it wanted to. IE, there is no = separation of duties. >>> =20 >>> What are the advantages of the UserInfo endpoint to the User or = Client?=20 >>> =20 >>> The UserInfo endpoint seems to just add more complexity, with no = ability to start a User interaction if additional consent is needed. >>> =20 >>> [richanna] >>> If the access token is sender-constrained, then no, the token = endpoint can=E2=80=99t fetch the data itself. But even without the = security angle, there is value in separating out the functionality as it = allows the GS to distribute it across systems with different owners. = E.g., there might be a directory API team that also owns the SCIM = interface and UserInfo endpoint. >> =20 >> An implementation can also route calls to different internal systems = while keeping the same endpoint. >> =20 >> I also think of SCiM and UserInfo as very different endpoints. I = would consider SCIM a resource, and UserInfo claims. I appreciate those = are similar in enterprise, but they are not in consumer contexts. >> =20 >> [richanna] >> Routing calls to different internal systems still means I have to = have some shared infrastructure that both teams manage. It=E2=80=99s = more complex than it needs to be. >> =20 >> I=E2=80=99m going to suggest we move this part of the discussion to a = separate thread because it=E2=80=99s too messy to keep in this awful = back-and-forth. I=E2=80=99ll just add here that I=E2=80=99m not = suggesting we only have a UserInfo endpoint. I=E2=80=99m arguing two = things: >> 1. The UserInfo endpoint is good, actually. It doesn=E2=80=99t = need to be MTI, but we should not preclude its existence. >> 2. If we provide a mechanism for requesting and receiving = claims in the GS Read Grant response, that mechanism should apply = generically to arbitrary resources. GSes can support it or not, for any = given resource. >> [/richanna] >> =20 >> >>> [richanna] >>> There are two big differences between those examples (e.g., QR Code, = app-based login approvals) and this mechanism in XAuth: >>> 1. In your examples of this behavior today, the reason for the = wait is clear and obvious, and driven by the user. E.g., my printer is = waiting for me to go enter this code and log in; Google sign in is = waiting for me to tap this button on my phone. That is not the case in = the XAuth protocol. The user is left sitting on a loading screen waiting = for a behind-the-scenes interaction between client and GS that may not = even happen. >>>=20 >>> 2. Unlike with code/QR flows or sign-in verification, there is no = active process on the client side to keep this async request open. A web = app client would have to introduce a server-side async process to manage = this aspect of the protocol. That=E2=80=99s not easy. >>>=20 >>> 3. The failure modes show up in more appropriate contexts, where = there are clear paths forward for the end user. In code/QR-based flows, = it=E2=80=99s detected on the client side, in the form of an AS that = never provides a response. In that scenario, the client can retry the = process. In sign-in verification, the problem occurs between two parts = of the AS, and the AS can allow the end user to retry or to use a = different authentication method. In the XAuth Create+Update scenario, = the failure is detected on the GS, and there is no clear path forward. = If the Client never calls Update Grant to flip interaction.keep to = false, what should the GS do? How long should it wait? Should it issue = the authorization anyway, assuming the Client will come back and ask for = it at some point? Should it redirect the end user back to the Client = anyway, or drop them on a landing page? Should it flag this as an error, = or is this the expected behavior for the Client? >>>=20 >>> =20 >>> I really think this is overcomplicating the protocol to an extent = that no one will actually implement it. >>> [/richanna] >> =20 >> The flow in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 = = is EXACTLY the same as the Google and Microsoft flows.=20 >> =20 >> While the flow in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 = = has additional steps, it is not fundamentally any different except the = Client is making another call to the GS after the first one returns. The = risk of the Client not making the second call and leaving the User = hanging is not really any different of the Client not making the first = call. >> =20 >> Besides the situation where the mobile device that MAY not be able to = make the second call might put to sleep, I don't see any implementation = issues. TxAuth works the same way as 3.1 as I understand it for = non-redirect flows. >> =20 >> [richanna] >> I don=E2=80=99t think you actually read what I wrote. If the flows = are exactly the same, tell me: >> 1. What does the user think is going on while they=E2=80=99re = sitting on the GS, watching a spinner as the GS waits for the Client to = make an Update Grant request in 3.4? >> 2. What existing Client component is holding open the Read = Grant request? >> a. If your answer is =E2=80=9Can async process on the = Client=E2=80=99s server=E2=80=9D then please re-read the second word of = that question. >> 3. How long should the GS wait for the Client to make the = Update Grant request in 3.4? What should the GS do if that never = happens? What is the path forward for the end user, at that point? >> [/richanna] >>> =20 >>> [pasting in from your later email] >>> While a single stage Grant request (3.1) in a mobile app that has = been put to sleep will recover fine, a multi-step (3.4) will fail. Since = 3.4 only makes sense if the Client is checking a database along the way, = I would expect the Client to have a server side, and the server could = take each step. >>> [/end paste] >>> =20 >>> [richanna] >>> Having a remote database and having a remote server are not the same = thing. This adds a lot of complexity to serverless apps. >>> [/richanna]=E1=90=A7 >> =20 >> Which aspect adds complexity? >> =20 >> The added complexity in keeping an interaction is making an = additional API call after the first API call. >> =20 >> [richanna] >> The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need = for the Client to maintain a persistent, asynchronous process to make = that API call. >> =20 >> It is incorrect to assume that every app with a database will = necessarily have a server side. A serverless app that does a redirect to = the GS, or that switches to an external browser (and thus may be put to = sleep) has no component that will reliably stay alive to hold open the = Read Grant request, receive the response, and follow up with an Update = Grant request (i.e., flow 3.4). Adding a server-side component to do = this orchestration adds significant complexity. >> [/richanna] >> =20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = > =20 --Apple-Mail=_1B61BB7D-2B26-4A07-A402-66321B432E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ah = yes, looks like the website is out of date =E2=80=94 that note dates to = a previous iteration where we had an explicit =E2=80=9Ctype=E2=80=9D = field and we were already seeing the limitations of that style. You=E2=80=99= re right that the spec, the actual text on the website=E2=80=99s = examples, and our implementation all allow combining these two. In fact, = there=E2=80=99s an example of it on that page! You can absolutely poll = and wait for a callback, both use a transaction continuation request. = I=E2=80=99ll clean that up, thanks! 

And in the XYZ model, =E2=80=9Csend the = response to this URL=E2=80=9D would be a different interaction type to = be requested from the client if it=E2=80=99s got a different set of = considerations than the callback URL. However, I=E2=80=99m curious what = =E2=80=9Cthe response=E2=80=9D would be in that case. Are we talking a = front-channel response, still, like the implicit flow? Or are we looking = for a way to push information back to the client in the back channel? If = it=E2=80=99s the latter, then that=E2=80=99s definitely a different = interaction style. And one of the good things in XYZ is that getting = info back to the client is now decoupled from how you get the user = involved, so the user could enter a code or go to a long (or short) = arbitrary URL, and the client=E2=80=99s means of getting to the next = step are the same menu of options regardless. 

 =E2=80=94 = Justin

On Feb 17, 2020, at 1:54 PM, Richard Backman, = Annabelle <richanna@amazon.com> wrote:

XYZ is a = lot closer to what I=E2=80=99m describing, but it still conflates = =E2=80=9Credirect to this URL after the workflow=E2=80=9D with =E2=80=9Cse= nd the response to this URL=E2=80=9D. I *think* the = draft as written would allow a Client to provide a callback but also = poll for the response, but it=E2=80=99s not very clear. This kind of = flow where the Client is actually split between device, backend, and = webapp within a single transaction is one that deserves more attention, = IMHO.
 
This note = on https://oauth.xyz/interaction/ also suggests XYZ is more = limited than it needs to be, but the draft seems to allow for this = already so maybe this note is just be out of date?
 
It = would be interesting to figure out if we can combine both the user code = and arbitrary redirect URL methods, giving the user a few options. This = should be as simple as allowing more flexibility on the interaction = request portion and having the server return all possible options.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Justin Richer <jricher@mit.edu>
Date: Saturday, February 15, = 2020 at 2:51 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: = [Txauth] XAuth -02
 
The interaction model that Annabelle describes below is = exactly the kind of thing that=E2=80=99s in XYZ:
 
https://oauth.xyz/interaction/
 
An earlier implementation of XYZ had a = =E2=80=9Ctype=E2=80=9D field like XAuth does. You can see that here:
 
https://tools.ietf.org/html/draft-richer-transactional-authz-00= #section-2.4
 
We moved away from it for all of the reasons = Annabelle is citing, along with the others I=E2=80=99ve stated = previously on the list that I don=E2=80=99t feel bear repeating again. = Having implemented both patterns directly in the same project, I can = attest that the code paths are significantly simpler  for the = current XYZ pattern, especially on the Authorization Server. You can = look at our code yourselves, if you like.
 
And for the =E2=80=9Csimple=E2=80=9D = client case that supports only one type (which I think we all believe = will be the overwhelmingly common case), I want to point out that the = XYZ approach and the XAuth approach are for all intents and purposes = identical. The XYZ approach allows for a lot more flexibility along with = a decrease in complexity. 
 
 =E2=80=94 Justin
 


On Feb 14, 2020, at 9:29 PM, Richard = Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
 
[richanna]
Replies inline.
[/richanna]
 
=E2=80=93
Annabelle Backman = (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 14, = 2020 at 9:10 AM
To: "Richard Backman, = Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] XAuth = -02
 
 
 
On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
[richanna]
Replies inline
[/richanna] 
<snip>
[richanna]
By user code-based = interaction, I mean the kind described in the OAuth 2.0 = Device Authorization Grant, where the user receives a code and short = URL from the client, navigates to that URL in a browser, and enters the = code. While this could be packed into interaction.message, this will = lead to clunkier user experiences:

1.   The GS may not be = able to provide localized instructions that match the locale on the = Client.

2.   Suppose the GS sends = a message that reads: =E2=80=9CScan the QR code or open a browser = to http://code.example/ and enter the code: = 12345.=E2=80=9D

a.    That instruction = does not make sense on a device that does not present a QR code. Imagine = hearing that from a smart speaker.

b.   That instruction is = confusingly redundant if the Client displays the QR code along with its = own instructions, like: =E2=80=9CScan the QR code or follow the = instructions below.=E2=80=9D

3.   Will =E2=80=9Cembed = the short URL and code in the message string=E2=80=9D be MTI? If not, = text-only clients would have a broken experience.

[/richanna]
 
Sounds like a text only interaction type should be added per = my note in the draft. Perhaps even one that is focused on the code flow, = where the parameters are the code and the URI to enter the code, letting = the Client present the parameters with localized content?
 
[richanna]
I think we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80= =9D concept wrong. We=E2=80=99re conflating three different things = together:

=C2=B7         What = does the Client need to send the end user to the GS?

o    A = human-friendly short URL and code.

o    Any = kind of URL, as long and ugly as it needs to be.

=C2=B7         How = will the Client receive the response from the GS?

o    Client = will make a request to the GS.

o    GS = will make a request to the Client. (I=E2=80=99ve had to implement this = for a custom integration, including it to demonstrate that other options = exist)

=C2=B7         Will = the GS return the end user to the Client, and if so how?

o    Yes, = by URL redirect.

o    No.

 
Here is a very non-normative example request fragment, for a = client that wants both a short URL plus code and a full URL so they can = opportunistically use one or the other (AWS CLI v2 does this), will = query the GS for the response, and wants the GS to redirect to a = publicly accessible URL on the Client=E2=80=99s website after the flow = (e.g., to show further documentation/branded content to the end = user):
{
"interact": {
  "code": { "max": 8 },
  "url": true
},
"response": {
  = "poll": true
},
"return": {
}
}
 
And here is an = equally non-normative example response fragment:
{
"interact": {
  = "code": "123456",
  = "code_url": "https://gs.example/code",
  "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef"=
}
}
 
(Seriously do not = read too much into these parameter names or syntax, this is just to give = a rough sense of how I=E2=80=99m thinking about this. Anyone who tries = to pick apart this example will be responded to with mocking memes.)
[/richanna]
 
 
2.   Clients support = multiple interaction modes and may not always know what the GS supports = (and vice-versa). For a multi-tenant GS, it may vary by tenant = configuration. Clients should be able to say what they can do, and the = GS should be able to tell them which one to use. It=E2=80=99s a very = simple but powerful inline negotiation.
 
That is what is in TxAuth. Would you = elaborate on how the GS might be constrained? Why would the GS not be = able to do all?
 
I would think all constraints would be at the Client. Am I = missing something?
 
[richanna]
Clients may support customer-defined GSes (e.g., enterprise = IdPs), which will vary in terms of which interaction modes they support. = While the set of interactions defined in XAuth might all be MTI for a = GS, we should assume that extensions will introduce new interactions = which will not be universally supported. An interaction mechanism might = have properties that cause some administrators to want to disable it, or = to restrict Clients to always use it. Are you assuming that a Client = will always make an OPTIONS discovery request first?
[/richanna] 
 
An example of why a given GS may not support a mode would be = helpful.
 
I was envisioning that if an optional = to support interaction mode was not supported at the GS, that it would = return an error. The Client would then try a different one. = Alternatively, the Client could start with an OPTIONS call in cases = where the GS is dynamicly chosen.
 
[richanna]
Lots of ASes don=E2=80=99t support Device Authorization = Grant. I think it=E2=80=99s safe to assume that interaction mode support = will vary for XAuth as well. =E2=80=9CKeep trying until you find one = that works=E2=80=9D sounds pretty painful for the client, and doesn=E2=80=99= t allow the client to use multiple interaction modes, as demonstrated in = my example above.
 
There are lots of reasons for wanting to support multiple = modes:

=C2=B7         Some = people are comfortable with QR codes, some aren=E2=80=99t.

=C2=B7         Some = people have smart phones that can scan them, some don=E2=80=99t.

=C2=B7         People = with smart phones may want to go through the authentication flow on = their desktop instead.

=C2=B7         Some = people may have to = go through the authentication flow on their desktop, because the GS = thinks iPhones only support Bluetooth-based security keys and insists = they cannot complete the login flow even though they have two YubiKey = 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)

[/richanna]
 
3.   I don=E2=80=99t see = the value of the =E2=80=9Cpopup=E2=80=9D interaction mode. Clients can = use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking as = someone who has done that, I really don=E2=80=99t recommend it. Popups = are increasingly unsupported, and prone to weird behavioral issues. = In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. = The last versions of IE Mobile didn=E2=80=99t support them at all (the = popped up page basically just loaded into the current window).. = in 
 
Popups are really useful in single-page apps as you want to = keep the context and not reload the page.
 
Agree that popups don't make sense in = mobile. A full redirect does of course. A single-page app on mobile = would open a new tab which would be a separate context rather than a = redirect.
 
[richanna]
Popups are broken and/or disabled in enough instances that we = should not encourage their usage by including explicit support for them = in the protocol. Nor are they necessary for SPAs in order to restore the = state of their app after the redirect.
 
Are they really that broken in desktop? I've used them = extensively myself in the past as it was a better user experience, but = that was a few years ago.
 
[richanna]
Popup blockers are = built in and aggressively enabled by default on all major browsers. = Communicating securely between windows is not easy, and from past = experience prone to failure thanks to weird browser bugs. Trusted Site = settings in IE and Edge can blow the whole thing up in weird ways = (speaking again from experience).
 
Also, it=E2=80=99s 2020. Stop branching on mobile vs. = desktop. I get that lots of people still do that, but that doesn=E2=80=99t= mean the protocol should cater to it.
[/richanna]
And again, a Client that really wants to give themselves a = headache with popups can do that themselves using =E2=80=9Credirect=E2=80=9D= mode. They just have to provide a landing page for the GS to redirect = back to that parses the response, passes it back to the main window, and = closes itself. I don=E2=80=99t see why the protocol would need to = explicitly describe this mechanism. 
[/richanna]
 
I think it is a useful signal for the GS in the experience it = wants to show the user.
 
[richanna]
Useful = how? The window dimensions are a better signal for how to present the = user experience. (*cough* responsive design *cough*)
[/richanna]
 
Section = 12.6:
        [Editor: is there =
some other reason to have the UserInfo
        endpoint?]
 
I may want to host = my UserInfo endpoint on a separate microservice from my token endpoint = (in OAuth 2.0/OIDC terms). The former might be part of my user = profile/directory stack, while the latter is part of the highly = privileged authentication/authorization stack.
 
 
The token endpoint has the access token anyway, so it can = fetch the data from the other endpoint itself if it wanted to. IE, there = is no separation of duties.
 
What are the advantages of the UserInfo endpoint to the User = or Client? 
 
The UserInfo endpoint seems to just add more complexity, with = no ability to start a User interaction if additional consent is = needed.
 
[richanna]
If the access token is sender-constrained, then no, the token = endpoint can=E2=80=99t fetch the data itself. But even without the = security angle, there is value in separating out the functionality as it = allows the GS to distribute it across systems with different owners. = E.g., there might be a directory API team that also owns the SCIM = interface and UserInfo endpoint.
 
An implementation can also route calls to different internal = systems while keeping the same endpoint.
 
I also think of SCiM and UserInfo as = very different endpoints. I would consider SCIM a resource, and UserInfo = claims. I appreciate those are similar in enterprise, but they are not = in consumer contexts.
 
[richanna]
Routing calls to = different internal systems still means I have to have some shared = infrastructure that both teams manage. It=E2=80=99s more complex than it = needs to be.
 
I=E2=80=99m going to suggest we move this part of the = discussion to a separate thread because it=E2=80=99s too messy to keep = in this awful back-and-forth. I=E2=80=99ll just add here that I=E2=80=99m = not suggesting we only have= a UserInfo endpoint. I=E2=80=99m arguing two things:

1.       The UserInfo = endpoint is good, actually. It doesn=E2=80=99t need to be MTI, but we = should not preclude its existence.

2.       If we provide = a mechanism for requesting and receiving claims in the GS Read Grant = response, that mechanism should apply generically to arbitrary = resources. GSes can support it or not, for any given resource.

[/richanna]
 
<snip>
[richanna]
There are two big differences between those examples (e.g., = QR Code, app-based login approvals) and this mechanism in XAuth:

1.   In your examples of = this behavior today, the reason for the wait is clear and obvious, and = driven by the user. E.g., my printer is waiting for me to go enter this = code and log in; Google sign in is waiting for me to tap this button on = my phone. That is not the case in the XAuth protocol. The user is left = sitting on a loading screen waiting for a behind-the-scenes interaction = between client and GS that may not even happen.

2.   Unlike with code/QR = flows or sign-in verification, there is no active process on the client = side to keep this async request open. A web app client would have to = introduce a server-side async process to manage this aspect of the = protocol. That=E2=80=99s not easy.

3.   The failure modes = show up in more appropriate contexts, where there are clear paths = forward for the end user. In code/QR-based flows, it=E2=80=99s detected = on the client side, in the form of an AS that never provides a response. = In that scenario, the client can retry the process. In sign-in = verification, the problem occurs between two parts of the AS, and the AS = can allow the end user to retry or to use a different authentication = method. In the XAuth Create+Update scenario, the failure is detected on = the GS, and there is no clear path forward. If the Client never calls = Update Grant to flip interaction.keep to false, what should the GS do? = How long should it wait? Should it issue the authorization anyway, = assuming the Client will come back and ask for it at some point? Should = it redirect the end user back to the Client anyway, or drop them on a = landing page? Should it flag this as an error, or is this the expected = behavior for the Client?

 
I really think this is overcomplicating the protocol to an = extent that no one will actually implement it.
[/richanna]
 
The flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#secti= on-3.1 is EXACTLY the same as the Google and Microsoft = flows. 
 
While the flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#secti= on-3.4 has additional steps, it is not fundamentally any = different except the Client is making another call to the GS after the = first one returns. The risk of the Client not making the second call and = leaving the User hanging is not really any different of the Client not = making the first call.
 
Besides the situation where the mobile device that MAY not be = able to make the second call might put to sleep, I don't see any = implementation issues. TxAuth works the same way as 3.1 as I understand = it for non-redirect flows.
 
[richanna]
I don=E2=80=99t = think you actually read what I wrote. If the flows are exactly the same, = tell me:

1.       What does the = user think is going on while they=E2=80=99re sitting on the GS, watching = a spinner as the GS waits for the Client to make an Update Grant request = in 3.4?

2.       What existing = Client component is holding open the Read Grant request?

a.       If your = answer is =E2=80=9Can async process on the Client=E2=80=99s server=E2=80=9D= then please re-read the second word of that question.

3.       How long = should the GS wait for the Client to make the Update Grant request in = 3.4? What should the GS do if that never happens? What is the path = forward for the end user, at that point?

[/richanna]
 
[pasting in from = your later email]
While a single stage Grant request (3.1) in a mobile app that = has been put to sleep will recover fine, a multi-step (3.4) will fail. = Since 3.4 only makes sense if the Client is checking a database along = the way, I would expect the Client to have a server side, and the = server could take each step.
[/end paste]
 
[richanna]
Having a remote database and having a remote server are not = the same thing. This adds a lot of complexity to serverless apps.
[/richanna]=E1=90=A7
 
Which aspect adds complexity?
 
The added complexity in keeping an = interaction is making an additional API call after the first API = call.
 
[richanna]
The issue isn=E2=80=99= t the API call itself, it=E2=80=99s the need for the Client to maintain = a persistent, asynchronous process to make that API call.
 
It is incorrect to assume that every = app with a database will necessarily have a server side. A serverless = app that does a redirect to the GS, or that switches to an external = browser (and thus may be put to sleep) has no component that will = reliably stay alive to hold open the Read Grant request, receive the = response, and follow up with an Update Grant request (i.e., flow 3.4). = Adding a server-side component to do this orchestration adds significant = complexity.
[/richanna]
 
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
 

= --Apple-Mail=_1B61BB7D-2B26-4A07-A402-66321B432E3C-- From nobody Mon Feb 17 18:49:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C2120041 for ; Mon, 17 Feb 2020 14:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fp5Myl0iy4o for ; Mon, 17 Feb 2020 14:10:22 -0800 (PST) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 9A2C6120048 for ; Mon, 17 Feb 2020 14:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1581977422; x=1613513422; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=baHFN8OwI4PZJuy41MEY0W1/6Ua9fBs9licEywPaiW0=; b=Ybre9T8npkuY6ji6W+D0x9ehJwRHl0GhgUsdT41SKcFukTL/YErTgQXN Axc655fAnCumVApFzp6skwfa7DD3ButX9aXeeUnkqaxNOCG+3yK4cYOrl Qm9PW+NwgXnn8rCRhX9Bgt0al5C2vx6KBZKrK9Wa6Ap/By3CY4rNqcyaN Y=; IronPort-SDR: r9mBEPlY58+dpHPFOC24zaJvsEQaUjvjahIqc+/xYTspW4zRkezgQjUjy6SKDy3ULOISqhpxgS x3DS1ASdXKgQ== X-IronPort-AV: E=Sophos; i="5.70,454,1574121600"; d="scan'208,217"; a="16734851" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-98acfc19.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 17 Feb 2020 22:10:07 +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-98acfc19.us-east-1.amazon.com (Postfix) with ESMTPS id 887C1A1E94; Mon, 17 Feb 2020 22:10:06 +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; Mon, 17 Feb 2020 22:10:06 +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; Mon, 17 Feb 2020 22:10: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; Mon, 17 Feb 2020 22:10:05 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: "txauth@ietf.org" Thread-Topic: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 Thread-Index: AQHV5dDs4U4nt6k0b0+KrG+KuF9zmKgfbEWA Date: Mon, 17 Feb 2020 22:10:05 +0000 Message-ID: References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> <69ED9ADA-BFAB-458D-AFA2-CCCEAFDCBC88@mit.edu> In-Reply-To: <69ED9ADA-BFAB-458D-AFA2-CCCEAFDCBC88@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.214] Content-Type: multipart/alternative; boundary="_000_E916DD08E0554FBBB324F8CE27C66194amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 22:10:29 -0000 --_000_E916DD08E0554FBBB324F8CE27C66194amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WFlaIHNlZW1zIHRvIGFzc3VtZSB0aGF0IGEgY2FsbGJhY2sgVVJMIGNhbiBiZSB1c2VkIHRvIGNv bnRpbnVlIHRoZSB0cmFuc2FjdGlvbiBhdCB0aGUgUkMgKGkuZS4sIGl04oCZcyBsaWtlIHRoZSBy ZWRpcmVjdF91cmkgaW4gdGhlIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQpLiBD b25zaWRlciBteSBleGFtcGxlIGluIHJlcGx5IHRvIERpY2ssIHdoZXJlIGEgc21hcnQgZGV2aWNl IHdpbGwgcG9sbCBmb3IgdGhlIHJlc3BvbnNlLCBidXQgd2FudHMgdG8gZGlyZWN0IHRoZSBlbmQg dXNlciB0byBhbiBpbnRyb2R1Y3Rpb24vdHV0b3JpYWwgcGFnZSBob3N0ZWQgb24gdGhlIG1hbnVm YWN0dXJlcuKAmXMgd2Vic2l0ZS4gVGhlIHdlYnNpdGUgaGFzIG5vIGtub3dsZWRnZSBvZiB0aGUg WFlaIHRyYW5zYWN0aW9uLiBJICp0aGluayogWFlaIHN1cHBvcnRzIHRoaXMsIGJ1dCBpdOKAmXMg bm90IG9idmlvdXMgYW5kIEkgY2FuIGltYWdpbmUgdGhhdCBBUyBzdXBwb3J0IG9yIHByb2hpYml0 aW9uIHdvdWxkIG1vcmUgb2Z0ZW4gc3RlbSBmcm9tIHNpZGUgZWZmZWN0cyBvZiBob3cgdGhlIEFT IHdhcyB3cml0dGVuIHJhdGhlciB0aGFuIGFzIGFuIGV4cGxpY2l0IGZlYXR1cmUgZGVjaXNpb24u DQoNCkJ1dCBpdOKAmXMgYWxzbyB3b3J0aCBjb25zaWRlcmluZyBjYXNlcyB3aGVyZSB0aGUgdHJh bnNhY3Rpb24gbWlnaHQgYmUgY29udGludWVkIHRocm91Z2ggdGhlIGNhbGxiYWNrIFVSTCwgYnV0 IHRoZSByZXNwb25zZSBpcyBzdGlsbCBkZXN0aW5lZCBmb3IgdGhlIGRldmljZS4gRm9yIGV4YW1w bGUsIHN1cHBvc2UgYSBDbGllbnQgdXNlcyB0aGUgY2FsbGJhY2sgVVJMIHRvIHByZXNlbnQgdGhl IGVuZCB1c2VyIHdpdGggYW4gb3Bwb3J0dW5pdHkgdG8gbGluayB0byBhbiBleGlzdGluZyBhY2Nv dW50IGF0IHRoZSBSQy4gSWYgdGhlIGVuZCB1c2VyIGhhcyBtdWx0aXBsZSBhY2NvdW50cyBhdCB0 aGUgQVMsIHRoZW4gYXQgdGhpcyBwb2ludCB0aGV5IG1pZ2h0IHJlYWxpemUgdGhleSBzaWduZWQg aW50byB0aGUgd3Jvbmcgb25lLCBhbmQgd2FudCB0byBzd2l0Y2guIElkZWFsbHkgdGhlIGVuZCB1 c2VyIHdvdWxkIG5vdCBoYXZlIHRvIG1hbnVhbGx5IHJlYm9vdCB0aGUgd2hvbGUgcHJvY2VzcyBm cm9tIHRoZSBzbWFydCBkZXZpY2UsIHNpbmNlIHRoZXnigJlyZSBhbHJlYWR5IHNpdHRpbmcgYXQg YSBicm93c2VyLiBPciBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBhbiBlbmQgdXNlciBhdXRob3Jp emVzIHNvbWUgYnV0IG5vdCBhbGwgb2YgdGhlIGFjY2VzcyByZXF1ZXN0ZWQgYnkgdGhlIENsaWVu dC4gVGhlIGNhbGxiYWNrIFVSTCBjb3VsZCBsYW5kIHRoZW0gb24gYSBwYWdlIHRoYXQgZXhwbGFp bnMgdGhlIGJlbmVmaXQgdGhleSB3b3VsZCBnZXQgZnJvbSBncmFudGluZyB0aGUgcmVqZWN0ZWQg YWNjZXNzLiBJZGVhbGx5IHRoZSBlbmQgdXNlciB3b3VsZCBiZSBhYmxlIHRvIG1vZGlmeSB0aGUg Z3JhbnQgdGhyb3VnaCB0aGF0IGJyb3dzZXIgc2Vzc2lvbi4gQSBzaW1pbGFyIGludGVyYWN0aW9u IG1pZ2h0IGhhcHBlbiBmYXIgb3V0IG9mIGJhbmQgZnJvbSB0aGUgb3JpZ2luYWwgYXV0aG9yaXph dGlvbiwgZm9yIGV4YW1wbGUgaWYgdGhlIGVuZCB1c2VyIGNob29zZXMgZnJvbSB3aXRoaW4gYSBt YW5hZ2VtZW50IGFwcCBmb3IgdGhlaXIgc21hcnQgZGV2aWNlIHRvIGVuYWJsZSBhIGZlYXR1cmUg dGhhdCByZXF1aXJlcyBhZGRpdGlvbmFsIGF1dGhvcml6YXRpb24uDQoNCuKAkw0KQW5uYWJlbGxl IEJhY2ttYW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20v aWRlbnRpdHkvDQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkRhdGU6IE1vbmRheSwg RmVicnVhcnkgMTcsIDIwMjAgYXQgMTI6MjkgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6ICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1 dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gW1VOVkVSSUZJRUQgU0VOREVSXSBS ZTogWEF1dGggLTAyDQoNCkFoIHllcywgbG9va3MgbGlrZSB0aGUgd2Vic2l0ZSBpcyBvdXQgb2Yg ZGF0ZSDigJQgdGhhdCBub3RlIGRhdGVzIHRvIGEgcHJldmlvdXMgaXRlcmF0aW9uIHdoZXJlIHdl IGhhZCBhbiBleHBsaWNpdCDigJx0eXBl4oCdIGZpZWxkIGFuZCB3ZSB3ZXJlIGFscmVhZHkgc2Vl aW5nIHRoZSBsaW1pdGF0aW9ucyBvZiB0aGF0IHN0eWxlLiBZb3XigJlyZSByaWdodCB0aGF0IHRo ZSBzcGVjLCB0aGUgYWN0dWFsIHRleHQgb24gdGhlIHdlYnNpdGXigJlzIGV4YW1wbGVzLCBhbmQg b3VyIGltcGxlbWVudGF0aW9uIGFsbCBhbGxvdyBjb21iaW5pbmcgdGhlc2UgdHdvLiBJbiBmYWN0 LCB0aGVyZeKAmXMgYW4gZXhhbXBsZSBvZiBpdCBvbiB0aGF0IHBhZ2UhIFlvdSBjYW4gYWJzb2x1 dGVseSBwb2xsIGFuZCB3YWl0IGZvciBhIGNhbGxiYWNrLCBib3RoIHVzZSBhIHRyYW5zYWN0aW9u IGNvbnRpbnVhdGlvbiByZXF1ZXN0LiBJ4oCZbGwgY2xlYW4gdGhhdCB1cCwgdGhhbmtzIQ0KDQpB bmQgaW4gdGhlIFhZWiBtb2RlbCwg4oCcc2VuZCB0aGUgcmVzcG9uc2UgdG8gdGhpcyBVUkzigJ0g d291bGQgYmUgYSBkaWZmZXJlbnQgaW50ZXJhY3Rpb24gdHlwZSB0byBiZSByZXF1ZXN0ZWQgZnJv bSB0aGUgY2xpZW50IGlmIGl04oCZcyBnb3QgYSBkaWZmZXJlbnQgc2V0IG9mIGNvbnNpZGVyYXRp b25zIHRoYW4gdGhlIGNhbGxiYWNrIFVSTC4gSG93ZXZlciwgSeKAmW0gY3VyaW91cyB3aGF0IOKA nHRoZSByZXNwb25zZeKAnSB3b3VsZCBiZSBpbiB0aGF0IGNhc2UuIEFyZSB3ZSB0YWxraW5nIGEg ZnJvbnQtY2hhbm5lbCByZXNwb25zZSwgc3RpbGwsIGxpa2UgdGhlIGltcGxpY2l0IGZsb3c/IE9y IGFyZSB3ZSBsb29raW5nIGZvciBhIHdheSB0byBwdXNoIGluZm9ybWF0aW9uIGJhY2sgdG8gdGhl IGNsaWVudCBpbiB0aGUgYmFjayBjaGFubmVsPyBJZiBpdOKAmXMgdGhlIGxhdHRlciwgdGhlbiB0 aGF04oCZcyBkZWZpbml0ZWx5IGEgZGlmZmVyZW50IGludGVyYWN0aW9uIHN0eWxlLiBBbmQgb25l IG9mIHRoZSBnb29kIHRoaW5ncyBpbiBYWVogaXMgdGhhdCBnZXR0aW5nIGluZm8gYmFjayB0byB0 aGUgY2xpZW50IGlzIG5vdyBkZWNvdXBsZWQgZnJvbSBob3cgeW91IGdldCB0aGUgdXNlciBpbnZv bHZlZCwgc28gdGhlIHVzZXIgY291bGQgZW50ZXIgYSBjb2RlIG9yIGdvIHRvIGEgbG9uZyAob3Ig c2hvcnQpIGFyYml0cmFyeSBVUkwsIGFuZCB0aGUgY2xpZW504oCZcyBtZWFucyBvZiBnZXR0aW5n IHRvIHRoZSBuZXh0IHN0ZXAgYXJlIHRoZSBzYW1lIG1lbnUgb2Ygb3B0aW9ucyByZWdhcmRsZXNz Lg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEZlYiAxNywgMjAyMCwgYXQgMTo1NCBQTSwgUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20+PiB3cm90ZToNCg0KWFlaIGlzIGEgbG90IGNsb3NlciB0byB3aGF0IEnigJlt IGRlc2NyaWJpbmcsIGJ1dCBpdCBzdGlsbCBjb25mbGF0ZXMg4oCccmVkaXJlY3QgdG8gdGhpcyBV UkwgYWZ0ZXIgdGhlIHdvcmtmbG934oCdIHdpdGgg4oCcc2VuZCB0aGUgcmVzcG9uc2UgdG8gdGhp cyBVUkzigJ0uIEkgKnRoaW5rKiB0aGUgZHJhZnQgYXMgd3JpdHRlbiB3b3VsZCBhbGxvdyBhIENs aWVudCB0byBwcm92aWRlIGEgY2FsbGJhY2sgYnV0IGFsc28gcG9sbCBmb3IgdGhlIHJlc3BvbnNl LCBidXQgaXTigJlzIG5vdCB2ZXJ5IGNsZWFyLiBUaGlzIGtpbmQgb2YgZmxvdyB3aGVyZSB0aGUg Q2xpZW50IGlzIGFjdHVhbGx5IHNwbGl0IGJldHdlZW4gZGV2aWNlLCBiYWNrZW5kLCBhbmQgd2Vi YXBwIHdpdGhpbiBhIHNpbmdsZSB0cmFuc2FjdGlvbiBpcyBvbmUgdGhhdCBkZXNlcnZlcyBtb3Jl IGF0dGVudGlvbiwgSU1ITy4NCg0KVGhpcyBub3RlIG9uIGh0dHBzOi8vb2F1dGgueHl6L2ludGVy YWN0aW9uLyBhbHNvIHN1Z2dlc3RzIFhZWiBpcyBtb3JlIGxpbWl0ZWQgdGhhbiBpdCBuZWVkcyB0 byBiZSwgYnV0IHRoZSBkcmFmdCBzZWVtcyB0byBhbGxvdyBmb3IgdGhpcyBhbHJlYWR5IHNvIG1h eWJlIHRoaXMgbm90ZSBpcyBqdXN0IGJlIG91dCBvZiBkYXRlPw0KDQpJdCB3b3VsZCBiZSBpbnRl cmVzdGluZyB0byBmaWd1cmUgb3V0IGlmIHdlIGNhbiBjb21iaW5lIGJvdGggdGhlIHVzZXIgY29k ZSBhbmQgYXJiaXRyYXJ5IHJlZGlyZWN0IFVSTCBtZXRob2RzLCBnaXZpbmcgdGhlIHVzZXIgYSBm ZXcgb3B0aW9ucy4gVGhpcyBzaG91bGQgYmUgYXMgc2ltcGxlIGFzIGFsbG93aW5nIG1vcmUgZmxl eGliaWxpdHkgb24gdGhlIGludGVyYWN0aW9uIHJlcXVlc3QgcG9ydGlvbiBhbmQgaGF2aW5nIHRo ZSBzZXJ2ZXIgcmV0dXJuIGFsbCBwb3NzaWJsZSBvcHRpb25zLg0KDQrigJMNCkFubmFiZWxsZSBC YWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5hbWF6b24uY29tL2lk ZW50aXR5Lw0KDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86 anJpY2hlckBtaXQuZWR1Pj4NCkRhdGU6IFNhdHVyZGF5LCBGZWJydWFyeSAxNSwgMjAyMCBhdCAy OjUxIFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9u LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+DQpDYzogInR4YXV0aEBpZXRmLm9yZzxt YWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGll dGYub3JnPj4NClN1YmplY3Q6IFtVTlZFUklGSUVEIFNFTkRFUl0gUmU6IFtUeGF1dGhdIFhBdXRo IC0wMg0KDQpUaGUgaW50ZXJhY3Rpb24gbW9kZWwgdGhhdCBBbm5hYmVsbGUgZGVzY3JpYmVzIGJl bG93IGlzIGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhpbmcgdGhhdOKAmXMgaW4gWFlaOg0KDQpodHRw czovL29hdXRoLnh5ei9pbnRlcmFjdGlvbi8NCg0KQW4gZWFybGllciBpbXBsZW1lbnRhdGlvbiBv ZiBYWVogaGFkIGEg4oCcdHlwZeKAnSBmaWVsZCBsaWtlIFhBdXRoIGRvZXMuIFlvdSBjYW4gc2Vl IHRoYXQgaGVyZToNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10 cmFuc2FjdGlvbmFsLWF1dGh6LTAwI3NlY3Rpb24tMi40DQoNCldlIG1vdmVkIGF3YXkgZnJvbSBp dCBmb3IgYWxsIG9mIHRoZSByZWFzb25zIEFubmFiZWxsZSBpcyBjaXRpbmcsIGFsb25nIHdpdGgg dGhlIG90aGVycyBJ4oCZdmUgc3RhdGVkIHByZXZpb3VzbHkgb24gdGhlIGxpc3QgdGhhdCBJIGRv buKAmXQgZmVlbCBiZWFyIHJlcGVhdGluZyBhZ2Fpbi4gSGF2aW5nIGltcGxlbWVudGVkIGJvdGgg cGF0dGVybnMgZGlyZWN0bHkgaW4gdGhlIHNhbWUgcHJvamVjdCwgSSBjYW4gYXR0ZXN0IHRoYXQg dGhlIGNvZGUgcGF0aHMgYXJlIHNpZ25pZmljYW50bHkgc2ltcGxlciAgZm9yIHRoZSBjdXJyZW50 IFhZWiBwYXR0ZXJuLCBlc3BlY2lhbGx5IG9uIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gWW91 IGNhbiBsb29rIGF0IG91ciBjb2RlIHlvdXJzZWx2ZXMsIGlmIHlvdSBsaWtlLg0KDQpBbmQgZm9y IHRoZSDigJxzaW1wbGXigJ0gY2xpZW50IGNhc2UgdGhhdCBzdXBwb3J0cyBvbmx5IG9uZSB0eXBl ICh3aGljaCBJIHRoaW5rIHdlIGFsbCBiZWxpZXZlIHdpbGwgYmUgdGhlIG92ZXJ3aGVsbWluZ2x5 IGNvbW1vbiBjYXNlKSwgSSB3YW50IHRvIHBvaW50IG91dCB0aGF0IHRoZSBYWVogYXBwcm9hY2gg YW5kIHRoZSBYQXV0aCBhcHByb2FjaCBhcmUgZm9yIGFsbCBpbnRlbnRzIGFuZCBwdXJwb3NlcyBp ZGVudGljYWwuIFRoZSBYWVogYXBwcm9hY2ggYWxsb3dzIGZvciBhIGxvdCBtb3JlIGZsZXhpYmls aXR5IGFsb25nIHdpdGggYSBkZWNyZWFzZSBpbiBjb21wbGV4aXR5Lg0KDQog4oCUIEp1c3Rpbg0K DQoNCg0KDQpPbiBGZWIgMTQsIDIwMjAsIGF0IDk6MjkgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIDxyaWNoYW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnJpY2hh bm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpbcmljaGFubmFdDQpS ZXBsaWVzIGlubGluZS4NClsvcmljaGFubmFdDQoNCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4gKHNo ZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvDQoN Cg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJv dW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFp bC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwgRmVicnVh cnkgMTQsIDIwMjAgYXQgOToxMCBBTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIg PHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmljaGFubmE9NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiAidHhhdXRoQGlldGYub3JnPG1haWx0bzp0 eGF1dGhAaWV0Zi5vcmc+IiA8dHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFhBdXRoIC0wMg0KDQoNCg0KT24gVGh1LCBGZWIgMTMs IDIwMjAgYXQgNjowOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBh bWF6b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCltyaWNoYW5uYV0NClJlcGxpZXMgaW5saW5lDQpbL3JpY2hhbm5hXQ0KPHNu aXA+DQpbcmljaGFubmFdDQpCeSB1c2VyIGNvZGUtYmFzZWQgaW50ZXJhY3Rpb24sIEkgbWVhbiB0 aGUga2luZCBkZXNjcmliZWQgaW4gdGhlIE9BdXRoIDIuMCBEZXZpY2UgQXV0aG9yaXphdGlvbiBH cmFudDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NjI4Piwgd2hlcmUgdGhlIHVzZXIg cmVjZWl2ZXMgYSBjb2RlIGFuZCBzaG9ydCBVUkwgZnJvbSB0aGUgY2xpZW50LCBuYXZpZ2F0ZXMg dG8gdGhhdCBVUkwgaW4gYSBicm93c2VyLCBhbmQgZW50ZXJzIHRoZSBjb2RlLiBXaGlsZSB0aGlz IGNvdWxkIGJlIHBhY2tlZCBpbnRvIGludGVyYWN0aW9uLm1lc3NhZ2UsIHRoaXMgd2lsbCBsZWFk IHRvIGNsdW5raWVyIHVzZXIgZXhwZXJpZW5jZXM6DQoNCjEuICAgVGhlIEdTIG1heSBub3QgYmUg YWJsZSB0byBwcm92aWRlIGxvY2FsaXplZCBpbnN0cnVjdGlvbnMgdGhhdCBtYXRjaCB0aGUgbG9j YWxlIG9uIHRoZSBDbGllbnQuDQoNCjIuICAgU3VwcG9zZSB0aGUgR1Mgc2VuZHMgYSBtZXNzYWdl IHRoYXQgcmVhZHM6IOKAnFNjYW4gdGhlIFFSIGNvZGUgb3Igb3BlbiBhIGJyb3dzZXIgdG8gaHR0 cDovL2NvZGUuZXhhbXBsZS8gYW5kIGVudGVyIHRoZSBjb2RlOiAxMjM0NS7igJ0NCg0KYS4gICAg VGhhdCBpbnN0cnVjdGlvbiBkb2VzIG5vdCBtYWtlIHNlbnNlIG9uIGEgZGV2aWNlIHRoYXQgZG9l cyBub3QgcHJlc2VudCBhIFFSIGNvZGUuIEltYWdpbmUgaGVhcmluZyB0aGF0IGZyb20gYSBzbWFy dCBzcGVha2VyLg0KDQpiLiAgIFRoYXQgaW5zdHJ1Y3Rpb24gaXMgY29uZnVzaW5nbHkgcmVkdW5k YW50IGlmIHRoZSBDbGllbnQgZGlzcGxheXMgdGhlIFFSIGNvZGUgYWxvbmcgd2l0aCBpdHMgb3du IGluc3RydWN0aW9ucywgbGlrZTog4oCcU2NhbiB0aGUgUVIgY29kZSBvciBmb2xsb3cgdGhlIGlu c3RydWN0aW9ucyBiZWxvdy7igJ0NCg0KMy4gICBXaWxsIOKAnGVtYmVkIHRoZSBzaG9ydCBVUkwg YW5kIGNvZGUgaW4gdGhlIG1lc3NhZ2Ugc3RyaW5n4oCdIGJlIE1UST8gSWYgbm90LCB0ZXh0LW9u bHkgY2xpZW50cyB3b3VsZCBoYXZlIGEgYnJva2VuIGV4cGVyaWVuY2UuDQpbL3JpY2hhbm5hXQ0K DQpTb3VuZHMgbGlrZSBhIHRleHQgb25seSBpbnRlcmFjdGlvbiB0eXBlIHNob3VsZCBiZSBhZGRl ZCBwZXIgbXkgbm90ZSBpbiB0aGUgZHJhZnQuIFBlcmhhcHMgZXZlbiBvbmUgdGhhdCBpcyBmb2N1 c2VkIG9uIHRoZSBjb2RlIGZsb3csIHdoZXJlIHRoZSBwYXJhbWV0ZXJzIGFyZSB0aGUgY29kZSBh bmQgdGhlIFVSSSB0byBlbnRlciB0aGUgY29kZSwgbGV0dGluZyB0aGUgQ2xpZW50IHByZXNlbnQg dGhlIHBhcmFtZXRlcnMgd2l0aCBsb2NhbGl6ZWQgY29udGVudD8NCg0KW3JpY2hhbm5hXQ0KSSB0 aGluayB3ZeKAmXJlIGFwcHJvYWNoaW5nIHRoZSDigJxpbnRlcmFjdGlvbuKAnSBjb25jZXB0IHdy b25nLiBXZeKAmXJlIGNvbmZsYXRpbmcgdGhyZWUgZGlmZmVyZW50IHRoaW5ncyB0b2dldGhlcjoN Cg0K4oCiICAgICAgICAgV2hhdCBkb2VzIHRoZSBDbGllbnQgbmVlZCB0byBzZW5kIHRoZSBlbmQg dXNlciB0byB0aGUgR1M/DQoNCm8gICAgQSBodW1hbi1mcmllbmRseSBzaG9ydCBVUkwgYW5kIGNv ZGUuDQoNCm8gICAgQW55IGtpbmQgb2YgVVJMLCBhcyBsb25nIGFuZCB1Z2x5IGFzIGl0IG5lZWRz IHRvIGJlLg0KDQrigKIgICAgICAgICBIb3cgd2lsbCB0aGUgQ2xpZW50IHJlY2VpdmUgdGhlIHJl c3BvbnNlIGZyb20gdGhlIEdTPw0KDQpvICAgIENsaWVudCB3aWxsIG1ha2UgYSByZXF1ZXN0IHRv IHRoZSBHUy4NCg0KbyAgICBHUyB3aWxsIG1ha2UgYSByZXF1ZXN0IHRvIHRoZSBDbGllbnQuIChJ 4oCZdmUgaGFkIHRvIGltcGxlbWVudCB0aGlzIGZvciBhIGN1c3RvbSBpbnRlZ3JhdGlvbiwgaW5j bHVkaW5nIGl0IHRvIGRlbW9uc3RyYXRlIHRoYXQgb3RoZXIgb3B0aW9ucyBleGlzdCkNCg0K4oCi ICAgICAgICAgV2lsbCB0aGUgR1MgcmV0dXJuIHRoZSBlbmQgdXNlciB0byB0aGUgQ2xpZW50LCBh bmQgaWYgc28gaG93Pw0KDQpvICAgIFllcywgYnkgVVJMIHJlZGlyZWN0Lg0KDQpvICAgIE5vLg0K DQpIZXJlIGlzIGEgdmVyeSBub24tbm9ybWF0aXZlIGV4YW1wbGUgcmVxdWVzdCBmcmFnbWVudCwg Zm9yIGEgY2xpZW50IHRoYXQgd2FudHMgYm90aCBhIHNob3J0IFVSTCBwbHVzIGNvZGUgYW5kIGEg ZnVsbCBVUkwgc28gdGhleSBjYW4gb3Bwb3J0dW5pc3RpY2FsbHkgdXNlIG9uZSBvciB0aGUgb3Ro ZXIgKEFXUyBDTEkgdjIgZG9lcyB0aGlzKSwgd2lsbCBxdWVyeSB0aGUgR1MgZm9yIHRoZSByZXNw b25zZSwgYW5kIHdhbnRzIHRoZSBHUyB0byByZWRpcmVjdCB0byBhIHB1YmxpY2x5IGFjY2Vzc2li bGUgVVJMIG9uIHRoZSBDbGllbnTigJlzIHdlYnNpdGUgYWZ0ZXIgdGhlIGZsb3cgKGUuZy4sIHRv IHNob3cgZnVydGhlciBkb2N1bWVudGF0aW9uL2JyYW5kZWQgY29udGVudCB0byB0aGUgZW5kIHVz ZXIpOg0Kew0KImludGVyYWN0Ijogew0KICAiY29kZSI6IHsgIm1heCI6IDggfSwNCiAgInVybCI6 IHRydWUNCn0sDQoicmVzcG9uc2UiOiB7DQogICJwb2xsIjogdHJ1ZQ0KfSwNCiJyZXR1cm4iOiB7 DQogICJ1cmwiOiAiaHR0cHM6Ly9oZWxwLnNtYXJ0ZGV2aWNlLmV4YW1wbGUvcG9zdC1zZXR1cCIN Cn0NCn0NCg0KQW5kIGhlcmUgaXMgYW4gZXF1YWxseSBub24tbm9ybWF0aXZlIGV4YW1wbGUgcmVz cG9uc2UgZnJhZ21lbnQ6DQp7DQoiaW50ZXJhY3QiOiB7DQogICJjb2RlIjogIjEyMzQ1NiIsDQog ICJjb2RlX3VybCI6ICJodHRwczovL2dzLmV4YW1wbGUvY29kZSIsDQogICJ1cmwiOiAiaHR0cHM6 Ly9ncy5leGFtcGxlL3hhdXRoLzEyMzQzNTY3ODkwYWJjZGVmMTIzNDU2Nzg5MGFiY2RlZiINCn0N Cn0NCg0KKFNlcmlvdXNseSBkbyBub3QgcmVhZCB0b28gbXVjaCBpbnRvIHRoZXNlIHBhcmFtZXRl ciBuYW1lcyBvciBzeW50YXgsIHRoaXMgaXMganVzdCB0byBnaXZlIGEgcm91Z2ggc2Vuc2Ugb2Yg aG93IEnigJltIHRoaW5raW5nIGFib3V0IHRoaXMuIEFueW9uZSB3aG8gdHJpZXMgdG8gcGljayBh cGFydCB0aGlzIGV4YW1wbGUgd2lsbCBiZSByZXNwb25kZWQgdG8gd2l0aCBtb2NraW5nIG1lbWVz LikNClsvcmljaGFubmFdDQoNCg0KMi4gICBDbGllbnRzIHN1cHBvcnQgbXVsdGlwbGUgaW50ZXJh Y3Rpb24gbW9kZXMgYW5kIG1heSBub3QgYWx3YXlzIGtub3cgd2hhdCB0aGUgR1Mgc3VwcG9ydHMg KGFuZCB2aWNlLXZlcnNhKS4gRm9yIGEgbXVsdGktdGVuYW50IEdTLCBpdCBtYXkgdmFyeSBieSB0 ZW5hbnQgY29uZmlndXJhdGlvbi4gQ2xpZW50cyBzaG91bGQgYmUgYWJsZSB0byBzYXkgd2hhdCB0 aGV5IGNhbiBkbywgYW5kIHRoZSBHUyBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIHRoZW0gd2hpY2gg b25lIHRvIHVzZS4gSXTigJlzIGEgdmVyeSBzaW1wbGUgYnV0IHBvd2VyZnVsIGlubGluZSBuZWdv dGlhdGlvbi4NCg0KVGhhdCBpcyB3aGF0IGlzIGluIFR4QXV0aC4gV291bGQgeW91IGVsYWJvcmF0 ZSBvbiBob3cgdGhlIEdTIG1pZ2h0IGJlIGNvbnN0cmFpbmVkPyBXaHkgd291bGQgdGhlIEdTIG5v dCBiZSBhYmxlIHRvIGRvIGFsbD8NCg0KSSB3b3VsZCB0aGluayBhbGwgY29uc3RyYWludHMgd291 bGQgYmUgYXQgdGhlIENsaWVudC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KW3JpY2hhbm5h XQ0KQ2xpZW50cyBtYXkgc3VwcG9ydCBjdXN0b21lci1kZWZpbmVkIEdTZXMgKGUuZy4sIGVudGVy cHJpc2UgSWRQcyksIHdoaWNoIHdpbGwgdmFyeSBpbiB0ZXJtcyBvZiB3aGljaCBpbnRlcmFjdGlv biBtb2RlcyB0aGV5IHN1cHBvcnQuIFdoaWxlIHRoZSBzZXQgb2YgaW50ZXJhY3Rpb25zIGRlZmlu ZWQgaW4gWEF1dGggbWlnaHQgYWxsIGJlIE1USSBmb3IgYSBHUywgd2Ugc2hvdWxkIGFzc3VtZSB0 aGF0IGV4dGVuc2lvbnMgd2lsbCBpbnRyb2R1Y2UgbmV3IGludGVyYWN0aW9ucyB3aGljaCB3aWxs IG5vdCBiZSB1bml2ZXJzYWxseSBzdXBwb3J0ZWQuIEFuIGludGVyYWN0aW9uIG1lY2hhbmlzbSBt aWdodCBoYXZlIHByb3BlcnRpZXMgdGhhdCBjYXVzZSBzb21lIGFkbWluaXN0cmF0b3JzIHRvIHdh bnQgdG8gZGlzYWJsZSBpdCwgb3IgdG8gcmVzdHJpY3QgQ2xpZW50cyB0byBhbHdheXMgdXNlIGl0 LiBBcmUgeW91IGFzc3VtaW5nIHRoYXQgYSBDbGllbnQgd2lsbCBhbHdheXMgbWFrZSBhbiBPUFRJ T05TIGRpc2NvdmVyeSByZXF1ZXN0IGZpcnN0Pw0KWy9yaWNoYW5uYV0NCg0KQW4gZXhhbXBsZSBv ZiB3aHkgYSBnaXZlbiBHUyBtYXkgbm90IHN1cHBvcnQgYSBtb2RlIHdvdWxkIGJlIGhlbHBmdWwu DQoNCkkgd2FzIGVudmlzaW9uaW5nIHRoYXQgaWYgYW4gb3B0aW9uYWwgdG8gc3VwcG9ydCBpbnRl cmFjdGlvbiBtb2RlIHdhcyBub3Qgc3VwcG9ydGVkIGF0IHRoZSBHUywgdGhhdCBpdCB3b3VsZCBy ZXR1cm4gYW4gZXJyb3IuIFRoZSBDbGllbnQgd291bGQgdGhlbiB0cnkgYSBkaWZmZXJlbnQgb25l LiBBbHRlcm5hdGl2ZWx5LCB0aGUgQ2xpZW50IGNvdWxkIHN0YXJ0IHdpdGggYW4gT1BUSU9OUyBj YWxsIGluIGNhc2VzIHdoZXJlIHRoZSBHUyBpcyBkeW5hbWljbHkgY2hvc2VuLg0KDQpbcmljaGFu bmFdDQpMb3RzIG9mIEFTZXMgZG9u4oCZdCBzdXBwb3J0IERldmljZSBBdXRob3JpemF0aW9uIEdy YW50LiBJIHRoaW5rIGl04oCZcyBzYWZlIHRvIGFzc3VtZSB0aGF0IGludGVyYWN0aW9uIG1vZGUg c3VwcG9ydCB3aWxsIHZhcnkgZm9yIFhBdXRoIGFzIHdlbGwuIOKAnEtlZXAgdHJ5aW5nIHVudGls IHlvdSBmaW5kIG9uZSB0aGF0IHdvcmtz4oCdIHNvdW5kcyBwcmV0dHkgcGFpbmZ1bCBmb3IgdGhl IGNsaWVudCwgYW5kIGRvZXNu4oCZdCBhbGxvdyB0aGUgY2xpZW50IHRvIHVzZSBtdWx0aXBsZSBp bnRlcmFjdGlvbiBtb2RlcywgYXMgZGVtb25zdHJhdGVkIGluIG15IGV4YW1wbGUgYWJvdmUuDQoN ClRoZXJlIGFyZSBsb3RzIG9mIHJlYXNvbnMgZm9yIHdhbnRpbmcgdG8gc3VwcG9ydCBtdWx0aXBs ZSBtb2RlczoNCg0K4oCiICAgICAgICAgU29tZSBwZW9wbGUgYXJlIGNvbWZvcnRhYmxlIHdpdGgg UVIgY29kZXMsIHNvbWUgYXJlbuKAmXQuDQoNCuKAoiAgICAgICAgIFNvbWUgcGVvcGxlIGhhdmUg c21hcnQgcGhvbmVzIHRoYXQgY2FuIHNjYW4gdGhlbSwgc29tZSBkb27igJl0Lg0KDQrigKIgICAg ICAgICBQZW9wbGUgd2l0aCBzbWFydCBwaG9uZXMgbWF5IHdhbnQgdG8gZ28gdGhyb3VnaCB0aGUg YXV0aGVudGljYXRpb24gZmxvdyBvbiB0aGVpciBkZXNrdG9wIGluc3RlYWQuDQoNCuKAoiAgICAg ICAgIFNvbWUgcGVvcGxlIG1heSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9u IGZsb3cgb24gdGhlaXIgZGVza3RvcCwgYmVjYXVzZSB0aGUgR1MgdGhpbmtzIGlQaG9uZXMgb25s eSBzdXBwb3J0IEJsdWV0b290aC1iYXNlZCBzZWN1cml0eSBrZXlzIGFuZCBpbnNpc3RzIHRoZXkg Y2Fubm90IGNvbXBsZXRlIHRoZSBsb2dpbiBmbG93IGV2ZW4gdGhvdWdoIHRoZXkgaGF2ZSB0d28g WXViaUtleSA1Q2kga2V5cyBvbiB0aGVpciBhY2NvdW50LiAoSEksIEdPT0dMRSBBQ0NPVU5UIFBS T1RFQ1RJT04gUFJPR1JBTSkNClsvcmljaGFubmFdDQoNCjMuICAgSSBkb27igJl0IHNlZSB0aGUg dmFsdWUgb2YgdGhlIOKAnHBvcHVw4oCdIGludGVyYWN0aW9uIG1vZGUuIENsaWVudHMgY2FuIHVz ZSDigJxyZWRpcmVjdOKAnSBtb2RlIHdpdGhpbiBwb3B1cHMuIEhvd2V2ZXIsIHNwZWFraW5nIGFz IHNvbWVvbmUgd2hvIGhhcyBkb25lIHRoYXQsIEkgcmVhbGx5IGRvbuKAmXQgcmVjb21tZW5kIGl0 LiBQb3B1cHMgYXJlIGluY3JlYXNpbmdseSB1bnN1cHBvcnRlZCwgYW5kIHByb25lIHRvIHdlaXJk IGJlaGF2aW9yYWwgaXNzdWVzLiBJbi1hcHAgYnJvd3NlcnMgaW4gRmFjZWJvb2ssIFR3aXR0ZXIs IGV0Yy4gdGVuZCB0byBoYXZlIHBvcHVwcyBkaXNhYmxlZC4gVGhlIGxhc3QgdmVyc2lvbnMgb2Yg SUUgTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSBhdCBhbGwgKHRoZSBwb3BwZWQgdXAgcGFn ZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0aGUgY3VycmVudCB3aW5kb3cpLi4gaW4NCg0K UG9wdXBzIGFyZSByZWFsbHkgdXNlZnVsIGluIHNpbmdsZS1wYWdlIGFwcHMgYXMgeW91IHdhbnQg dG8ga2VlcCB0aGUgY29udGV4dCBhbmQgbm90IHJlbG9hZCB0aGUgcGFnZS4NCg0KQWdyZWUgdGhh dCBwb3B1cHMgZG9uJ3QgbWFrZSBzZW5zZSBpbiBtb2JpbGUuIEEgZnVsbCByZWRpcmVjdCBkb2Vz IG9mIGNvdXJzZS4gQSBzaW5nbGUtcGFnZSBhcHAgb24gbW9iaWxlIHdvdWxkIG9wZW4gYSBuZXcg dGFiIHdoaWNoIHdvdWxkIGJlIGEgc2VwYXJhdGUgY29udGV4dCByYXRoZXIgdGhhbiBhIHJlZGly ZWN0Lg0KDQpbcmljaGFubmFdDQpQb3B1cHMgYXJlIGJyb2tlbiBhbmQvb3IgZGlzYWJsZWQgaW4g ZW5vdWdoIGluc3RhbmNlcyB0aGF0IHdlIHNob3VsZCBub3QgZW5jb3VyYWdlIHRoZWlyIHVzYWdl IGJ5IGluY2x1ZGluZyBleHBsaWNpdCBzdXBwb3J0IGZvciB0aGVtIGluIHRoZSBwcm90b2NvbC4g Tm9yIGFyZSB0aGV5IG5lY2Vzc2FyeSBmb3IgU1BBcyBpbiBvcmRlciB0byByZXN0b3JlIHRoZSBz dGF0ZSBvZiB0aGVpciBhcHAgYWZ0ZXIgdGhlIHJlZGlyZWN0Lg0KDQpBcmUgdGhleSByZWFsbHkg dGhhdCBicm9rZW4gaW4gZGVza3RvcD8gSSd2ZSB1c2VkIHRoZW0gZXh0ZW5zaXZlbHkgbXlzZWxm IGluIHRoZSBwYXN0IGFzIGl0IHdhcyBhIGJldHRlciB1c2VyIGV4cGVyaWVuY2UsIGJ1dCB0aGF0 IHdhcyBhIGZldyB5ZWFycyBhZ28uDQoNCltyaWNoYW5uYV0NClBvcHVwIGJsb2NrZXJzIGFyZSBi dWlsdCBpbiBhbmQgYWdncmVzc2l2ZWx5IGVuYWJsZWQgYnkgZGVmYXVsdCBvbiBhbGwgbWFqb3Ig YnJvd3NlcnMuIENvbW11bmljYXRpbmcgc2VjdXJlbHkgYmV0d2VlbiB3aW5kb3dzIGlzIG5vdCBl YXN5LCBhbmQgZnJvbSBwYXN0IGV4cGVyaWVuY2UgcHJvbmUgdG8gZmFpbHVyZSB0aGFua3MgdG8g d2VpcmQgYnJvd3NlciBidWdzLiBUcnVzdGVkIFNpdGUgc2V0dGluZ3MgaW4gSUUgYW5kIEVkZ2Ug Y2FuIGJsb3cgdGhlIHdob2xlIHRoaW5nIHVwIGluIHdlaXJkIHdheXMgKHNwZWFraW5nIGFnYWlu IGZyb20gZXhwZXJpZW5jZSkuDQoNCkFsc28sIGl04oCZcyAyMDIwLiBTdG9wIGJyYW5jaGluZyBv biBtb2JpbGUgdnMuIGRlc2t0b3AuIEkgZ2V0IHRoYXQgbG90cyBvZiBwZW9wbGUgc3RpbGwgZG8g dGhhdCwgYnV0IHRoYXQgZG9lc27igJl0IG1lYW4gdGhlIHByb3RvY29sIHNob3VsZCBjYXRlciB0 byBpdC4NClsvcmljaGFubmFdDQpBbmQgYWdhaW4sIGEgQ2xpZW50IHRoYXQgcmVhbGx5IHdhbnRz IHRvIGdpdmUgdGhlbXNlbHZlcyBhIGhlYWRhY2hlIHdpdGggcG9wdXBzIGNhbiBkbyB0aGF0IHRo ZW1zZWx2ZXMgdXNpbmcg4oCccmVkaXJlY3TigJ0gbW9kZS4gVGhleSBqdXN0IGhhdmUgdG8gcHJv dmlkZSBhIGxhbmRpbmcgcGFnZSBmb3IgdGhlIEdTIHRvIHJlZGlyZWN0IGJhY2sgdG8gdGhhdCBw YXJzZXMgdGhlIHJlc3BvbnNlLCBwYXNzZXMgaXQgYmFjayB0byB0aGUgbWFpbiB3aW5kb3csIGFu ZCBjbG9zZXMgaXRzZWxmLiBJIGRvbuKAmXQgc2VlIHdoeSB0aGUgcHJvdG9jb2wgd291bGQgbmVl ZCB0byBleHBsaWNpdGx5IGRlc2NyaWJlIHRoaXMgbWVjaGFuaXNtLg0KWy9yaWNoYW5uYV0NCg0K SSB0aGluayBpdCBpcyBhIHVzZWZ1bCBzaWduYWwgZm9yIHRoZSBHUyBpbiB0aGUgZXhwZXJpZW5j ZSBpdCB3YW50cyB0byBzaG93IHRoZSB1c2VyLg0KDQpbcmljaGFubmFdDQpVc2VmdWwgaG93PyBU aGUgd2luZG93IGRpbWVuc2lvbnMgYXJlIGEgYmV0dGVyIHNpZ25hbCBmb3IgaG93IHRvIHByZXNl bnQgdGhlIHVzZXIgZXhwZXJpZW5jZS4gKCpjb3VnaCogcmVzcG9uc2l2ZSBkZXNpZ24gKmNvdWdo KikNClsvcmljaGFubmFdDQoNClNlY3Rpb24gMTIuNjoNCg0KICAgICAgICBbRWRpdG9yOiBpcyB0 aGVyZSBzb21lIG90aGVyIHJlYXNvbiB0byBoYXZlIHRoZSBVc2VySW5mbw0KDQogICAgICAgIGVu ZHBvaW50P10NCg0KSSBtYXkgd2FudCB0byBob3N0IG15IFVzZXJJbmZvIGVuZHBvaW50IG9uIGEg c2VwYXJhdGUgbWljcm9zZXJ2aWNlIGZyb20gbXkgdG9rZW4gZW5kcG9pbnQgKGluIE9BdXRoIDIu MC9PSURDIHRlcm1zKS4gVGhlIGZvcm1lciBtaWdodCBiZSBwYXJ0IG9mIG15IHVzZXIgcHJvZmls ZS9kaXJlY3Rvcnkgc3RhY2ssIHdoaWxlIHRoZSBsYXR0ZXIgaXMgcGFydCBvZiB0aGUgaGlnaGx5 IHByaXZpbGVnZWQgYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzdGFjay4NCg0KDQpUaGUg dG9rZW4gZW5kcG9pbnQgaGFzIHRoZSBhY2Nlc3MgdG9rZW4gYW55d2F5LCBzbyBpdCBjYW4gZmV0 Y2ggdGhlIGRhdGEgZnJvbSB0aGUgb3RoZXIgZW5kcG9pbnQgaXRzZWxmIGlmIGl0IHdhbnRlZCB0 by4gSUUsIHRoZXJlIGlzIG5vIHNlcGFyYXRpb24gb2YgZHV0aWVzLg0KDQpXaGF0IGFyZSB0aGUg YWR2YW50YWdlcyBvZiB0aGUgVXNlckluZm8gZW5kcG9pbnQgdG8gdGhlIFVzZXIgb3IgQ2xpZW50 Pw0KDQpUaGUgVXNlckluZm8gZW5kcG9pbnQgc2VlbXMgdG8ganVzdCBhZGQgbW9yZSBjb21wbGV4 aXR5LCB3aXRoIG5vIGFiaWxpdHkgdG8gc3RhcnQgYSBVc2VyIGludGVyYWN0aW9uIGlmIGFkZGl0 aW9uYWwgY29uc2VudCBpcyBuZWVkZWQuDQoNCltyaWNoYW5uYV0NCklmIHRoZSBhY2Nlc3MgdG9r ZW4gaXMgc2VuZGVyLWNvbnN0cmFpbmVkLCB0aGVuIG5vLCB0aGUgdG9rZW4gZW5kcG9pbnQgY2Fu 4oCZdCBmZXRjaCB0aGUgZGF0YSBpdHNlbGYuIEJ1dCBldmVuIHdpdGhvdXQgdGhlIHNlY3VyaXR5 IGFuZ2xlLCB0aGVyZSBpcyB2YWx1ZSBpbiBzZXBhcmF0aW5nIG91dCB0aGUgZnVuY3Rpb25hbGl0 eSBhcyBpdCBhbGxvd3MgdGhlIEdTIHRvIGRpc3RyaWJ1dGUgaXQgYWNyb3NzIHN5c3RlbXMgd2l0 aCBkaWZmZXJlbnQgb3duZXJzLiBFLmcuLCB0aGVyZSBtaWdodCBiZSBhIGRpcmVjdG9yeSBBUEkg dGVhbSB0aGF0IGFsc28gb3ducyB0aGUgU0NJTSBpbnRlcmZhY2UgYW5kIFVzZXJJbmZvIGVuZHBv aW50Lg0KDQpBbiBpbXBsZW1lbnRhdGlvbiBjYW4gYWxzbyByb3V0ZSBjYWxscyB0byBkaWZmZXJl bnQgaW50ZXJuYWwgc3lzdGVtcyB3aGlsZSBrZWVwaW5nIHRoZSBzYW1lIGVuZHBvaW50Lg0KDQpJ IGFsc28gdGhpbmsgb2YgU0NpTSBhbmQgVXNlckluZm8gYXMgdmVyeSBkaWZmZXJlbnQgZW5kcG9p bnRzLiBJIHdvdWxkIGNvbnNpZGVyIFNDSU0gYSByZXNvdXJjZSwgYW5kIFVzZXJJbmZvIGNsYWlt cy4gSSBhcHByZWNpYXRlIHRob3NlIGFyZSBzaW1pbGFyIGluIGVudGVycHJpc2UsIGJ1dCB0aGV5 IGFyZSBub3QgaW4gY29uc3VtZXIgY29udGV4dHMuDQoNCltyaWNoYW5uYV0NClJvdXRpbmcgY2Fs bHMgdG8gZGlmZmVyZW50IGludGVybmFsIHN5c3RlbXMgc3RpbGwgbWVhbnMgSSBoYXZlIHRvIGhh dmUgc29tZSBzaGFyZWQgaW5mcmFzdHJ1Y3R1cmUgdGhhdCBib3RoIHRlYW1zIG1hbmFnZS4gSXTi gJlzIG1vcmUgY29tcGxleCB0aGFuIGl0IG5lZWRzIHRvIGJlLg0KDQpJ4oCZbSBnb2luZyB0byBz dWdnZXN0IHdlIG1vdmUgdGhpcyBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHRvIGEgc2VwYXJhdGUg dGhyZWFkIGJlY2F1c2UgaXTigJlzIHRvbyBtZXNzeSB0byBrZWVwIGluIHRoaXMgYXdmdWwgYmFj ay1hbmQtZm9ydGguIEnigJlsbCBqdXN0IGFkZCBoZXJlIHRoYXQgSeKAmW0gbm90IHN1Z2dlc3Rp bmcgd2Ugb25seSBoYXZlIGEgVXNlckluZm8gZW5kcG9pbnQuIEnigJltIGFyZ3VpbmcgdHdvIHRo aW5nczoNCg0KMS4gICAgICAgVGhlIFVzZXJJbmZvIGVuZHBvaW50IGlzIGdvb2QsIGFjdHVhbGx5 LiBJdCBkb2VzbuKAmXQgbmVlZCB0byBiZSBNVEksIGJ1dCB3ZSBzaG91bGQgbm90IHByZWNsdWRl IGl0cyBleGlzdGVuY2UuDQoNCjIuICAgICAgIElmIHdlIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9y IHJlcXVlc3RpbmcgYW5kIHJlY2VpdmluZyBjbGFpbXMgaW4gdGhlIEdTIFJlYWQgR3JhbnQgcmVz cG9uc2UsIHRoYXQgbWVjaGFuaXNtIHNob3VsZCBhcHBseSBnZW5lcmljYWxseSB0byBhcmJpdHJh cnkgcmVzb3VyY2VzLiBHU2VzIGNhbiBzdXBwb3J0IGl0IG9yIG5vdCwgZm9yIGFueSBnaXZlbiBy ZXNvdXJjZS4NClsvcmljaGFubmFdDQoNCjxzbmlwPg0KW3JpY2hhbm5hXQ0KVGhlcmUgYXJlIHR3 byBiaWcgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aG9zZSBleGFtcGxlcyAoZS5nLiwgUVIgQ29kZSwg YXBwLWJhc2VkIGxvZ2luIGFwcHJvdmFscykgYW5kIHRoaXMgbWVjaGFuaXNtIGluIFhBdXRoOg0K DQoxLiAgIEluIHlvdXIgZXhhbXBsZXMgb2YgdGhpcyBiZWhhdmlvciB0b2RheSwgdGhlIHJlYXNv biBmb3IgdGhlIHdhaXQgaXMgY2xlYXIgYW5kIG9idmlvdXMsIGFuZCBkcml2ZW4gYnkgdGhlIHVz ZXIuIEUuZy4sIG15IHByaW50ZXIgaXMgd2FpdGluZyBmb3IgbWUgdG8gZ28gZW50ZXIgdGhpcyBj b2RlIGFuZCBsb2cgaW47IEdvb2dsZSBzaWduIGluIGlzIHdhaXRpbmcgZm9yIG1lIHRvIHRhcCB0 aGlzIGJ1dHRvbiBvbiBteSBwaG9uZS4gVGhhdCBpcyBub3QgdGhlIGNhc2UgaW4gdGhlIFhBdXRo IHByb3RvY29sLiBUaGUgdXNlciBpcyBsZWZ0IHNpdHRpbmcgb24gYSBsb2FkaW5nIHNjcmVlbiB3 YWl0aW5nIGZvciBhIGJlaGluZC10aGUtc2NlbmVzIGludGVyYWN0aW9uIGJldHdlZW4gY2xpZW50 IGFuZCBHUyB0aGF0IG1heSBub3QgZXZlbiBoYXBwZW4uDQoNCjIuICAgVW5saWtlIHdpdGggY29k ZS9RUiBmbG93cyBvciBzaWduLWluIHZlcmlmaWNhdGlvbiwgdGhlcmUgaXMgbm8gYWN0aXZlIHBy b2Nlc3Mgb24gdGhlIGNsaWVudCBzaWRlIHRvIGtlZXAgdGhpcyBhc3luYyByZXF1ZXN0IG9wZW4u IEEgd2ViIGFwcCBjbGllbnQgd291bGQgaGF2ZSB0byBpbnRyb2R1Y2UgYSBzZXJ2ZXItc2lkZSBh c3luYyBwcm9jZXNzIHRvIG1hbmFnZSB0aGlzIGFzcGVjdCBvZiB0aGUgcHJvdG9jb2wuIFRoYXTi gJlzIG5vdCBlYXN5Lg0KDQozLiAgIFRoZSBmYWlsdXJlIG1vZGVzIHNob3cgdXAgaW4gbW9yZSBh cHByb3ByaWF0ZSBjb250ZXh0cywgd2hlcmUgdGhlcmUgYXJlIGNsZWFyIHBhdGhzIGZvcndhcmQg Zm9yIHRoZSBlbmQgdXNlci4gSW4gY29kZS9RUi1iYXNlZCBmbG93cywgaXTigJlzIGRldGVjdGVk IG9uIHRoZSBjbGllbnQgc2lkZSwgaW4gdGhlIGZvcm0gb2YgYW4gQVMgdGhhdCBuZXZlciBwcm92 aWRlcyBhIHJlc3BvbnNlLiBJbiB0aGF0IHNjZW5hcmlvLCB0aGUgY2xpZW50IGNhbiByZXRyeSB0 aGUgcHJvY2Vzcy4gSW4gc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZSBwcm9ibGVtIG9jY3VycyBi ZXR3ZWVuIHR3byBwYXJ0cyBvZiB0aGUgQVMsIGFuZCB0aGUgQVMgY2FuIGFsbG93IHRoZSBlbmQg dXNlciB0byByZXRyeSBvciB0byB1c2UgYSBkaWZmZXJlbnQgYXV0aGVudGljYXRpb24gbWV0aG9k LiBJbiB0aGUgWEF1dGggQ3JlYXRlK1VwZGF0ZSBzY2VuYXJpbywgdGhlIGZhaWx1cmUgaXMgZGV0 ZWN0ZWQgb24gdGhlIEdTLCBhbmQgdGhlcmUgaXMgbm8gY2xlYXIgcGF0aCBmb3J3YXJkLiBJZiB0 aGUgQ2xpZW50IG5ldmVyIGNhbGxzIFVwZGF0ZSBHcmFudCB0byBmbGlwIGludGVyYWN0aW9uLmtl ZXAgdG8gZmFsc2UsIHdoYXQgc2hvdWxkIHRoZSBHUyBkbz8gSG93IGxvbmcgc2hvdWxkIGl0IHdh aXQ/IFNob3VsZCBpdCBpc3N1ZSB0aGUgYXV0aG9yaXphdGlvbiBhbnl3YXksIGFzc3VtaW5nIHRo ZSBDbGllbnQgd2lsbCBjb21lIGJhY2sgYW5kIGFzayBmb3IgaXQgYXQgc29tZSBwb2ludD8gU2hv dWxkIGl0IHJlZGlyZWN0IHRoZSBlbmQgdXNlciBiYWNrIHRvIHRoZSBDbGllbnQgYW55d2F5LCBv ciBkcm9wIHRoZW0gb24gYSBsYW5kaW5nIHBhZ2U/IFNob3VsZCBpdCBmbGFnIHRoaXMgYXMgYW4g ZXJyb3IsIG9yIGlzIHRoaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGZvciB0aGUgQ2xpZW50Pw0K DQpJIHJlYWxseSB0aGluayB0aGlzIGlzIG92ZXJjb21wbGljYXRpbmcgdGhlIHByb3RvY29sIHRv IGFuIGV4dGVudCB0aGF0IG5vIG9uZSB3aWxsIGFjdHVhbGx5IGltcGxlbWVudCBpdC4NClsvcmlj aGFubmFdDQoNClRoZSBmbG93IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJkdC14YXV0aC1wcm90b2NvbC0wMiNzZWN0aW9uLTMuMSBpcyBFWEFDVExZIHRoZSBzYW1lIGFz IHRoZSBHb29nbGUgYW5kIE1pY3Jvc29mdCBmbG93cy4NCg0KV2hpbGUgdGhlIGZsb3cgaW4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAyI3Nl Y3Rpb24tMy40IGhhcyBhZGRpdGlvbmFsIHN0ZXBzLCBpdCBpcyBub3QgZnVuZGFtZW50YWxseSBh bnkgZGlmZmVyZW50IGV4Y2VwdCB0aGUgQ2xpZW50IGlzIG1ha2luZyBhbm90aGVyIGNhbGwgdG8g dGhlIEdTIGFmdGVyIHRoZSBmaXJzdCBvbmUgcmV0dXJucy4gVGhlIHJpc2sgb2YgdGhlIENsaWVu dCBub3QgbWFraW5nIHRoZSBzZWNvbmQgY2FsbCBhbmQgbGVhdmluZyB0aGUgVXNlciBoYW5naW5n IGlzIG5vdCByZWFsbHkgYW55IGRpZmZlcmVudCBvZiB0aGUgQ2xpZW50IG5vdCBtYWtpbmcgdGhl IGZpcnN0IGNhbGwuDQoNCkJlc2lkZXMgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGUgbW9iaWxlIGRl dmljZSB0aGF0IE1BWSBub3QgYmUgYWJsZSB0byBtYWtlIHRoZSBzZWNvbmQgY2FsbCBtaWdodCBw dXQgdG8gc2xlZXAsIEkgZG9uJ3Qgc2VlIGFueSBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMuIFR4QXV0 aCB3b3JrcyB0aGUgc2FtZSB3YXkgYXMgMy4xIGFzIEkgdW5kZXJzdGFuZCBpdCBmb3Igbm9uLXJl ZGlyZWN0IGZsb3dzLg0KDQpbcmljaGFubmFdDQpJIGRvbuKAmXQgdGhpbmsgeW91IGFjdHVhbGx5 IHJlYWQgd2hhdCBJIHdyb3RlLiBJZiB0aGUgZmxvd3MgYXJlIGV4YWN0bHkgdGhlIHNhbWUsIHRl bGwgbWU6DQoNCjEuICAgICAgIFdoYXQgZG9lcyB0aGUgdXNlciB0aGluayBpcyBnb2luZyBvbiB3 aGlsZSB0aGV54oCZcmUgc2l0dGluZyBvbiB0aGUgR1MsIHdhdGNoaW5nIGEgc3Bpbm5lciBhcyB0 aGUgR1Mgd2FpdHMgZm9yIHRoZSBDbGllbnQgdG8gbWFrZSBhbiBVcGRhdGUgR3JhbnQgcmVxdWVz dCBpbiAzLjQ/DQoNCjIuICAgICAgIFdoYXQgZXhpc3RpbmcgQ2xpZW50IGNvbXBvbmVudCBpcyBo b2xkaW5nIG9wZW4gdGhlIFJlYWQgR3JhbnQgcmVxdWVzdD8NCg0KYS4gICAgICAgSWYgeW91ciBh bnN3ZXIgaXMg4oCcYW4gYXN5bmMgcHJvY2VzcyBvbiB0aGUgQ2xpZW504oCZcyBzZXJ2ZXLigJ0g dGhlbiBwbGVhc2UgcmUtcmVhZCB0aGUgc2Vjb25kIHdvcmQgb2YgdGhhdCBxdWVzdGlvbi4NCg0K My4gICAgICAgSG93IGxvbmcgc2hvdWxkIHRoZSBHUyB3YWl0IGZvciB0aGUgQ2xpZW50IHRvIG1h a2UgdGhlIFVwZGF0ZSBHcmFudCByZXF1ZXN0IGluIDMuND8gV2hhdCBzaG91bGQgdGhlIEdTIGRv IGlmIHRoYXQgbmV2ZXIgaGFwcGVucz8gV2hhdCBpcyB0aGUgcGF0aCBmb3J3YXJkIGZvciB0aGUg ZW5kIHVzZXIsIGF0IHRoYXQgcG9pbnQ/DQpbL3JpY2hhbm5hXQ0KDQpbcGFzdGluZyBpbiBmcm9t IHlvdXIgbGF0ZXIgZW1haWxdDQpXaGlsZSBhIHNpbmdsZSBzdGFnZSBHcmFudCByZXF1ZXN0ICgz LjEpIGluIGEgbW9iaWxlIGFwcCB0aGF0IGhhcyBiZWVuIHB1dCB0byBzbGVlcCB3aWxsIHJlY292 ZXIgZmluZSwgYSBtdWx0aS1zdGVwICgzLjQpIHdpbGwgZmFpbC4gU2luY2UgMy40IG9ubHkgbWFr ZXMgc2Vuc2UgaWYgdGhlIENsaWVudCBpcyBjaGVja2luZyBhIGRhdGFiYXNlIGFsb25nIHRoZSB3 YXksIEkgd291bGQgZXhwZWN0IHRoZSBDbGllbnQgdG8gaGF2ZSBhIHNlcnZlciBzaWRlLCBhbmQg dGhlIHNlcnZlciBjb3VsZCB0YWtlIGVhY2ggc3RlcC4NClsvZW5kIHBhc3RlXQ0KDQpbcmljaGFu bmFdDQpIYXZpbmcgYSByZW1vdGUgZGF0YWJhc2UgYW5kIGhhdmluZyBhIHJlbW90ZSBzZXJ2ZXIg YXJlIG5vdCB0aGUgc2FtZSB0aGluZy4gVGhpcyBhZGRzIGEgbG90IG9mIGNvbXBsZXhpdHkgdG8g c2VydmVybGVzcyBhcHBzLg0KWy9yaWNoYW5uYV1baHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3Qu Y29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29u dGVudCZndWlkPTdjZDE4ZWE2LThjNTAtNDZkYy1iZTI1LWU5OWY2MTRkYWI4Ml3hkKcNCg0KV2hp Y2ggYXNwZWN0IGFkZHMgY29tcGxleGl0eT8NCg0KVGhlIGFkZGVkIGNvbXBsZXhpdHkgaW4ga2Vl cGluZyBhbiBpbnRlcmFjdGlvbiBpcyBtYWtpbmcgYW4gYWRkaXRpb25hbCBBUEkgY2FsbCBhZnRl ciB0aGUgZmlyc3QgQVBJIGNhbGwuDQoNCltyaWNoYW5uYV0NClRoZSBpc3N1ZSBpc27igJl0IHRo ZSBBUEkgY2FsbCBpdHNlbGYsIGl04oCZcyB0aGUgbmVlZCBmb3IgdGhlIENsaWVudCB0byBtYWlu dGFpbiBhIHBlcnNpc3RlbnQsIGFzeW5jaHJvbm91cyBwcm9jZXNzIHRvIG1ha2UgdGhhdCBBUEkg Y2FsbC4NCg0KSXQgaXMgaW5jb3JyZWN0IHRvIGFzc3VtZSB0aGF0IGV2ZXJ5IGFwcCB3aXRoIGEg ZGF0YWJhc2Ugd2lsbCBuZWNlc3NhcmlseSBoYXZlIGEgc2VydmVyIHNpZGUuIEEgc2VydmVybGVz cyBhcHAgdGhhdCBkb2VzIGEgcmVkaXJlY3QgdG8gdGhlIEdTLCBvciB0aGF0IHN3aXRjaGVzIHRv IGFuIGV4dGVybmFsIGJyb3dzZXIgKGFuZCB0aHVzIG1heSBiZSBwdXQgdG8gc2xlZXApIGhhcyBu byBjb21wb25lbnQgdGhhdCB3aWxsIHJlbGlhYmx5IHN0YXkgYWxpdmUgdG8gaG9sZCBvcGVuIHRo ZSBSZWFkIEdyYW50IHJlcXVlc3QsIHJlY2VpdmUgdGhlIHJlc3BvbnNlLCBhbmQgZm9sbG93IHVw IHdpdGggYW4gVXBkYXRlIEdyYW50IHJlcXVlc3QgKGkuZS4sIGZsb3cgMy40KS4gQWRkaW5nIGEg c2VydmVyLXNpZGUgY29tcG9uZW50IHRvIGRvIHRoaXMgb3JjaGVzdHJhdGlvbiBhZGRzIHNpZ25p ZmljYW50IGNvbXBsZXhpdHkuDQpbL3JpY2hhbm5hXQ0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlz dA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QN ClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KDQo= --_000_E916DD08E0554FBBB324F8CE27C66194amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <36DC618FC286DA41AC7E508863FA9565@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDAgNSAw IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJ cGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2Ut MToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnAuZ21haWwtbS0x MzkxMzY2ODI4MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbS0xMzkxMzY2ODI4 MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMz MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbS0xMzkxMzY2ODI4MzY3 NDIyMzMwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlhZWiBzZWVtcyB0byBhc3N1bWUgdGhhdCBhIGNhbGxiYWNrIFVSTCBjYW4gYmUgdXNlZCB0byBj b250aW51ZSB0aGUgdHJhbnNhY3Rpb24gYXQgdGhlIFJDIChpLmUuLCBpdOKAmXMgbGlrZSB0aGUg cmVkaXJlY3RfdXJpIGluIHRoZSBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50KS4g Q29uc2lkZXIgbXkgZXhhbXBsZSBpbiByZXBseSB0byBEaWNrLCB3aGVyZSBhIHNtYXJ0IGRldmlj ZSB3aWxsIHBvbGwNCiBmb3IgdGhlIHJlc3BvbnNlLCBidXQgd2FudHMgdG8gZGlyZWN0IHRoZSBl bmQgdXNlciB0byBhbiBpbnRyb2R1Y3Rpb24vdHV0b3JpYWwgcGFnZSBob3N0ZWQgb24gdGhlIG1h bnVmYWN0dXJlcuKAmXMgd2Vic2l0ZS4gVGhlIHdlYnNpdGUgaGFzIG5vIGtub3dsZWRnZSBvZiB0 aGUgWFlaIHRyYW5zYWN0aW9uLiBJICo8Yj50aGluazwvYj4qIFhZWiBzdXBwb3J0cyB0aGlzLCBi dXQgaXTigJlzIG5vdCBvYnZpb3VzIGFuZCBJIGNhbiBpbWFnaW5lIHRoYXQgQVMNCiBzdXBwb3J0 IG9yIHByb2hpYml0aW9uIHdvdWxkIG1vcmUgb2Z0ZW4gc3RlbSBmcm9tIHNpZGUgZWZmZWN0cyBv ZiBob3cgdGhlIEFTIHdhcyB3cml0dGVuIHJhdGhlciB0aGFuIGFzIGFuIGV4cGxpY2l0IGZlYXR1 cmUgZGVjaXNpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBpdOKAmXMgYWxzbyB3b3J0 aCBjb25zaWRlcmluZyBjYXNlcyB3aGVyZSB0aGUgdHJhbnNhY3Rpb24gbWlnaHQgYmUgY29udGlu dWVkIHRocm91Z2ggdGhlIGNhbGxiYWNrIFVSTCwgYnV0IHRoZSByZXNwb25zZSBpcyBzdGlsbCBk ZXN0aW5lZCBmb3IgdGhlIGRldmljZS4gRm9yIGV4YW1wbGUsIHN1cHBvc2UgYSBDbGllbnQgdXNl cyB0aGUgY2FsbGJhY2sgVVJMIHRvIHByZXNlbnQgdGhlIGVuZCB1c2VyIHdpdGgNCiBhbiBvcHBv cnR1bml0eSB0byBsaW5rIHRvIGFuIGV4aXN0aW5nIGFjY291bnQgYXQgdGhlIFJDLiBJZiB0aGUg ZW5kIHVzZXIgaGFzIG11bHRpcGxlIGFjY291bnRzIGF0IHRoZSBBUywgdGhlbiBhdCB0aGlzIHBv aW50IHRoZXkgbWlnaHQgcmVhbGl6ZSB0aGV5IHNpZ25lZCBpbnRvIHRoZSB3cm9uZyBvbmUsIGFu ZCB3YW50IHRvIHN3aXRjaC4gSWRlYWxseSB0aGUgZW5kIHVzZXIgd291bGQgbm90IGhhdmUgdG8g bWFudWFsbHkgcmVib290IHRoZSB3aG9sZQ0KIHByb2Nlc3MgZnJvbSB0aGUgc21hcnQgZGV2aWNl LCBzaW5jZSB0aGV54oCZcmUgYWxyZWFkeSBzaXR0aW5nIGF0IGEgYnJvd3Nlci4gT3IgY29uc2lk ZXIgdGhlIGNhc2Ugd2hlcmUgYW4gZW5kIHVzZXIgYXV0aG9yaXplcyBzb21lIGJ1dCBub3QgYWxs IG9mIHRoZSBhY2Nlc3MgcmVxdWVzdGVkIGJ5IHRoZSBDbGllbnQuIFRoZSBjYWxsYmFjayBVUkwg Y291bGQgbGFuZCB0aGVtIG9uIGEgcGFnZSB0aGF0IGV4cGxhaW5zIHRoZSBiZW5lZml0IHRoZXkg d291bGQNCiBnZXQgZnJvbSBncmFudGluZyB0aGUgcmVqZWN0ZWQgYWNjZXNzLiBJZGVhbGx5IHRo ZSBlbmQgdXNlciB3b3VsZCBiZSBhYmxlIHRvIG1vZGlmeSB0aGUgZ3JhbnQgdGhyb3VnaCB0aGF0 IGJyb3dzZXIgc2Vzc2lvbi4gQSBzaW1pbGFyIGludGVyYWN0aW9uIG1pZ2h0IGhhcHBlbiBmYXIg b3V0IG9mIGJhbmQgZnJvbSB0aGUgb3JpZ2luYWwgYXV0aG9yaXphdGlvbiwgZm9yIGV4YW1wbGUg aWYgdGhlIGVuZCB1c2VyIGNob29zZXMgZnJvbSB3aXRoaW4NCiBhIG1hbmFnZW1lbnQgYXBwIGZv ciB0aGVpciBzbWFydCBkZXZpY2UgdG8gZW5hYmxlIGEgZmVhdHVyZSB0aGF0IHJlcXVpcmVzIGFk ZGl0aW9uYWwgYXV0aG9yaXphdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJl bGxlIEJhY2ttYW4gKHNoZS9oZXIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5LyI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRp dHkvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGll dGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1 Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDIwIGF0IDEyOjI5 IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90 OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0 aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogW1R4YXV0aF0gW1VOVkVSSUZJRUQgU0VOREVSXSBSZTogWEF1dGggLTAyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWggeWVzLCBsb29rcyBs aWtlIHRoZSB3ZWJzaXRlIGlzIG91dCBvZiBkYXRlIOKAlCB0aGF0IG5vdGUgZGF0ZXMgdG8gYSBw cmV2aW91cyBpdGVyYXRpb24gd2hlcmUgd2UgaGFkIGFuIGV4cGxpY2l0IOKAnHR5cGXigJ0gZmll bGQgYW5kIHdlIHdlcmUgYWxyZWFkeSBzZWVpbmcgdGhlIGxpbWl0YXRpb25zIG9mIHRoYXQgc3R5 bGUuIFlvdeKAmXJlIHJpZ2h0IHRoYXQgdGhlIHNwZWMsDQogdGhlIGFjdHVhbCB0ZXh0IG9uIHRo ZSB3ZWJzaXRl4oCZcyBleGFtcGxlcywgYW5kIG91ciBpbXBsZW1lbnRhdGlvbiBhbGwgYWxsb3cg Y29tYmluaW5nIHRoZXNlIHR3by4gSW4gZmFjdCwgdGhlcmXigJlzIGFuIGV4YW1wbGUgb2YgaXQg b24gdGhhdCBwYWdlISBZb3UgY2FuIGFic29sdXRlbHkgcG9sbCBhbmQgd2FpdCBmb3IgYSBjYWxs YmFjaywgYm90aCB1c2UgYSB0cmFuc2FjdGlvbiBjb250aW51YXRpb24gcmVxdWVzdC4gSeKAmWxs IGNsZWFuIHRoYXQgdXAsDQogdGhhbmtzISZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+QW5kIGluIHRoZSBYWVogbW9kZWwsIOKAnHNlbmQgdGhlIHJlc3BvbnNl IHRvIHRoaXMgVVJM4oCdIHdvdWxkIGJlIGEgZGlmZmVyZW50IGludGVyYWN0aW9uIHR5cGUgdG8g YmUgcmVxdWVzdGVkIGZyb20gdGhlIGNsaWVudCBpZiBpdOKAmXMgZ290IGEgZGlmZmVyZW50IHNl dCBvZiBjb25zaWRlcmF0aW9ucyB0aGFuIHRoZSBjYWxsYmFjayBVUkwuIEhvd2V2ZXIsIEnigJlt IGN1cmlvdXMNCiB3aGF0IOKAnHRoZSByZXNwb25zZeKAnSB3b3VsZCBiZSBpbiB0aGF0IGNhc2Uu IEFyZSB3ZSB0YWxraW5nIGEgZnJvbnQtY2hhbm5lbCByZXNwb25zZSwgc3RpbGwsIGxpa2UgdGhl IGltcGxpY2l0IGZsb3c/IE9yIGFyZSB3ZSBsb29raW5nIGZvciBhIHdheSB0byBwdXNoIGluZm9y bWF0aW9uIGJhY2sgdG8gdGhlIGNsaWVudCBpbiB0aGUgYmFjayBjaGFubmVsPyBJZiBpdOKAmXMg dGhlIGxhdHRlciwgdGhlbiB0aGF04oCZcyBkZWZpbml0ZWx5IGEgZGlmZmVyZW50DQogaW50ZXJh Y3Rpb24gc3R5bGUuIEFuZCBvbmUgb2YgdGhlIGdvb2QgdGhpbmdzIGluIFhZWiBpcyB0aGF0IGdl dHRpbmcgaW5mbyBiYWNrIHRvIHRoZSBjbGllbnQgaXMgbm93IGRlY291cGxlZCBmcm9tIGhvdyB5 b3UgZ2V0IHRoZSB1c2VyIGludm9sdmVkLCBzbyB0aGUgdXNlciBjb3VsZCBlbnRlciBhIGNvZGUg b3IgZ28gdG8gYSBsb25nIChvciBzaG9ydCkgYXJiaXRyYXJ5IFVSTCwgYW5kIHRoZSBjbGllbnTi gJlzIG1lYW5zIG9mIGdldHRpbmcgdG8NCiB0aGUgbmV4dCBzdGVwIGFyZSB0aGUgc2FtZSBtZW51 IG9mIG9wdGlvbnMgcmVnYXJkbGVzcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIEZlYiAxNywgMjAyMCwgYXQgMTo1NCBQTSwgUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t Ij5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlhZWiBpcyBhIGxvdCBjbG9zZXIgdG8gd2hhdCBJ4oCZbSBkZXNj cmliaW5nLCBidXQgaXQgc3RpbGwgY29uZmxhdGVzIOKAnHJlZGlyZWN0IHRvIHRoaXMgVVJMIGFm dGVyIHRoZSB3b3JrZmxvd+KAnSB3aXRoIOKAnHNlbmQgdGhlIHJlc3BvbnNlIHRvIHRoaXMgVVJM 4oCdLiBJICo8Yj50aGluazwvYj4qIHRoZSBkcmFmdCBhcyB3cml0dGVuIHdvdWxkIGFsbG93IGEg Q2xpZW50IHRvIHByb3ZpZGUNCiBhIGNhbGxiYWNrIGJ1dCBhbHNvIHBvbGwgZm9yIHRoZSByZXNw b25zZSwgYnV0IGl04oCZcyBub3QgdmVyeSBjbGVhci4gVGhpcyBraW5kIG9mIGZsb3cgd2hlcmUg dGhlIENsaWVudCBpcyBhY3R1YWxseSBzcGxpdCBiZXR3ZWVuIGRldmljZSwgYmFja2VuZCwgYW5k IHdlYmFwcCB3aXRoaW4gYSBzaW5nbGUgdHJhbnNhY3Rpb24gaXMgb25lIHRoYXQgZGVzZXJ2ZXMg bW9yZSBhdHRlbnRpb24sIElNSE8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+VGhpcyBub3RlIG9uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vb2F1dGgueHl6L2ludGVyYWN0aW9uLyI+ aHR0cHM6Ly9vYXV0aC54eXovaW50ZXJhY3Rpb24vPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbHNvIHN1Z2dlc3RzIFhZWiBpcyBtb3JlIGxpbWl0 ZWQgdGhhbg0KIGl0IG5lZWRzIHRvIGJlLCBidXQgdGhlIGRyYWZ0IHNlZW1zIHRvIGFsbG93IGZv ciB0aGlzIGFscmVhZHkgc28gbWF5YmUgdGhpcyBub3RlIGlzIGp1c3QgYmUgb3V0IG9mIGRhdGU/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGZpZ3VyZSBvdXQgaWYg d2UgY2FuIGNvbWJpbmUgYm90aCB0aGUgdXNlciBjb2RlIGFuZCBhcmJpdHJhcnkgcmVkaXJlY3Qg VVJMIG1ldGhvZHMsIGdpdmluZyB0aGUgdXNlciBhIGZldyBvcHRpb25zLiBUaGlzIHNob3VsZCBi ZSBhcyBzaW1wbGUgYXMgYWxsb3dpbmcgbW9yZSBmbGV4aWJpbGl0eSBvbiB0aGUgaW50ZXJhY3Rp b24NCiByZXF1ZXN0IHBvcnRpb24gYW5kIGhhdmluZyB0aGUgc2VydmVyIHJldHVybiBhbGwgcG9z c2libGUgb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50 aXR5Lzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5KdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmlj aGVyQG1pdC5lZHU8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5TYXR1cmRheSwgRmVicnVhcnkgMTUsIDIwMjAg YXQgMjo1MSBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmci PnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0 Zi5vcmciPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPltVTlZFUklGSUVEIFNF TkRFUl0gUmU6IFtUeGF1dGhdIFhBdXRoIC0wMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGludGVyYWN0aW9u IG1vZGVsIHRoYXQgQW5uYWJlbGxlIGRlc2NyaWJlcyBiZWxvdyBpcyBleGFjdGx5IHRoZSBraW5k IG9mIHRoaW5nIHRoYXTigJlzIGluIFhZWjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJodHRwczovL29hdXRoLnh5 ei9pbnRlcmFjdGlvbi8iPmh0dHBzOi8vb2F1dGgueHl6L2ludGVyYWN0aW9uLzwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkFuIGVhcmxpZXIgaW1wbGVtZW50YXRpb24gb2YgWFlaIGhhZCBhIOKAnHR5cGXigJ0g ZmllbGQgbGlrZSBYQXV0aCBkb2VzLiBZb3UgY2FuIHNlZSB0aGF0IGhlcmU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5z YWN0aW9uYWwtYXV0aHotMDAjc2VjdGlvbi0yLjQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wMCNzZWN0aW9uLTIuNDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPldlIG1vdmVkIGF3YXkgZnJvbSBpdCBmb3IgYWxsIG9mIHRoZSByZWFzb25zIEFu bmFiZWxsZSBpcyBjaXRpbmcsIGFsb25nIHdpdGggdGhlIG90aGVycyBJ4oCZdmUgc3RhdGVkIHBy ZXZpb3VzbHkgb24gdGhlIGxpc3QgdGhhdCBJIGRvbuKAmXQgZmVlbCBiZWFyIHJlcGVhdGluZyBh Z2Fpbi4gSGF2aW5nIGltcGxlbWVudGVkIGJvdGggcGF0dGVybnMgZGlyZWN0bHkgaW4gdGhlDQog c2FtZSBwcm9qZWN0LCBJIGNhbiBhdHRlc3QgdGhhdCB0aGUgY29kZSBwYXRocyBhcmUgc2lnbmlm aWNhbnRseSBzaW1wbGVyICZuYnNwO2ZvciB0aGUgY3VycmVudCBYWVogcGF0dGVybiwgZXNwZWNp YWxseSBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFlvdSBjYW4gbG9vayBhdCBvdXIgY29k ZSB5b3Vyc2VsdmVzLCBpZiB5b3UgbGlrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFuZCBmb3IgdGhlIOKAnHNp bXBsZeKAnSBjbGllbnQgY2FzZSB0aGF0IHN1cHBvcnRzIG9ubHkgb25lIHR5cGUgKHdoaWNoIEkg dGhpbmsgd2UgYWxsIGJlbGlldmUgd2lsbCBiZSB0aGUgb3ZlcndoZWxtaW5nbHkgY29tbW9uIGNh c2UpLCBJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIFhZWiBhcHByb2FjaCBhbmQgdGhlIFhB dXRoIGFwcHJvYWNoIGFyZSBmb3IgYWxsIGludGVudHMNCiBhbmQgcHVycG9zZXMgaWRlbnRpY2Fs LiBUaGUgWFlaIGFwcHJvYWNoIGFsbG93cyBmb3IgYSBsb3QgbW9yZSBmbGV4aWJpbGl0eSBhbG9u ZyB3aXRoIGEgZGVjcmVhc2UgaW4gY29tcGxleGl0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw O+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gRmViIDE0LCAyMDIwLCBhdCA5OjI5 IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hh bm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyI+cmljaGFubmE9NDBhbWF6b24uY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZXBsaWVzIGlu bGluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+4oCTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+QW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5 Lzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5UeGF1dGggJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyI+ dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYNCiBvZiBEaWNrIEhhcmR0 ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21h aWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5LCBGZWJydWFyeSAxNCwgMjAyMCBhdCA5OjEw IEFNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyI+cmljaGFu bmE9NDBhbWF6b24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90OzxhIGhy ZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPlJlOiBbVHhhdXRoXSBYQXV0aCAtMDI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPk9uIFRodSwgRmViIDEzLCAyMDIwIGF0IDY6MDggUE0gUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMu aWV0Zi5vcmciPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UmVwbGllcyBpbmxpbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0Ny41NXB0Ij4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlsvcmljaGFubmFdJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZsdDtz bmlwJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+QnkgdXNlciBjb2RlLWJhc2VkIGludGVyYWN0aW9uLCBJIG1lYW4g dGhlIGtpbmQgZGVzY3JpYmVkIGluIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NjI4IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGggMi4wIERldmljZSBBdXRob3JpemF0aW9uIEdyYW50 PC9hPiwNCiB3aGVyZSB0aGUgdXNlciByZWNlaXZlcyBhIGNvZGUgYW5kIHNob3J0IFVSTCBmcm9t IHRoZSBjbGllbnQsIG5hdmlnYXRlcyB0byB0aGF0IFVSTCBpbiBhIGJyb3dzZXIsIGFuZCBlbnRl cnMgdGhlIGNvZGUuIFdoaWxlIHRoaXMgY291bGQgYmUgcGFja2VkIGludG8gaW50ZXJhY3Rpb24u bWVzc2FnZSwgdGhpcyB3aWxsIGxlYWQgdG8gY2x1bmtpZXIgdXNlciBleHBlcmllbmNlczo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4 MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMGluO3RleHQt aW5kZW50Oi0uMjVpbiI+DQoxLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlRoZSBHUyBt YXkgbm90IGJlIGFibGUgdG8gcHJvdmlkZSBsb2NhbGl6ZWQgaW5zdHJ1Y3Rpb25zIHRoYXQgbWF0 Y2ggdGhlIGxvY2FsZSBvbiB0aGUgQ2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Imdt YWlsLW0tMTM5MTM2NjgyODM2NzQyMjMzMG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoyLjBpbjt0ZXh0LWluZGVudDotLjI1aW4iPg0KMi48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5i c3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj5TdXBwb3NlIHRoZSBHUyBzZW5kcyBhIG1lc3NhZ2UgdGhhdCByZWFkczog4oCcU2Nh biB0aGUgUVIgY29kZSBvciBvcGVuIGEgYnJvd3NlciB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vY29kZS5leGFtcGxlLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9jb2RlLmV4YW1wbGUvPC9hPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbmQNCiBlbnRlciB0aGUgY29kZTogMTIz NDUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIy MzMwbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuNWluO3RleHQtaW5kZW50 Oi0uMjVpbiI+DQphLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlRoYXQgaW5z dHJ1Y3Rpb24gZG9lcyBub3QgbWFrZSBzZW5zZSBvbiBhIGRldmljZSB0aGF0IGRvZXMgbm90IHBy ZXNlbnQgYSBRUiBjb2RlLiBJbWFnaW5lIGhlYXJpbmcgdGhhdCBmcm9tIGEgc21hcnQgc3BlYWtl ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBt c29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi41aW47dGV4dC1pbmRlbnQ6LS4y NWluIj4NCmIuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+VGhhdCBpbnN0cnVjdGlvbiBp cyBjb25mdXNpbmdseSByZWR1bmRhbnQgaWYgdGhlIENsaWVudCBkaXNwbGF5cyB0aGUgUVIgY29k ZSBhbG9uZyB3aXRoIGl0cyBvd24gaW5zdHJ1Y3Rpb25zLCBsaWtlOiDigJxTY2FuIHRoZSBRUiBj b2RlIG9yDQogZm9sbG93IHRoZSBpbnN0cnVjdGlvbnMgYmVsb3cu4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIyMzMwbXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjIuMGluO3RleHQtaW5kZW50Oi0uMjVpbiI+DQozLjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPldpbGwg4oCcZW1iZWQgdGhlIHNob3J0IFVSTCBhbmQgY29k ZSBpbiB0aGUgbWVzc2FnZSBzdHJpbmfigJ0gYmUgTVRJPyBJZiBub3QsIHRleHQtb25seSBjbGll bnRzIHdvdWxkIGhhdmUgYSBicm9rZW4gZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5u YV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Tb3VuZHMgbGlrZSBhIHRleHQgb25seSBpbnRl cmFjdGlvbiB0eXBlIHNob3VsZCBiZSBhZGRlZCBwZXIgbXkgbm90ZSBpbiB0aGUgZHJhZnQuIFBl cmhhcHMgZXZlbiBvbmUgdGhhdCBpcyBmb2N1c2VkIG9uIHRoZSBjb2RlIGZsb3csIHdoZXJlIHRo ZSBwYXJhbWV0ZXJzIGFyZSB0aGUgY29kZSBhbmQgdGhlIFVSSSB0byBlbnRlciB0aGUgY29kZSwg bGV0dGluZyB0aGUNCiBDbGllbnQgcHJlc2VudCB0aGUgcGFyYW1ldGVycyB3aXRoIGxvY2FsaXpl ZCBjb250ZW50PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayB3ZeKAmXJlIGFwcHJvYWNoaW5nIHRoZSDigJxp bnRlcmFjdGlvbuKAnSBjb25jZXB0IHdyb25nLiBXZeKAmXJlIGNvbmZsYXRpbmcgdGhyZWUgZGlm ZmVyZW50IHRoaW5ncyB0b2dldGhlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW4iPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5XaGF0 IGRvZXMgdGhlIENsaWVudCBuZWVkIHRvIHNlbmQgdGhlIGVuZCB1c2VyIHRvIHRoZSBHUz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWxlZnQ6Mi4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5BIGh1 bWFuLWZyaWVuZGx5IHNob3J0IFVSTCBhbmQgY29kZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6Mi4waW47bWFyZ2luLWJv dHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5Bbnkga2luZCBvZiBVUkwsIGFzIGxvbmcg YW5kIHVnbHkgYXMgaXQgbmVlZHMgdG8gYmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5Ib3cgd2lsbCB0aGUgQ2xp ZW50IHJlY2VpdmUgdGhlIHJlc3BvbnNlIGZyb20gdGhlIEdTPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoyLjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPkNsaWVudCB3aWxsIG1ha2UgYSBy ZXF1ZXN0IHRvIHRoZSBHUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6Mi4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3Rl eHQtaW5kZW50Oi0uMjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj5HUyB3aWxsIG1ha2UgYSByZXF1ZXN0IHRvIHRoZSBDbGllbnQuIChJ 4oCZdmUgaGFkIHRvIGltcGxlbWVudCB0aGlzIGZvciBhDQogY3VzdG9tIGludGVncmF0aW9uLCBp bmNsdWRpbmcgaXQgdG8gZGVtb25zdHJhdGUgdGhhdCBvdGhlciBvcHRpb25zIGV4aXN0KTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDoxLjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+V2lsbCB0aGUgR1MgcmV0dXJuIHRoZSBlbmQgdXNlciB0byB0aGUgQ2xpZW50LCBh bmQgaWYgc28gaG93PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjBpbjttYXJnaW4tbGVmdDoyLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1p bmRlbnQ6LS4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPlllcywgYnkgVVJMIHJlZGlyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoyLjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPk5vLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IZXJlIGlz IGEgdmVyeSBub24tbm9ybWF0aXZlIGV4YW1wbGUgcmVxdWVzdCBmcmFnbWVudCwgZm9yIGEgY2xp ZW50IHRoYXQgd2FudHMgYm90aCBhIHNob3J0IFVSTCBwbHVzIGNvZGUgYW5kIGEgZnVsbCBVUkwg c28gdGhleSBjYW4gb3Bwb3J0dW5pc3RpY2FsbHkgdXNlIG9uZSBvciB0aGUgb3RoZXIgKEFXUyBD TEkgdjIgZG9lcyB0aGlzKSwgd2lsbCBxdWVyeSB0aGUNCiBHUyBmb3IgdGhlIHJlc3BvbnNlLCBh bmQgd2FudHMgdGhlIEdTIHRvIHJlZGlyZWN0IHRvIGEgcHVibGljbHkgYWNjZXNzaWJsZSBVUkwg b24gdGhlIENsaWVudOKAmXMgd2Vic2l0ZSBhZnRlciB0aGUgZmxvdyAoZS5nLiwgdG8gc2hvdyBm dXJ0aGVyIGRvY3VtZW50YXRpb24vYnJhbmRlZCBjb250ZW50IHRvIHRoZSBlbmQgdXNlcik6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj57PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50 OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZxdW90O2ludGVyYWN0 JnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVvdDtjb2RlJnF1b3Q7OiB7ICZxdW90O21heCZxdW90 OzogOCB9LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyIj4mbmJzcDsgJnF1b3Q7dXJsJnF1b3Q7OiB0cnVlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQt aW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn0sPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi PiZxdW90O3Jlc3BvbnNlJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVvdDtwb2xsJnF1b3Q7OiB0 cnVlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPn0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXIiPiZxdW90O3JldHVybiZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWlu ZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsgJnF1 b3Q7dXJsJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2hlbHAuc21hcnRkZXZpY2UuZXhh bXBsZS9wb3N0LXNldHVwIj5odHRwczovL2hlbHAuc21hcnRkZXZpY2UuZXhhbXBsZS9wb3N0LXNl dHVwPC9hPiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDoxMy41cHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q291cmllciI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+QW5kIGhlcmUgaXMgYW4gZXF1YWxseSBub24tbm9ybWF0aXZlIGV4YW1w bGUgcmVzcG9uc2UgZnJhZ21lbnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVy Ij57PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPiZxdW90O2ludGVyYWN0JnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEz LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVvdDtjb2Rl JnF1b3Q7OiAmcXVvdDsxMjM0NTYmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50OjEzLjVwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyAmcXVvdDtjb2RlX3VybCZx dW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9ncy5leGFtcGxlL2NvZGUiPmh0dHBzOi8vZ3Mu ZXhhbXBsZS9jb2RlPC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6MTMuNXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZxdW90O3VybCZxdW90OzogJnF1 b3Q7PGEgaHJlZj0iaHR0cHM6Ly9ncy5leGFtcGxlL3hhdXRoLzEyMzQzNTY3ODkwYWJjZGVmMTIz NDU2Nzg5MGFiY2RlZiI+aHR0cHM6Ly9ncy5leGFtcGxlL3hhdXRoLzEyMzQzNTY3ODkwYWJjZGVm MTIzNDU2Nzg5MGFiY2RlZjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6MTMuNXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNvdXJpZXIiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb3VyaWVyIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPihTZXJpb3VzbHkgZG8gbm90IHJlYWQgdG9vIG11 Y2ggaW50byB0aGVzZSBwYXJhbWV0ZXIgbmFtZXMgb3Igc3ludGF4LCB0aGlzIGlzIGp1c3QgdG8g Z2l2ZSBhIHJvdWdoIHNlbnNlIG9mIGhvdyBJ4oCZbSB0aGlua2luZyBhYm91dCB0aGlzLiBBbnlv bmUgd2hvIHRyaWVzIHRvIHBpY2sgYXBhcnQgdGhpcyBleGFtcGxlIHdpbGwgYmUgcmVzcG9uZGVk IHRvIHdpdGggbW9ja2luZw0KIG1lbWVzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluIj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjIuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+Q2xpZW50 cyBzdXBwb3J0IG11bHRpcGxlIGludGVyYWN0aW9uIG1vZGVzIGFuZCBtYXkgbm90IGFsd2F5cyBr bm93IHdoYXQgdGhlIEdTIHN1cHBvcnRzIChhbmQNCiB2aWNlLXZlcnNhKS4gRm9yIGEgbXVsdGkt dGVuYW50IEdTLCBpdCBtYXkgdmFyeSBieSB0ZW5hbnQgY29uZmlndXJhdGlvbi4gQ2xpZW50cyBz aG91bGQgYmUgYWJsZSB0byBzYXkgd2hhdCB0aGV5IGNhbiBkbywgYW5kIHRoZSBHUyBzaG91bGQg YmUgYWJsZSB0byB0ZWxsIHRoZW0gd2hpY2ggb25lIHRvIHVzZS4gSXTigJlzIGEgdmVyeSBzaW1w bGUgYnV0IHBvd2VyZnVsIGlubGluZSBuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYXQgaXMgd2hhdCBpcyBp biBUeEF1dGguIFdvdWxkIHlvdSBlbGFib3JhdGUgb24gaG93IHRoZSBHUyBtaWdodCBiZSBjb25z dHJhaW5lZD8gV2h5IHdvdWxkIHRoZSBHUyBub3QgYmUgYWJsZSB0byBkbyBhbGw/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3b3VsZCB0aGluayBhbGwgY29uc3RyYWlu dHMgd291bGQgYmUgYXQgdGhlIENsaWVudC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2xpZW50cyBtYXkgc3VwcG9y dCBjdXN0b21lci1kZWZpbmVkIEdTZXMgKGUuZy4sIGVudGVycHJpc2UgSWRQcyksIHdoaWNoIHdp bGwgdmFyeSBpbiB0ZXJtcyBvZiB3aGljaCBpbnRlcmFjdGlvbiBtb2RlcyB0aGV5IHN1cHBvcnQu IFdoaWxlIHRoZSBzZXQgb2YgaW50ZXJhY3Rpb25zIGRlZmluZWQgaW4gWEF1dGggbWlnaHQgYWxs IGJlIE1USSBmb3IgYSBHUywgd2Ugc2hvdWxkDQogYXNzdW1lIHRoYXQgZXh0ZW5zaW9ucyB3aWxs IGludHJvZHVjZSBuZXcgaW50ZXJhY3Rpb25zIHdoaWNoIHdpbGwgbm90IGJlIHVuaXZlcnNhbGx5 IHN1cHBvcnRlZC4gQW4gaW50ZXJhY3Rpb24gbWVjaGFuaXNtIG1pZ2h0IGhhdmUgcHJvcGVydGll cyB0aGF0IGNhdXNlIHNvbWUgYWRtaW5pc3RyYXRvcnMgdG8gd2FudCB0byBkaXNhYmxlIGl0LCBv ciB0byByZXN0cmljdCBDbGllbnRzIHRvIGFsd2F5cyB1c2UgaXQuIEFyZSB5b3UgYXNzdW1pbmcg dGhhdA0KIGEgQ2xpZW50IHdpbGwgYWx3YXlzIG1ha2UgYW4gT1BUSU9OUyBkaXNjb3ZlcnkgcmVx dWVzdCBmaXJzdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsvcmljaGFubmFdJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gZXhhbXBsZSBvZiB3aHkgYSBnaXZlbiBHUyBt YXkgbm90IHN1cHBvcnQgYSBtb2RlIHdvdWxkIGJlIGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkkgd2FzIGVudmlzaW9uaW5nIHRoYXQgaWYgYW4gb3B0aW9uYWwg dG8gc3VwcG9ydCBpbnRlcmFjdGlvbiBtb2RlIHdhcyBub3Qgc3VwcG9ydGVkIGF0IHRoZSBHUywg dGhhdCBpdCB3b3VsZCByZXR1cm4gYW4gZXJyb3IuIFRoZSBDbGllbnQgd291bGQgdGhlbiB0cnkg YSBkaWZmZXJlbnQgb25lLiBBbHRlcm5hdGl2ZWx5LCB0aGUgQ2xpZW50IGNvdWxkIHN0YXJ0IHdp dGgNCiBhbiBPUFRJT05TIGNhbGwgaW4gY2FzZXMgd2hlcmUgdGhlIEdTIGlzIGR5bmFtaWNseSBj aG9zZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5Mb3RzIG9mIEFTZXMgZG9u4oCZdCBzdXBwb3J0IERldmljZSBBdXRo b3JpemF0aW9uIEdyYW50LiBJIHRoaW5rIGl04oCZcyBzYWZlIHRvIGFzc3VtZSB0aGF0IGludGVy YWN0aW9uIG1vZGUgc3VwcG9ydCB3aWxsIHZhcnkgZm9yIFhBdXRoIGFzIHdlbGwuIOKAnEtlZXAg dHJ5aW5nIHVudGlsIHlvdSBmaW5kIG9uZSB0aGF0IHdvcmtz4oCdIHNvdW5kcyBwcmV0dHkgcGFp bmZ1bCBmb3INCiB0aGUgY2xpZW50LCBhbmQgZG9lc27igJl0IGFsbG93IHRoZSBjbGllbnQgdG8g dXNlIG11bHRpcGxlIGludGVyYWN0aW9uIG1vZGVzLCBhcyBkZW1vbnN0cmF0ZWQgaW4gbXkgZXhh bXBsZSBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZXJlIGFyZSBsb3RzIG9mIHJlYXNvbnMgZm9yIHdh bnRpbmcgdG8gc3VwcG9ydCBtdWx0aXBsZSBtb2Rlczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0 OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW4iPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj5Tb21lIHBlb3BsZSBhcmUgY29tZm9ydGFibGUgd2l0aCBRUiBjb2Rlcywgc29tZSBhcmVu 4oCZdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWxlZnQ6MS41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0u MjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wi PsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPlNvbWUgcGVvcGxlIGhhdmUgc21hcnQgcGhvbmVzIHRoYXQgY2Fu IHNjYW4gdGhlbSwgc29tZSBkb27igJl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjVpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+UGVvcGxlIHdpdGggc21hcnQg cGhvbmVzIG1heSB3YW50IHRvIGdvIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIGZsb3cgb24N CiB0aGVpciBkZXNrdG9wIGluc3RlYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAw MDFwdDt0ZXh0LWluZGVudDotLjI1aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5Tb21lIHBlb3BsZSBtYXk8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGk+aGF2ZTwvaT48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dG8NCiBnbyB0 aHJvdWdoIHRoZSBhdXRoZW50aWNhdGlvbiBmbG93IG9uIHRoZWlyIGRlc2t0b3AsIGJlY2F1c2Ug dGhlIEdTIHRoaW5rcyBpUGhvbmVzIG9ubHkgc3VwcG9ydCBCbHVldG9vdGgtYmFzZWQgc2VjdXJp dHkga2V5cyBhbmQgaW5zaXN0cyB0aGV5IGNhbm5vdCBjb21wbGV0ZSB0aGUgbG9naW4gZmxvdyBl dmVuIHRob3VnaCB0aGV5IGhhdmUgdHdvIFl1YmlLZXkgNUNpIGtleXMgb24gdGhlaXIgYWNjb3Vu dC4gKEhJLCBHT09HTEUgQUNDT1VOVCBQUk9URUNUSU9ODQogUFJPR1JBTSk8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41 aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+My48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj5JIGRvbuKAmXQgc2VlIHRoZSB2YWx1ZSBvZiB0aGUg4oCccG9wdXDigJ0gaW50ZXJhY3Rpb24g bW9kZS4gQ2xpZW50cyBjYW4gdXNlIOKAnHJlZGlyZWN04oCdIG1vZGUgd2l0aGluDQogcG9wdXBz LiBIb3dldmVyLCBzcGVha2luZyBhcyBzb21lb25lIHdobyBoYXMgZG9uZSB0aGF0LCBJIHJlYWxs eSBkb27igJl0IHJlY29tbWVuZCBpdC4gUG9wdXBzIGFyZSBpbmNyZWFzaW5nbHkgdW5zdXBwb3J0 ZWQsIGFuZCBwcm9uZSB0byB3ZWlyZCBiZWhhdmlvcmFsIGlzc3Vlcy4gSW4tYXBwIGJyb3dzZXJz IGluIEZhY2Vib29rLCBUd2l0dGVyLCBldGMuIHRlbmQgdG8gaGF2ZSBwb3B1cHMgZGlzYWJsZWQu IFRoZSBsYXN0IHZlcnNpb25zIG9mIElFDQogTW9iaWxlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSBh dCBhbGwgKHRoZSBwb3BwZWQgdXAgcGFnZSBiYXNpY2FsbHkganVzdCBsb2FkZWQgaW50byB0aGUg Y3VycmVudCB3aW5kb3cpLi4gaW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBvcHVwcyBhcmUgcmVhbGx5IHVzZWZ1bCBp biBzaW5nbGUtcGFnZSBhcHBzIGFzIHlvdSB3YW50IHRvIGtlZXAgdGhlIGNvbnRleHQgYW5kIG5v dCByZWxvYWQgdGhlIHBhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ QWdyZWUgdGhhdCBwb3B1cHMgZG9uJ3QgbWFrZSBzZW5zZSBpbiBtb2JpbGUuIEEgZnVsbCByZWRp cmVjdCBkb2VzIG9mIGNvdXJzZS4gQSBzaW5nbGUtcGFnZSBhcHAgb24gbW9iaWxlIHdvdWxkIG9w ZW4gYSBuZXcgdGFiIHdoaWNoIHdvdWxkIGJlIGEgc2VwYXJhdGUgY29udGV4dCByYXRoZXIgdGhh biBhIHJlZGlyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+UG9wdXBzIGFyZSBicm9rZW4gYW5kL29yIGRpc2FibGVkIGluIGVu b3VnaCBpbnN0YW5jZXMgdGhhdCB3ZSBzaG91bGQgbm90IGVuY291cmFnZSB0aGVpciB1c2FnZSBi eSBpbmNsdWRpbmcgZXhwbGljaXQgc3VwcG9ydCBmb3IgdGhlbSBpbiB0aGUgcHJvdG9jb2wuIE5v ciBhcmUgdGhleSBuZWNlc3NhcnkgZm9yIFNQQXMgaW4gb3JkZXIgdG8gcmVzdG9yZSB0aGUgc3Rh dGUNCiBvZiB0aGVpciBhcHAgYWZ0ZXIgdGhlIHJlZGlyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkFyZSB0aGV5IHJlYWxseSB0aGF0IGJyb2tlbiBpbiBkZXNrdG9wPyBJJ3ZlIHVzZWQg dGhlbSBleHRlbnNpdmVseSBteXNlbGYgaW4gdGhlIHBhc3QgYXMgaXQgd2FzIGEgYmV0dGVyIHVz ZXIgZXhwZXJpZW5jZSwgYnV0IHRoYXQgd2FzIGEgZmV3IHllYXJzIGFnby48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bcmljaGFubmFdPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBv cHVwIGJsb2NrZXJzIGFyZSBidWlsdCBpbiBhbmQgYWdncmVzc2l2ZWx5IGVuYWJsZWQgYnkgZGVm YXVsdCBvbiBhbGwgbWFqb3IgYnJvd3NlcnMuIENvbW11bmljYXRpbmcgc2VjdXJlbHkgYmV0d2Vl biB3aW5kb3dzIGlzIG5vdCBlYXN5LCBhbmQgZnJvbSBwYXN0IGV4cGVyaWVuY2UgcHJvbmUgdG8g ZmFpbHVyZSB0aGFua3MgdG8gd2VpcmQgYnJvd3NlciBidWdzLg0KIFRydXN0ZWQgU2l0ZSBzZXR0 aW5ncyBpbiBJRSBhbmQgRWRnZSBjYW4gYmxvdyB0aGUgd2hvbGUgdGhpbmcgdXAgaW4gd2VpcmQg d2F5cyAoc3BlYWtpbmcgYWdhaW4gZnJvbSBleHBlcmllbmNlKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFsc28s IGl04oCZcyAyMDIwLiBTdG9wIGJyYW5jaGluZyBvbiBtb2JpbGUgdnMuIGRlc2t0b3AuIEkgZ2V0 IHRoYXQgbG90cyBvZiBwZW9wbGUgc3RpbGwgZG8gdGhhdCwgYnV0IHRoYXQgZG9lc27igJl0IG1l YW4gdGhlIHByb3RvY29sIHNob3VsZCBjYXRlciB0byBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkFuZCBhZ2FpbiwgYSBDbGllbnQgdGhhdCByZWFsbHkgd2FudHMgdG8gZ2l2ZSB0aGVtc2VsdmVz IGEgaGVhZGFjaGUgd2l0aCBwb3B1cHMgY2FuIGRvIHRoYXQgdGhlbXNlbHZlcyB1c2luZyDigJxy ZWRpcmVjdOKAnSBtb2RlLiBUaGV5IGp1c3QgaGF2ZSB0byBwcm92aWRlIGEgbGFuZGluZyBwYWdl IGZvciB0aGUgR1MgdG8gcmVkaXJlY3QgYmFjayB0byB0aGF0IHBhcnNlcyB0aGUNCiByZXNwb25z ZSwgcGFzc2VzIGl0IGJhY2sgdG8gdGhlIG1haW4gd2luZG93LCBhbmQgY2xvc2VzIGl0c2VsZi4g SSBkb27igJl0IHNlZSB3aHkgdGhlIHByb3RvY29sIHdvdWxkIG5lZWQgdG8gZXhwbGljaXRseSBk ZXNjcmliZSB0aGlzIG1lY2hhbmlzbS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JIHRoaW5rIGl0IGlzIGEgdXNlZnVsIHNpZ25hbCBmb3IgdGhlIEdTIGluIHRoZSBl eHBlcmllbmNlIGl0IHdhbnRzIHRvIHNob3cgdGhlIHVzZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5Vc2VmdWwgaG93PyBUaGUgd2luZG93IGRpbWVuc2lvbnMgYXJlIGEgYmV0dGVyIHNpZ25h bCBmb3IgaG93IHRvIHByZXNlbnQgdGhlIHVzZXIgZXhwZXJpZW5jZS4gKCpjb3VnaCogcmVzcG9u c2l2ZSBkZXNpZ24gKmNvdWdoKik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlNlY3Rpb24gMTIuNjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1tFZGl0b3I6IGlzIHRoZXJlIHNvbWUgb3RoZXIgcmVh c29uIHRvIGhhdmUgdGhlIFVzZXJJbmZvPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjIuMGluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZW5kcG9pbnQ/XTxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JIG1heSB3YW50IHRvIGhvc3QgbXkgVXNlckluZm8gZW5kcG9pbnQgb24gYSBzZXBh cmF0ZSBtaWNyb3NlcnZpY2UgZnJvbSBteSB0b2tlbiBlbmRwb2ludCAoaW4gT0F1dGggMi4wL09J REMgdGVybXMpLiBUaGUgZm9ybWVyIG1pZ2h0IGJlIHBhcnQgb2YgbXkgdXNlciBwcm9maWxlL2Rp cmVjdG9yeSBzdGFjaywgd2hpbGUgdGhlIGxhdHRlciBpcyBwYXJ0IG9mIHRoZSBoaWdobHkNCiBw cml2aWxlZ2VkIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24gc3RhY2suPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgdG9rZW4gZW5k cG9pbnQgaGFzIHRoZSBhY2Nlc3MgdG9rZW4gYW55d2F5LCBzbyBpdCBjYW4gZmV0Y2ggdGhlIGRh dGEgZnJvbSB0aGUgb3RoZXIgZW5kcG9pbnQgaXRzZWxmIGlmIGl0IHdhbnRlZCB0by4gSUUsIHRo ZXJlIGlzIG5vIHNlcGFyYXRpb24gb2YgZHV0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPldoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBVc2VySW5mbyBlbmRw b2ludCB0byB0aGUgVXNlciBvciBDbGllbnQ/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlIFVzZXJJbmZvIGVuZHBvaW50IHNlZW1zIHRvIGp1c3QgYWRkIG1v cmUgY29tcGxleGl0eSwgd2l0aCBubyBhYmlsaXR5IHRvIHN0YXJ0IGEgVXNlciBpbnRlcmFjdGlv biBpZiBhZGRpdGlvbmFsIGNvbnNlbnQgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SWYgdGhlIGFjY2VzcyB0b2tl biBpcyBzZW5kZXItY29uc3RyYWluZWQsIHRoZW4gbm8sIHRoZSB0b2tlbiBlbmRwb2ludCBjYW7i gJl0IGZldGNoIHRoZSBkYXRhIGl0c2VsZi4gQnV0IGV2ZW4gd2l0aG91dCB0aGUgc2VjdXJpdHkg YW5nbGUsIHRoZXJlIGlzIHZhbHVlIGluIHNlcGFyYXRpbmcgb3V0IHRoZSBmdW5jdGlvbmFsaXR5 IGFzIGl0IGFsbG93cyB0aGUgR1MgdG8NCiBkaXN0cmlidXRlIGl0IGFjcm9zcyBzeXN0ZW1zIHdp dGggZGlmZmVyZW50IG93bmVycy4gRS5nLiwgdGhlcmUgbWlnaHQgYmUgYSBkaXJlY3RvcnkgQVBJ IHRlYW0gdGhhdCBhbHNvIG93bnMgdGhlIFNDSU0gaW50ZXJmYWNlIGFuZCBVc2VySW5mbyBlbmRw b2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbiBpbXBsZW1lbnRhdGlvbiBjYW4gYWxz byByb3V0ZSBjYWxscyB0byBkaWZmZXJlbnQgaW50ZXJuYWwgc3lzdGVtcyB3aGlsZSBrZWVwaW5n IHRoZSBzYW1lIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J IGFsc28gdGhpbmsgb2YgU0NpTSBhbmQgVXNlckluZm8gYXMgdmVyeSBkaWZmZXJlbnQgZW5kcG9p bnRzLiBJIHdvdWxkIGNvbnNpZGVyIFNDSU0gYSByZXNvdXJjZSwgYW5kIFVzZXJJbmZvIGNsYWlt cy4gSSBhcHByZWNpYXRlIHRob3NlIGFyZSBzaW1pbGFyIGluIGVudGVycHJpc2UsIGJ1dCB0aGV5 IGFyZSBub3QgaW4gY29uc3VtZXIgY29udGV4dHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Sb3V0aW5nIGNhbGxzIHRv IGRpZmZlcmVudCBpbnRlcm5hbCBzeXN0ZW1zIHN0aWxsIG1lYW5zIEkgaGF2ZSB0byBoYXZlIHNv bWUgc2hhcmVkIGluZnJhc3RydWN0dXJlIHRoYXQgYm90aCB0ZWFtcyBtYW5hZ2UuIEl04oCZcyBt b3JlIGNvbXBsZXggdGhhbiBpdCBuZWVkcyB0byBiZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPknigJltIGdvaW5n IHRvIHN1Z2dlc3Qgd2UgbW92ZSB0aGlzIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gdG8gYSBzZXBh cmF0ZSB0aHJlYWQgYmVjYXVzZSBpdOKAmXMgdG9vIG1lc3N5IHRvIGtlZXAgaW4gdGhpcyBhd2Z1 bCBiYWNrLWFuZC1mb3J0aC4gSeKAmWxsIGp1c3QgYWRkIGhlcmUgdGhhdCBJ4oCZbSBub3Qgc3Vn Z2VzdGluZyB3ZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48aT5vbmx5PC9pPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5oYXZlDQogYSBVc2VySW5mbyBlbmRwb2ludC4gSeKAmW0gYXJndWluZyB0d28gdGhpbmdz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3Rl eHQtaW5kZW50Oi0uMjVpbiI+DQoxLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPlRoZSBVc2VySW5mbyBlbmRwb2ludCBpcyBnb29kLCBhY3R1YWxs eS4gSXQgZG9lc27igJl0IG5lZWQgdG8gYmUgTVRJLCBidXQgd2Ugc2hvdWxkIG5vdCBwcmVjbHVk ZSBpdHMgZXhpc3RlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4 dC1pbmRlbnQ6LS4yNWluIj4NCjIuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+SWYgd2UgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgcmVxdWVzdGlu ZyBhbmQgcmVjZWl2aW5nIGNsYWltcyBpbiB0aGUgR1MgUmVhZCBHcmFudCByZXNwb25zZSwgdGhh dCBtZWNoYW5pc20gc2hvdWxkIGFwcGx5IGdlbmVyaWNhbGx5DQogdG8gYXJiaXRyYXJ5IHJlc291 cmNlcy4gR1NlcyBjYW4gc3VwcG9ydCBpdCBvciBub3QsIGZvciBhbnkgZ2l2ZW4gcmVzb3VyY2Uu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9yaWNoYW5uYV08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZsdDtzbmlwJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlcmUgYXJlIHR3byBiaWcgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aG9z ZSBleGFtcGxlcyAoZS5nLiwgUVIgQ29kZSwgYXBwLWJhc2VkIGxvZ2luIGFwcHJvdmFscykgYW5k IHRoaXMgbWVjaGFuaXNtIGluIFhBdXRoOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJnbWFpbC1tLTEzOTEzNjY4MjgzNjc0MjIzMzBtc29saXN0cGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6Mi4waW47dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjEuPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+SW4geW91ciBleGFtcGxlcyBvZiB0aGlzIGJlaGF2aW9yIHRv ZGF5LCB0aGUgcmVhc29uIGZvciB0aGUgd2FpdCBpcyBjbGVhciBhbmQgb2J2aW91cywgYW5kIGRy aXZlbiBieSB0aGUgdXNlci4gRS5nLiwgbXkgcHJpbnRlciBpcyB3YWl0aW5nDQogZm9yIG1lIHRv IGdvIGVudGVyIHRoaXMgY29kZSBhbmQgbG9nIGluOyBHb29nbGUgc2lnbiBpbiBpcyB3YWl0aW5n IGZvciBtZSB0byB0YXAgdGhpcyBidXR0b24gb24gbXkgcGhvbmUuIFRoYXQgaXMgbm90IHRoZSBj YXNlIGluIHRoZSBYQXV0aCBwcm90b2NvbC4gVGhlIHVzZXIgaXMgbGVmdCBzaXR0aW5nIG9uIGEg bG9hZGluZyBzY3JlZW4gd2FpdGluZyBmb3IgYSBiZWhpbmQtdGhlLXNjZW5lcyBpbnRlcmFjdGlv biBiZXR3ZWVuIGNsaWVudCBhbmQNCiBHUyB0aGF0IG1heSBub3QgZXZlbiBoYXBwZW4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS0xMzkxMzY2ODI4MzY3NDIyMzMwbXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMGluO3RleHQtaW5kZW50Oi0uMjVpbiI+DQoy LjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlVubGlrZSB3aXRoIGNvZGUvUVIgZmxvd3Mg b3Igc2lnbi1pbiB2ZXJpZmljYXRpb24sIHRoZXJlIGlzIG5vIGFjdGl2ZSBwcm9jZXNzIG9uIHRo ZSBjbGllbnQgc2lkZSB0byBrZWVwIHRoaXMgYXN5bmMgcmVxdWVzdCBvcGVuLiBBIHdlYg0KIGFw cCBjbGllbnQgd291bGQgaGF2ZSB0byBpbnRyb2R1Y2UgYSBzZXJ2ZXItc2lkZSBhc3luYyBwcm9j ZXNzIHRvIG1hbmFnZSB0aGlzIGFzcGVjdCBvZiB0aGUgcHJvdG9jb2wuIFRoYXTigJlzIG5vdCBl YXN5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tMTM5MTM2NjgyODM2NzQyMjMz MG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjBpbjt0ZXh0LWluZGVudDot LjI1aW4iPg0KMy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5UaGUgZmFpbHVyZSBtb2Rl cyBzaG93IHVwIGluIG1vcmUgYXBwcm9wcmlhdGUgY29udGV4dHMsIHdoZXJlIHRoZXJlIGFyZSBj bGVhciBwYXRocyBmb3J3YXJkIGZvciB0aGUgZW5kIHVzZXIuIEluIGNvZGUvUVItYmFzZWQgZmxv d3MsIGl04oCZcw0KIGRldGVjdGVkIG9uIHRoZSBjbGllbnQgc2lkZSwgaW4gdGhlIGZvcm0gb2Yg YW4gQVMgdGhhdCBuZXZlciBwcm92aWRlcyBhIHJlc3BvbnNlLiBJbiB0aGF0IHNjZW5hcmlvLCB0 aGUgY2xpZW50IGNhbiByZXRyeSB0aGUgcHJvY2Vzcy4gSW4gc2lnbi1pbiB2ZXJpZmljYXRpb24s IHRoZSBwcm9ibGVtIG9jY3VycyBiZXR3ZWVuIHR3byBwYXJ0cyBvZiB0aGUgQVMsIGFuZCB0aGUg QVMgY2FuIGFsbG93IHRoZSBlbmQgdXNlciB0byByZXRyeSBvciB0bw0KIHVzZSBhIGRpZmZlcmVu dCBhdXRoZW50aWNhdGlvbiBtZXRob2QuIEluIHRoZSBYQXV0aCBDcmVhdGUmIzQzO1VwZGF0ZSBz Y2VuYXJpbywgdGhlIGZhaWx1cmUgaXMgZGV0ZWN0ZWQgb24gdGhlIEdTLCBhbmQgdGhlcmUgaXMg bm8gY2xlYXIgcGF0aCBmb3J3YXJkLiBJZiB0aGUgQ2xpZW50IG5ldmVyIGNhbGxzIFVwZGF0ZSBH cmFudCB0byBmbGlwIGludGVyYWN0aW9uLmtlZXAgdG8gZmFsc2UsIHdoYXQgc2hvdWxkIHRoZSBH UyBkbz8gSG93IGxvbmcgc2hvdWxkDQogaXQgd2FpdD8gU2hvdWxkIGl0IGlzc3VlIHRoZSBhdXRo b3JpemF0aW9uIGFueXdheSwgYXNzdW1pbmcgdGhlIENsaWVudCB3aWxsIGNvbWUgYmFjayBhbmQg YXNrIGZvciBpdCBhdCBzb21lIHBvaW50PyBTaG91bGQgaXQgcmVkaXJlY3QgdGhlIGVuZCB1c2Vy IGJhY2sgdG8gdGhlIENsaWVudCBhbnl3YXksIG9yIGRyb3AgdGhlbSBvbiBhIGxhbmRpbmcgcGFn ZT8gU2hvdWxkIGl0IGZsYWcgdGhpcyBhcyBhbiBlcnJvciwgb3IgaXMgdGhpcyB0aGUgZXhwZWN0 ZWQNCiBiZWhhdmlvciBmb3IgdGhlIENsaWVudD88bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JIHJlYWxseSB0aGluayB0aGlzIGlzIG92ZXJjb21wbGljYXRp bmcgdGhlIHByb3RvY29sIHRvIGFuIGV4dGVudCB0aGF0IG5vIG9uZSB3aWxsIGFjdHVhbGx5IGlt cGxlbWVudCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsvcmljaGFubmFdPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGZsb3cgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDIjc2VjdGlvbi0z LjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2Nv bC0wMiNzZWN0aW9uLTMuMTwvYT4mbmJzcDtpcyBFWEFDVExZIHRoZSBzYW1lIGFzIHRoZSBHb29n bGUgYW5kIE1pY3Jvc29mdA0KIGZsb3dzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5XaGlsZSB0aGUgZmxvdyBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMiNzZWN0aW9uLTMuNCI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAy I3NlY3Rpb24tMy40PC9hPiZuYnNwO2hhcyBhZGRpdGlvbmFsIHN0ZXBzLCBpdCBpcyBub3QgZnVu ZGFtZW50YWxseQ0KIGFueSBkaWZmZXJlbnQgZXhjZXB0IHRoZSBDbGllbnQgaXMgbWFraW5nIGFu b3RoZXIgY2FsbCB0byB0aGUgR1MgYWZ0ZXIgdGhlIGZpcnN0IG9uZSByZXR1cm5zLiBUaGUgcmlz ayBvZiB0aGUgQ2xpZW50IG5vdCBtYWtpbmcgdGhlIHNlY29uZCBjYWxsIGFuZCBsZWF2aW5nIHRo ZSBVc2VyIGhhbmdpbmcgaXMgbm90IHJlYWxseSBhbnkgZGlmZmVyZW50IG9mIHRoZSBDbGllbnQg bm90IG1ha2luZyB0aGUgZmlyc3QgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+QmVzaWRlcyB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBtb2JpbGUgZGV2aWNlIHRoYXQg TUFZIG5vdCBiZSBhYmxlIHRvIG1ha2UgdGhlIHNlY29uZCBjYWxsIG1pZ2h0IHB1dCB0byBzbGVl cCwgSSBkb24ndCBzZWUgYW55IGltcGxlbWVudGF0aW9uIGlzc3Vlcy4gVHhBdXRoIHdvcmtzIHRo ZSBzYW1lIHdheSBhcyAzLjEgYXMgSSB1bmRlcnN0YW5kIGl0IGZvciBub24tcmVkaXJlY3QNCiBm bG93cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5bcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkkgZG9u4oCZdCB0aGluayB5b3UgYWN0dWFsbHkgcmVhZCB3aGF0IEkg d3JvdGUuIElmIHRoZSBmbG93cyBhcmUgZXhhY3RseSB0aGUgc2FtZSwgdGVsbCBtZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVu dDotLjI1aW4iPg0KMS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj5XaGF0IGRvZXMgdGhlIHVzZXIgdGhpbmsgaXMgZ29pbmcgb24gd2hpbGUgdGhl eeKAmXJlIHNpdHRpbmcgb24gdGhlIEdTLCB3YXRjaGluZyBhIHNwaW5uZXIgYXMgdGhlIEdTIHdh aXRzIGZvciB0aGUgQ2xpZW50IHRvIG1ha2UgYW4gVXBkYXRlDQogR3JhbnQgcmVxdWVzdCBpbiAz LjQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGlu O21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1 aW4iPg0KMi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj5XaGF0IGV4aXN0aW5nIENsaWVudCBjb21wb25lbnQgaXMgaG9sZGluZyBvcGVuIHRoZSBS ZWFkIEdyYW50IHJlcXVlc3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjIuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0 ZXh0LWluZGVudDotLjI1aW4iPg0KYS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj5JZiB5b3VyIGFuc3dlciBpcyDigJxhbiBhc3luYyBwcm9jZXNz IG9uIHRoZSBDbGllbnTigJlzIHNlcnZlcuKAnSB0aGVuIHBsZWFzZSByZS1yZWFkIHRoZSBzZWNv bmQgd29yZCBvZiB0aGF0IHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjVpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj4NCjMuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+SG93IGxvbmcgc2hvdWxkIHRoZSBHUyB3YWl0IGZv ciB0aGUgQ2xpZW50IHRvIG1ha2UgdGhlIFVwZGF0ZSBHcmFudCByZXF1ZXN0IGluIDMuND8gV2hh dCBzaG91bGQgdGhlIEdTIGRvIGlmIHRoYXQgbmV2ZXIgaGFwcGVucz8gV2hhdA0KIGlzIHRoZSBw YXRoIGZvcndhcmQgZm9yIHRoZSBlbmQgdXNlciwgYXQgdGhhdCBwb2ludD88bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bcGFzdGluZyBpbiBmcm9tIHlvdXIgbGF0ZXIg ZW1haWxdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hpbGUgYSBzaW5nbGUgc3RhZ2Ug R3JhbnQgcmVxdWVzdCAoMy4xKSBpbiBhIG1vYmlsZSBhcHAgdGhhdCBoYXMgYmVlbiBwdXQgdG8g c2xlZXAgd2lsbCByZWNvdmVyIGZpbmUsIGEgbXVsdGktc3RlcCAoMy40KSB3aWxsIGZhaWwuIFNp bmNlIDMuNCBvbmx5IG1ha2VzIHNlbnNlIGlmIHRoZSBDbGllbnQgaXMgY2hlY2tpbmcgYSBkYXRh YmFzZSBhbG9uZyB0aGUgd2F5LA0KIEkgd291bGQmbmJzcDtleHBlY3QgdGhlIENsaWVudCB0byBo YXZlIGEgc2VydmVyIHNpZGUsIGFuZCB0aGUgc2VydmVyIGNvdWxkIHRha2UgZWFjaCBzdGVwLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9lbmQgcGFzdGVdPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPltyaWNoYW5uYV08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhhdmluZyBhIHJlbW90ZSBkYXRhYmFzZSBhbmQg aGF2aW5nIGEgcmVtb3RlIHNlcnZlciBhcmUgbm90IHRoZSBzYW1lIHRoaW5nLiBUaGlzIGFkZHMg YSBsb3Qgb2YgY29tcGxleGl0eSB0byBzZXJ2ZXJsZXNzIGFwcHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5bL3JpY2hhbm5hXTxpbWcgYm9yZGVyPSIwIiBpZD0iZ21haWwtbV8tMTM5MTM2 NjgyODM2NzQyMjMzMF94MDA1Zl94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUu YXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7 dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD03Y2QxOGVhNi04YzUwLTQ2ZGMtYmUyNS1lOTlmNjE0 ZGFiODIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2Fk dWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5XaGljaCBhc3BlY3QgYWRkcyBjb21wbGV4aXR5PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgYWRkZWQgY29tcGxleGl0eSBpbiBrZWVwaW5nIGFu IGludGVyYWN0aW9uIGlzIG1ha2luZyBhbiBhZGRpdGlvbmFsIEFQSSBjYWxsIGFmdGVyIHRoZSBm aXJzdCBBUEkgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPltyaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGlzc3VlIGlzbuKA mXQgdGhlIEFQSSBjYWxsIGl0c2VsZiwgaXTigJlzIHRoZSBuZWVkIGZvciB0aGUgQ2xpZW50IHRv IG1haW50YWluIGEgcGVyc2lzdGVudCwgYXN5bmNocm9ub3VzIHByb2Nlc3MgdG8gbWFrZSB0aGF0 IEFQSSBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SXQgaXMgaW5jb3JyZWN0IHRvIGFzc3VtZSB0aGF0IGV2 ZXJ5IGFwcCB3aXRoIGEgZGF0YWJhc2Ugd2lsbCBuZWNlc3NhcmlseSBoYXZlIGEgc2VydmVyIHNp ZGUuIEEgc2VydmVybGVzcyBhcHAgdGhhdCBkb2VzIGEgcmVkaXJlY3QgdG8gdGhlIEdTLCBvciB0 aGF0IHN3aXRjaGVzIHRvIGFuIGV4dGVybmFsIGJyb3dzZXIgKGFuZCB0aHVzIG1heSBiZSBwdXQg dG8gc2xlZXApDQogaGFzIG5vIGNvbXBvbmVudCB0aGF0IHdpbGwgcmVsaWFibHkgc3RheSBhbGl2 ZSB0byBob2xkIG9wZW4gdGhlIFJlYWQgR3JhbnQgcmVxdWVzdCwgcmVjZWl2ZSB0aGUgcmVzcG9u c2UsIGFuZCBmb2xsb3cgdXAgd2l0aCBhbiBVcGRhdGUgR3JhbnQgcmVxdWVzdCAoaS5lLiwgZmxv dyAzLjQpLiBBZGRpbmcgYSBzZXJ2ZXItc2lkZSBjb21wb25lbnQgdG8gZG8gdGhpcyBvcmNoZXN0 cmF0aW9uIGFkZHMgc2lnbmlmaWNhbnQgY29tcGxleGl0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Wy9y aWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0tPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4tLTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpUeGF1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5UeGF1dGhAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90eGF1dGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4 YXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E916DD08E0554FBBB324F8CE27C66194amazoncom_-- From nobody Mon Feb 17 18:51:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C1B1200F5 for ; Mon, 17 Feb 2020 15:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 S6vQOJsfmeX5 for ; Mon, 17 Feb 2020 15:03:06 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 BB932120041 for ; Mon, 17 Feb 2020 15:03:05 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01HN3250030658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 18:03:03 -0500 From: Justin Richer Message-Id: <13201C08-338F-4187-833D-F7C63A7BEACB@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_84450714-5A66-4155-90BD-071AF1BD7F78" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 17 Feb 2020 18:03:01 -0500 In-Reply-To: Cc: "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> <69ED9ADA-BFAB-458D-AFA2-CCCEAFDCBC88@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 23:03:12 -0000 --Apple-Mail=_84450714-5A66-4155-90BD-071AF1BD7F78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the explanation, that=E2=80=99s helpful. XYZ=E2=80=99s = =E2=80=9Ccallback=E2=80=9D structure is indeed for continuing the = transaction, like the redirect URI but with the features of PKCE and = State built-in and required. For the kind of more static = post-authorization redirect you=E2=80=99re asking for, I wouldn=E2=80=99t = call that a callback and would expect it to have another URLs in the = request. The same mechanism could be used for the client pushing a URL = to have backchannel messages pushed directly to it. All of these should = be allowable in parallel and separate from how the user gets out to the = server. =E2=80=94 Justin > On Feb 17, 2020, at 5:10 PM, Richard Backman, Annabelle = wrote: >=20 > XYZ seems to assume that a callback URL can be used to continue the = transaction at the RC (i.e., it=E2=80=99s like the redirect_uri in the = OAuth 2.0 authorization code grant). Consider my example in reply to = Dick, where a smart device will poll for the response, but wants to = direct the end user to an introduction/tutorial page hosted on the = manufacturer=E2=80=99s website. The website has no knowledge of the XYZ = transaction. I *think* XYZ supports this, but it=E2=80=99s not obvious = and I can imagine that AS support or prohibition would more often stem = from side effects of how the AS was written rather than as an explicit = feature decision. > =20 > But it=E2=80=99s also worth considering cases where the transaction = might be continued through the callback URL, but the response is still = destined for the device. For example, suppose a Client uses the callback = URL to present the end user with an opportunity to link to an existing = account at the RC. If the end user has multiple accounts at the AS, then = at this point they might realize they signed into the wrong one, and = want to switch. Ideally the end user would not have to manually reboot = the whole process from the smart device, since they=E2=80=99re already = sitting at a browser. Or consider the case where an end user authorizes = some but not all of the access requested by the Client. The callback URL = could land them on a page that explains the benefit they would get from = granting the rejected access. Ideally the end user would be able to = modify the grant through that browser session. A similar interaction = might happen far out of band from the original authorization, for = example if the end user chooses from within a management app for their = smart device to enable a feature that requires additional authorization. > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth on behalf of Justin Richer = > Date: Monday, February 17, 2020 at 12:29 PM > To: "Richard Backman, Annabelle" > Cc: "txauth@ietf.org" > Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 > =20 > Ah yes, looks like the website is out of date =E2=80=94 that note = dates to a previous iteration where we had an explicit =E2=80=9Ctype=E2=80= =9D field and we were already seeing the limitations of that style. = You=E2=80=99re right that the spec, the actual text on the website=E2=80=99= s examples, and our implementation all allow combining these two. In = fact, there=E2=80=99s an example of it on that page! You can absolutely = poll and wait for a callback, both use a transaction continuation = request. I=E2=80=99ll clean that up, thanks! =20 > =20 > And in the XYZ model, =E2=80=9Csend the response to this URL=E2=80=9D = would be a different interaction type to be requested from the client if = it=E2=80=99s got a different set of considerations than the callback = URL. However, I=E2=80=99m curious what =E2=80=9Cthe response=E2=80=9D = would be in that case. Are we talking a front-channel response, still, = like the implicit flow? Or are we looking for a way to push information = back to the client in the back channel? If it=E2=80=99s the latter, then = that=E2=80=99s definitely a different interaction style. And one of the = good things in XYZ is that getting info back to the client is now = decoupled from how you get the user involved, so the user could enter a = code or go to a long (or short) arbitrary URL, and the client=E2=80=99s = means of getting to the next step are the same menu of options = regardless.=20 > =20 > =E2=80=94 Justin >=20 >=20 >> On Feb 17, 2020, at 1:54 PM, Richard Backman, Annabelle = > wrote: >> =20 >> XYZ is a lot closer to what I=E2=80=99m describing, but it still = conflates =E2=80=9Credirect to this URL after the workflow=E2=80=9D with = =E2=80=9Csend the response to this URL=E2=80=9D. I *think* the draft as = written would allow a Client to provide a callback but also poll for the = response, but it=E2=80=99s not very clear. This kind of flow where the = Client is actually split between device, backend, and webapp within a = single transaction is one that deserves more attention, IMHO. >> =20 >> This note on https://oauth.xyz/interaction/ = also suggests XYZ is more limited than = it needs to be, but the draft seems to allow for this already so maybe = this note is just be out of date? >> =20 >> It would be interesting to figure out if we can combine both the user = code and arbitrary redirect URL methods, giving the user a few options. = This should be as simple as allowing more flexibility on the interaction = request portion and having the server return all possible options. >> =20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> =20 >> =20 >> From: Justin Richer > >> Date: Saturday, February 15, 2020 at 2:51 PM >> To: "Richard Backman, Annabelle" > >> Cc: "txauth@ietf.org " > >> Subject: [UNVERIFIED SENDER] Re: [Txauth] XAuth -02 >> =20 >> The interaction model that Annabelle describes below is exactly the = kind of thing that=E2=80=99s in XYZ: >> =20 >> https://oauth.xyz/interaction/ >> =20 >> An earlier implementation of XYZ had a =E2=80=9Ctype=E2=80=9D field = like XAuth does. You can see that here: >> =20 >> = https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2.= 4 = >> =20 >> We moved away from it for all of the reasons Annabelle is citing, = along with the others I=E2=80=99ve stated previously on the list that I = don=E2=80=99t feel bear repeating again. Having implemented both = patterns directly in the same project, I can attest that the code paths = are significantly simpler for the current XYZ pattern, especially on = the Authorization Server. You can look at our code yourselves, if you = like. >> =20 >> And for the =E2=80=9Csimple=E2=80=9D client case that supports only = one type (which I think we all believe will be the overwhelmingly common = case), I want to point out that the XYZ approach and the XAuth approach = are for all intents and purposes identical. The XYZ approach allows for = a lot more flexibility along with a decrease in complexity.=20 >> =20 >> =E2=80=94 Justin >> =20 >>=20 >>=20 >>=20 >>> On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle = > wrote: >>> =20 >>> [richanna] >>> Replies inline. >>> [/richanna] >>> =20 >>> =E2=80=93 >>> Annabelle Backman (she/her) >>> AWS Identity >>> https://aws.amazon.com/identity/ >>> =20 >>> =20 >>> From: Txauth > on behalf of Dick Hardt = > >>> Date: Friday, February 14, 2020 at 9:10 AM >>> To: "Richard Backman, Annabelle" = > >>> Cc: "txauth@ietf.org " > >>> Subject: Re: [Txauth] XAuth -02 >>> =20 >>> =20 >>> =20 >>> On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle = > wrote: >>>> [richanna] >>>> Replies inline >>>> [/richanna]=20 >>>> >>>> [richanna] >>>> By user code-based interaction, I mean the kind described in the = OAuth 2.0 Device Authorization Grant = , where the user receives a code and = short URL from the client, navigates to that URL in a browser, and = enters the code. While this could be packed into interaction.message, = this will lead to clunkier user experiences: >>>> 1. The GS may not be able to provide localized instructions that = match the locale on the Client. >>>>=20 >>>> 2. Suppose the GS sends a message that reads: =E2=80=9CScan the = QR code or open a browser to http://code.example/ = and enter the code: 12345.=E2=80=9D >>>>=20 >>>> a. That instruction does not make sense on a device that does = not present a QR code. Imagine hearing that from a smart speaker. >>>>=20 >>>> b. That instruction is confusingly redundant if the Client = displays the QR code along with its own instructions, like: =E2=80=9CScan = the QR code or follow the instructions below.=E2=80=9D >>>>=20 >>>> 3. Will =E2=80=9Cembed the short URL and code in the message = string=E2=80=9D be MTI? If not, text-only clients would have a broken = experience. >>>>=20 >>>> [/richanna] >>> =20 >>> Sounds like a text only interaction type should be added per my note = in the draft. Perhaps even one that is focused on the code flow, where = the parameters are the code and the URI to enter the code, letting the = Client present the parameters with localized content? >>> =20 >>> [richanna] >>> I think we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80=9D = concept wrong. We=E2=80=99re conflating three different things together: >>> =C2=B7 What does the Client need to send the end user to the = GS? >>> o A human-friendly short URL and code. >>> o Any kind of URL, as long and ugly as it needs to be. >>> =C2=B7 How will the Client receive the response from the GS? >>> o Client will make a request to the GS. >>> o GS will make a request to the Client. (I=E2=80=99ve had to = implement this for a custom integration, including it to demonstrate = that other options exist) >>> =C2=B7 Will the GS return the end user to the Client, and if = so how? >>> o Yes, by URL redirect. >>> o No. >>> =20 >>> Here is a very non-normative example request fragment, for a client = that wants both a short URL plus code and a full URL so they can = opportunistically use one or the other (AWS CLI v2 does this), will = query the GS for the response, and wants the GS to redirect to a = publicly accessible URL on the Client=E2=80=99s website after the flow = (e.g., to show further documentation/branded content to the end user): >>> { >>> "interact": { >>> "code": { "max": 8 }, >>> "url": true >>> }, >>> "response": { >>> "poll": true >>> }, >>> "return": { >>> "url": "https://help.smartdevice.example/post-setup = " >>> } >>> } >>> =20 >>> And here is an equally non-normative example response fragment: >>> { >>> "interact": { >>> "code": "123456", >>> "code_url": "https://gs.example/code ", >>> "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef = " >>> } >>> } >>> =20 >>> (Seriously do not read too much into these parameter names or = syntax, this is just to give a rough sense of how I=E2=80=99m thinking = about this. Anyone who tries to pick apart this example will be = responded to with mocking memes.) >>> [/richanna] >>>> =20 >>>> =20 >>>>> 2. Clients support multiple interaction modes and may not always = know what the GS supports (and vice-versa). For a multi-tenant GS, it = may vary by tenant configuration. Clients should be able to say what = they can do, and the GS should be able to tell them which one to use. = It=E2=80=99s a very simple but powerful inline negotiation. >>>> =20 >>>> That is what is in TxAuth. Would you elaborate on how the GS might = be constrained? Why would the GS not be able to do all? >>>> =20 >>>> I would think all constraints would be at the Client. Am I missing = something? >>>> =20 >>>> [richanna] >>>> Clients may support customer-defined GSes (e.g., enterprise IdPs), = which will vary in terms of which interaction modes they support. While = the set of interactions defined in XAuth might all be MTI for a GS, we = should assume that extensions will introduce new interactions which will = not be universally supported. An interaction mechanism might have = properties that cause some administrators to want to disable it, or to = restrict Clients to always use it. Are you assuming that a Client will = always make an OPTIONS discovery request first? >>>> [/richanna]=20 >>> =20 >>> An example of why a given GS may not support a mode would be = helpful. >>> =20 >>> I was envisioning that if an optional to support interaction mode = was not supported at the GS, that it would return an error. The Client = would then try a different one. Alternatively, the Client could start = with an OPTIONS call in cases where the GS is dynamicly chosen. >>> =20 >>> [richanna] >>> Lots of ASes don=E2=80=99t support Device Authorization Grant. I = think it=E2=80=99s safe to assume that interaction mode support will = vary for XAuth as well. =E2=80=9CKeep trying until you find one that = works=E2=80=9D sounds pretty painful for the client, and doesn=E2=80=99t = allow the client to use multiple interaction modes, as demonstrated in = my example above. >>> =20 >>> There are lots of reasons for wanting to support multiple modes: >>> =C2=B7 Some people are comfortable with QR codes, some = aren=E2=80=99t. >>> =C2=B7 Some people have smart phones that can scan them, = some don=E2=80=99t. >>> =C2=B7 People with smart phones may want to go through the = authentication flow on their desktop instead. >>> =C2=B7 Some people may have to go through the authentication = flow on their desktop, because the GS thinks iPhones only support = Bluetooth-based security keys and insists they cannot complete the login = flow even though they have two YubiKey 5Ci keys on their account. (HI, = GOOGLE ACCOUNT PROTECTION PROGRAM) >>> [/richanna] >>>> =20 >>>>> 3. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D = interaction mode. Clients can use =E2=80=9Credirect=E2=80=9D mode within = popups. However, speaking as someone who has done that, I really don=E2=80= =99t recommend it. Popups are increasingly unsupported, and prone to = weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend = to have popups disabled. The last versions of IE Mobile didn=E2=80=99t = support them at all (the popped up page basically just loaded into the = current window).. in=20 >>>> =20 >>>> Popups are really useful in single-page apps as you want to keep = the context and not reload the page. >>>> =20 >>>> Agree that popups don't make sense in mobile. A full redirect does = of course. A single-page app on mobile would open a new tab which would = be a separate context rather than a redirect. >>>> =20 >>>> [richanna] >>>> Popups are broken and/or disabled in enough instances that we = should not encourage their usage by including explicit support for them = in the protocol. Nor are they necessary for SPAs in order to restore the = state of their app after the redirect. >>> =20 >>> Are they really that broken in desktop? I've used them extensively = myself in the past as it was a better user experience, but that was a = few years ago. >>> =20 >>> [richanna] >>> Popup blockers are built in and aggressively enabled by default on = all major browsers. Communicating securely between windows is not easy, = and from past experience prone to failure thanks to weird browser bugs. = Trusted Site settings in IE and Edge can blow the whole thing up in = weird ways (speaking again from experience). >>> =20 >>> Also, it=E2=80=99s 2020. Stop branching on mobile vs. desktop. I get = that lots of people still do that, but that doesn=E2=80=99t mean the = protocol should cater to it. >>> [/richanna] >>>> And again, a Client that really wants to give themselves a headache = with popups can do that themselves using =E2=80=9Credirect=E2=80=9D = mode. They just have to provide a landing page for the GS to redirect = back to that parses the response, passes it back to the main window, and = closes itself. I don=E2=80=99t see why the protocol would need to = explicitly describe this mechanism.=20 >>>> [/richanna] >>> =20 >>> I think it is a useful signal for the GS in the experience it wants = to show the user. >>> =20 >>> [richanna] >>> Useful how? The window dimensions are a better signal for how to = present the user experience. (*cough* responsive design *cough*) >>> [/richanna] >>>> =20 >>>>> Section 12.6: >>>>> [Editor: is there some other reason to have the UserInfo >>>>> endpoint?] >>>>> =20 >>>>> I may want to host my UserInfo endpoint on a separate microservice = from my token endpoint (in OAuth 2.0/OIDC terms). The former might be = part of my user profile/directory stack, while the latter is part of the = highly privileged authentication/authorization stack. >>>> =20 >>>> =20 >>>> The token endpoint has the access token anyway, so it can fetch the = data from the other endpoint itself if it wanted to. IE, there is no = separation of duties. >>>> =20 >>>> What are the advantages of the UserInfo endpoint to the User or = Client?=20 >>>> =20 >>>> The UserInfo endpoint seems to just add more complexity, with no = ability to start a User interaction if additional consent is needed. >>>> =20 >>>> [richanna] >>>> If the access token is sender-constrained, then no, the token = endpoint can=E2=80=99t fetch the data itself. But even without the = security angle, there is value in separating out the functionality as it = allows the GS to distribute it across systems with different owners. = E.g., there might be a directory API team that also owns the SCIM = interface and UserInfo endpoint. >>> =20 >>> An implementation can also route calls to different internal systems = while keeping the same endpoint. >>> =20 >>> I also think of SCiM and UserInfo as very different endpoints. I = would consider SCIM a resource, and UserInfo claims. I appreciate those = are similar in enterprise, but they are not in consumer contexts. >>> =20 >>> [richanna] >>> Routing calls to different internal systems still means I have to = have some shared infrastructure that both teams manage. It=E2=80=99s = more complex than it needs to be. >>> =20 >>> I=E2=80=99m going to suggest we move this part of the discussion to = a separate thread because it=E2=80=99s too messy to keep in this awful = back-and-forth. I=E2=80=99ll just add here that I=E2=80=99m not = suggesting we only have a UserInfo endpoint. I=E2=80=99m arguing two = things: >>> 1. The UserInfo endpoint is good, actually. It doesn=E2=80=99t = need to be MTI, but we should not preclude its existence. >>> 2. If we provide a mechanism for requesting and receiving = claims in the GS Read Grant response, that mechanism should apply = generically to arbitrary resources. GSes can support it or not, for any = given resource. >>> [/richanna] >>> =20 >>> >>>> [richanna] >>>> There are two big differences between those examples (e.g., QR = Code, app-based login approvals) and this mechanism in XAuth: >>>> 1. In your examples of this behavior today, the reason for the = wait is clear and obvious, and driven by the user. E.g., my printer is = waiting for me to go enter this code and log in; Google sign in is = waiting for me to tap this button on my phone. That is not the case in = the XAuth protocol. The user is left sitting on a loading screen waiting = for a behind-the-scenes interaction between client and GS that may not = even happen. >>>>=20 >>>> 2. Unlike with code/QR flows or sign-in verification, there is no = active process on the client side to keep this async request open. A web = app client would have to introduce a server-side async process to manage = this aspect of the protocol. That=E2=80=99s not easy. >>>>=20 >>>> 3. The failure modes show up in more appropriate contexts, where = there are clear paths forward for the end user. In code/QR-based flows, = it=E2=80=99s detected on the client side, in the form of an AS that = never provides a response. In that scenario, the client can retry the = process. In sign-in verification, the problem occurs between two parts = of the AS, and the AS can allow the end user to retry or to use a = different authentication method. In the XAuth Create+Update scenario, = the failure is detected on the GS, and there is no clear path forward. = If the Client never calls Update Grant to flip interaction.keep to = false, what should the GS do? How long should it wait? Should it issue = the authorization anyway, assuming the Client will come back and ask for = it at some point? Should it redirect the end user back to the Client = anyway, or drop them on a landing page? Should it flag this as an error, = or is this the expected behavior for the Client? >>>>=20 >>>> =20 >>>> I really think this is overcomplicating the protocol to an extent = that no one will actually implement it. >>>> [/richanna] >>> =20 >>> The flow in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 = = is EXACTLY the same as the Google and Microsoft flows.=20 >>> =20 >>> While the flow in = https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 = = has additional steps, it is not fundamentally any different except the = Client is making another call to the GS after the first one returns. The = risk of the Client not making the second call and leaving the User = hanging is not really any different of the Client not making the first = call. >>> =20 >>> Besides the situation where the mobile device that MAY not be able = to make the second call might put to sleep, I don't see any = implementation issues. TxAuth works the same way as 3.1 as I understand = it for non-redirect flows. >>> =20 >>> [richanna] >>> I don=E2=80=99t think you actually read what I wrote. If the flows = are exactly the same, tell me: >>> 1. What does the user think is going on while they=E2=80=99re = sitting on the GS, watching a spinner as the GS waits for the Client to = make an Update Grant request in 3.4? >>> 2. What existing Client component is holding open the Read = Grant request? >>> a. If your answer is =E2=80=9Can async process on the = Client=E2=80=99s server=E2=80=9D then please re-read the second word of = that question. >>> 3. How long should the GS wait for the Client to make the = Update Grant request in 3.4? What should the GS do if that never = happens? What is the path forward for the end user, at that point? >>> [/richanna] >>>> =20 >>>> [pasting in from your later email] >>>> While a single stage Grant request (3.1) in a mobile app that has = been put to sleep will recover fine, a multi-step (3.4) will fail. Since = 3.4 only makes sense if the Client is checking a database along the way, = I would expect the Client to have a server side, and the server could = take each step. >>>> [/end paste] >>>> =20 >>>> [richanna] >>>> Having a remote database and having a remote server are not the = same thing. This adds a lot of complexity to serverless apps. >>>> [/richanna]=E1=90=A7 >>> =20 >>> Which aspect adds complexity? >>> =20 >>> The added complexity in keeping an interaction is making an = additional API call after the first API call. >>> =20 >>> [richanna] >>> The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need = for the Client to maintain a persistent, asynchronous process to make = that API call. >>> =20 >>> It is incorrect to assume that every app with a database will = necessarily have a server side. A serverless app that does a redirect to = the GS, or that switches to an external browser (and thus may be put to = sleep) has no component that will reliably stay alive to hold open the = Read Grant request, receive the response, and follow up with an Update = Grant request (i.e., flow 3.4). Adding a server-side component to do = this orchestration adds significant complexity. >>> [/richanna] >>> =20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_84450714-5A66-4155-90BD-071AF1BD7F78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the explanation, that=E2=80=99s helpful. XYZ=E2=80=99= s =E2=80=9Ccallback=E2=80=9D structure is indeed for continuing the = transaction, like the redirect URI but with the features of PKCE and = State built-in and required. For the kind of more static = post-authorization redirect you=E2=80=99re asking for, I wouldn=E2=80=99t = call that a callback and would expect it to have another URLs in the = request. The same mechanism could be used for the client pushing a URL = to have backchannel messages pushed directly to it. All of these should = be allowable in parallel and separate from how the user gets out to the = server.

 =E2=80=94= Justin

On Feb 17, 2020, at 5:10 PM, = Richard Backman, Annabelle <richanna@amazon.com> wrote:

XYZ seems = to assume that a callback URL can be used to continue the transaction at = the RC (i.e., it=E2=80=99s like the redirect_uri in the OAuth 2.0 = authorization code grant). Consider my example in reply to Dick, where a = smart device will poll for the response, but wants to direct the end = user to an introduction/tutorial page hosted on the manufacturer=E2=80=99s= website. The website has no knowledge of the XYZ transaction. I *think* XYZ supports this, but it=E2=80=99s not obvious = and I can imagine that AS support or prohibition would more often stem = from side effects of how the AS was written rather than as an explicit = feature decision.
 
But it=E2=80=99s also worth considering cases where the = transaction might be continued through the callback URL, but the = response is still destined for the device. For example, suppose a Client = uses the callback URL to present the end user with an opportunity to = link to an existing account at the RC. If the end user has multiple = accounts at the AS, then at this point they might realize they signed = into the wrong one, and want to switch. Ideally the end user would not = have to manually reboot the whole process from the smart device, since = they=E2=80=99re already sitting at a browser. Or consider the case where = an end user authorizes some but not all of the access requested by the = Client. The callback URL could land them on a page that explains the = benefit they would get from granting the rejected access. Ideally the = end user would be able to modify the grant through that browser session. = A similar interaction might happen far out of band from the original = authorization, for example if the end user chooses from within a = management app for their smart device to enable a feature that requires = additional authorization.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: Monday, February 17, = 2020 at 12:29 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] = [UNVERIFIED SENDER] Re: XAuth -02
 
Ah yes, looks like the website is out = of date =E2=80=94 that note dates to a previous iteration where we had = an explicit =E2=80=9Ctype=E2=80=9D field and we were already seeing the = limitations of that style. You=E2=80=99re right that the spec, the = actual text on the website=E2=80=99s examples, and our implementation = all allow combining these two. In fact, there=E2=80=99s an example of it = on that page! You can absolutely poll and wait for a callback, both use = a transaction continuation request. I=E2=80=99ll clean that up, = thanks!  
 
And in the XYZ model, =E2=80=9Csend the = response to this URL=E2=80=9D would be a different interaction type to = be requested from the client if it=E2=80=99s got a different set of = considerations than the callback URL. However, I=E2=80=99m curious what = =E2=80=9Cthe response=E2=80=9D would be in that case. Are we talking a = front-channel response, still, like the implicit flow? Or are we looking = for a way to push information back to the client in the back channel? If = it=E2=80=99s the latter, then that=E2=80=99s definitely a different = interaction style. And one of the good things in XYZ is that getting = info back to the client is now decoupled from how you get the user = involved, so the user could enter a code or go to a long (or short) = arbitrary URL, and the client=E2=80=99s means of getting to the next = step are the same menu of options regardless. 
 
 =E2=80=94 Justin


On Feb 17, 2020, at 1:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
XYZ is a lot closer to what I=E2=80=99m = describing, but it still conflates =E2=80=9Credirect to this URL after = the workflow=E2=80=9D with =E2=80=9Csend the response to this URL=E2=80=9D= . I *think* the draft as written would allow a Client = to provide a callback but also poll for the response, but it=E2=80=99s = not very clear. This kind of flow where the Client is actually split = between device, backend, and webapp within a single transaction is one = that deserves more attention, IMHO.
 
This note on https://oauth.xyz/interaction/ also suggests XYZ is more = limited than it needs to be, but the draft seems to allow for this = already so maybe this note is just be out of date?
 
It would be interesting to figure out if we can combine both = the user code and arbitrary redirect URL methods, giving the user a few = options. This should be as simple as allowing more flexibility on the = interaction request portion and having the server return all possible = options.
 
=E2=80=93
Annabelle Backman = (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Justin Richer <jricher@mit.edu>
Date: Saturday, February 15, = 2020 at 2:51 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: [UNVERIFIED SENDER] Re: = [Txauth] XAuth -02
 
The interaction = model that Annabelle describes below is exactly the kind of thing = that=E2=80=99s in XYZ:
 
 
An earlier implementation of XYZ had a = =E2=80=9Ctype=E2=80=9D field like XAuth does. You can see that here:
 
https://tools.ietf.org/html/draft-richer-transactional-authz-00= #section-2.4
 
We moved away from it for all of the reasons Annabelle is = citing, along with the others I=E2=80=99ve stated previously on the list = that I don=E2=80=99t feel bear repeating again. Having implemented both = patterns directly in the same project, I can attest that the code paths = are significantly simpler  for the current XYZ pattern, especially = on the Authorization Server. You can look at our code yourselves, if you = like.
 
And for the =E2=80=9Csimple=E2=80=9D = client case that supports only one type (which I think we all believe = will be the overwhelmingly common case), I want to point out that the = XYZ approach and the XAuth approach are for all intents and purposes = identical. The XYZ approach allows for a lot more flexibility along with = a decrease in complexity. 
 
 =E2=80=94 Justin
 



On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
 
[richanna]
Replies inline.
[/richanna]
 
=E2=80=93
Annabelle Backman = (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 14, = 2020 at 9:10 AM
To: "Richard Backman, = Annabelle" <richanna=3D40amazon.com@dmarc.ietf.org>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] XAuth = -02
 
 
 
On Thu, = Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:
[richanna]
Replies = inline
[/richanna] 
<snip>
[richanna]
By user code-based interaction, I mean = the kind described in the OAuth 2.0 = Device Authorization Grant, where the user receives a code and short = URL from the client, navigates to that URL in a browser, and enters the = code. While this could be packed into interaction.message, this will = lead to clunkier user experiences:

1.   The GS may not be = able to provide localized instructions that match the locale on the = Client.

2.   Suppose the GS sends = a message that reads: =E2=80=9CScan the QR code or open a browser = to http://code.example/ and enter the code: = 12345.=E2=80=9D

a.    That instruction = does not make sense on a device that does not present a QR code. Imagine = hearing that from a smart speaker.

b.   That instruction is = confusingly redundant if the Client displays the QR code along with its = own instructions, like: =E2=80=9CScan the QR code or follow the = instructions below.=E2=80=9D

3.   Will =E2=80=9Cembed = the short URL and code in the message string=E2=80=9D be MTI? If not, = text-only clients would have a broken experience.

[/richanna]
 
Sounds like a text only interaction type should be added per = my note in the draft. Perhaps even one that is focused on the code flow, = where the parameters are the code and the URI to enter the code, letting = the Client present the parameters with localized content?
 
[richanna]
I think we=E2=80=99re approaching the = =E2=80=9Cinteraction=E2=80=9D concept wrong. We=E2=80=99re conflating = three different things together:
=C2=B7         What does the Client = need to send the end user to the GS?

o    A human-friendly = short URL and code.

o    Any kind of URL, as = long and ugly as it needs to be.

=C2=B7         How will the Client = receive the response from the GS?

o    Client will make a = request to the GS.

o    GS will make a = request to the Client. (I=E2=80=99ve had to implement this for a custom = integration, including it to demonstrate that other options exist)

=C2=B7         Will the GS return = the end user to the Client, and if so how?

o    Yes, by URL = redirect.

o    No.

 
Here is a very non-normative example = request fragment, for a client that wants both a short URL plus code and = a full URL so they can opportunistically use one or the other (AWS CLI = v2 does this), will query the GS for the response, and wants the GS to = redirect to a publicly accessible URL on the Client=E2=80=99s website = after the flow (e.g., to show further documentation/branded content to = the end user):
{
"interact": {
  "code": { "max": 8 },
  "url": true
},
"response": {
  "poll": true
},
"return": {
  "url": "https://help.smartdevice.example/post-setup"
}
}
 
And here is an equally non-normative = example response fragment:
{
"interact": {
  "code": "123456",
  "code_url": "https://gs.example/code",
  "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef"=
}
}
 
(Seriously do not read too much into = these parameter names or syntax, this is just to give a rough sense of = how I=E2=80=99m thinking about this. Anyone who tries to pick apart this = example will be responded to with mocking memes.)
[/richanna]
 
 
2.   Clients support = multiple interaction modes and may not always know what the GS supports = (and vice-versa). For a multi-tenant GS, it may vary by tenant = configuration. Clients should be able to say what they can do, and the = GS should be able to tell them which one to use. It=E2=80=99s a very = simple but powerful inline negotiation.
 
That is what is in TxAuth. Would you elaborate on how the GS = might be constrained? Why would the GS not be able to do all?
 
I would = think all constraints would be at the Client. Am I missing = something?
 
[richanna]
Clients may support customer-defined = GSes (e.g., enterprise IdPs), which will vary in terms of which = interaction modes they support. While the set of interactions defined in = XAuth might all be MTI for a GS, we should assume that extensions will = introduce new interactions which will not be universally supported. An = interaction mechanism might have properties that cause some = administrators to want to disable it, or to restrict Clients to always = use it. Are you assuming that a Client will always make an OPTIONS = discovery request first?
[/richanna] 
 
An example of why a given GS may not support a mode would be = helpful.
 
I was = envisioning that if an optional to support interaction mode was not = supported at the GS, that it would return an error. The Client would = then try a different one. Alternatively, the Client could start with an = OPTIONS call in cases where the GS is dynamicly chosen.
 
[richanna]
Lots of ASes don=E2=80=99t support = Device Authorization Grant. I think it=E2=80=99s safe to assume that = interaction mode support will vary for XAuth as well. =E2=80=9CKeep = trying until you find one that works=E2=80=9D sounds pretty painful for = the client, and doesn=E2=80=99t allow the client to use multiple = interaction modes, as demonstrated in my example above.
 
There are lots of reasons for wanting = to support multiple modes:

=C2=B7         Some people are = comfortable with QR codes, some aren=E2=80=99t.

=C2=B7         Some people have = smart phones that can scan them, some don=E2=80=99t.

=C2=B7         People with smart = phones may want to go through the authentication flow on their desktop = instead.

=C2=B7         Some people may have to go through the = authentication flow on their desktop, because the GS thinks iPhones only = support Bluetooth-based security keys and insists they cannot complete = the login flow even though they have two YubiKey 5Ci keys on their = account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)

[/richanna]
 
3.   I don=E2=80=99t see = the value of the =E2=80=9Cpopup=E2=80=9D interaction mode. Clients can = use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking as = someone who has done that, I really don=E2=80=99t recommend it. Popups = are increasingly unsupported, and prone to weird behavioral issues. = In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. = The last versions of IE Mobile didn=E2=80=99t support them at all (the = popped up page basically just loaded into the current window).. = in 
 
Popups are really useful in single-page apps as you want to = keep the context and not reload the page.
 
Agree = that popups don't make sense in mobile. A full redirect does of course. = A single-page app on mobile would open a new tab which would be a = separate context rather than a redirect.
 
[richanna]
Popups are broken and/or disabled in = enough instances that we should not encourage their usage by including = explicit support for them in the protocol. Nor are they necessary for = SPAs in order to restore the state of their app after the redirect.
 
Are they really that broken in desktop? I've used them = extensively myself in the past as it was a better user experience, but = that was a few years ago.
 
[richanna]
Popup blockers are built in and = aggressively enabled by default on all major browsers. Communicating = securely between windows is not easy, and from past experience prone to = failure thanks to weird browser bugs. Trusted Site settings in IE and = Edge can blow the whole thing up in weird ways (speaking again from = experience).
 
Also, it=E2=80=99s 2020. Stop branching = on mobile vs. desktop. I get that lots of people still do that, but that = doesn=E2=80=99t mean the protocol should cater to it.
[/richanna]
And = again, a Client that really wants to give themselves a headache with = popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. = They just have to provide a landing page for the GS to redirect back to = that parses the response, passes it back to the main window, and closes = itself. I don=E2=80=99t see why the protocol would need to explicitly = describe this mechanism. 
[/richanna]
 
I think it is a useful signal for the GS in the experience it = wants to show the user.
 
[richanna]
Useful how? The window dimensions are a = better signal for how to present the user experience. (*cough* = responsive design *cough*)
[/richanna]
 
Section 12.6:
        [Editor: is there =
some other reason to have the UserInfo
        endpoint?]
 
I may = want to host my UserInfo endpoint on a separate microservice from my = token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my = user profile/directory stack, while the latter is part of the highly = privileged authentication/authorization stack.
 
 
The token endpoint has the access token anyway, so it can = fetch the data from the other endpoint itself if it wanted to. IE, there = is no separation of duties.
 
What are = the advantages of the UserInfo endpoint to the User or Client? 
 
The = UserInfo endpoint seems to just add more complexity, with no ability to = start a User interaction if additional consent is needed.
 
[richanna]
If the access token is = sender-constrained, then no, the token endpoint can=E2=80=99t fetch the = data itself. But even without the security angle, there is value in = separating out the functionality as it allows the GS to distribute it = across systems with different owners. E.g., there might be a directory = API team that also owns the SCIM interface and UserInfo endpoint.
 
An implementation can also route calls to different internal = systems while keeping the same endpoint.
 
I also = think of SCiM and UserInfo as very different endpoints. I would consider = SCIM a resource, and UserInfo claims. I appreciate those are similar in = enterprise, but they are not in consumer contexts.
 
[richanna]
Routing calls to different internal = systems still means I have to have some shared infrastructure that both = teams manage. It=E2=80=99s more complex than it needs to be.
 
I=E2=80=99m going to suggest we move = this part of the discussion to a separate thread because it=E2=80=99s = too messy to keep in this awful back-and-forth. I=E2=80=99ll just add = here that I=E2=80=99m not suggesting we only have a UserInfo endpoint. = I=E2=80=99m arguing two things:

1.       The UserInfo = endpoint is good, actually. It doesn=E2=80=99t need to be MTI, but we = should not preclude its existence.

2.       If we provide a = mechanism for requesting and receiving claims in the GS Read Grant = response, that mechanism should apply generically to arbitrary = resources. GSes can support it or not, for any given resource.

[/richanna]
 
<snip>
[richanna]
There are = two big differences between those examples (e.g., QR Code, app-based = login approvals) and this mechanism in XAuth:

1.   In your examples of = this behavior today, the reason for the wait is clear and obvious, and = driven by the user. E.g., my printer is waiting for me to go enter this = code and log in; Google sign in is waiting for me to tap this button on = my phone. That is not the case in the XAuth protocol. The user is left = sitting on a loading screen waiting for a behind-the-scenes interaction = between client and GS that may not even happen.

2.   Unlike with code/QR = flows or sign-in verification, there is no active process on the client = side to keep this async request open. A web app client would have to = introduce a server-side async process to manage this aspect of the = protocol. That=E2=80=99s not easy.

3.   The failure modes = show up in more appropriate contexts, where there are clear paths = forward for the end user. In code/QR-based flows, it=E2=80=99s detected = on the client side, in the form of an AS that never provides a response. = In that scenario, the client can retry the process. In sign-in = verification, the problem occurs between two parts of the AS, and the AS = can allow the end user to retry or to use a different authentication = method. In the XAuth Create+Update scenario, the failure is detected on = the GS, and there is no clear path forward. If the Client never calls = Update Grant to flip interaction.keep to false, what should the GS do? = How long should it wait? Should it issue the authorization anyway, = assuming the Client will come back and ask for it at some point? Should = it redirect the end user back to the Client anyway, or drop them on a = landing page? Should it flag this as an error, or is this the expected = behavior for the Client?

 
I really think this is overcomplicating = the protocol to an extent that no one will actually implement it.
[/richanna]
 
The flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#secti= on-3.1 is EXACTLY the same as the Google and Microsoft = flows. 
 
While the flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#secti= on-3.4 has additional steps, it is not fundamentally any = different except the Client is making another call to the GS after the = first one returns. The risk of the Client not making the second call and = leaving the User hanging is not really any different of the Client not = making the first call.
 
Besides the situation where the mobile device that MAY not be = able to make the second call might put to sleep, I don't see any = implementation issues. TxAuth works the same way as 3.1 as I understand = it for non-redirect flows.
 
[richanna]
I don=E2=80=99t think you actually read = what I wrote. If the flows are exactly the same, tell me:

1.       What does the user = think is going on while they=E2=80=99re sitting on the GS, watching a = spinner as the GS waits for the Client to make an Update Grant request = in 3.4?

2.       What existing Client = component is holding open the Read Grant request?

a.       If your answer is = =E2=80=9Can async process on the Client=E2=80=99s server=E2=80=9D then = please re-read the second word of that question.

3.       How long should the = GS wait for the Client to make the Update Grant request in 3.4? What = should the GS do if that never happens? What is the path forward for the = end user, at that point?

[/richanna]
 
[pasting in from your later email]
While a single stage Grant request = (3.1) in a mobile app that has been put to sleep will recover fine, a = multi-step (3.4) will fail. Since 3.4 only makes sense if the Client is = checking a database along the way, I would expect the Client to = have a server side, and the server could take each step.
[/end paste]
 
[richanna]
Having a remote database and having a = remote server are not the same thing. This adds a lot of complexity to = serverless apps.
[/richanna]=E1=90=A7
 
Which aspect adds complexity?
 
The added = complexity in keeping an interaction is making an additional API call = after the first API call.
 
[richanna]
The issue isn=E2=80=99t the API call = itself, it=E2=80=99s the need for the Client to maintain a persistent, = asynchronous process to make that API call.
 
It is incorrect to assume that every = app with a database will necessarily have a server side. A serverless = app that does a redirect to the GS, or that switches to an external = browser (and thus may be put to sleep) has no component that will = reliably stay alive to hold open the Read Grant request, receive the = response, and follow up with an Update Grant request (i.e., flow 3.4). = Adding a server-side component to do this orchestration adds significant = complexity.
[/richanna]
 
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_84450714-5A66-4155-90BD-071AF1BD7F78-- From nobody Mon Feb 17 18:53:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB76F12002E for ; Mon, 17 Feb 2020 16:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 INF1Iipb2IPe for ; Mon, 17 Feb 2020 16:22:09 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 7CF1E120866 for ; Mon, 17 Feb 2020 16:22:08 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id 9so13113891lfq.10 for ; Mon, 17 Feb 2020 16:22:08 -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=sGfnMAhbRiSnn2iKHJCyxwdC0fZzXgoxcZ4fAcH8md8=; b=mylbR+IkD4wu9u8yYWDEBBrlNXQwHHYV3niuJvzz2m6RAymTxY7HPOFCkOYW8SGShx n5AkGUfWoH5iGRSfJaCE9HZf+NmYqoaUeSFYHGl99BwYsGj/9GR2Z0VH3IQ8782bqkBK moZS1U1VgOJtcVGKrOxCvxEnbI6/P8iZN/jvHH59c2Rejl5mn9Ec+CSkr+191EK0oBba hJGIHZt7moGnTnBKkBEiIi7Kc1ScFuH1Uh6jCgLQgOcaA++BKJnsy7W2ozzliA81MTfT p5GutTaJ47T4HYOHzGkLk5dljNBZbKCo0AzXC1/zjUVBrJ1jIBB6oIR5Z1XktdE/mWeM w3ig== 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=sGfnMAhbRiSnn2iKHJCyxwdC0fZzXgoxcZ4fAcH8md8=; b=Wb5qeiOiKAFbQ+igoIRNPg5FpApCZaxXt0BpDZ9Dnnp0GiWvtDFdDWe4x7cvqYVTs8 F8jQL6wV+XjpgdDF/GxqI3MM39DZCxrblHvgCV1M95mhcrH/TtXa25y9zB0BhOvVSwZs 56LbvBIMpGzlz0MFh3osRf7m+NKXYXiUzX2lkRl7PdJMlOhj/1SFpzta/TpulH5MuTrA CuQRe7Su5sh4K2QO2FP6zd1oewx0L1Uo9LgNQNESl7lF5kURHD+rUDwqKl5wqdYg7gvT qMCq4Zj0b5rJTkVaKwurZ1Xy/ZwJ2BFg6mAAcONfFTc0/nXJp5yGKzb4W43rInpNhQfp 6e8g== X-Gm-Message-State: APjAAAVevv1hNQCwB7O9GguDu/1voIdGjoZi7Bed7BeMTeNuYXXNfRTI uQgCF38pW4Dz/XqKaH9+XPEgUtHd3j10p61D1C8dbGbG/X0= X-Google-Smtp-Source: APXvYqyeiadPI5InD3L0DDPokcGXv2/qGgndguSKwOVBPsh5dZfdlp0sAPcb5trrB3B2VV3nF09/IhIx9L5Yfq1XA1o= X-Received: by 2002:a05:6512:78:: with SMTP id i24mr9412240lfo.10.1581985326499; Mon, 17 Feb 2020 16:22:06 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> From: Dick Hardt Date: Mon, 17 Feb 2020 16:21:39 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006d0bc9059ecea963" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 00:22:13 -0000 --0000000000006d0bc9059ecea963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 14, 2020 at 6:29 PM Richard Backman, Annabelle wrote: > [richanna] > > Replies inline. > > [/richanna] > > Sounds like a text only interaction type should be added per my note in > the draft. Perhaps even one that is focused on the code flow, where the > parameters are the code and the URI to enter the code, letting the Client > present the parameters with localized content? > > > > [richanna] > > I think we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80=9D conce= pt wrong. We=E2=80=99re > conflating three different things together: > > - What does the Client need to send the end user to the GS? > > > - A human-friendly short URL and code. > - Any kind of URL, as long and ugly as it needs to be. > > > - How will the Client receive the response from the GS? > > > - Client will make a request to the GS. > - GS will make a request to the Client. (I=E2=80=99ve had to implem= ent this > for a custom integration, including it to demonstrate that other op= tions > exist) > > > - Will the GS return the end user to the Client, and if so how? > > > - Yes, by URL redirect. > - No. > > Your suggestions are capabilities oriented, similar (as noted in later emails) as in XYZ. XAuth is centered around the user experience the Client is able to deliver. There is always some artifact the Client is getting the User to provide the GS. > > An example of why a given GS may not support a mode would be helpful. > > > > I was envisioning that if an optional to support interaction mode was not > supported at the GS, that it would return an error. The Client would then > try a different one. Alternatively, the Client could start with an OPTION= S > call in cases where the GS is dynamicly chosen. > > > > [richanna] > > Lots of ASes don=E2=80=99t support Device Authorization Grant. I think it= =E2=80=99s safe > to assume that interaction mode support will vary for XAuth as well. =E2= =80=9CKeep > trying until you find one that works=E2=80=9D sounds pretty painful for t= he client, > and doesn=E2=80=99t allow the client to use multiple interaction modes, a= s > demonstrated in my example above. > If the device can only show a text string, that is all it can do. The Client can't move forward with either XYZ or XAuth if the AS/GS does not support a user code. > > > There are lots of reasons for wanting to support multiple modes: > > - Some people are comfortable with QR codes, some aren=E2=80=99t. > - Some people have smart phones that can scan them, some don=E2=80=99t= . > - People with smart phones may want to go through the authentication > flow on their desktop instead. > - Some people may *have* to go through the authentication flow on > their desktop, because the GS thinks iPhones only support Bluetooth-ba= sed > security keys and insists they cannot complete the login flow even tho= ugh > they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT > PROTECTION PROGRAM) > > All of your examples are choices for the User, which the Client would nee= d to present to the User. Per my comment above based on your suggestion, "qrcode" also shows the "code" information, which satisfies all your suggestions above. > > Are they really that broken in desktop? I've used them extensively myself > in the past as it was a better user experience, but that was a few years > ago. > > > > [richanna] > > Popup blockers are built in and aggressively enabled by default on all > major browsers. Communicating securely between windows is not easy, and > from past experience prone to failure thanks to weird browser bugs. Trust= ed > Site settings in IE and Edge can blow the whole thing up in weird ways > (speaking again from experience). > I checked what popular sites listed at https://ahrefs.com/blog/most-visited-websites/ use: - sites that use popups - pinterest - expedia - tripadvisor - nytimes - indeed.com - quora - redfin - trulia - sites that use a full page redirect - IMDB - an Amazon property =3D) Looks like most sites prefer popups and have figured out how to do it -- except IMDB. > > > Also, it=E2=80=99s 2020. Stop branching on mobile vs. desktop. I get that= lots of > people still do that, but that doesn=E2=80=99t mean the protocol should c= ater to it. > Mobile and desktop are different though. They don't offer the same experiences. On mobile, a GS may have a mobile app that can receive push notifications. The security parameters are different. Some implementations will want to know which platform is being used. We should not remove that signal for them. > [/richanna] > > And again, a Client that really wants to give themselves a headache with > popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They= just have to > provide a landing page for the GS to redirect back to that parses the > response, passes it back to the main window, and closes itself. I don=E2= =80=99t see > why the protocol would need to explicitly describe this mechanism. > > [/richanna] > > > > I think it is a useful signal for the GS in the experience it wants to > show the user. > > > > [richanna] > > Useful how? The window dimensions are a better signal for how to present > the user experience. (*cough* responsive design *cough*) > > [/richanna] > Responsive design is one way to address things. Lots of apps still have an m.example.com site for mobile content. Our goal is not to decide how an app should build a user experience. We should give them as much useful signal as they may need to make their own choices. > > > Section 12.6: > > [Editor: is there some other reason to have the UserInfo > > endpoint?] > > > > I may want to host my UserInfo endpoint on a separate microservice from m= y > token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my > user profile/directory stack, while the latter is part of the highly > privileged authentication/authorization stack. > > > > > > The token endpoint has the access token anyway, so it can fetch the data > from the other endpoint itself if it wanted to. IE, there is no separatio= n > of duties. > > > > What are the advantages of the UserInfo endpoint to the User or Client? > > > > The UserInfo endpoint seems to just add more complexity, with no ability > to start a User interaction if additional consent is needed. > > > > [richanna] > > If the access token is sender-constrained, then no, the token endpoint > can=E2=80=99t fetch the data itself. But even without the security angle,= there is > value in separating out the functionality as it allows the GS to distribu= te > it across systems with different owners. E.g., there might be a directory > API team that also owns the SCIM interface and UserInfo endpoint. > > > > An implementation can also route calls to different internal systems whil= e > keeping the same endpoint. > > > > I also think of SCiM and UserInfo as very different endpoints. I would > consider SCIM a resource, and UserInfo claims. I appreciate those are > similar in enterprise, but they are not in consumer contexts. > > > > [richanna] > > Routing calls to different internal systems still means I have to have > some shared infrastructure that both teams manage. It=E2=80=99s more comp= lex than > it needs to be. > For the GS. It is simpler for the Client. As stated, I think we should push complexity to the GS all other things being equal. > > > I=E2=80=99m going to suggest we move this part of the discussion to a sep= arate > thread because it=E2=80=99s too messy to keep in this awful back-and-fort= h. I=E2=80=99ll > just add here that I=E2=80=99m not suggesting we *only* have a UserInfo e= ndpoint. > I=E2=80=99m arguing two things: > > 1. The UserInfo endpoint is good, actually. It doesn=E2=80=99t need to= be MTI, > but we should not preclude its existence. > 2. If we provide a mechanism for requesting and receiving claims in > the GS Read Grant response, that mechanism should apply generically to > arbitrary resources. GSes can support it or not, for any given resourc= e. > > agree on moving this to another thread. I disagree completely on your statements. We are designing a protocol, where interop and security should be chosen over having numerous ways to do accomplish the same thing. > > 1. > > [/richanna] > > > > > > [richanna] > > There are two big differences between those examples (e.g., QR Code, > app-based login approvals) and this mechanism in XAuth: > > 1. In your examples of this behavior today, the reason for the wait is > clear and obvious, and driven by the user. E.g., my printer is waiting fo= r > me to go enter this code and log in; Google sign in is waiting for me to > tap this button on my phone. That is not the case in the XAuth protocol. > The user is left sitting on a loading screen waiting for a > behind-the-scenes interaction between client and GS that may not even > happen. > > 2. Unlike with code/QR flows or sign-in verification, there is no > active process on the client side to keep this async request open. A web > app client would have to introduce a server-side async process to manage > this aspect of the protocol. That=E2=80=99s not easy. > > 3. The failure modes show up in more appropriate contexts, where there > are clear paths forward for the end user. In code/QR-based flows, it=E2= =80=99s > detected on the client side, in the form of an AS that never provides a > response. In that scenario, the client can retry the process. In sign-in > verification, the problem occurs between two parts of the AS, and the AS > can allow the end user to retry or to use a different authentication > method. In the XAuth Create+Update scenario, the failure is detected on t= he > GS, and there is no clear path forward. If the Client never calls Update > Grant to flip interaction.keep to false, what should the GS do? How long > should it wait? Should it issue the authorization anyway, assuming the > Client will come back and ask for it at some point? Should it redirect th= e > end user back to the Client anyway, or drop them on a landing page? Shoul= d > it flag this as an error, or is this the expected behavior for the Client= ? > > > > I really think this is overcomplicating the protocol to an extent that no > one will actually implement it. > > [/richanna] > > > > The flow in > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 is > EXACTLY the same as the Google and Microsoft flows. > > > > While the flow in > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 has > additional steps, it is not fundamentally any different except the Client > is making another call to the GS after the first one returns. The risk of > the Client not making the second call and leaving the User hanging is not > really any different of the Client not making the first call. > > > > Besides the situation where the mobile device that MAY not be able to mak= e > the second call might put to sleep, I don't see any implementation issues= . > TxAuth works the same way as 3.1 as I understand it for non-redirect flow= s. > > > > [richanna] > > I don=E2=80=99t think you actually read what I wrote. If the flows are ex= actly the > same, tell me: > I did. I'm not sure we are talking about the same Google and Microsoft flows because your questions are making untrue statements. he eg: in (2), there is an active process in the Client waiting for the server to respond when the user has completed the authentication. As soon as authentication completes in the mobile phone, the Client change to an authenticated state. > 1. What does the user think is going on while they=E2=80=99re sitting = on the > GS, watching a spinner as the GS waits for the Client to make an Updat= e > Grant request in 3.4? > > I said the flows are exactly the same for 3.1 > > 1. > 2. What existing Client component is holding open the Read Grant > request? > > > 1. If your answer is =E2=80=9Can async process on the Client=E2=80=99s= server=E2=80=9D then > please re-read the second word of that question. > > As I stated, the only *potential* issue is with multi-step flows on mobil= e where the app is shut down. > > 1. > > > 1. How long should the GS wait for the Client to make the Update Grant > request in 3.4? What should the GS do if that never happens? What is t= he > path forward for the end user, at that point? > > 3.1 has the GS waiting for the Client as well. All the same questions apply to any aspect of the protocol where one party does not do the next step. The User is the most likely party to not continue. What do the GS and Client do if the User has been sent to the GS, but walks away from their device? > > 1. > > [/richanna] > > > > [pasting in from your later email] > > While a single stage Grant request (3.1) in a mobile app that has been pu= t > to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only > makes sense if the Client is checking a database along the way, I > would expect the Client to have a server side, and the server could take > each step. > > [/end paste] > > > > [richanna] > > Having a remote database and having a remote server are not the same > thing. This adds a lot of complexity to serverless apps. > > [/richanna]=E1=90=A7 > > > > Which aspect adds complexity? > > > > The added complexity in keeping an interaction is making an additional AP= I > call after the first API call. > > > > [richanna] > > The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for th= e Client to > maintain a persistent, asynchronous process to make that API call. > The 3.1 flow, and all the XYZ flows where there is no redirect all have the same requirement of the Client. An async call to a server is pretty straight forward in all modern web languages. If the Client is a mobile app put to sleep, it can remake the call to the GS and get the results in a 3.1 flow. > > > It is incorrect to assume that every app with a database will necessarily > have a server side. A serverless app that does a redirect to the GS, or > that switches to an external browser (and thus may be put to sleep) has n= o > component that will reliably stay alive to hold open the Read Grant > request, receive the response, and follow up with an Update Grant request > (i.e., flow 3.4). Adding a server-side component to do this orchestration > adds significant complexity. > 3.4 is not a required flow for the Client, and is an edge case for sophisticated Clients. > [/richanna] > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > =E1=90=A7 --0000000000006d0bc9059ecea963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 14, 2020 at 6:29 PM Richa= rd Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

[richanna]

Replies inline.

[/richanna]

=C2=A0Sounds like a text only interaction typ= e should be added per my note in the draft. Perhaps even one that is focuse= d on the code flow, where the parameters are the code and the URI to enter = the code, letting the Client present the parameters with localized content?

=C2=A0

[richanna]

I think we=E2=80=99re approaching the =E2=80=9Cinter= action=E2=80=9D concept wrong. We=E2=80=99re conflating three different thi= ngs together:

  • What does the Client need to send the end user to the GS?<= u>
    • A human-friendly short URL and code.
    • Any kind of URL, as long and ugly as it needs to be.
    • How will the Client receive the response from the GS?
      • Client will make a request to the GS.
      • GS will make a request to the Client. (I=E2=80=99ve had to implement this = for a custom integration, including it to demonstrate that other options ex= ist)
    • Will the GS return the end user to the Client, and if so how?<= /u>
      • Yes, by URL redirect.
      • No.
Your suggestions are cap= abilities oriented, similar (as noted in later emails) as in XYZ.

XAuth is centered around the user experience the Client is = able to deliver.

There is always some artifact the= Client is getting the User to provide the GS.

=C2=A0

An example of why a give= n GS may not support a mode would be helpful.

=C2=A0

I was envisioning that i= f an optional to support interaction mode was not supported at the GS, that= it would return an error. The Client would then try a different one. Alter= natively, the Client could start with an OPTIONS call in cases where the GS is dynamicly chosen.

=C2=A0

[richanna]

Lots of ASes don=E2=80=99t support Device Authorizat= ion Grant. I think it=E2=80=99s safe to assume that interaction mode suppor= t will vary for XAuth as well. =E2=80=9CKeep trying until you find one that= works=E2=80=9D sounds pretty painful for the client, and doesn=E2=80=99t allow the client to use multiple interaction modes, as demonstrated in my = example above.


If the device can only show a text string, that is all it can do. The= Client can't move forward with either XYZ or XAuth if the AS/GS does n= ot support a user code.
=C2=A0

<= /p>

=C2=A0

There are lots of reasons for wanting to support mul= tiple modes:

  • Some people are comfortable with QR codes, some aren=E2=80=99t.
  • Some people have smart phones that can scan them= , some don=E2=80=99t.
  • People with smart phones = may want to go through the authentication flow on their desktop instead.=
  • Some people may have to go through the authentication flow on their desktop, because= the GS thinks iPhones only support Bluetooth-based security keys and insis= ts they cannot complete the login flow even though they have two YubiKey 5C= i keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
All of your examples are choices for the User, which the Client = would need to present to the User.=C2=A0

Per my co= mment above based on your suggestion, "qrcode" also shows the &qu= ot;code" information, which satisfies all your suggestions above.



=

=C2=A0

Are they really that bro= ken in desktop? I've used them extensively myself in the past as it was= a better user experience, but that was a few years ago.

=C2=A0

[richanna]

Popup blockers are built in and aggressively enabled= by default on all major browsers. Communicating securely between windows i= s not easy, and from past experience prone to failure thanks to weird brows= er bugs. Trusted Site settings in IE and Edge can blow the whole thing up in weird ways (speaking again from= experience).


=
I checked what popular sites listed at https://ahrefs.com/blog/most-visited-websites/<= /a> use:

- sites that use popups
- pinte= rest
- expedia
- tripadvisor
- nytimes
- quora
- redfin=
- trulia

- sites that use a full page redirect
- IMDB - an Amazon property =3D)

=
Looks like most sites prefer popups and have figur= ed out how to do it -- except IMDB.
=C2= =A0
=

=C2=A0

Also, it=E2=80=99s 2020. Stop branching on mobile vs= . desktop. I get that lots of people still do that, but that doesn=E2=80=99= t mean the protocol should cater to it.


Mobile and desktop are different though. The= y don't offer the same experiences.

On mobile,= a GS may have a mobile app that can receive push notifications. The securi= ty parameters are different.

Some implementations = will want to know which platform is being used. We should not remove that s= ignal for them.=C2=A0

=C2=A0

[/richanna]

And again, a Client that really wants to give themselves a headache with po= pups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They jus= t have to provide a landing page for the GS to redirect back to that parses= the response, passes it back to the main window, and closes itself. I don=E2=80=99t see why the protocol would need to expl= icitly describe this mechanism.=C2=A0

[/richanna]

=C2=A0

I think it is a useful s= ignal for the GS in the experience it wants to show the user.=

=C2=A0

[richanna]

Useful how? The window dimensions are a better signa= l for how to present the user experience. (*cough* responsive design *cough= *)

[/richanna]


Responsive design is one way to address things. L= ots of apps still have an m.example.com site for mobile content.



=C2=A0

=C2=A0

Section 12.6:

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 =C2=A0[Editor: is there some other reason to have the=
 UserInfo
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoint?]

=C2=A0

I may want to host my UserInfo endpoint on a separate microservice from my = token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my us= er profile/directory stack, while the latter is part of the highly privileg= ed authentication/authorization stack.

=C2=A0

=C2=A0

The token endpoint has the access token anyway, so it can fetch the data fr= om the other endpoint itself if it wanted to. IE, there is no separation of= duties.

=C2=A0

What are the advantages of the UserInfo endpoint to the User or Client?=C2= =A0

=C2=A0

The UserInfo endpoint seems to just add more complexity, with no ability to= start a User interaction if additional consent is needed.

=C2=A0

[richanna]

If the access token is sender-constrained, then no, the token endpoint can= =E2=80=99t fetch the data itself. But even without the security angle, ther= e is value in separating out the functionality as it allows the GS to distr= ibute it across systems with different owners. E.g., there might be a directory API team that also owns the SCIM interfac= e and UserInfo endpoint.

=C2=A0

An implementation can al= so route calls to different internal systems while keeping the same endpoin= t.

=C2=A0

I also think of SCiM and= UserInfo as very different endpoints. I would consider SCIM a resource, an= d UserInfo claims. I appreciate those are similar in enterprise, but they a= re not in consumer contexts.

=C2=A0

[richanna]

Routing calls to different internal systems still me= ans I have to have some shared infrastructure that both teams manage. It=E2= =80=99s more complex than it needs to be.

=

For the GS. It is simpler for the Client. = As stated, I think we should push complexity to the GS all other things bei= ng equal.=C2=A0
=C2=A0

=C2=A0

I=E2=80=99m going to suggest we move this part of th= e discussion to a separate thread because it=E2=80=99s too messy to keep in= this awful back-and-forth. I=E2=80=99ll just add here that I=E2=80=99m not= suggesting we only have a UserInfo endpoint. I=E2=80=99m arguing two things:

  1. The UserInfo endpoint is good, actually. It doesn=E2=80=99t need = to be MTI, but we should not preclude its existence.
  2. If we provide a mechanism for requesting and receiving claims in the = GS Read Grant response, that mechanism should apply generically to arbitrar= y resources. GSes can support it or not, for any given resource.

agree on moving this to another thread.

[richanna]

There are two big differences between those examples (e.g., QR Code, app-ba= sed login approvals) and this mechanism in XAuth:

1.=C2=A0= =C2=A0 In your examples of this behavior today, the reason fo= r the wait is clear and obvious, and driven by the user. E.g., my printer i= s waiting for me to go enter this code and log in; Google sign in is waitin= g for me to tap this button on my phone. That is not the case in the XAuth protocol. The user is left sit= ting on a loading screen waiting for a behind-the-scenes interaction betwee= n client and GS that may not even happen.

2.=C2=A0= =C2=A0 Unlike with code/QR flows or sign-in verification, the= re is no active process on the client side to keep this async request open.= A web app client would have to introduce a server-side async process to ma= nage this aspect of the protocol. That=E2=80=99s not easy.

3.=C2=A0= =C2=A0 The failure modes show up in more appropriate contexts= , where there are clear paths forward for the end user. In code/QR-based fl= ows, it=E2=80=99s detected on the client side, in the form of an AS that ne= ver provides a response. In that scenario, the client can retry the process. In sign-in verification, the problem occ= urs between two parts of the AS, and the AS can allow the end user to retry= or to use a different authentication method. In the XAuth Create+Update sc= enario, the failure is detected on the GS, and there is no clear path forward. If the Client never calls U= pdate Grant to flip interaction.keep to false, what should the GS do? How l= ong should it wait? Should it issue the authorization anyway, assuming the = Client will come back and ask for it at some point? Should it redirect the end user back to the Client anywa= y, or drop them on a landing page? Should it flag this as an error, or is t= his the expected behavior for the Client?

=C2=A0

I really think this is overcomplicating the protocol to an extent that no o= ne will actually implement it.

[/richanna]

=C2=A0

The flow in=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-02= #section-3.1=C2=A0is EXACTLY the same as the Google and Microsoft flows.=C2=A0

=C2=A0

While the flow in=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section= -3.4" target=3D"_blank">https://tools.ietf.org/html/draft-hardt-xauth-proto= col-02#section-3.4=C2=A0has additional steps, it is not fundamentally any different except the Client is making another call to the GS after the= first one returns. The risk of the Client not making the second call and l= eaving the User hanging is not really any different of the Client not makin= g the first call.

=C2=A0

Besides the situation wh= ere the mobile device that MAY not be able to make the second call might pu= t to sleep, I don't see any implementation issues. TxAuth works the sam= e way as 3.1 as I understand it for non-redirect flows.

=C2=A0

[richanna]

I don=E2=80=99t think you actually read what I wrote= . If the flows are exactly the same, tell me:


I did. I'm not sure we are talking= about the same Google and Microsoft flows because your questions are makin= g untrue statements.
he
eg: in (2), there is an active = process in the Client waiting for the server to respond when the user has c= ompleted the authentication. As soon as authentication completes in the mob= ile phone, the Client change to an authenticated state.

  1. What does the user think is going on while they=E2=80=99re sittin= g on the GS, watching a spinner as the GS waits for the Client to make an U= pdate Grant request in 3.4?
I said the flows are exactly the same for 3.1
=C2=A0
=
  2. What existing Client component is holding o= pen the Read Grant request?
    1. If your answer is =E2=80=9Can async process on the Client=E2=80= =99s server=E2=80=9D then please re-read the second word of that question.<= /li>
As I stated, = the only *potential* issue is with multi-step flows on mobile where the app= is shut down.


=C2=A0
  1. How long should the GS wait for the Client to make the Update Gra= nt request in 3.4? What should the GS do if that never happens? What is the= path forward for the end user, at that point?

=
3.1 has the GS waiting for the Client as well. All the same questions = apply to any aspect of the protocol where one party does not do the next st= ep. The User is the most likely party to not continue. What do the GS and C= lient do if the User has been sent to the GS, but walks away from their dev= ice?
=C2=A0

[/richanna]

=C2=A0

[pasting in from your later email]

While a single stage Grant request (3.1) in a mobile app that has been put = to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only ma= kes sense if the Client is checking a database along the way, I would=C2=A0= expect the Client to have a server side, and the server could take each step.

[/end paste]

=C2=A0

[richanna]

Having a remote database and having a remote server are not the same thing.= This adds a lot of complexity to serverless apps.

[/richanna]=E1=90=A7

=C2=A0

Which aspect adds comple= xity?

=C2=A0

The added complexity in = keeping an interaction is making an additional API call after the first API= call.

=C2=A0

[richanna]

The issue isn=E2=80=99t the API call itself, it=E2= =80=99s the need for the Client to maintain a persistent, asynchronous proc= ess to make that API call.


The 3.1 flow, and all the XYZ flows where there is no red= irect all have the same requirement of the Client.

An async call to a server is pretty straight forward in all modern web lan= guages.

If the Client is a mobile app put to sleep= , it can remake the call to the GS and get the results in a 3.1 flow.=C2=A0=
=C2=A0
<= div>

=C2=A0

It is incorrect to assume that every app with a data= base will necessarily have a server side. A serverless app that does a redi= rect to the GS, or that switches to an external browser (and thus may be pu= t to sleep) has no component that will reliably stay alive to hold open the Read Grant request, receive the = response, and follow up with an Update Grant request (i.e., flow 3.4). Addi= ng a server-side component to do this orchestration adds significant comple= xity.


3.4= is not a required flow for the Client, and is an edge case for sophisticat= ed Clients.
=C2=A0

[/richanna]

=C2=A0

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7
--0000000000006d0bc9059ecea963-- From nobody Mon Feb 17 18:54:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385B2120874 for ; Mon, 17 Feb 2020 16:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 fLI-wGTYqauj for ; Mon, 17 Feb 2020 16:32:18 -0800 (PST) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 AF052120866 for ; Mon, 17 Feb 2020 16:32:17 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id x7so20855481ljc.1 for ; Mon, 17 Feb 2020 16:32:17 -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=FUBgOGQous/rMtB3hSIko/yHke1jgVemQTrQyADDrMA=; b=K3RL0ExiApZ5NZDBm1LiyYDIolqi5AhSwBl1rSjX1KOvE+qriNdmDUyrOpGtq9qq2P Y6rBvDMfBoSYozK5Jqu2wfwxcqhcVUcNwXup7eq6nnQcUL/hPwt66akUdnKHzzia63cb ed0M096rLfmp1YlIASpF0O8UYzfXhlsYkR4c9UTrqJ4UjeZ5m9fZwCiDDCIyyIbHaFcw K14lH1plIaBYduqdaRhTURMt5lyOzbGB7pkByzG7ioNHxM5lZKwP1CG2q4k0bb3vtaAZ RlGGCpEplKdnQMuBiLiac4Cl9pbivdZ6u43sKfSwfOEo2LLUK17RIrsQdxSaqq08Z9Mq w1qg== 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=FUBgOGQous/rMtB3hSIko/yHke1jgVemQTrQyADDrMA=; b=gLKTe0X6vZFixF6GcrytFSo8mEPYlRyrC+fHNgbRhzfUAO5ITlMW6I5zGgeMoJC82c 4iGMPa4t/i1sfqKGQs2hl+M1YTk9707PaB67doMRJ/XQXprKNRvr71s536g/Jr9a7/rt rSWndled+93rmzsF4q0SvAjcgEysXB6R8m/jKs6Le3jdYS+AsPljbHV2NeBXv1ioGY86 8QZf+7fWTKr6eYboHvRc0uH7078evT18yyXXQnq0//U2IjbDAwuZtX5uGDhU88KYZGWA FBhlrYSF9mNMdkfxYaPKBW2zoXFJVXRmdZY3S4dIvW/7kOZa851qw+W1xCOxZPHMl3if S5Lw== X-Gm-Message-State: APjAAAV/qmmfAv2ivr+pMcUaPrQjcqCgV78wbm0W6QtGyCwO63WW6OM+ 0tXIOKuKG0KA6K2uVF4+HtFX4bnYuxhE1xmg2SYo4lq4 X-Google-Smtp-Source: APXvYqyjRd0RCRysJdHPh9sSuBFrAMGvnPrPJLZzmBAWXNaM5MBv/OKYbVRZIogRnAG6lRSarf/tpDIPtyDL94CqC68= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr11549971ljj.212.1581985935015; Mon, 17 Feb 2020 16:32:15 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> <35B0906C-9798-4436-8625-BA5397AFD35F@mit.edu> <69ED9ADA-BFAB-458D-AFA2-CCCEAFDCBC88@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 17 Feb 2020 16:31:48 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b2446a059ececd94" Archived-At: Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 00:32:24 -0000 --000000000000b2446a059ececd94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did not see the suggestion for the device to ask the GS to send the User to a new page on completion. Great idea. Will add it to the next draft. wrt. your example of a user that did not authorize all the requests. The Client won't know that until the User has completed the request, so the Client can't determine which page to send the User to until then. with the Client and GS having a dialog at the same time as the User and GS interact, the Client can provide the GS with a page appropriate for the user responses. The flow in 3.4 in XAuth. =E1=90=A7 On Mon, Feb 17, 2020 at 2:10 PM Richard Backman, Annabelle wrote: > XYZ seems to assume that a callback URL can be used to continue the > transaction at the RC (i.e., it=E2=80=99s like the redirect_uri in the OA= uth 2.0 > authorization code grant). Consider my example in reply to Dick, where a > smart device will poll for the response, but wants to direct the end user > to an introduction/tutorial page hosted on the manufacturer=E2=80=99s web= site. The > website has no knowledge of the XYZ transaction. I **think** XYZ supports > this, but it=E2=80=99s not obvious and I can imagine that AS support or p= rohibition > would more often stem from side effects of how the AS was written rather > than as an explicit feature decision. > > > > But it=E2=80=99s also worth considering cases where the transaction might= be > continued through the callback URL, but the response is still destined fo= r > the device. For example, suppose a Client uses the callback URL to presen= t > the end user with an opportunity to link to an existing account at the RC= . > If the end user has multiple accounts at the AS, then at this point they > might realize they signed into the wrong one, and want to switch. Ideally > the end user would not have to manually reboot the whole process from the > smart device, since they=E2=80=99re already sitting at a browser. Or cons= ider the > case where an end user authorizes some but not all of the access requeste= d > by the Client. The callback URL could land them on a page that explains t= he > benefit they would get from granting the rejected access. Ideally the end > user would be able to modify the grant through that browser session. A > similar interaction might happen far out of band from the original > authorization, for example if the end user chooses from within a manageme= nt > app for their smart device to enable a feature that requires additional > authorization. > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Justin Richer < > jricher@mit.edu> > *Date: *Monday, February 17, 2020 at 12:29 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02 > > > > Ah yes, looks like the website is out of date =E2=80=94 that note dates t= o a > previous iteration where we had an explicit =E2=80=9Ctype=E2=80=9D field = and we were > already seeing the limitations of that style. You=E2=80=99re right that t= he spec, > the actual text on the website=E2=80=99s examples, and our implementation= all allow > combining these two. In fact, there=E2=80=99s an example of it on that pa= ge! You > can absolutely poll and wait for a callback, both use a transaction > continuation request. I=E2=80=99ll clean that up, thanks! > > > > And in the XYZ model, =E2=80=9Csend the response to this URL=E2=80=9D wou= ld be a different > interaction type to be requested from the client if it=E2=80=99s got a di= fferent > set of considerations than the callback URL. However, I=E2=80=99m curious= what =E2=80=9Cthe > response=E2=80=9D would be in that case. Are we talking a front-channel r= esponse, > still, like the implicit flow? Or are we looking for a way to push > information back to the client in the back channel? If it=E2=80=99s the l= atter, > then that=E2=80=99s definitely a different interaction style. And one of = the good > things in XYZ is that getting info back to the client is now decoupled fr= om > how you get the user involved, so the user could enter a code or go to a > long (or short) arbitrary URL, and the client=E2=80=99s means of getting = to the > next step are the same menu of options regardless. > > > > =E2=80=94 Justin > > > > On Feb 17, 2020, at 1:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > XYZ is a lot closer to what I=E2=80=99m describing, but it still conflate= s > =E2=80=9Credirect to this URL after the workflow=E2=80=9D with =E2=80=9Cs= end the response to this > URL=E2=80=9D. I **think** the draft as written would allow a Client to pr= ovide a > callback but also poll for the response, but it=E2=80=99s not very clear.= This kind > of flow where the Client is actually split between device, backend, and > webapp within a single transaction is one that deserves more attention, > IMHO. > > > > This note on https://oauth.xyz/interaction/ also suggests XYZ is more > limited than it needs to be, but the draft seems to allow for this alread= y > so maybe this note is just be out of date? > > > > It would be interesting to figure out if we can combine both the user cod= e > and arbitrary redirect URL methods, giving the user a few options. This > should be as simple as allowing more flexibility on the interaction reque= st > portion and having the server return all possible options. > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Justin Richer > *Date: *Saturday, February 15, 2020 at 2:51 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *[UNVERIFIED SENDER] Re: [Txauth] XAuth -02 > > > > The interaction model that Annabelle describes below is exactly the kind > of thing that=E2=80=99s in XYZ: > > > > https://oauth.xyz/interaction/ > > > > An earlier implementation of XYZ had a =E2=80=9Ctype=E2=80=9D field like = XAuth does. You > can see that here: > > > > https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2= .4 > > > > We moved away from it for all of the reasons Annabelle is citing, along > with the others I=E2=80=99ve stated previously on the list that I don=E2= =80=99t feel bear > repeating again. Having implemented both patterns directly in the same > project, I can attest that the code paths are significantly simpler for > the current XYZ pattern, especially on the Authorization Server. You can > look at our code yourselves, if you like. > > > > And for the =E2=80=9Csimple=E2=80=9D client case that supports only one t= ype (which I > think we all believe will be the overwhelmingly common case), I want to > point out that the XYZ approach and the XAuth approach are for all intent= s > and purposes identical. The XYZ approach allows for a lot more flexibilit= y > along with a decrease in complexity. > > > > =E2=80=94 Justin > > > > > > > On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle < > richanna=3D40amazon.com@dmarc.ietf.org> wrote: > > > > [richanna] > > Replies inline. > > [/richanna] > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, February 14, 2020 at 9:10 AM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] XAuth -02 > > > > > > > > On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > [richanna] > > Replies inline > > [/richanna] > > > > [richanna] > > By user code-based interaction, I mean the kind described in the OAuth > 2.0 Device Authorization Grant , > where the user receives a code and short URL from the client, navigates t= o > that URL in a browser, and enters the code. While this could be packed in= to > interaction.message, this will lead to clunkier user experiences: > > 1. The GS may not be able to provide localized instructions that match > the locale on the Client. > > 2. Suppose the GS sends a message that reads: =E2=80=9CScan the QR code= or open > a browser to http://code.example/ and enter the code: 12345.=E2=80=9D > > a. That instruction does not make sense on a device that does not > present a QR code. Imagine hearing that from a smart speaker. > > b. That instruction is confusingly redundant if the Client displays the > QR code along with its own instructions, like: =E2=80=9CScan the QR code = or follow > the instructions below.=E2=80=9D > > 3. Will =E2=80=9Cembed the short URL and code in the message string=E2= =80=9D be MTI? If > not, text-only clients would have a broken experience. > > [/richanna] > > > > Sounds like a text only interaction type should be added per my note in > the draft. Perhaps even one that is focused on the code flow, where the > parameters are the code and the URI to enter the code, letting the Client > present the parameters with localized content? > > > > [richanna] > > I think we=E2=80=99re approaching the =E2=80=9Cinteraction=E2=80=9D conce= pt wrong. We=E2=80=99re > conflating three different things together: > > =C2=B7 What does the Client need to send the end user to the GS? > > o A human-friendly short URL and code. > > o Any kind of URL, as long and ugly as it needs to be. > > =C2=B7 How will the Client receive the response from the GS? > > o Client will make a request to the GS. > > o GS will make a request to the Client. (I=E2=80=99ve had to implement= this > for a custom integration, including it to demonstrate that other options > exist) > > =C2=B7 Will the GS return the end user to the Client, and if so h= ow? > > o Yes, by URL redirect. > > o No. > > > > Here is a very non-normative example request fragment, for a client that > wants both a short URL plus code and a full URL so they can > opportunistically use one or the other (AWS CLI v2 does this), will query > the GS for the response, and wants the GS to redirect to a publicly > accessible URL on the Client=E2=80=99s website after the flow (e.g., to s= how > further documentation/branded content to the end user): > > { > > "interact": { > > "code": { "max": 8 }, > > "url": true > > }, > > "response": { > > "poll": true > > }, > > "return": { > > "url": "https://help.smartdevice.example/post-setup" > > } > > } > > > > And here is an equally non-normative example response fragment: > > { > > "interact": { > > "code": "123456", > > "code_url": "https://gs.example/code", > > "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef" > > } > > } > > > > (Seriously do not read too much into these parameter names or syntax, thi= s > is just to give a rough sense of how I=E2=80=99m thinking about this. Any= one who > tries to pick apart this example will be responded to with mocking memes.= ) > > [/richanna] > > > > > > 2. Clients support multiple interaction modes and may not always know > what the GS supports (and vice-versa). For a multi-tenant GS, it may vary > by tenant configuration. Clients should be able to say what they can do, > and the GS should be able to tell them which one to use. It=E2=80=99s a v= ery simple > but powerful inline negotiation. > > > > That is what is in TxAuth. Would you elaborate on how the GS might be > constrained? Why would the GS not be able to do all? > > > > I would think all constraints would be at the Client. Am I missing > something? > > > > [richanna] > > Clients may support customer-defined GSes (e.g., enterprise IdPs), which > will vary in terms of which interaction modes they support. While the set > of interactions defined in XAuth might all be MTI for a GS, we should > assume that extensions will introduce new interactions which will not be > universally supported. An interaction mechanism might have properties tha= t > cause some administrators to want to disable it, or to restrict Clients t= o > always use it. Are you assuming that a Client will always make an OPTIONS > discovery request first? > > [/richanna] > > > > An example of why a given GS may not support a mode would be helpful. > > > > I was envisioning that if an optional to support interaction mode was not > supported at the GS, that it would return an error. The Client would then > try a different one. Alternatively, the Client could start with an OPTION= S > call in cases where the GS is dynamicly chosen. > > > > [richanna] > > Lots of ASes don=E2=80=99t support Device Authorization Grant. I think it= =E2=80=99s safe > to assume that interaction mode support will vary for XAuth as well. =E2= =80=9CKeep > trying until you find one that works=E2=80=9D sounds pretty painful for t= he client, > and doesn=E2=80=99t allow the client to use multiple interaction modes, a= s > demonstrated in my example above. > > > > There are lots of reasons for wanting to support multiple modes: > > =C2=B7 Some people are comfortable with QR codes, some aren=E2=80= =99t. > > =C2=B7 Some people have smart phones that can scan them, some don= =E2=80=99t. > > =C2=B7 People with smart phones may want to go through the > authentication flow on their desktop instead. > > =C2=B7 Some people may *have* to go through the authentication fl= ow on > their desktop, because the GS thinks iPhones only support Bluetooth-based > security keys and insists they cannot complete the login flow even though > they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT > PROTECTION PROGRAM) > > [/richanna] > > > > 3. I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D interac= tion mode. Clients can > use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking as s= omeone who has > done that, I really don=E2=80=99t recommend it. Popups are increasingly > unsupported, and prone to weird behavioral issues. In-app browsers in > Facebook, Twitter, etc. tend to have popups disabled. The last versions o= f > IE Mobile didn=E2=80=99t support them at all (the popped up page basicall= y just > loaded into the current window).. in > > > > Popups are really useful in single-page apps as you want to keep the > context and not reload the page. > > > > Agree that popups don't make sense in mobile. A full redirect does of > course. A single-page app on mobile would open a new tab which would be a > separate context rather than a redirect. > > > > [richanna] > > Popups are broken and/or disabled in enough instances that we should not > encourage their usage by including explicit support for them in the > protocol. Nor are they necessary for SPAs in order to restore the state o= f > their app after the redirect. > > > > Are they really that broken in desktop? I've used them extensively myself > in the past as it was a better user experience, but that was a few years > ago. > > > > [richanna] > > Popup blockers are built in and aggressively enabled by default on all > major browsers. Communicating securely between windows is not easy, and > from past experience prone to failure thanks to weird browser bugs. Trust= ed > Site settings in IE and Edge can blow the whole thing up in weird ways > (speaking again from experience). > > > > Also, it=E2=80=99s 2020. Stop branching on mobile vs. desktop. I get that= lots of > people still do that, but that doesn=E2=80=99t mean the protocol should c= ater to it. > > [/richanna] > > And again, a Client that really wants to give themselves a headache with > popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They= just have to > provide a landing page for the GS to redirect back to that parses the > response, passes it back to the main window, and closes itself. I don=E2= =80=99t see > why the protocol would need to explicitly describe this mechanism. > > [/richanna] > > > > I think it is a useful signal for the GS in the experience it wants to > show the user. > > > > [richanna] > > Useful how? The window dimensions are a better signal for how to present > the user experience. (*cough* responsive design *cough*) > > [/richanna] > > > > Section 12.6: > > [Editor: is there some other reason to have the UserInfo > > endpoint?] > > > > I may want to host my UserInfo endpoint on a separate microservice from m= y > token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my > user profile/directory stack, while the latter is part of the highly > privileged authentication/authorization stack. > > > > > > The token endpoint has the access token anyway, so it can fetch the data > from the other endpoint itself if it wanted to. IE, there is no separatio= n > of duties. > > > > What are the advantages of the UserInfo endpoint to the User or Client? > > > > The UserInfo endpoint seems to just add more complexity, with no ability > to start a User interaction if additional consent is needed. > > > > [richanna] > > If the access token is sender-constrained, then no, the token endpoint > can=E2=80=99t fetch the data itself. But even without the security angle,= there is > value in separating out the functionality as it allows the GS to distribu= te > it across systems with different owners. E.g., there might be a directory > API team that also owns the SCIM interface and UserInfo endpoint. > > > > An implementation can also route calls to different internal systems whil= e > keeping the same endpoint. > > > > I also think of SCiM and UserInfo as very different endpoints. I would > consider SCIM a resource, and UserInfo claims. I appreciate those are > similar in enterprise, but they are not in consumer contexts. > > > > [richanna] > > Routing calls to different internal systems still means I have to have > some shared infrastructure that both teams manage. It=E2=80=99s more comp= lex than > it needs to be. > > > > I=E2=80=99m going to suggest we move this part of the discussion to a sep= arate > thread because it=E2=80=99s too messy to keep in this awful back-and-fort= h. I=E2=80=99ll > just add here that I=E2=80=99m not suggesting we *only* have a UserInfo e= ndpoint. > I=E2=80=99m arguing two things: > > 1. The UserInfo endpoint is good, actually. It doesn=E2=80=99t need= to be > MTI, but we should not preclude its existence. > > 2. If we provide a mechanism for requesting and receiving claims in > the GS Read Grant response, that mechanism should apply generically to > arbitrary resources. GSes can support it or not, for any given resource. > > [/richanna] > > > > > > [richanna] > > There are two big differences between those examples (e.g., QR Code, > app-based login approvals) and this mechanism in XAuth: > > 1. In your examples of this behavior today, the reason for the wait is > clear and obvious, and driven by the user. E.g., my printer is waiting fo= r > me to go enter this code and log in; Google sign in is waiting for me to > tap this button on my phone. That is not the case in the XAuth protocol. > The user is left sitting on a loading screen waiting for a > behind-the-scenes interaction between client and GS that may not even > happen. > > 2. Unlike with code/QR flows or sign-in verification, there is no > active process on the client side to keep this async request open. A web > app client would have to introduce a server-side async process to manage > this aspect of the protocol. That=E2=80=99s not easy. > > 3. The failure modes show up in more appropriate contexts, where there > are clear paths forward for the end user. In code/QR-based flows, it=E2= =80=99s > detected on the client side, in the form of an AS that never provides a > response. In that scenario, the client can retry the process. In sign-in > verification, the problem occurs between two parts of the AS, and the AS > can allow the end user to retry or to use a different authentication > method. In the XAuth Create+Update scenario, the failure is detected on t= he > GS, and there is no clear path forward. If the Client never calls Update > Grant to flip interaction.keep to false, what should the GS do? How long > should it wait? Should it issue the authorization anyway, assuming the > Client will come back and ask for it at some point? Should it redirect th= e > end user back to the Client anyway, or drop them on a landing page? Shoul= d > it flag this as an error, or is this the expected behavior for the Client= ? > > > > I really think this is overcomplicating the protocol to an extent that no > one will actually implement it. > > [/richanna] > > > > The flow in > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 is > EXACTLY the same as the Google and Microsoft flows. > > > > While the flow in > https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 has > additional steps, it is not fundamentally any different except the Client > is making another call to the GS after the first one returns. The risk of > the Client not making the second call and leaving the User hanging is not > really any different of the Client not making the first call. > > > > Besides the situation where the mobile device that MAY not be able to mak= e > the second call might put to sleep, I don't see any implementation issues= . > TxAuth works the same way as 3.1 as I understand it for non-redirect flow= s. > > > > [richanna] > > I don=E2=80=99t think you actually read what I wrote. If the flows are ex= actly the > same, tell me: > > 1. What does the user think is going on while they=E2=80=99re sitti= ng on > the GS, watching a spinner as the GS waits for the Client to make an Upda= te > Grant request in 3.4? > > 2. What existing Client component is holding open the Read Grant > request? > > a. If your answer is =E2=80=9Can async process on the Client=E2=80= =99s server=E2=80=9D then > please re-read the second word of that question. > > 3. How long should the GS wait for the Client to make the Update > Grant request in 3.4? What should the GS do if that never happens? What i= s > the path forward for the end user, at that point? > > [/richanna] > > > > [pasting in from your later email] > > While a single stage Grant request (3.1) in a mobile app that has been pu= t > to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only > makes sense if the Client is checking a database along the way, I > would expect the Client to have a server side, and the server could take > each step. > > [/end paste] > > > > [richanna] > > Having a remote database and having a remote server are not the same > thing. This adds a lot of complexity to serverless apps. > > [/richanna]=E1=90=A7 > > > > Which aspect adds complexity? > > > > The added complexity in keeping an interaction is making an additional AP= I > call after the first API call. > > > > [richanna] > > The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for th= e Client to > maintain a persistent, asynchronous process to make that API call. > > > > It is incorrect to assume that every app with a database will necessarily > have a server side. A serverless app that does a redirect to the GS, or > that switches to an external browser (and thus may be put to sleep) has n= o > component that will reliably stay alive to hold open the Read Grant > request, receive the response, and follow up with an Update Grant request > (i.e., flow 3.4). Adding a server-side component to do this orchestration > adds significant complexity. > > [/richanna] > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b2446a059ececd94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I did not see the suggestion for the device to ask the GS = to send the User to a new page on completion. Great idea. Will add it to th= e next draft.

wrt. your example of a user that did not a= uthorize all the requests. The Client won't know that until the User ha= s completed the request, so the Client can't determine which page to se= nd the User to until then.

with the Client and GS = having a dialog at the same time as the User and GS interact, the Client ca= n provide the GS with a page appropriate for the user responses. The flow i= n 3.4 in XAuth.

3D""=E1=90=A7
On Mon, = Feb 17, 2020 at 2:10 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

XYZ seems to assume that a callback URL can be used = to continue the transaction at the RC (i.e., it=E2=80=99s like the redirect= _uri in the OAuth 2.0 authorization code grant). Consider my example in rep= ly to Dick, where a smart device will poll for the response, but wants to direct the end user to an introduction/tuto= rial page hosted on the manufacturer=E2=80=99s website. The website has no = knowledge of the XYZ transaction. I *think* XYZ supports this, but i= t=E2=80=99s not obvious and I can imagine that AS support or prohibition would more often stem from side effects of how the = AS was written rather than as an explicit feature decision.

=C2=A0

But it=E2=80=99s also worth considering cases where = the transaction might be continued through the callback URL, but the respon= se is still destined for the device. For example, suppose a Client uses the= callback URL to present the end user with an opportunity to link to an existing account at the RC. If the end user h= as multiple accounts at the AS, then at this point they might realize they = signed into the wrong one, and want to switch. Ideally the end user would n= ot have to manually reboot the whole process from the smart device, since they=E2=80=99re already sitting at a = browser. Or consider the case where an end user authorizes some but not all= of the access requested by the Client. The callback URL could land them on= a page that explains the benefit they would get from granting the rejected access. Ideally the end user would be able = to modify the grant through that browser session. A similar interaction mig= ht happen far out of band from the original authorization, for example if t= he end user chooses from within a management app for their smart device to enable a feature that requires = additional authorization.

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Justin Richer <jricher@mit.edu>
Date: Monday, February 17, 2020 at 12:29 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02

=C2=A0

Ah yes, looks like the w= ebsite is out of date =E2=80=94 that note dates to a previous iteration whe= re we had an explicit =E2=80=9Ctype=E2=80=9D field and we were already seei= ng the limitations of that style. You=E2=80=99re right that the spec, the actual text on the website=E2=80=99s examples, and our implementation = all allow combining these two. In fact, there=E2=80=99s an example of it on= that page! You can absolutely poll and wait for a callback, both use a tra= nsaction continuation request. I=E2=80=99ll clean that up, thanks!=C2=A0

=C2=A0

And in the XYZ model, = =E2=80=9Csend the response to this URL=E2=80=9D would be a different intera= ction type to be requested from the client if it=E2=80=99s got a different = set of considerations than the callback URL. However, I=E2=80=99m curious what =E2=80=9Cthe response=E2=80=9D would be in that case. Are we talking = a front-channel response, still, like the implicit flow? Or are we looking = for a way to push information back to the client in the back channel? If it= =E2=80=99s the latter, then that=E2=80=99s definitely a different interaction style. And one of the good things in XYZ is that getting info = back to the client is now decoupled from how you get the user involved, so = the user could enter a code or go to a long (or short) arbitrary URL, and t= he client=E2=80=99s means of getting to the next step are the same menu of options regardless.=C2=A0=

=C2=A0

=C2=A0=E2=80=94 Justin



On Feb 17, 2020, at 1:54= PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

=C2=A0

XYZ is a lot closer to w= hat I=E2=80=99m describing, but it still conflates =E2=80=9Credirect to thi= s URL after the workflow=E2=80=9D with =E2=80=9Csend the response to this U= RL=E2=80=9D. I *think* the draft as written would allow a Client to = provide a callback but also poll for the response, but it=E2=80=99s not very clear= . This kind of flow where the Client is actually split between device, back= end, and webapp within a single transaction is one that deserves more atten= tion, IMHO.

=C2=A0

This note on=C2=A0https://oauth.xyz/int= eraction/=C2=A0also suggests XYZ is more limited than it needs to be, but the draft seems to allow for this already so maybe thi= s note is just be out of date?

=C2=A0

It would be interesting = to figure out if we can combine both the user code and arbitrary redirect U= RL methods, giving the user a few options. This should be as simple as allo= wing more flexibility on the interaction request portion and having the server return all possible options.<= u>

=C2=A0

=E2=80=93

Annabelle Backman (she/her)

AWS Identity

=C2=A0

=C2=A0

=C2=A0

The interaction model th= at Annabelle describes below is exactly the kind of thing that=E2=80=99s in= XYZ:

=C2=A0

=C2=A0

An earlier implementatio= n of XYZ had a =E2=80=9Ctype=E2=80=9D field like XAuth does. You can see th= at here:

=C2=A0

=C2=A0

We moved away from it fo= r all of the reasons Annabelle is citing, along with the others I=E2=80=99v= e stated previously on the list that I don=E2=80=99t feel bear repeating ag= ain. Having implemented both patterns directly in the same project, I can attest that the code paths are significantly simpler = =C2=A0for the current XYZ pattern, especially on the Authorization Server. = You can look at our code yourselves, if you like.

=C2=A0

And for the =E2=80=9Csim= ple=E2=80=9D client case that supports only one type (which I think we all = believe will be the overwhelmingly common case), I want to point out that t= he XYZ approach and the XAuth approach are for all intents and purposes identical. The XYZ approach allows for a lot more flexibility= along with a decrease in complexity.=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0




On Feb 14, 2020, at 9:29= PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org= > wrote:

=C2=A0

[richanna]=

Replies inline.

[/richanna]

=C2=A0

=E2=80=93

Annabelle Backman (she/her)

AWS Identity

=C2=A0

=C2=A0

From:=C2=A0Txauth <txauth-bounces@ie= tf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:= =C2=A0Friday, February 14, 2020 at 9:10 AM
To:=C2= =A0"Richard Backman, Annabelle" <richanna=3D40amaz= on.com@dmarc.ietf.org>
Cc:=C2= =A0"tx= auth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re: [Txauth] XAuth -02

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 13, 2020 at = 6:08 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

[richanna]=

Replies inline=

[/richanna]=C2=A0=

<snip>

[richanna]=

By user code-based inter= action, I mean the kind described in the=C2=A0OAuth 2.0 Device Authorization Grant, where the user receives a code and short URL from the client, navigates to= that URL in a browser, and enters the code. While this could be packed int= o interaction.message, this will lead to clunkier user experiences:<= u>

1.=C2=A0=C2=A0=C2=A0The GS may not be able to provide localized instr= uctions that match the locale on the Client.

2.=C2=A0=C2=A0=C2=A0Suppose the GS sends a message that reads: =E2=80= =9CScan the QR code or open a browser to=C2=A0http://code.example/=C2=A0and enter the code: 12345.=E2=80=9D

a.=C2=A0=C2=A0=C2=A0=C2=A0That instruction does not make sense on a d= evice that does not present a QR code. Imagine hearing that from a smart sp= eaker.

b.=C2=A0=C2=A0=C2=A0That instruction is confusingly redundant if the = Client displays the QR code along with its own instructions, like: =E2=80= =9CScan the QR code or follow the instructions below.=E2=80=9D

3.=C2=A0=C2=A0=C2=A0Will =E2=80=9Cembed the short URL and code in the= message string=E2=80=9D be MTI? If not, text-only clients would have a bro= ken experience.

[/richanna]

=C2=A0

Sounds like a text only = interaction type should be added per my note in the draft. Perhaps even one= that is focused on the code flow, where the parameters are the code and th= e URI to enter the code, letting the Client present the parameters with localized content?

=C2=A0

[richanna]=

I think we=E2=80=99re ap= proaching the =E2=80=9Cinteraction=E2=80=9D concept wrong. We=E2=80=99re co= nflating three different things together:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0What does the Client need= to send the end user to the GS?

o= =C2=A0=C2=A0=C2=A0=C2=A0A human-friendly short URL and code.

o= =C2=A0=C2=A0=C2=A0=C2=A0Any kind of URL, as long and ugly as it needs= to be.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0How will the Client recei= ve the response from the GS?

o= =C2=A0=C2=A0=C2=A0=C2=A0Client will make a request to the GS.<= u>

o= =C2=A0=C2=A0=C2=A0=C2=A0GS will make a request to the Client. (I=E2= =80=99ve had to implement this for a custom integration, including it to demonstrate that other options exist)<= u>

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Will the GS return the en= d user to the Client, and if so how?

o= =C2=A0=C2=A0=C2=A0=C2=A0Yes, by URL redirect.

o= =C2=A0=C2=A0=C2=A0=C2=A0No.

=C2=A0

Here is a very non-norma= tive example request fragment, for a client that wants both a short URL plu= s code and a full URL so they can opportunistically use one or the other (A= WS CLI v2 does this), will query the GS for the response, and wants the GS to redirect to a publicly accessible= URL on the Client=E2=80=99s website after the flow (e.g., to show further = documentation/branded content to the end user):

{

"interact": {=

=C2=A0 "code": { "max": = 8 },

=C2=A0 "url": true

},

"response": {=

=C2=A0 "poll": true<= u>

},

"return": {

}

}

=C2=A0

And here is an equally n= on-normative example response fragment:

{

"interact": {=

=C2=A0 "code": "123456",=

=C2=A0 "code_url": "https://gs.example/code&= quot;,

}

}

=C2=A0

(Seriously do not read t= oo much into these parameter names or syntax, this is just to give a rough = sense of how I=E2=80=99m thinking about this. Anyone who tries to pick apar= t this example will be responded to with mocking memes.)

[/richanna]

=C2=A0

=C2=A0

2.=C2=A0=C2=A0=C2=A0Clients support multiple interaction modes and may not always know what t= he GS supports (and vice-versa). For a multi-tenant GS, it may vary by tenant configuration. C= lients should be able to say what they can do, and the GS should be able to= tell them which one to use. It=E2=80=99s a very simple but powerful inline= negotiation.

=C2=A0

That is what is in TxAut= h. Would you elaborate on how the GS might be constrained? Why would the GS= not be able to do all?

=C2=A0

I would think all constr= aints would be at the Client. Am I missing something?

=C2=A0

[richanna]=

Clients may support cust= omer-defined GSes (e.g., enterprise IdPs), which will vary in terms of whic= h interaction modes they support. While the set of interactions defined in = XAuth might all be MTI for a GS, we should assume that extensions will introduce new interactions which will not be u= niversally supported. An interaction mechanism might have properties that c= ause some administrators to want to disable it, or to restrict Clients to a= lways use it. Are you assuming that a Client will always make an OPTIONS discovery request first?

[/richanna]=C2=A0=

=C2=A0

An example of why a give= n GS may not support a mode would be helpful.

=C2=A0

I was envisioning that i= f an optional to support interaction mode was not supported at the GS, that= it would return an error. The Client would then try a different one. Alter= natively, the Client could start with an OPTIONS call in cases where the GS is dynamicly chosen.

=C2=A0

[richanna]=

Lots of ASes don=E2=80= =99t support Device Authorization Grant. I think it=E2=80=99s safe to assum= e that interaction mode support will vary for XAuth as well. =E2=80=9CKeep = trying until you find one that works=E2=80=9D sounds pretty painful for the client, and doesn=E2=80=99t allow the client to use multiple interacti= on modes, as demonstrated in my example above.

=C2=A0

There are lots of reason= s for wanting to support multiple modes:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Some people are comfortab= le with QR codes, some aren=E2=80=99t.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Some people have smart ph= ones that can scan them, some don=E2=80=99t.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0People with smart phones = may want to go through the authentication flow on their desktop instead.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Some people may=C2=A0hav= e=C2= =A0to go through the authentication flow on their desktop, because the GS thinks= iPhones only support Bluetooth-based security keys and insists they cannot= complete the login flow even though they have two YubiKey 5Ci keys on thei= r account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)

[/richanna]

=C2=A0

3.=C2=A0=C2=A0=C2=A0I don=E2=80=99t see the value of the =E2=80=9Cpopup=E2=80=9D interaction = mode. Clients can use =E2=80=9Credirect=E2=80=9D mode within popups. However, speaking as someone who has done that, I really don=E2=80= =99t recommend it. Popups are increasingly unsupported, and prone to weird = behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have = popups disabled. The last versions of IE Mobile didn=E2=80=99t support them at all (the popped up page basically ju= st loaded into the current window).. in=C2=A0

=C2=A0

Popups are really useful= in single-page apps as you want to keep the context and not reload the pag= e.

=C2=A0

Agree that popups don= 9;t make sense in mobile. A full redirect does of course. A single-page app= on mobile would open a new tab which would be a separate context rather th= an a redirect.

=C2=A0

[richanna]=

Popups are broken and/or= disabled in enough instances that we should not encourage their usage by i= ncluding explicit support for them in the protocol. Nor are they necessary = for SPAs in order to restore the state of their app after the redirect.

=C2=A0

Are they really that bro= ken in desktop? I've used them extensively myself in the past as it was= a better user experience, but that was a few years ago.

=C2=A0

[richanna]=

Popup blockers are built= in and aggressively enabled by default on all major browsers. Communicatin= g securely between windows is not easy, and from past experience prone to f= ailure thanks to weird browser bugs. Trusted Site settings in IE and Edge can blow the whole thing up in weird = ways (speaking again from experience).

=C2=A0

Also, it=E2=80=99s 2020.= Stop branching on mobile vs. desktop. I get that lots of people still do t= hat, but that doesn=E2=80=99t mean the protocol should cater to it.<= u>

[/richanna]

And again, a Client that= really wants to give themselves a headache with popups can do that themsel= ves using =E2=80=9Credirect=E2=80=9D mode. They just have to provide a land= ing page for the GS to redirect back to that parses the response, passes it back to the main window, and closes itself. I don=E2= =80=99t see why the protocol would need to explicitly describe this mechani= sm.=C2=A0

[/richanna]

=C2=A0

I think it is a useful s= ignal for the GS in the experience it wants to show the user.=

=C2=A0

[richanna]=

Useful how? The window d= imensions are a better signal for how to present the user experience. (*cou= gh* responsive design *cough*)

[/richanna]

=C2=A0

Section 12.6:<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[=
Editor: is there some other reason to have the UserInfo
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e=
ndpoint?]

=C2=A0

I may want to host my Us= erInfo endpoint on a separate microservice from my token endpoint (in OAuth= 2.0/OIDC terms). The former might be part of my user profile/directory sta= ck, while the latter is part of the highly privileged authentication/authorization stack.

=C2=A0

=C2=A0

The token endpoint has t= he access token anyway, so it can fetch the data from the other endpoint it= self if it wanted to. IE, there is no separation of duties.

=C2=A0

What are the advantages = of the UserInfo endpoint to the User or Client?=C2=A0

=C2=A0

The UserInfo endpoint se= ems to just add more complexity, with no ability to start a User interactio= n if additional consent is needed.

=C2=A0

[richanna]=

If the access token is s= ender-constrained, then no, the token endpoint can=E2=80=99t fetch the data= itself. But even without the security angle, there is value in separating = out the functionality as it allows the GS to distribute it across systems with different owners. E.g., there might be a= directory API team that also owns the SCIM interface and UserInfo endpoint= .

=C2=A0

An implementation can al= so route calls to different internal systems while keeping the same endpoin= t.

=C2=A0

I also think of SCiM and= UserInfo as very different endpoints. I would consider SCIM a resource, an= d UserInfo claims. I appreciate those are similar in enterprise, but they a= re not in consumer contexts.

=C2=A0

[richanna]=

Routing calls to differe= nt internal systems still means I have to have some shared infrastructure t= hat both teams manage. It=E2=80=99s more complex than it needs to be.

=C2=A0

I=E2=80=99m going to sug= gest we move this part of the discussion to a separate thread because it=E2= =80=99s too messy to keep in this awful back-and-forth. I=E2=80=99ll just a= dd here that I=E2=80=99m not suggesting we=C2=A0only=C2=A0have a UserInfo endpoint. I=E2=80=99m arguing two things:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The UserInfo endpoint is = good, actually. It doesn=E2=80=99t need to be MTI, but we should not preclu= de its existence.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0If we provide a mechanism= for requesting and receiving claims in the GS Read Grant response, that me= chanism should apply generically to arbitrary resources. GSes can support it or not, for any given resource= .

[/richanna]

=C2=A0

<snip>

[richanna]=

There are two big differ= ences between those examples (e.g., QR Code, app-based login approvals) and= this mechanism in XAuth:

1.=C2=A0=C2=A0=C2=A0In your examples of this behavior today, the reas= on for the wait is clear and obvious, and driven by the user. E.g., my prin= ter is waiting for me to go enter this code and log in; Google sign in is waiting for me = to tap this button on my phone. That is not the case in the XAuth protocol.= The user is left sitting on a loading screen waiting for a behind-the-scen= es interaction between client and GS that may not even happen.

2.=C2=A0=C2=A0=C2=A0Unlike with code/QR flows or sign-in verification= , there is no active process on the client side to keep this async request = open. A web app client would have to introduce a server-side async process to manage t= his aspect of the protocol. That=E2=80=99s not easy.

3.=C2=A0=C2=A0=C2=A0The failure modes show up in more appropriate con= texts, where there are clear paths forward for the end user. In code/QR-bas= ed flows, it=E2=80=99s detected on the client side, in the form of an AS that never provides a re= sponse. In that scenario, the client can retry the process. In sign-in veri= fication, the problem occurs between two parts of the AS, and the AS can al= low the end user to retry or to use a different authentication method. In the XAuth Create+Update scenario= , the failure is detected on the GS, and there is no clear path forward. If= the Client never calls Update Grant to flip interaction.keep to false, wha= t should the GS do? How long should it wait? Should it issue the authorization anyway, assuming the Client wil= l come back and ask for it at some point? Should it redirect the end user b= ack to the Client anyway, or drop them on a landing page? Should it flag th= is as an error, or is this the expected behavior for the Client?

=C2=A0

I really think this is o= vercomplicating the protocol to an extent that no one will actually impleme= nt it.

[/richanna]

=C2=A0

The flow in=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-02= #section-3.1=C2=A0is EXACTLY the same as the Google and Microsoft flows.=C2=A0

=C2=A0

While the flow in=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section= -3.4" target=3D"_blank">https://tools.ietf.org/html/draft-hardt-xauth-proto= col-02#section-3.4=C2=A0has additional steps, it is not fundamentally any different except the Client is making another call to the GS after the= first one returns. The risk of the Client not making the second call and l= eaving the User hanging is not really any different of the Client not makin= g the first call.

=C2=A0

Besides the situation wh= ere the mobile device that MAY not be able to make the second call might pu= t to sleep, I don't see any implementation issues. TxAuth works the sam= e way as 3.1 as I understand it for non-redirect flows.

=C2=A0

[richanna]=

I don=E2=80=99t think yo= u actually read what I wrote. If the flows are exactly the same, tell me:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0What does the user think = is going on while they=E2=80=99re sitting on the GS, watching a spinner as = the GS waits for the Client to make an Update Grant request in 3.4?

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0What existing Client comp= onent is holding open the Read Grant request?

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0If your answer is =E2=80= =9Can async process on the Client=E2=80=99s server=E2=80=9D then please re-= read the second word of that question.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0How long should the GS wa= it for the Client to make the Update Grant request in 3.4? What should the = GS do if that never happens? What is the path forward for the end user, at that point?

[/richanna]

=C2=A0

[pasting in from your la= ter email]

While a single stage Gra= nt request (3.1) in a mobile app that has been put to sleep will recover fi= ne, a multi-step (3.4) will fail. Since 3.4 only makes sense if the Client = is checking a database along the way, I would=C2=A0expect the Client to have a server side, and the server could= take each step.

[/end paste]

=C2=A0

[richanna]=

Having a remote database= and having a remote server are not the same thing. This adds a lot of comp= lexity to serverless apps.

[/richanna]=E1=90=A7

=C2=A0

Which aspect adds comple= xity?

=C2=A0

The added complexity in = keeping an interaction is making an additional API call after the first API= call.

=C2=A0

[richanna]=

The issue isn=E2=80=99t = the API call itself, it=E2=80=99s the need for the Client to maintain a per= sistent, asynchronous process to make that API call.

=C2=A0

It is incorrect to assum= e that every app with a database will necessarily have a server side. A ser= verless app that does a redirect to the GS, or that switches to an external= browser (and thus may be put to sleep) has no component that will reliably stay alive to hold open the Read Grant= request, receive the response, and follow up with an Update Grant request = (i.e., flow 3.4). Adding a server-side component to do this orchestration a= dds significant complexity.

[/richanna]

=C2=A0

=C2=A0

=C2=A0

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000b2446a059ececd94-- From nobody Mon Feb 17 18:55:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29A712006F for ; Mon, 17 Feb 2020 18:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.496 X-Spam-Level: X-Spam-Status: No, score=-14.496 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 nQlTnRlntDHE for ; Mon, 17 Feb 2020 18:26:15 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (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 B97B6120033 for ; Mon, 17 Feb 2020 18:26: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=1581992775; x=1613528775; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MtkRY21mFCGV3UrXf6ColUD3p5Q+a/SjAj418kfwIYc=; b=iId7BfWfQeXhCMN1foj4CrQtz2mX/KJAUhMrD0EVo7VnosOrgnWvtod9 jGMnG+5hoeAwNAHjJ1o7wXUHjHTychjJfm9cAijkG1oG3LGdW+DsrJWT3 AHDc7HZ4rK/eBkgcnm04hrnotx3HwZbb4ZHzuhEWcahYa4+tWe3ByQWdJ o=; IronPort-SDR: nzNRrPfZk4Ll+kVVhgpGacho1Iq+9hUYoyfdE9n8ZVoFMYkN+9pwiwbrmbU+d5QTOtI7yJJLyM 3vZHgJcgaWIw== X-IronPort-AV: E=Sophos; i="5.70,454,1574121600"; d="scan'208,217"; a="17606631" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-c7c08562.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 18 Feb 2020 02:26:03 +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-c7c08562.us-east-1.amazon.com (Postfix) with ESMTPS id 281D2241F15 for ; Tue, 18 Feb 2020 02:26:01 +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; Tue, 18 Feb 2020 02:26:01 +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; Tue, 18 Feb 2020 02:26:00 +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, 18 Feb 2020 02:26:00 +0000 From: "Richard Backman, Annabelle" To: "txauth@ietf.org" Thread-Topic: [Txauth] XAuth -02 Thread-Index: AQHV3jRcCsQaXzP9e0Gex6TsPtSqQKgUiKoAgAPnIYCAAQUDgIABgbqAgAAWcoCABRljgP//nKIA Date: Tue, 18 Feb 2020 02:26:00 +0000 Message-ID: References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@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.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.54] Content-Type: multipart/alternative; boundary="_000_CE1AA4C2619D4CE9808FB2E03227EEAFamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 02:26:20 -0000 --_000_CE1AA4C2619D4CE9808FB2E03227EEAFamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQrigJMNCkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczov L2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lw0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNv bT4NCkRhdGU6IE1vbmRheSwgRmVicnVhcnkgMTcsIDIwMjAgYXQgNDoyMiBQTQ0KVG86ICJSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRm Lm9yZz4NCkNjOiAidHhhdXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtUeGF1dGhdIFhBdXRoIC0wMg0KDQoNCg0KT24gRnJpLCBGZWIgMTQsIDIwMjAgYXQgNjoy OSBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmE9NDBhbWF6b24uY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToN Cg0KPHNuaXA+DQpUaGVyZSBhcmUgbG90cyBvZiByZWFzb25zIGZvciB3YW50aW5nIHRvIHN1cHBv cnQgbXVsdGlwbGUgbW9kZXM6DQoNCsK3ICAgICAgU29tZSBwZW9wbGUgYXJlIGNvbWZvcnRhYmxl IHdpdGggUVIgY29kZXMsIHNvbWUgYXJlbuKAmXQuDQoNCsK3ICAgICAgU29tZSBwZW9wbGUgaGF2 ZSBzbWFydCBwaG9uZXMgdGhhdCBjYW4gc2NhbiB0aGVtLCBzb21lIGRvbuKAmXQuDQoNCsK3ICAg ICAgUGVvcGxlIHdpdGggc21hcnQgcGhvbmVzIG1heSB3YW50IHRvIGdvIHRocm91Z2ggdGhlIGF1 dGhlbnRpY2F0aW9uIGZsb3cgb24gdGhlaXIgZGVza3RvcCBpbnN0ZWFkLg0KDQrCtyAgICAgIFNv bWUgcGVvcGxlIG1heSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIGZsb3cg b24gdGhlaXIgZGVza3RvcCwgYmVjYXVzZSB0aGUgR1MgdGhpbmtzIGlQaG9uZXMgb25seSBzdXBw b3J0IEJsdWV0b290aC1iYXNlZCBzZWN1cml0eSBrZXlzIGFuZCBpbnNpc3RzIHRoZXkgY2Fubm90 IGNvbXBsZXRlIHRoZSBsb2dpbiBmbG93IGV2ZW4gdGhvdWdoIHRoZXkgaGF2ZSB0d28gWXViaUtl eSA1Q2kga2V5cyBvbiB0aGVpciBhY2NvdW50LiAoSEksIEdPT0dMRSBBQ0NPVU5UIFBST1RFQ1RJ T04gUFJPR1JBTSkNCkFsbCBvZiB5b3VyIGV4YW1wbGVzIGFyZSBjaG9pY2VzIGZvciB0aGUgVXNl ciwgd2hpY2ggdGhlIENsaWVudCB3b3VsZCBuZWVkIHRvIHByZXNlbnQgdG8gdGhlIFVzZXIuDQoN ClBlciBteSBjb21tZW50IGFib3ZlIGJhc2VkIG9uIHlvdXIgc3VnZ2VzdGlvbiwgInFyY29kZSIg YWxzbyBzaG93cyB0aGUgImNvZGUiIGluZm9ybWF0aW9uLCB3aGljaCBzYXRpc2ZpZXMgYWxsIHlv dXIgc3VnZ2VzdGlvbnMgYWJvdmUuDQoNCltyaWNoYW5uYV0NClllcywgSSBhbSBqdXN0aWZ5aW5n IHRoZSB2YWx1ZSBvZiBhbGxvd2luZyBDbGllbnRzIHRvIHJlcXVlc3QgYW5kIHByZXNlbnQgbXVs dGlwbGUgaW50ZXJhY3Rpb24gbWV0aG9kcyBieSBwcm92aWRpbmcgdGhlc2UgYXJlIHNvbWUgZXhh bXBsZXMgb2YgY2FzZXMgd2hlcmUgaXQgcHJvdmlkZXMgY2xlYXIgYmVuZWZpdCB0byB0aGUgZW5k IHVzZXIuIFlvdSBjYW4gc2VlIHRoaXMgaW1wbGVtZW50ZWQgaW4gdGhlIEFXUyBDTEkgdjLigJlz IHN1cHBvcnQgZm9yIEFXUyBTU08uIEFuZCDigJxTY2FuIHRoaXMgPFFSIGNvZGU+IG9yIDxhbHRl cm5hdGUgaW5zdHJ1Y3Rpb25zPuKAnSBpcyBhIHByZXR0eSBjb21tb24gcGF0dGVybiBmb3IgYW55 dGhpbmcgaW52b2x2aW5nIFFSIGNvZGVzLiBXaGVyZSBkaWQgeW91IHN1Z2dlc3QgdGhhdCB0aGUg 4oCccXJjb2Rl4oCdIGludGVyYWN0aW9uIG9iamVjdCB3b3VsZCBpbmNsdWRlIHRoZSBjb2RlIGlu Zm9ybWF0aW9uPyBBcmUgeW91IHJlZmVycmluZyB0byB5b3VyIGNvbW1lbnQgcHJvcG9zaW5nIGEg 4oCcdGV4dCBvbmx5IGludGVyYWN0aW9uIHR5cGXigJ0/IFRoYXQgY29tbWVudCBzb3VuZGVkIGxp a2UgYW4gZWl0aGVyL29yIHRvIG1lLCBhcyBpbiB0aGUgQ2xpZW50IGNvdWxkIG9wdCBmb3IgdGhl IHRleHQtb25seSBpbnRlcmFjdGlvbiB0aGF0IHByb3ZpZGVzIHRoZW0gdGhlIGNvZGUgb3IgdGhl IHFyY29kZSBpbnRlcmFjdGlvbiB0aGF0IHByb3ZpZGVzIHRoZW0gYSBzaG9ydCBVUkwsIG5vdCBi b3RoLg0KWy9yaWNoYW5uYV0NCg0KPHNuaXA+DQoNCkkgY2hlY2tlZCB3aGF0IHBvcHVsYXIgc2l0 ZXMgbGlzdGVkIGF0IGh0dHBzOi8vYWhyZWZzLmNvbS9ibG9nL21vc3QtdmlzaXRlZC13ZWJzaXRl cy8gdXNlOg0KDQotIHNpdGVzIHRoYXQgdXNlIHBvcHVwcw0KLSBwaW50ZXJlc3QNCi0gZXhwZWRp YQ0KLSB0cmlwYWR2aXNvcg0KLSBueXRpbWVzDQotIGluZGVlZC5jb208aHR0cDovL2luZGVlZC5j b20+DQotIHF1b3JhDQotIHJlZGZpbg0KLSB0cnVsaWENCg0KLSBzaXRlcyB0aGF0IHVzZSBhIGZ1 bGwgcGFnZSByZWRpcmVjdA0KLSBJTURCIC0gYW4gQW1hem9uIHByb3BlcnR5ID0pDQoNCkxvb2tz IGxpa2UgbW9zdCBzaXRlcyBwcmVmZXIgcG9wdXBzIGFuZCBoYXZlIGZpZ3VyZWQgb3V0IGhvdyB0 byBkbyBpdCAtLSBleGNlcHQgSU1EQi4NCg0KW3JpY2hhbm5hXQ0KSSBqdXN0IHRyaWVkIHVzaW5n IEdvb2dsZSBTaWduIEluIG9uIFBpbnRlcmVzdCwgRXhwZWRpYSwgYW5kIElNRGIsIHdoZW4gYWNj ZXNzZWQgdmlhIGEgbGluayBpbiBhIEZhY2Vib29rIHBvc3QgaW4gdGhlIEZhY2Vib29rIGFwcC4g R3Vlc3Mgd2hpY2ggb25lIHdvcmtlZCBhbmQgd2hpY2ggdHdvIGRpZG7igJl0PyDwn5iDIFRoaXMg cGVyZmVjdGx5IGlsbHVzdHJhdGVzIG15IHBvaW50IHRoYXQgcG9wdXBzIGFyZSB1bnJlbGlhYmxl LCBhbmQgY2FuIGZhaWwgaW4gd2VpcmQgd2F5cy4NClsvcmljaGFubmFdDQoNCg0KQWxzbywgaXTi gJlzIDIwMjAuIFN0b3AgYnJhbmNoaW5nIG9uIG1vYmlsZSB2cy4uIGRlc2t0b3AuIEkgZ2V0IHRo YXQgbG90cyBvZiBwZW9wbGUgc3RpbGwgZG8gdGhhdCwgYnV0IHRoYXQgZG9lc27igJl0IG1lYW4g dGhlIHByb3RvY29sIHNob3VsZCBjYXRlciB0byBpdC4NCg0KTW9iaWxlIGFuZCBkZXNrdG9wIGFy ZSBkaWZmZXJlbnQgdGhvdWdoLiBUaGV5IGRvbid0IG9mZmVyIHRoZSBzYW1lIGV4cGVyaWVuY2Vz Lg0KDQpPbiBtb2JpbGUsIGEgR1MgbWF5IGhhdmUgYSBtb2JpbGUgYXBwIHRoYXQgY2FuIHJlY2Vp dmUgcHVzaCBub3RpZmljYXRpb25zLiBUaGUgc2VjdXJpdHkgcGFyYW1ldGVycyBhcmUgZGlmZmVy ZW50Lg0KDQpTb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIHdhbnQgdG8ga25vdyB3aGljaCBwbGF0 Zm9ybSBpcyBiZWluZyB1c2VkLiBXZSBzaG91bGQgbm90IHJlbW92ZSB0aGF0IHNpZ25hbCBmb3Ig dGhlbS4NCg0KW3JpY2hhbm5hXQ0KTXkgY29tbWVudCB3YXMgYWltZWQgYXQgdGhlIGltcGxpY2F0 aW9uIHRoYXQgQ2xpZW50cyBtaWdodCBvcHQgdG8gdXNlIGEgcG9wdXAgaW50ZXJhY3Rpb24gbW9k ZSBvbiDigJxkZXNrdG9w4oCdIGJ1dCBkbyBzb21ldGhpbmcgZGlmZmVyZW50IChlLmcuLCByZWRp cmVjdCkgb24gbW9iaWxlLiBJbiBhbnkgY2FzZSwgaWYgdGhlIENsaWVudCBpcyBpbXBsZW1lbnRp bmcgcmVkaXJlY3QgZm9yIG1vYmlsZSBhbnl3YXksIHRoZW4gaXQgaXMgbm90IG11Y2ggd29yayBm b3IgdGhlbSB0byB3cmFwIHRoYXQgaW4gYSBwb3B1cCBpZiB0aGV5IHJlYWxseSB3YW50IHRoYXQg ZXhwZXJpZW5jZSBvbiBkZXNrdG9wLg0KWy9yaWNoYW5uYV0NCg0KQW5kIGFnYWluLCBhIENsaWVu dCB0aGF0IHJlYWxseSB3YW50cyB0byBnaXZlIHRoZW1zZWx2ZXMgYSBoZWFkYWNoZSB3aXRoIHBv cHVwcyBjYW4gZG8gdGhhdCB0aGVtc2VsdmVzIHVzaW5nIOKAnHJlZGlyZWN04oCdIG1vZGUuIFRo ZXkganVzdCBoYXZlIHRvIHByb3ZpZGUgYSBsYW5kaW5nIHBhZ2UgZm9yIHRoZSBHUyB0byByZWRp cmVjdCBiYWNrIHRvIHRoYXQgcGFyc2VzIHRoZSByZXNwb25zZSwgcGFzc2VzIGl0IGJhY2sgdG8g dGhlIG1haW4gd2luZG93LCBhbmQgY2xvc2VzIGl0c2VsZi4gSSBkb27igJl0IHNlZSB3aHkgdGhl IHByb3RvY29sIHdvdWxkIG5lZWQgdG8gZXhwbGljaXRseSBkZXNjcmliZSB0aGlzIG1lY2hhbmlz bS4NClsvcmljaGFubmFdDQoNCkkgdGhpbmsgaXQgaXMgYSB1c2VmdWwgc2lnbmFsIGZvciB0aGUg R1MgaW4gdGhlIGV4cGVyaWVuY2UgaXQgd2FudHMgdG8gc2hvdyB0aGUgdXNlci4NCg0KW3JpY2hh bm5hXQ0KVXNlZnVsIGhvdz8gVGhlIHdpbmRvdyBkaW1lbnNpb25zIGFyZSBhIGJldHRlciBzaWdu YWwgZm9yIGhvdyB0byBwcmVzZW50IHRoZSB1c2VyIGV4cGVyaWVuY2UuICgqY291Z2gqIHJlc3Bv bnNpdmUgZGVzaWduICpjb3VnaCopDQpbL3JpY2hhbm5hXQ0KDQpSZXNwb25zaXZlIGRlc2lnbiBp cyBvbmUgd2F5IHRvIGFkZHJlc3MgdGhpbmdzLiBMb3RzIG9mIGFwcHMgc3RpbGwgaGF2ZSBhbiBt LmV4YW1wbGUuY29tPGh0dHA6Ly9tLmV4YW1wbGUuY29tPiBzaXRlIGZvciBtb2JpbGUgY29udGVu dC4NCg0KT3VyIGdvYWwgaXMgbm90IHRvIGRlY2lkZSBob3cgYW4gYXBwIHNob3VsZCBidWlsZCBh IHVzZXIgZXhwZXJpZW5jZS4gV2Ugc2hvdWxkIGdpdmUgdGhlbSBhcyBtdWNoIHVzZWZ1bCBzaWdu YWwgYXMgdGhleSBtYXkgbmVlZCB0byBtYWtlIHRoZWlyIG93biBjaG9pY2VzLg0KDQpbcmljaGFu bmFdDQpXaGF0IHNpZ25hbCB0aG91Z2g/IFdoYXQgdXNlZnVsIGluZm9ybWF0aW9uIGRvZXMgdGhl IEdTIGdldCBvdXQgb2Yga25vd2luZyB0aGF0IHRoZSBDbGllbnQgaW50ZW5kcyB0byBvcGVuIHRo ZSBpbnRlcmFjdGlvbiBVUkkgaW4gYSBwb3B1cCwgdGhhdCBpdCBkb2VzbuKAmXQgYWxyZWFkeSBo YXZlIG1vcmUgYWNjdXJhdGUgc291cmNlcyBmb3I/IEkgbWVudGlvbmVkIHJlc3BvbnNpdmUgZGVz aWduIGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgSSBjYW4gdGhpbmsgb2YgaXMgdGhhdCBpdCBtaWdo dCBpbmZvcm0gaG93IHRoZSBHUyBwcmVzZW50cyB0aGUgc2lnbiBpbiBleHBlcmllbmNlLCBidXQg 4oCccG9wdXDigJ0gb24gaXRzIG93biBkb2VzbuKAmXQgbmVjZXNzYXJpbHkgbWVhbiBpdCB3aWxs IGJlIGEgc21hbGwgb3IgcG9ydHJhaXQtZGltZW5zaW9uZWQgd2luZG93LiBTbyB0aGUgR1MgaXMg c3RpbGwganVzdCBndWVzc2luZyB1bnRpbCBpdOKAmXMgYWN0dWFsbHkgbG9hZGVkIGluIHRoZSBw b3B1cCwgYW5kIGF0IHRoYXQgcG9pbnQgaXQgY2FuIGNoZWNrIHRoZSBhY3R1YWwgd2luZG93IGRp bWVuc2lvbnMgYW5kIHVzZSBDU1MgbWVkaWEgcXVlcmllcywgZXRjLg0KWy9yaWNoYW5uYV0NCg0K PHNuaXA+DQoNCg0KMy4gICBIb3cgbG9uZyBzaG91bGQgdGhlIEdTIHdhaXQgZm9yIHRoZSBDbGll bnQgdG8gbWFrZSB0aGUgVXBkYXRlIEdyYW50IHJlcXVlc3QgaW4gMy40PyBXaGF0IHNob3VsZCB0 aGUgR1MgZG8gaWYgdGhhdCBuZXZlciBoYXBwZW5zPyBXaGF0IGlzIHRoZSBwYXRoIGZvcndhcmQg Zm9yIHRoZSBlbmQgdXNlciwgYXQgdGhhdCBwb2ludD8NCg0KMy4xIGhhcyB0aGUgR1Mgd2FpdGlu ZyBmb3IgdGhlIENsaWVudCBhcyB3ZWxsLiBBbGwgdGhlIHNhbWUgcXVlc3Rpb25zIGFwcGx5IHRv IGFueSBhc3BlY3Qgb2YgdGhlIHByb3RvY29sIHdoZXJlIG9uZSBwYXJ0eSBkb2VzIG5vdCBkbyB0 aGUgbmV4dCBzdGVwLiBUaGUgVXNlciBpcyB0aGUgbW9zdCBsaWtlbHkgcGFydHkgdG8gbm90IGNv bnRpbnVlLiBXaGF0IGRvIHRoZSBHUyBhbmQgQ2xpZW50IGRvIGlmIHRoZSBVc2VyIGhhcyBiZWVu IHNlbnQgdG8gdGhlIEdTLCBidXQgd2Fsa3MgYXdheSBmcm9tIHRoZWlyIGRldmljZT8NCg0KW3Jp Y2hhbm5hXQ0KSW4gc3RlcCAzLjQsIHN0ZXBzIDYgdGhyb3VnaCA4LCB0aGUgR1MgcmV0dXJucyB0 aGUgUmVhZCBHcmFudCByZXNwb25zZSAoNiksIHRoZSBDbGllbnQgZXZhbHVhdGVzIGl0ICg3KSwg YW5kIHRoZW4gdGhlIENsaWVudCBtYWtlcyBhbiBVcGRhdGUgR3JhbnQgcmVxdWVzdCB0byB0aGUg R1MgKDgpLiBUaHJvdWdob3V0IHRoaXMgdGltZSwgdGhlIGVuZCB1c2VyIGlzIHNpdHRpbmcgYXQg dGhlIEdT4oCmd2F0Y2hpbmcgYSBzcGlubmVyLCBJIGd1ZXNzPyBIb3cgbG9uZyBkb2VzIHRoZSBB UyB3YWl0IGZvciB0aGUgVXBkYXRlIEdyYW50IHJlcXVlc3Q/IFdoYXQgaWYgaXQgbmV2ZXIgY29t ZXM/IEnigJltIG5vdCB0YWxraW5nIGFib3V0IHRoZSBlbmQgdXNlciB3YWxraW5nIGF3YXksIEni gJltIHRhbGtpbmcgYWJvdXQgdGhlIENsaWVudCBmYWlsaW5nIHRvIHRlbGwgdGhlIEdTIHRvIGFk dmFuY2UgdGhlIGZsb3cuDQpbL3JpY2hhbm5hXQ0KDQo8c25pcD4NCg0KVGhlIGlzc3VlIGlzbuKA mXQgdGhlIEFQSSBjYWxsIGl0c2VsZiwgaXTigJlzIHRoZSBuZWVkIGZvciB0aGUgQ2xpZW50IHRv IG1haW50YWluIGEgcGVyc2lzdGVudCwgYXN5bmNocm9ub3VzIHByb2Nlc3MgdG8gbWFrZSB0aGF0 IEFQSSBjYWxsLg0KDQpUaGUgMy4xIGZsb3csIGFuZCBhbGwgdGhlIFhZWiBmbG93cyB3aGVyZSB0 aGVyZSBpcyBubyByZWRpcmVjdCBhbGwgaGF2ZSB0aGUgc2FtZSByZXF1aXJlbWVudCBvZiB0aGUg Q2xpZW50Lg0KDQpBbiBhc3luYyBjYWxsIHRvIGEgc2VydmVyIGlzIHByZXR0eSBzdHJhaWdodCBm b3J3YXJkIGluIGFsbCBtb2Rlcm4gd2ViIGxhbmd1YWdlcy4NCg0KSWYgdGhlIENsaWVudCBpcyBh IG1vYmlsZSBhcHAgcHV0IHRvIHNsZWVwLCBpdCBjYW4gcmVtYWtlIHRoZSBjYWxsIHRvIHRoZSBH UyBhbmQgZ2V0IHRoZSByZXN1bHRzIGluIGEgMy4xIGZsb3cuDQoNCltyaWNoYW5uYV0NCkl04oCZ cyBub3QganVzdCBhbiBhc3luYyBjYWxsIHRvIGEgc2VydmVyLCBpdOKAmXMgYW4gYXN5bmMgY2Fs bCBpbml0aWF0ZWQgd2hpbGUgaGFuZGxpbmcgYW4gSFRUUCByZXF1ZXN0IGFuZCB0aGF0IHN1cnZp dmVzIHRoZSBjb21wbGV0aW9uIG9mIHRoYXQgcmVxdWVzdC4gVGhpcyBpcyBub3QgdHJpdmlhbCwg YW5kIGV2ZW4gd2hlcmUgdGhlcmUgYXJlIHRvb2xzIHRvIGhlbHAgd2l0aCB0aGlzIHRoZXkgYXJl IG9mdGVuIGZ1bGwgb2Ygc2hhcnAgZWRnZXMgYW5kIGludHJvZHVjZSBmdW4gbmV3IGZhaWx1cmUg bW9kZXMgKERvZXMgeW91ciBpbXBsZW1lbnRhdGlvbiBmYWlsIGZhc3Qgd2hlbiB5b3VyIGFzeW5j IHRocmVhZCBwb29sIGdldHMgZXhoYXVzdGVkPyBObz8gQmV0dGVyIGhvcGUgeW91ciB1c2VycyBs aWtlIDUwM3PigKYpLg0KDQpJIHN1Z2dlc3QgYSBzZXBhcmF0ZSB0aHJlYWQgZm9yIHRoaXMgb25l IGFzIHdlbGwuDQpbL3JpY2hhbm5hXQ0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90 P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQm Z3VpZD1iNjQ5NTBkNC1kNThmLTRiZjYtOTc1Mi01NDNiODIxMzNmMzRd4ZCnDQo= --_000_CE1AA4C2619D4CE9808FB2E03227EEAFamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuZ21haWwtbS03MDI2NTY3MTcxNDMyNzA5ODUzbXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwt bS03MDI2NTY3MTcxNDMyNzA5ODUzbXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tNzAyNjU2 NzE3MTQzMjcwOTg1M21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8t NzAyNjU2NzE3MTQzMjcwOTg1M21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjc5MDU4NTg0ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTI4NDAwNzgxODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjk1NDc0OTE0NDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs Mg0KCXttc28tbGlzdC1pZDo5NTk3Mjg4NDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02MTEw MjkxMDg7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTI1MjU4OTk4NjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTkwMjY2MTkwMjt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTI2MjE4MTYz NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg3MjExNDU0Mjt9DQpAbGlzdCBsNDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxp c3QtaWQ6MTM1NjA3NDAzMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMTE1NzI1NDY7fQ0K QGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDoxNDE1NDc1MTI0Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNjExMDI5MTA4O30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjE0Mjc2NDg0 NjM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzk3MTk2MjQ4O30NCkBsaXN0IGw3OmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDgNCgl7bXNvLWxpc3QtaWQ6MTQ2MTk5MjE5NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE3 NTA3ODY1ODt9DQpAbGlzdCBsODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDg6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDg6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDg6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDg6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDg6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDkNCgl7bXNvLWxpc3QtaWQ6MTYzMDQ3MjQzNTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9DQpAbGlzdCBsOTpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjM7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTANCgl7bXNvLWxp c3QtaWQ6MTY2NzEyNTA0NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9DQpA bGlzdCBsMTA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDEwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTENCgl7bXNv LWxpc3QtaWQ6MTY5MzUzMzQ2NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxMTAyOTEwODt9 DQpAbGlzdCBsMTINCgl7bXNvLWxpc3QtaWQ6MjA0MzI4ODk0MjsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTkzODk1Njc4Njt9DQpAbGlzdCBsMTI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMjpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDEyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMw0KCXttc28tbGlz dC1pZDoyMDUzODQ4MjE2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjExMDI5MTA4O30NCkBs aXN0IGwxNA0KCXttc28tbGlzdC1pZDoyMDgzNjcyMzkxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotNjExMDI5MTA4O30NCkBsaXN0IGwxNDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTQ6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+4oCTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBCYWNrbWFu IChzaGUvaGVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lzwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+VHhhdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsg b24gYmVoYWxmIG9mIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5Nb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDIwIGF0IDQ6MjIgUE08YnI+DQo8 Yj5UbzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNo YW5uYT00MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhdIFhBdXRoIC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIEZyaSwgRmViIDE0LCAyMDIwIGF0IDY6Mjkg UE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hPTxhIGhyZWY9Im1haWx0 bzo0MGFtYXpvbi5jb21AZG1hcmMuaWV0Zi5vcmciPjQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7c25pcCZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KVGhl cmUgYXJlIGxvdHMgb2YgcmVhc29ucyBmb3Igd2FudGluZyB0byBzdXBwb3J0IG11bHRpcGxlIG1v ZGVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzAyNjU2NzE3MTQzMjcwOTg1 M21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzciPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U29tZSBwZW9wbGUgYXJlIGNvbWZvcnRhYmxlIHdpdGgg UVIgY29kZXMsIHNvbWUgYXJlbuKAmXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwt bS03MDI2NTY3MTcxNDMyNzA5ODUzbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNyBsZXZlbDEgbGZvNyI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Tb21lIHBlb3BsZSBo YXZlIHNtYXJ0IHBob25lcyB0aGF0IGNhbiBzY2FuIHRoZW0sIHNvbWUgZG9u4oCZdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTcwMjY1NjcxNzE0MzI3MDk4NTNtc29saXN0cGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0Omw3IGxldmVsMSBsZm83Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPlBlb3BsZSB3aXRoIHNtYXJ0IHBob25lcyBtYXkgd2FudCB0byBnbyB0aHJv dWdoIHRoZSBhdXRoZW50aWNhdGlvbiBmbG93IG9uIHRoZWlyIGRlc2t0b3AgaW5zdGVhZC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTcwMjY1NjcxNzE0MzI3MDk4NTNtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0Omw3IGxldmVsMSBsZm83Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPlNvbWUgcGVvcGxlIG1heSA8aT5oYXZlPC9pPiB0byBnbyB0aHJvdWdo IHRoZSBhdXRoZW50aWNhdGlvbiBmbG93IG9uIHRoZWlyIGRlc2t0b3AsIGJlY2F1c2UgdGhlIEdT IHRoaW5rcyBpUGhvbmVzIG9ubHkgc3VwcG9ydCBCbHVldG9vdGgtYmFzZWQgc2VjdXJpdHkga2V5 cyBhbmQgaW5zaXN0cyB0aGV5IGNhbm5vdCBjb21wbGV0ZSB0aGUgbG9naW4gZmxvdyBldmVuIHRo b3VnaCB0aGV5IGhhdmUNCiB0d28gWXViaUtleSA1Q2kga2V5cyBvbiB0aGVpciBhY2NvdW50LiAo SEksIEdPT0dMRSBBQ0NPVU5UIFBST1RFQ1RJT04gUFJPR1JBTSk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFsbCBvZiB5 b3VyIGV4YW1wbGVzIGFyZSBjaG9pY2VzIGZvciB0aGUgVXNlciwgd2hpY2ggdGhlIENsaWVudCB3 b3VsZCBuZWVkIHRvIHByZXNlbnQgdG8gdGhlIFVzZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UGVyIG15IGNvbW1lbnQgYWJvdmUgYmFzZWQg b24geW91ciBzdWdnZXN0aW9uLCAmcXVvdDtxcmNvZGUmcXVvdDsgYWxzbyBzaG93cyB0aGUgJnF1 b3Q7Y29kZSZxdW90OyBpbmZvcm1hdGlvbiwgd2hpY2ggc2F0aXNmaWVzIGFsbCB5b3VyIHN1Z2dl c3Rpb25zIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bcmljaGFubmFdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIEkgYW0ganVzdGlmeWluZyB0aGUgdmFs dWUgb2YgYWxsb3dpbmcgQ2xpZW50cyB0byByZXF1ZXN0IGFuZCBwcmVzZW50IG11bHRpcGxlIGlu dGVyYWN0aW9uIG1ldGhvZHMgYnkgcHJvdmlkaW5nIHRoZXNlIGFyZSBzb21lIGV4YW1wbGVzIG9m IGNhc2VzIHdoZXJlIGl0IHByb3ZpZGVzIGNsZWFyIGJlbmVmaXQgdG8gdGhlIGVuZCB1c2VyLiBZ b3UgY2FuIHNlZSB0aGlzIGltcGxlbWVudGVkIGluIHRoZSBBV1MNCiBDTEkgdjLigJlzIHN1cHBv cnQgZm9yIEFXUyBTU08uIEFuZCDigJxTY2FuIHRoaXMgJmx0O1FSIGNvZGUmZ3Q7IG9yICZsdDth bHRlcm5hdGUgaW5zdHJ1Y3Rpb25zJmd0O+KAnSBpcyBhIHByZXR0eSBjb21tb24gcGF0dGVybiBm b3IgYW55dGhpbmcgaW52b2x2aW5nIFFSIGNvZGVzLiBXaGVyZSBkaWQgeW91IHN1Z2dlc3QgdGhh dCB0aGUg4oCccXJjb2Rl4oCdIGludGVyYWN0aW9uIG9iamVjdCB3b3VsZCBpbmNsdWRlIHRoZSBj b2RlIGluZm9ybWF0aW9uPyBBcmUgeW91IHJlZmVycmluZw0KIHRvIHlvdXIgY29tbWVudCBwcm9w b3NpbmcgYSDigJx0ZXh0IG9ubHkgaW50ZXJhY3Rpb24gdHlwZeKAnT8gVGhhdCBjb21tZW50IHNv dW5kZWQgbGlrZSBhbiBlaXRoZXIvb3IgdG8gbWUsIGFzIGluIHRoZSBDbGllbnQgY291bGQgb3B0 IGZvciB0aGUgdGV4dC1vbmx5IGludGVyYWN0aW9uIHRoYXQgcHJvdmlkZXMgdGhlbSB0aGUgY29k ZSBvciB0aGUgcXJjb2RlIGludGVyYWN0aW9uIHRoYXQgcHJvdmlkZXMgdGhlbSBhIHNob3J0IFVS TCwgbm90IGJvdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL3JpY2hh bm5hXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGNoZWNrZWQgd2hhdCBwb3B1bGFyIHNp dGVzIGxpc3RlZCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9haHJlZnMuY29tL2Jsb2cvbW9zdC12aXNp dGVkLXdlYnNpdGVzLyI+aHR0cHM6Ly9haHJlZnMuY29tL2Jsb2cvbW9zdC12aXNpdGVkLXdlYnNp dGVzLzwvYT4gdXNlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KLSBzaXRlcyB0aGF0IHVzZSBwb3B1cHM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMw LjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LSBwaW50ZXJlc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIGV4 cGVkaWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIHRyaXBhZHZpc29yPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+LSBueXRpbWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LSA8YSBocmVmPSJodHRwOi8vaW5kZWVk LmNvbSI+aW5kZWVkLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIHF1b3JhPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+LSByZWRmaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIHRydWxpYTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4tIHNpdGVzIHRoYXQgdXNlIGEgZnVsbCBwYWdlIHJlZGlyZWN0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gSU1EQiAtIGFuIEFtYXpvbiBwcm9wZXJ0eSA9KTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5Mb29rcyBsaWtlIG1vc3Qgc2l0ZXMgcHJlZmVyIHBvcHVwcyBhbmQgaGF2ZSBmaWd1cmVkIG91 dCBob3cgdG8gZG8gaXQgLS0gZXhjZXB0IElNREIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlty aWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkganVzdCB0cmll ZCB1c2luZyBHb29nbGUgU2lnbiBJbiBvbiBQaW50ZXJlc3QsIEV4cGVkaWEsIGFuZCBJTURiLCB3 aGVuIGFjY2Vzc2VkIHZpYSBhIGxpbmsgaW4gYSBGYWNlYm9vayBwb3N0IGluIHRoZSBGYWNlYm9v ayBhcHAuIEd1ZXNzIHdoaWNoIG9uZSB3b3JrZWQgYW5kIHdoaWNoIHR3byBkaWRu4oCZdD8NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OyI+JiMx Mjg1MTU7PC9zcGFuPiBUaGlzIHBlcmZlY3RseSBpbGx1c3RyYXRlcyBteSBwb2ludCB0aGF0IHBv cHVwcyBhcmUgdW5yZWxpYWJsZSwgYW5kIGNhbiBmYWlsIGluIHdlaXJkIHdheXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KQWxzbywgaXTigJlzIDIwMjAuIFN0b3AgYnJhbmNoaW5nIG9uIG1v YmlsZSB2cy4uIGRlc2t0b3AuIEkgZ2V0IHRoYXQgbG90cyBvZiBwZW9wbGUgc3RpbGwgZG8gdGhh dCwgYnV0IHRoYXQgZG9lc27igJl0IG1lYW4gdGhlIHByb3RvY29sIHNob3VsZCBjYXRlciB0byBp dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk1vYmlsZSBhbmQgZGVza3Rv cCBhcmUgZGlmZmVyZW50IHRob3VnaC4gVGhleSBkb24ndCBvZmZlciB0aGUgc2FtZSBleHBlcmll bmNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBt b2JpbGUsIGEgR1MgbWF5IGhhdmUgYSBtb2JpbGUgYXBwIHRoYXQgY2FuIHJlY2VpdmUgcHVzaCBu b3RpZmljYXRpb25zLiBUaGUgc2VjdXJpdHkgcGFyYW1ldGVycyBhcmUgZGlmZmVyZW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNvbWUgaW1wbGVtZW50 YXRpb25zIHdpbGwgd2FudCB0byBrbm93IHdoaWNoIHBsYXRmb3JtIGlzIGJlaW5nIHVzZWQuIFdl IHNob3VsZCBub3QgcmVtb3ZlIHRoYXQgc2lnbmFsIGZvciB0aGVtLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3Jp Y2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgY29tbWVudCB3 YXMgYWltZWQgYXQgdGhlIGltcGxpY2F0aW9uIHRoYXQgQ2xpZW50cyBtaWdodCBvcHQgdG8gdXNl IGEgcG9wdXAgaW50ZXJhY3Rpb24gbW9kZSBvbiDigJxkZXNrdG9w4oCdIGJ1dCBkbyBzb21ldGhp bmcgZGlmZmVyZW50IChlLmcuLCByZWRpcmVjdCkgb24gbW9iaWxlLiBJbiBhbnkgY2FzZSwgaWYg dGhlIENsaWVudCBpcyBpbXBsZW1lbnRpbmcgcmVkaXJlY3QgZm9yIG1vYmlsZSBhbnl3YXksIHRo ZW4NCiBpdCBpcyBub3QgbXVjaCB3b3JrIGZvciB0aGVtIHRvIHdyYXAgdGhhdCBpbiBhIHBvcHVw IGlmIHRoZXkgcmVhbGx5IHdhbnQgdGhhdCBleHBlcmllbmNlIG9uIGRlc2t0b3AuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MS4waW4iPg0KQW5kIGFnYWluLCBhIENsaWVudCB0aGF0IHJlYWxseSB3YW50cyB0byBn aXZlIHRoZW1zZWx2ZXMgYSBoZWFkYWNoZSB3aXRoIHBvcHVwcyBjYW4gZG8gdGhhdCB0aGVtc2Vs dmVzIHVzaW5nIOKAnHJlZGlyZWN04oCdIG1vZGUuIFRoZXkganVzdCBoYXZlIHRvIHByb3ZpZGUg YSBsYW5kaW5nIHBhZ2UgZm9yIHRoZSBHUyB0byByZWRpcmVjdCBiYWNrIHRvIHRoYXQgcGFyc2Vz IHRoZSByZXNwb25zZSwgcGFzc2VzIGl0IGJhY2sgdG8gdGhlIG1haW4gd2luZG93LA0KIGFuZCBj bG9zZXMgaXRzZWxmLiBJIGRvbuKAmXQgc2VlIHdoeSB0aGUgcHJvdG9jb2wgd291bGQgbmVlZCB0 byBleHBsaWNpdGx5IGRlc2NyaWJlIHRoaXMgbWVjaGFuaXNtLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluIj4NClsvcmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+ DQpJIHRoaW5rIGl0IGlzIGEgdXNlZnVsIHNpZ25hbCBmb3IgdGhlIEdTIGluIHRoZSBleHBlcmll bmNlIGl0IHdhbnRzIHRvIHNob3cgdGhlIHVzZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpb cmljaGFubmFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpVc2VmdWwgaG93PyBUaGUgd2luZG93IGRpbWVuc2lv bnMgYXJlIGEgYmV0dGVyIHNpZ25hbCBmb3IgaG93IHRvIHByZXNlbnQgdGhlIHVzZXIgZXhwZXJp ZW5jZS4gKCpjb3VnaCogcmVzcG9uc2l2ZSBkZXNpZ24gKmNvdWdoKik8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClsvcmljaGFubmFdPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZXNwb25zaXZlIGRlc2lnbiBpcyBv bmUgd2F5IHRvIGFkZHJlc3MgdGhpbmdzLiBMb3RzIG9mIGFwcHMgc3RpbGwgaGF2ZSBhbg0KPGEg aHJlZj0iaHR0cDovL20uZXhhbXBsZS5jb20iPm0uZXhhbXBsZS5jb208L2E+IHNpdGUgZm9yIG1v YmlsZSBjb250ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPk91ciBnb2FsIGlzIG5vdCB0byBkZWNpZGUgaG93IGFuIGFwcCBzaG91bGQgYnVpbGQgYSB1 c2VyIGV4cGVyaWVuY2UuIFdlIHNob3VsZCBnaXZlIHRoZW0gYXMgbXVjaCB1c2VmdWwgc2lnbmFs IGFzIHRoZXkgbWF5IG5lZWQgdG8gbWFrZSB0aGVpciBvd24gY2hvaWNlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltyaWNo YW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgc2lnbmFsIHRo b3VnaD8gV2hhdCB1c2VmdWwgaW5mb3JtYXRpb24gZG9lcyB0aGUgR1MgZ2V0IG91dCBvZiBrbm93 aW5nIHRoYXQgdGhlIENsaWVudCBpbnRlbmRzIHRvIG9wZW4gdGhlIGludGVyYWN0aW9uIFVSSSBp biBhIHBvcHVwLCB0aGF0IGl0IGRvZXNu4oCZdCBhbHJlYWR5IGhhdmUgbW9yZSBhY2N1cmF0ZSBz b3VyY2VzIGZvcj8gSSBtZW50aW9uZWQgcmVzcG9uc2l2ZSBkZXNpZ24gYmVjYXVzZSB0aGUNCiBv bmx5IHRoaW5nIEkgY2FuIHRoaW5rIG9mIGlzIHRoYXQgaXQgbWlnaHQgaW5mb3JtIGhvdyB0aGUg R1MgcHJlc2VudHMgdGhlIHNpZ24gaW4gZXhwZXJpZW5jZSwgYnV0IOKAnHBvcHVw4oCdIG9uIGl0 cyBvd24gZG9lc27igJl0IG5lY2Vzc2FyaWx5IG1lYW4gaXQgd2lsbCBiZSBhIHNtYWxsIG9yIHBv cnRyYWl0LWRpbWVuc2lvbmVkIHdpbmRvdy4gU28gdGhlIEdTIGlzIHN0aWxsIGp1c3QgZ3Vlc3Np bmcgdW50aWwgaXTigJlzIGFjdHVhbGx5IGxvYWRlZCBpbg0KIHRoZSBwb3B1cCwgYW5kIGF0IHRo YXQgcG9pbnQgaXQgY2FuIGNoZWNrIHRoZSBhY3R1YWwgd2luZG93IGRpbWVuc2lvbnMgYW5kIHVz ZSBDU1MgbWVkaWEgcXVlcmllcywgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3NuaXAmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9ImdtYWlsLW0tNzAyNjU2NzE3MTQzMjcwOTg1M21zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDkgbGV2 ZWwxIGxmbzE0Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkhvdyBsb25nIHNob3Vs ZCB0aGUgR1Mgd2FpdCBmb3IgdGhlIENsaWVudCB0byBtYWtlIHRoZSBVcGRhdGUgR3JhbnQgcmVx dWVzdCBpbiAzLjQ/IFdoYXQgc2hvdWxkIHRoZSBHUyBkbyBpZiB0aGF0IG5ldmVyIGhhcHBlbnM/ IFdoYXQgaXMgdGhlIHBhdGggZm9yd2FyZCBmb3IgdGhlIGVuZCB1c2VyLCBhdCB0aGF0IHBvaW50 PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+My4xIGhhcyB0aGUgR1Mgd2Fp dGluZyBmb3IgdGhlIENsaWVudCBhcyB3ZWxsLiBBbGwgdGhlIHNhbWUgcXVlc3Rpb25zIGFwcGx5 IHRvIGFueSBhc3BlY3Qgb2YgdGhlIHByb3RvY29sIHdoZXJlIG9uZSBwYXJ0eSBkb2VzIG5vdCBk byB0aGUgbmV4dCBzdGVwLiBUaGUgVXNlciBpcyB0aGUgbW9zdCBsaWtlbHkgcGFydHkgdG8gbm90 IGNvbnRpbnVlLiBXaGF0IGRvIHRoZQ0KIEdTIGFuZCBDbGllbnQgZG8gaWYgdGhlIFVzZXIgaGFz IGJlZW4gc2VudCB0byB0aGUgR1MsIGJ1dCB3YWxrcyBhd2F5IGZyb20gdGhlaXIgZGV2aWNlPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bcmljaGFubmFdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiBzdGVwIDMuNCwgc3RlcHMgNiB0aHJvdWdoIDgsIHRoZSBHUyByZXR1 cm5zIHRoZSBSZWFkIEdyYW50IHJlc3BvbnNlICg2KSwgdGhlIENsaWVudCBldmFsdWF0ZXMgaXQg KDcpLCBhbmQgdGhlbiB0aGUgQ2xpZW50IG1ha2VzIGFuIFVwZGF0ZSBHcmFudCByZXF1ZXN0IHRv IHRoZSBHUyAoOCkuIFRocm91Z2hvdXQgdGhpcyB0aW1lLCB0aGUgZW5kIHVzZXIgaXMgc2l0dGlu ZyBhdCB0aGUgR1PigKZ3YXRjaGluZyBhDQogc3Bpbm5lciwgSSBndWVzcz8gSG93IGxvbmcgZG9l cyB0aGUgQVMgd2FpdCBmb3IgdGhlIFVwZGF0ZSBHcmFudCByZXF1ZXN0PyBXaGF0IGlmIGl0IG5l dmVyIGNvbWVzPyBJ4oCZbSBub3QgdGFsa2luZyBhYm91dCB0aGUgZW5kIHVzZXIgd2Fsa2luZyBh d2F5LCBJ4oCZbSB0YWxraW5nIGFib3V0IHRoZSBDbGllbnQgZmFpbGluZyB0byB0ZWxsIHRoZSBH UyB0byBhZHZhbmNlIHRoZSBmbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Wy9yaWNoYW5uYV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3NuaXAmZ3Q7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KVGhl IGlzc3VlIGlzbuKAmXQgdGhlIEFQSSBjYWxsIGl0c2VsZiwgaXTigJlzIHRoZSBuZWVkIGZvciB0 aGUgQ2xpZW50IHRvIG1haW50YWluIGEgcGVyc2lzdGVudCwgYXN5bmNocm9ub3VzIHByb2Nlc3Mg dG8gbWFrZSB0aGF0IEFQSSBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VGhlIDMuMSBmbG93LCBhbmQgYWxsIHRoZSBYWVogZmxvd3Mgd2hlcmUgdGhlcmUgaXMgbm8g cmVkaXJlY3QgYWxsIGhhdmUgdGhlIHNhbWUgcmVxdWlyZW1lbnQgb2YgdGhlIENsaWVudC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbiBhc3luYyBjYWxs IHRvIGEgc2VydmVyIGlzIHByZXR0eSBzdHJhaWdodCBmb3J3YXJkIGluIGFsbCBtb2Rlcm4gd2Vi IGxhbmd1YWdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JZiB0aGUgQ2xpZW50IGlzIGEgbW9iaWxlIGFwcCBwdXQgdG8gc2xlZXAsIGl0IGNhbiByZW1h a2UgdGhlIGNhbGwgdG8gdGhlIEdTIGFuZCBnZXQgdGhlIHJlc3VsdHMgaW4gYSAzLjEgZmxvdy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIG5vdCBqdXN0IGFuIGFzeW5jIGNhbGwgdG8gYSBz ZXJ2ZXIsIGl04oCZcyBhbiBhc3luYyBjYWxsIGluaXRpYXRlZCB3aGlsZSBoYW5kbGluZyBhbiBI VFRQIHJlcXVlc3QgYW5kIHRoYXQgc3Vydml2ZXMgdGhlIGNvbXBsZXRpb24gb2YgdGhhdCByZXF1 ZXN0LiBUaGlzIGlzIG5vdCB0cml2aWFsLCBhbmQgZXZlbiB3aGVyZSB0aGVyZSBhcmUgdG9vbHMg dG8gaGVscCB3aXRoIHRoaXMgdGhleSBhcmUgb2Z0ZW4NCiBmdWxsIG9mIHNoYXJwIGVkZ2VzIGFu ZCBpbnRyb2R1Y2UgZnVuIG5ldyBmYWlsdXJlIG1vZGVzIChEb2VzIHlvdXIgaW1wbGVtZW50YXRp b24gZmFpbCBmYXN0IHdoZW4geW91ciBhc3luYyB0aHJlYWQgcG9vbCBnZXRzIGV4aGF1c3RlZD8g Tm8/IEJldHRlciBob3BlIHlvdXIgdXNlcnMgbGlrZSA1MDNz4oCmKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBzdWdnZXN0IGEgc2VwYXJhdGUgdGhyZWFkIGZvciB0aGlzIG9uZSBhcyB3ZWxs LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy9yaWNoYW5uYV08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBf aTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xq YXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9 YjY0OTUwZDQtZDU4Zi00YmY2LTk3NTItNTQzYjgyMTMzZjM0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CE1AA4C2619D4CE9808FB2E03227EEAFamazoncom_-- From nobody Tue Feb 18 03:17:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311C21202DD for ; Tue, 18 Feb 2020 03:17:04 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coil.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8J1q4U-7Uat for ; Tue, 18 Feb 2020 03:17:00 -0800 (PST) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 25479120639 for ; Tue, 18 Feb 2020 03:17:00 -0800 (PST) Received: by mail-ed1-x544.google.com with SMTP id dc19so24327222edb.10 for ; Tue, 18 Feb 2020 03:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=suZM4wyxA/htVw6K5Jr8keYuPLZNEiYaDd+Cv0oiUaM=; b=HSfDjiqOpU8fhrhP1P/HZuvs7Xra6KsuvhCfOOzE1zTeJKxmBu+QSiIaH5pe8Mkx7z DhLZZHbNyj2dIIT5ZfIgK70v8BQTfz4Pg2punWrEPDMp9BNxaP7AfIVoeE5EtE9BcJAV 4XvKVGbUZYMwbQBudKRccKJ57CSQf34WQd3i1Thn1ImLMyo+EPEcgtAk/s75ZxR9Ng5p 4CyfKxOSFCYVuv+ZlYSEK0kyDxY8gSnXvP/olfX8yqQ717R06jsicV3fMWWW7HB+dhQe LhbRZadMXlvyumEAoa9fyOqDIFoT+982KtxthtWUHlJNGY7P0FU0CXp1O3rBD2KcAzjL iIPg== 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=suZM4wyxA/htVw6K5Jr8keYuPLZNEiYaDd+Cv0oiUaM=; b=m8nddTROyV1N7DKRlXnZW2ilcBDMP4PpSSimLsPCKBXd8CXn5N5NGUMMRz4NDIvX5r VPHJsL4BFzOuPwE+n2BPc55v8DLhfcrU1NUqcZ0ZAlNj95TC0ODBkjBvljYZnqwKF61G zziBidqTgfRH2ap6IxzVal1PlZ0Ath//1NGPGnI4e4IPlCNyRny9ZZc0ziUInWxCBFd1 nMnp7QZNN4b0Vyb+D5uP4gEzjdiwuq7NEKYWnklV8UmiZl8vL4dNyi21WJXyMIVNobAV ALSdQzb3/KBrSx0Vl2OoqeLypCV/hE6fLT+YEbQ+eCNHQRrZVMKnivh5bM3C3Chtj82+ J7yw== X-Gm-Message-State: APjAAAXynPHQ8JQowzmowsXWnW2bnExq9dK+ohH2W6IGX82Kk4S+JbdW ismi/LpnEseCGckXYuLykVqDWp+sirug7UYTv6p50D7onb/mUg== X-Google-Smtp-Source: APXvYqxLAd7WbNkzEPJuP3JjF0mdfFqAOi+aEQoPAMiLnH26Fq/gd1GQVtMSUI1ZYfhNfBYUDHybRssMElY5Sp8/Aho= X-Received: by 2002:a17:906:f753:: with SMTP id jp19mr19888461ejb.121.1582024617779; Tue, 18 Feb 2020 03:16:57 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: From: Matthew De Haast Date: Tue, 18 Feb 2020 13:16:44 +0200 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e73d3059ed7cfc3" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 11:17:04 -0000 --0000000000005e73d3059ed7cfc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for this Dick. Appreciate the draft to be able to compare ideas to XYZ. The rational section also helped as it answered some of the questions I was going to ask. 1. OPTIONS for metadata. I really like this way of asking for metadata on the resources. 2. We have both the Read Grant endpoint and then an explicit Token Refresh endpoint? Is it not possible that if a client wanted to refresh the tokens it could just do a Read against the grant? Thinking aloud, the biggest issue with what I propose is token lifecycle and how to handle that. 3. 5.5.4 Authorization Object. one of the following values: "oauth_scope" or "oauth_rich" Is there a specific reason to try support both methods? I would prefer this to be collapsed to a singular new definition for authorization, similar to RAR, to reduce confusion. 4. 4. Grant and Authz Lifecycle > At any point in time, there can only be one Grant for the GS, Client, > and User tuple. > > The Grant/Authz lifecycle isn't clear for our use-case. How would the current API handle a client getting one time authz to perform singular financial transactions? There could be multiple of these auths for a single client at the same time. 5. I am also in agreement with Annabelle that it seems better for the Client to inform the GS on what interactions are possible and let the GS decide. Matt On Tue, Feb 18, 2020 at 4:26 AM Richard Backman, Annabelle wrote: > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, February 17, 2020 at 4:22 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] XAuth -02 > > > > > > > > On Fri, Feb 14, 2020 at 6:29 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > > > > > There are lots of reasons for wanting to support multiple modes: > > =C2=B7 Some people are comfortable with QR codes, some aren=E2=80=99= t. > > =C2=B7 Some people have smart phones that can scan them, some don=E2= =80=99t. > > =C2=B7 People with smart phones may want to go through the authentic= ation > flow on their desktop instead. > > =C2=B7 Some people may *have* to go through the authentication flow = on > their desktop, because the GS thinks iPhones only support Bluetooth-based > security keys and insists they cannot complete the login flow even though > they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT > PROTECTION PROGRAM) > > All of your examples are choices for the User, which the Client would nee= d > to present to the User. > > > > Per my comment above based on your suggestion, "qrcode" also shows the > "code" information, which satisfies all your suggestions above. > > > > [richanna] > > Yes, I am justifying the value of allowing Clients to request and present > multiple interaction methods by providing these are some examples of case= s > where it provides clear benefit to the end user. You can see this > implemented in the AWS CLI v2=E2=80=99s support for AWS SSO. And =E2=80= =9CScan this code> or =E2=80=9D is a pretty common pattern for= anything > involving QR codes. Where did you suggest that the =E2=80=9Cqrcode=E2=80= =9D interaction > object would include the code information? Are you referring to your > comment proposing a =E2=80=9Ctext only interaction type=E2=80=9D? That co= mment sounded like > an either/or to me, as in the Client could opt for the text-only > interaction that provides them the code or the qrcode interaction that > provides them a short URL, not both. > > [/richanna] > > > > > > > > I checked what popular sites listed at > https://ahrefs.com/blog/most-visited-websites/ use: > > > - sites that use popups > > - pinterest > > - expedia > > - tripadvisor > > - nytimes > > - indeed.com > > - quora > > - redfin > > - trulia > > > > - sites that use a full page redirect > > - IMDB - an Amazon property =3D) > > > > Looks like most sites prefer popups and have figured out how to do it -- > except IMDB. > > > > [richanna] > > I just tried using Google Sign In on Pinterest, Expedia, and IMDb, when > accessed via a link in a Facebook post in the Facebook app. Guess which o= ne > worked and which two didn=E2=80=99t? =F0=9F=98=83 This perfectly illustra= tes my point that > popups are unreliable, and can fail in weird ways. > > [/richanna] > > > > > > Also, it=E2=80=99s 2020. Stop branching on mobile vs.. desktop. I get tha= t lots of > people still do that, but that doesn=E2=80=99t mean the protocol should c= ater to it. > > > > Mobile and desktop are different though. They don't offer the same > experiences. > > > > On mobile, a GS may have a mobile app that can receive push notifications= . > The security parameters are different. > > > > Some implementations will want to know which platform is being used. We > should not remove that signal for them. > > > > [richanna] > > My comment was aimed at the implication that Clients might opt to use a > popup interaction mode on =E2=80=9Cdesktop=E2=80=9D but do something diff= erent (e.g., > redirect) on mobile. In any case, if the Client is implementing redirect > for mobile anyway, then it is not much work for them to wrap that in a > popup if they really want that experience on desktop. > > [/richanna] > > > > And again, a Client that really wants to give themselves a headache with > popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They= just have to > provide a landing page for the GS to redirect back to that parses the > response, passes it back to the main window, and closes itself. I don=E2= =80=99t see > why the protocol would need to explicitly describe this mechanism. > > [/richanna] > > > > I think it is a useful signal for the GS in the experience it wants to > show the user. > > > > [richanna] > > Useful how? The window dimensions are a better signal for how to present > the user experience. (*cough* responsive design *cough*) > > [/richanna] > > > > Responsive design is one way to address things. Lots of apps still have a= n > m.example.com site for mobile content. > > > > Our goal is not to decide how an app should build a user experience. We > should give them as much useful signal as they may need to make their own > choices. > > > > [richanna] > > What signal though? What useful information does the GS get out of knowin= g > that the Client intends to open the interaction URI in a popup, that it > doesn=E2=80=99t already have more accurate sources for? I mentioned respo= nsive > design because the only thing I can think of is that it might inform how > the GS presents the sign in experience, but =E2=80=9Cpopup=E2=80=9D on it= s own doesn=E2=80=99t > necessarily mean it will be a small or portrait-dimensioned window. So th= e > GS is still just guessing until it=E2=80=99s actually loaded in the popup= , and at > that point it can check the actual window dimensions and use CSS media > queries, etc. > > [/richanna] > > > > > > > > 3. How long should the GS wait for the Client to make the Update Grant > request in 3.4? What should the GS do if that never happens? What is the > path forward for the end user, at that point? > > > > 3.1 has the GS waiting for the Client as well. All the same questions > apply to any aspect of the protocol where one party does not do the next > step. The User is the most likely party to not continue. What do the GS a= nd > Client do if the User has been sent to the GS, but walks away from their > device? > > > > [richanna] > > In step 3.4, steps 6 through 8, the GS returns the Read Grant response > (6), the Client evaluates it (7), and then the Client makes an Update Gra= nt > request to the GS (8). Throughout this time, the end user is sitting at t= he > GS=E2=80=A6watching a spinner, I guess? How long does the AS wait for the= Update > Grant request? What if it never comes? I=E2=80=99m not talking about the = end user > walking away, I=E2=80=99m talking about the Client failing to tell the GS= to > advance the flow. > > [/richanna] > > > > > > > > The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for th= e Client to > maintain a persistent, asynchronous process to make that API call. > > > > The 3.1 flow, and all the XYZ flows where there is no redirect all have > the same requirement of the Client. > > > > An async call to a server is pretty straight forward in all modern web > languages. > > > > If the Client is a mobile app put to sleep, it can remake the call to the > GS and get the results in a 3.1 flow. > > > > [richanna] > > It=E2=80=99s not just an async call to a server, it=E2=80=99s an async ca= ll initiated > while handling an HTTP request and that survives the completion of that > request. This is not trivial, and even where there are tools to help with > this they are often full of sharp edges and introduce fun new failure mod= es > (Does your implementation fail fast when your async thread pool gets > exhausted? No? Better hope your users like 503s=E2=80=A6). > > > > I suggest a separate thread for this one as well. > > [/richanna] > > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005e73d3059ed7cfc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this Dic= k. Appreciate the draft to be able to compare ideas to XYZ. The rational se= ction also helped as it answered some of the questions I was going to ask.<= /div>

1. OPTIONS for metadata. I really like this way of= asking for metadata on the resources.

2. We have = both the Read Grant endpoint and then an explicit Token Refresh endpoint? I= s it not possible that if a client wanted to refresh the tokens it could ju= st do a Read against the grant? Thinking aloud, the biggest issue with what= I propose is token lifecycle and how to handle that.

3. 5.5.4 Authorization Object.
one of the following values: "oauth_scope" or
      "oauth_rich"
Is there a specific reason to = try support both methods? I would prefer this to be collapsed to a singular= new definition for authorization, similar to RAR, to reduce confusion.

4. 4. Grant and Authz Lifecycle
At any =
point in time, there can only be one Grant for the GS, Client,
   and User tuple.
The Grant/Authz lifecycle i= sn't clear for our use-case. How would the current API handle a client = getting one time authz to perform singular financial transactions? There co= uld be multiple of these auths for a single client at the same time.

5. I am also in agreement with Annabelle that it see= ms better for the Client to inform the GS on what interactions are possible= and let the GS decide.

Matt

On Tue, Feb 18, 2020 at 4:26 AM Richard Backman, Annabel= le <richanna=3D40amazon.c= om@dmarc.ietf.org> wrote:

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Monday, February 17, 2020 at 4:22 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] XAuth -02

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 14, 2020 at = 6:29 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

=C2=A0

<snip>

There are lots of reasons for wanting to support multiple modes:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people are comfortable with QR codes, some= aren=E2=80=99t.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people have smart phones that can scan the= m, some don=E2=80=99t.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 People with smart phones may want to go through= the authentication flow on their desktop instead.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people may have to go through the a= uthentication flow on their desktop, because the GS thinks iPhones only sup= port Bluetooth-based security keys and insists they cannot complete the log= in flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROG= RAM)

All of your examples are= choices for the User, which the Client would need to present to the User.= =C2=A0

=C2=A0

Per my comment above bas= ed on your suggestion, "qrcode" also shows the "code" i= nformation, which satisfies all your suggestions above.

=C2=A0

[richanna]

Yes, I am justifying the value of allowing Clients t= o request and present multiple interaction methods by providing these are s= ome examples of cases where it provides clear benefit to the end user. You = can see this implemented in the AWS CLI v2=E2=80=99s support for AWS SSO. And =E2=80=9CScan this <QR code&g= t; or <alternate instructions>=E2=80=9D is a pretty common pattern fo= r anything involving QR codes. Where did you suggest that the =E2=80=9Cqrco= de=E2=80=9D interaction object would include the code information? Are you = referring to your comment proposing a =E2=80=9Ctext only interaction type=E2=80=9D? = That comment sounded like an either/or to me, as in the Client could opt fo= r the text-only interaction that provides them the code or the qrcode inter= action that provides them a short URL, not both.

[/richanna]

=C2=A0

<snip>

=C2=A0

I checked what popular s= ites listed at https://ahrefs.com/blog/most-visited-websites/ use:


- sites that use popups

- pinterest

- expedia<= /p>

- tripadvisor<= /u>

- nytimes<= /p>

- quora

- redfin

- trulia

=C2=A0

- sites that use a full = page redirect

- IMDB - an Amazon prope= rty =3D)

=C2=A0

Looks like most sites pr= efer popups and have figured out how to do it -- except IMDB.=

=C2=A0

[richanna]

I just tried using Google Sign In on Pinterest, Expe= dia, and IMDb, when accessed via a link in a Facebook post in the Facebook = app. Guess which one worked and which two didn=E2=80=99t? =F0=9F=98=83 This perfectly illustrates my point that popups are unreliable, and can = fail in weird ways.

[/richanna]

=C2=A0

=C2=A0

Also, it=E2=80=99s 2020. Stop branching on mobile vs.. desktop. I get that = lots of people still do that, but that doesn=E2=80=99t mean the protocol sh= ould cater to it.

=C2=A0

Mobile and desktop are d= ifferent though. They don't offer the same experiences.

=C2=A0

On mobile, a GS may have= a mobile app that can receive push notifications. The security parameters = are different.

=C2=A0

Some implementations wil= l want to know which platform is being used. We should not remove that sign= al for them.=C2=A0

=C2=A0

[richanna]

My comment was aimed at the implication that Clients= might opt to use a popup interaction mode on =E2=80=9Cdesktop=E2=80=9D but= do something different (e.g., redirect) on mobile. In any case, if the Cli= ent is implementing redirect for mobile anyway, then it is not much work for them to wrap that in a popup if they really want t= hat experience on desktop.

[/richanna]

=C2=A0

And again, a Client that really wants to give themselves a headache with po= pups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They jus= t have to provide a landing page for the GS to redirect back to that parses= the response, passes it back to the main window, and closes itself. I don=E2=80=99t see why the protocol would need to expl= icitly describe this mechanism.=C2=A0

[/richanna]

=C2=A0

I think it is a useful signal for the GS in the experience it wants to show= the user.

=C2=A0

[richanna]

Useful how? The window dimensions are a better signal for how to present th= e user experience. (*cough* responsive design *cough*)

[/richanna]

=C2=A0

Responsive design is one= way to address things. Lots of apps still have an m.example.com site f= or mobile content.

=C2=A0

Our goal is not to decid= e how an app should build a user experience. We should give them as much us= eful signal as they may need to make their own choices.

=C2=A0

[richanna]

What signal though? What useful information does the= GS get out of knowing that the Client intends to open the interaction URI = in a popup, that it doesn=E2=80=99t already have more accurate sources for?= I mentioned responsive design because the only thing I can think of is that it might inform how the GS presents the = sign in experience, but =E2=80=9Cpopup=E2=80=9D on its own doesn=E2=80=99t = necessarily mean it will be a small or portrait-dimensioned window. So the = GS is still just guessing until it=E2=80=99s actually loaded in the popup, and at that point it can check the actual window dimensions and= use CSS media queries, etc.

[/richanna]

=C2=A0

<snip>

=C2=A0

3.=C2=A0= =C2=A0 How long should the GS wait for the Client to make the= Update Grant request in 3.4? What should the GS do if that never happens? = What is the path forward for the end user, at that point?

=C2=A0

3.1 has the GS waiting f= or the Client as well. All the same questions apply to any aspect of the pr= otocol where one party does not do the next step. The User is the most like= ly party to not continue. What do the GS and Client do if the User has been sent to the GS, but walks away from = their device?

=C2=A0

[richanna]

In step 3.4, steps 6 through 8, the GS returns the R= ead Grant response (6), the Client evaluates it (7), and then the Client ma= kes an Update Grant request to the GS (8). Throughout this time, the end us= er is sitting at the GS=E2=80=A6watching a spinner, I guess? How long does the AS wait for the Update Grant request? = What if it never comes? I=E2=80=99m not talking about the end user walking = away, I=E2=80=99m talking about the Client failing to tell the GS to advanc= e the flow.

[/richanna]

=C2=A0

<snip>

=C2=A0

The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for the = Client to maintain a persistent, asynchronous process to make that API call= .

=C2=A0

The 3.1 flow, and all th= e XYZ flows where there is no redirect all have the same requirement of the= Client.

=C2=A0

An async call to a serve= r is pretty straight forward in all modern web languages.

=C2=A0

If the Client is a mobil= e app put to sleep, it can remake the call to the GS and get the results in= a 3.1 flow.=C2=A0

=C2=A0

[richanna]

It=E2=80=99s not just an async call to a server, it= =E2=80=99s an async call initiated while handling an HTTP request and that = survives the completion of that request. This is not trivial, and even wher= e there are tools to help with this they are often full of sharp edges and introduce fun new failure modes (Does your impleme= ntation fail fast when your async thread pool gets exhausted? No? Better ho= pe your users like 503s=E2=80=A6).

=C2=A0

I suggest a separate thread for this one as well.=

[/richanna]

=E1=90=A7

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000005e73d3059ed7cfc3-- From nobody Tue Feb 18 11:03:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826AD12001E for ; Tue, 18 Feb 2020 11:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Lk56mtZXVq3s for ; Tue, 18 Feb 2020 11:03:26 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3029012007C for ; Tue, 18 Feb 2020 11:03:26 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id o15so24259389ljg.6 for ; Tue, 18 Feb 2020 11:03:26 -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=2QW4wKB7Aw3+aSLoDhZw3cvTrh4IFzUI9TbPcFk5Aq4=; b=YgWuovPxvKnH+QM5DGjZqPFo4PsP3Choh2cpX++aZscCY1z2Oe0kPptnxxYuqkcbV6 eXl/hGRhVQ2gcsqMWIkjk4rNgi3OlukdiDwGgKdDTcj95WZ0AVAZXaC8HEcPZSMt22Zu dCAA1Tmp8gzw5tvcYaR4/BVnuZYDk1XTokOa2TPdYa14m6tTDpOmVJq0+WjrWt7ntfNy NwdvLh7ITW3c7RPwx9xgQYpB13JSDbezBs2nk05w3L31Fer+fxdgbCQtgCTW1aEDX5Gs 00pf51+HxOHuz54lBlIWwhAbYhXvz2aIL70VL9BJP21Nmnoo3jMkw1qSiDStKenvdSkr oefQ== 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=2QW4wKB7Aw3+aSLoDhZw3cvTrh4IFzUI9TbPcFk5Aq4=; b=bNyyMhlCaSGlxzFJTuXJyuMbSBwq2x2sgdLDY7efT4KxlHD2Nrg4fRcBFgPPV/wc4e kK1SW1bQ+U2MqZJokKXFR9Y04g8ZomrHt9aatHMOO45yy3mjkBgbQtFXWjnihK0Ei5nX ptmxfXThUmYTUK577AanX9GaEM3hDX084+W8xsnoJqr1pMBLjdVY32uUia9REQDdxbav 4a8maVAlcANss7KW5Ln+3uWIRmLCAI4mkp439O/dUTETq4XTMK53hGRRuuLjSZ9/YPFd i6qLFEpbgCS9EqQTZutfgmeDgVAnqvJGN7ScUy1kLFSInRLQaNrrjfKp5YRzevvEWuZj 5Skw== X-Gm-Message-State: APjAAAVIICqf1VeG9nB0udx3zcLjnRIbH/r7xnacgvlEIUllfEJw/ahr ZGf9AKQkYKJDDZQhYS1lVVonEpgv8ONaMLo8fm7yrM0WxEI= X-Google-Smtp-Source: APXvYqxbnQSyxHFiV6HvG3THVE0ZzTxnm81X/TtRBSBN7UOM+Lpq799Gl4+SusxFQtkhUvRy8SjMTF8q2uX1FIAZgPw= X-Received: by 2002:a2e:730e:: with SMTP id o14mr14003309ljc.51.1582052604228; Tue, 18 Feb 2020 11:03:24 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: From: Dick Hardt Date: Tue, 18 Feb 2020 11:02:57 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007dba8a059ede530e" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:03:31 -0000 --0000000000007dba8a059ede530e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 17, 2020 at 6:26 PM Richard Backman, Annabelle wrote: > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, February 17, 2020 at 4:22 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] XAuth -02 > > > > > > > > On Fri, Feb 14, 2020 at 6:29 PM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > > > > > > There are lots of reasons for wanting to support multiple modes: > > =C2=B7 Some people are comfortable with QR codes, some aren=E2=80=99= t. > > =C2=B7 Some people have smart phones that can scan them, some don=E2= =80=99t. > > =C2=B7 People with smart phones may want to go through the authentic= ation > flow on their desktop instead. > > =C2=B7 Some people may *have* to go through the authentication flow = on > their desktop, because the GS thinks iPhones only support Bluetooth-based > security keys and insists they cannot complete the login flow even though > they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT > PROTECTION PROGRAM) > > All of your examples are choices for the User, which the Client would nee= d > to present to the User. > > > > Per my comment above based on your suggestion, "qrcode" also shows the > "code" information, which satisfies all your suggestions above. > > > > [richanna] > > Yes, I am justifying the value of allowing Clients to request and present > multiple interaction methods by providing these are some examples of case= s > where it provides clear benefit to the end user. You can see this > implemented in the AWS CLI v2=E2=80=99s support for AWS SSO. And =E2=80= =9CScan this code> or =E2=80=9D is a pretty common pattern for= anything > involving QR codes. Where did you suggest that the =E2=80=9Cqrcode=E2=80= =9D interaction > object would include the code information? Are you referring to your > comment proposing a =E2=80=9Ctext only interaction type=E2=80=9D? That co= mment sounded like > an either/or to me, as in the Client could opt for the text-only > interaction that provides them the code or the qrcode interaction that > provides them a short URL, not both. > > [/richanna] > Yes, I thought I had included a link to the section in the latest I have yet to publish. https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protocol= .html#name-interaction-types "qrcode"- A QR Code and a user code with URL to navigate to "code"- A user code with URL to navigate to > > > > > > I checked what popular sites listed at > https://ahrefs.com/blog/most-visited-websites/ use: > > > - sites that use popups > > - pinterest > > - expedia > > - tripadvisor > > - nytimes > > - indeed.com > > - quora > > - redfin > > - trulia > > > > - sites that use a full page redirect > > - IMDB - an Amazon property =3D) > > > > Looks like most sites prefer popups and have figured out how to do it -- > except IMDB. > > > > [richanna] > > I just tried using Google Sign In on Pinterest, Expedia, and IMDb, when > accessed via a link in a Facebook post in the Facebook app. Guess which o= ne > worked and which two didn=E2=80=99t? =F0=9F=98=83 This perfectly illustra= tes my point that > popups are unreliable, and can fail in weird ways. > > [/richanna] > Your scenario is a little terse for me to follow, but it does not really matter. Most large site are happy with doing a popup. Who are we to tell them not too? Your criticism is that it might not always work. It would be different is there was a security vulnerability, but that is not what I am understanding from your criticism. > > > > > Also, it=E2=80=99s 2020. Stop branching on mobile vs.. desktop. I get tha= t lots of > people still do that, but that doesn=E2=80=99t mean the protocol should c= ater to it. > > > > Mobile and desktop are different though. They don't offer the same > experiences. > > > > On mobile, a GS may have a mobile app that can receive push notifications= . > The security parameters are different. > > > > Some implementations will want to know which platform is being used. We > should not remove that signal for them. > > > > [richanna] > > My comment was aimed at the implication that Clients might opt to use a > popup interaction mode on =E2=80=9Cdesktop=E2=80=9D but do something diff= erent (e.g., > redirect) on mobile. In any case, if the Client is implementing redirect > for mobile anyway, then it is not much work for them to wrap that in a > popup if they really want that experience on desktop. > > [/richanna] > > > > And again, a Client that really wants to give themselves a headache with > popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They= just have to > provide a landing page for the GS to redirect back to that parses the > response, passes it back to the main window, and closes itself. I don=E2= =80=99t see > why the protocol would need to explicitly describe this mechanism. > > [/richanna] > > > > I think it is a useful signal for the GS in the experience it wants to > show the user. > > > > [richanna] > > Useful how? The window dimensions are a better signal for how to present > the user experience. (*cough* responsive design *cough*) > > [/richanna] > > > > Responsive design is one way to address things. Lots of apps still have a= n > m.example.com site for mobile content. > > > > Our goal is not to decide how an app should build a user experience. We > should give them as much useful signal as they may need to make their own > choices. > > > > [richanna] > > What signal though? What useful information does the GS get out of knowin= g > that the Client intends to open the interaction URI in a popup, that it > doesn=E2=80=99t already have more accurate sources for? I mentioned respo= nsive > design because the only thing I can think of is that it might inform how > the GS presents the sign in experience, but =E2=80=9Cpopup=E2=80=9D on it= s own doesn=E2=80=99t > necessarily mean it will be a small or portrait-dimensioned window. So th= e > GS is still just guessing until it=E2=80=99s actually loaded in the popup= , and at > that point it can check the actual window dimensions and use CSS media > queries, etc. > > [/richanna] > > > > > In XAuth I am proposing that the GS closes the popup window. One less thing for a Client to do, and and negates any communication issue between the popup and the main window. A Client using a popup may be a useful signal for the GS in doing threat and risk analysis. > > > 3. How long should the GS wait for the Client to make the Update Grant > request in 3.4? What should the GS do if that never happens? What is the > path forward for the end user, at that point? > > > > 3.1 has the GS waiting for the Client as well. All the same questions > apply to any aspect of the protocol where one party does not do the next > step. The User is the most likely party to not continue. What do the GS a= nd > Client do if the User has been sent to the GS, but walks away from their > device? > > > > [richanna] > > In step 3.4, steps 6 through 8, the GS returns the Read Grant response > (6), the Client evaluates it (7), and then the Client makes an Update Gra= nt > request to the GS (8). Throughout this time, the end user is sitting at t= he > GS=E2=80=A6watching a spinner, I guess? How long does the AS wait for the= Update > Grant request? What if it never comes? I=E2=80=99m not talking about the = end user > walking away, I=E2=80=99m talking about the Client failing to tell the GS= to > advance the flow. > > [/richanna] > 1) 3.4 is for a sophisticated Client that wants to incrementally ask for authorization from the GS, and a GS that supports it. 2) There are lots of web apps that call a backend service and are waiting for something to complete. So yes, the GS would let the User know it is waiting. 3) How long to wait? Whatever the GS thinks is reasonable, and not any different than other experiences where the app is waiting for a backend process. 4) The same situation can happen in 3.1. Steps (4) and (5) can happen independent of each other. Step (5) could happen sometime after Step (7), in which case the User is waiting for the Client to call. My point about the User walking away is that there are numerous ways for the protocol to not complete. > > > > > > > The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for th= e Client to > maintain a persistent, asynchronous process to make that API call. > > > > The 3.1 flow, and all the XYZ flows where there is no redirect all have > the same requirement of the Client. > > > > An async call to a server is pretty straight forward in all modern web > languages. > > > > If the Client is a mobile app put to sleep, it can remake the call to the > GS and get the results in a 3.1 flow. > > > > [richanna] > > It=E2=80=99s not just an async call to a server, it=E2=80=99s an async ca= ll initiated > while handling an HTTP request and that survives the completion of that > request. This is not trivial, and even where there are tools to help with > this they are often full of sharp edges and introduce fun new failure mod= es > (Does your implementation fail fast when your async thread pool gets > exhausted? No? Better hope your users like 503s=E2=80=A6). > > > > I suggest a separate thread for this one as well. > I don't understand why you think an async pool is needed. A dumb Client can syncronously make a call, wait for a response, and then make the next call. The code in a GS is more complicated, as it needs to coordinate calls from the Client with interactions with the User, but that is the case in 3.1 as well. > [/richanna] > > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > =E1=90=A7 --0000000000007dba8a059ede530e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 17, 2020 at 6:26 PM Richa= rd Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Monday, February 17, 2020 at 4:22 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] XAuth -02

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 14, 2020 at = 6:29 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

=C2=A0

<snip>

There are lots of reasons for wanting to support multiple modes:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people are comfortable with QR codes, some= aren=E2=80=99t.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people have smart phones that can scan the= m, some don=E2=80=99t.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 People with smart phones may want to go through= the authentication flow on their desktop instead.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people may have to go through the a= uthentication flow on their desktop, because the GS thinks iPhones only sup= port Bluetooth-based security keys and insists they cannot complete the log= in flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROG= RAM)

All of your examples are= choices for the User, which the Client would need to present to the User.= =C2=A0

=C2=A0

Per my comment above bas= ed on your suggestion, "qrcode" also shows the "code" i= nformation, which satisfies all your suggestions above.

=C2=A0

[richanna]

Yes, I am justifying the value of allowing Clients t= o request and present multiple interaction methods by providing these are s= ome examples of cases where it provides clear benefit to the end user. You = can see this implemented in the AWS CLI v2=E2=80=99s support for AWS SSO. And =E2=80=9CScan this <QR code&g= t; or <alternate instructions>=E2=80=9D is a pretty common pattern fo= r anything involving QR codes. Where did you suggest that the =E2=80=9Cqrco= de=E2=80=9D interaction object would include the code information? Are you = referring to your comment proposing a =E2=80=9Ctext only interaction type=E2=80=9D? = That comment sounded like an either/or to me, as in the Client could opt fo= r the text-only interaction that provides them the code or the qrcode inter= action that provides them a short URL, not both.

[/richanna]


Yes, I thought I had included a link to the secti= on in the latest I have yet to publish.

= =C2=A0
"qrcode"- A QR Code and a user code with URL to = navigate to

"code"- A user code wit= h URL to navigate to

=C2=A0

<snip>

=C2=A0

I checked what popular s= ites listed at https://ahrefs.com/blog/most-visited-websites/ use:


- sites that use popups

- pinterest

- expedia<= /p>

- tripadvisor<= /u>

- nytimes<= /p>

- quora

- redfin

- trulia

=C2=A0

- sites that use a full = page redirect

- IMDB - an Amazon prope= rty =3D)

=C2=A0

Looks like most sites pr= efer popups and have figured out how to do it -- except IMDB.=

=C2=A0

[richanna]

I just tried using Google Sign In on Pinterest, Expe= dia, and IMDb, when accessed via a link in a Facebook post in the Facebook = app. Guess which one worked and which two didn=E2=80=99t? =F0=9F=98=83 This perfectly illustrates my point that popups are unreliable, and can = fail in weird ways.

[/richanna]

<= br>
Your scenario is a little terse for me to follow, but it does= not really matter. Most large site are happy with doing a popup. Who are w= e to tell them not too?=C2=A0

Your criticism is th= at it might not always work. It would be different is there was a security = vulnerability, but that is not what I am understanding from your criticism.= =C2=A0



=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
<= div>

=C2=A0

=C2=A0

Also, it=E2=80=99s 2020. Stop branching on mobile vs.. desktop. I get that = lots of people still do that, but that doesn=E2=80=99t mean the protocol sh= ould cater to it.

=C2=A0

Mobile and desktop are d= ifferent though. They don't offer the same experiences.

=C2=A0

On mobile, a GS may have= a mobile app that can receive push notifications. The security parameters = are different.

=C2=A0

Some implementations wil= l want to know which platform is being used. We should not remove that sign= al for them.=C2=A0

=C2=A0

[richanna]

My comment was aimed at the implication that Clients= might opt to use a popup interaction mode on =E2=80=9Cdesktop=E2=80=9D but= do something different (e.g., redirect) on mobile. In any case, if the Cli= ent is implementing redirect for mobile anyway, then it is not much work for them to wrap that in a popup if they really want t= hat experience on desktop.

[/richanna]

=C2=A0

And again, a Client that really wants to give themselves a headache with po= pups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They jus= t have to provide a landing page for the GS to redirect back to that parses= the response, passes it back to the main window, and closes itself. I don=E2=80=99t see why the protocol would need to expl= icitly describe this mechanism.=C2=A0

[/richanna]

=C2=A0

I think it is a useful signal for the GS in the experience it wants to show= the user.

=C2=A0

[richanna]

Useful how? The window dimensions are a better signal for how to present th= e user experience. (*cough* responsive design *cough*)

[/richanna]

=C2=A0

Responsive design is one= way to address things. Lots of apps still have an m.example.com site f= or mobile content.

=C2=A0

Our goal is not to decid= e how an app should build a user experience. We should give them as much us= eful signal as they may need to make their own choices.

=C2=A0

[richanna]

What signal though? What useful information does the= GS get out of knowing that the Client intends to open the interaction URI = in a popup, that it doesn=E2=80=99t already have more accurate sources for?= I mentioned responsive design because the only thing I can think of is that it might inform how the GS presents the = sign in experience, but =E2=80=9Cpopup=E2=80=9D on its own doesn=E2=80=99t = necessarily mean it will be a small or portrait-dimensioned window. So the = GS is still just guessing until it=E2=80=99s actually loaded in the popup, and at that point it can check the actual window dimensions and= use CSS media queries, etc.

[/richanna]

=C2=A0

<snip>


In XAuth I am proposing that the GS closes the p= opup window. One less thing for a Client to do, and and negates any communi= cation issue between the popup and the main window.

A Client using a popup may be a useful signal for the GS in doing threat = and risk analysis.=C2=A0

=C2=A0

=C2=A0

3.=C2=A0= =C2=A0 How long should the GS wait for the Client to make the= Update Grant request in 3.4? What should the GS do if that never happens? = What is the path forward for the end user, at that point?

=C2=A0

3.1 has the GS waiting f= or the Client as well. All the same questions apply to any aspect of the pr= otocol where one party does not do the next step. The User is the most like= ly party to not continue. What do the GS and Client do if the User has been sent to the GS, but walks away from = their device?

=C2=A0

[richanna]

In step 3.4, steps 6 through 8, the GS returns the R= ead Grant response (6), the Client evaluates it (7), and then the Client ma= kes an Update Grant request to the GS (8). Throughout this time, the end us= er is sitting at the GS=E2=80=A6watching a spinner, I guess? How long does the AS wait for the Update Grant request? = What if it never comes? I=E2=80=99m not talking about the end user walking = away, I=E2=80=99m talking about the Client failing to tell the GS to advanc= e the flow.

[/richanna]


1) 3.4 is for a sophisticated Client that wants t= o incrementally ask for authorization from the GS, and a GS that supports i= t.=C2=A0

2) There are lots of web apps that call a= backend service and are waiting for something to complete. So yes, the GS = would let the User know it is waiting.

3) How long= to wait? Whatever the GS thinks is reasonable, and not any different than = other experiences where the app is waiting for a backend process.

4) The same situation can happen in 3.1. Steps (4) and (5) = can happen independent of each other. Step (5) could happen sometime after = Step (7), in which case the User is waiting for the Client to call.=C2=A0

My point about the User walking away is that there = are numerous ways for the protocol to not complete.=C2=A0

=C2=A0

=C2=A0

<snip>

=C2=A0

The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for the = Client to maintain a persistent, asynchronous process to make that API call= .

=C2=A0

The 3.1 flow, and all th= e XYZ flows where there is no redirect all have the same requirement of the= Client.

=C2=A0

An async call to a serve= r is pretty straight forward in all modern web languages.

=C2=A0

If the Client is a mobil= e app put to sleep, it can remake the call to the GS and get the results in= a 3.1 flow.=C2=A0

=C2=A0

[richanna]

It=E2=80=99s not just an async call to a server, it= =E2=80=99s an async call initiated while handling an HTTP request and that = survives the completion of that request. This is not trivial, and even wher= e there are tools to help with this they are often full of sharp edges and introduce fun new failure modes (Does your impleme= ntation fail fast when your async thread pool gets exhausted? No? Better ho= pe your users like 503s=E2=80=A6).

=C2=A0

I suggest a separate thread for this one as well.


I don't= understand why you think an async pool is needed. A dumb Client can syncro= nously make a call, wait for a response, and then make the next call.
=

The code in a GS is more complicated, as it needs to co= ordinate calls from the Client with interactions with the User, but that is= the case in 3.1 as well.

=C2=A0

[/richanna]

=E1=90=A7<= /p>

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7
--0000000000007dba8a059ede530e-- From nobody Tue Feb 18 11:14:38 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056B1200FB for ; Tue, 18 Feb 2020 11:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CAe3Rnc3GzRK for ; Tue, 18 Feb 2020 11:14:32 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450: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 8ACC212001E for ; Tue, 18 Feb 2020 11:14:31 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id n20so250367lfa.2 for ; Tue, 18 Feb 2020 11:14:31 -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=dTNvz9RyMk5fojkEPvmB5KUP5e14E1F5nCT5eWdZV5o=; b=HD8guAuYEbLeW2RWZ1MyhPpYiIqBkmMq0niW2nnHKb3ZDLMKN/oB2W0atFJhd0YG2y jjRXe08j9O6+uqoLwmTbRPNQLSxEILmYukBtGW7oAKcVkI3RyzKNE1w3zkZplbEoenXA gKe3jfD6kyPw082acO40xeiL5bQ0Kzw/ede7D91SlSziKLNxtXsPWgEKjQ22gxF8Ma4p Ot3b3RAqL2PtSHEc6n/8mocIx1+Do28zkAVW32BUGqPQlV2n/3EP9bpxPczprQ484T2F uJH1nzHc/3WdTTRzgoS6G5Z38qyMVEVsN69mFV9mWYppi/OhcwWk1T5YDK8cKtaUQyII jQFg== 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=dTNvz9RyMk5fojkEPvmB5KUP5e14E1F5nCT5eWdZV5o=; b=S/urVDSBr4YBVuIFG4i+iSYkKHimy9ZHwDfeFONCR11sMVGtFefO43h4l+hEes/H+X BvkRZMmVELoT1VKRe1/Q4PcDuKvWdexVqwNCDOsLeSIFZTqCjoRELMaeKYww275wMhmL lGtHAZ/zn8mUL2JBOx4yNNxV6X3JoyIAdMY9R5MEcGdiAGh8ie/YcjwPJN3yuGDf0atG 2bFLVUwHRhrA9sJ7NkMqIKATJMvL+munF0C/hb9A5qxQjv6SdRhurV8JlEHVpDS924Xp U1/UcGwZs0QfqcfeH1yaJqG0PPXW8xRd+W+gQLtUxLOoN4XN3RNJulLIOutZbk/vUFBq 5gpg== X-Gm-Message-State: APjAAAXanlvj40A+AGTms4E4NGa/2gdpMPxDkaNoT9KYqB1sY8FXMIRY Kf5k4SFHzdO9kurfXiyBnn71qi7fdNnxYCFz1BM= X-Google-Smtp-Source: APXvYqz61ZJtAq4xuZpdvQBBc53JjSwhr2AYl5/cJEBEJwHM1VhxV0rVVOVcsT3+2tlbLmVrTGWtvVNAtVDPwH1m1CI= X-Received: by 2002:a19:7711:: with SMTP id s17mr11106509lfc.164.1582053269458; Tue, 18 Feb 2020 11:14:29 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: From: Dick Hardt Date: Tue, 18 Feb 2020 11:14:03 -0800 Message-ID: To: Matthew De Haast Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000245485059ede7b7d" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 19:14:36 -0000 --000000000000245485059ede7b7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast wrote: > Thanks for this Dick. Appreciate the draft to be able to compare ideas to > XYZ. The rational section also helped as it answered some of the question= s > I was going to ask. > > 1. OPTIONS for metadata. I really like this way of asking for metadata on > the resources. > > 2. We have both the Read Grant endpoint and then an explicit Token Refres= h > endpoint? Is it not possible that if a client wanted to refresh the token= s > it could just do a Read against the grant? Thinking aloud, the biggest > issue with what I propose is token lifecycle and how to handle that. > I was thinking a read against the Grant would return everything in the Grant, which would include a refresh of all tokens, and return all claims There is the edge case where an Authorization had been deleted directly, and then what does a read of the Grant do. Does it create a new Authorization? A number of questions to explore here. We are still bouncing around ideas! > > 3. 5.5.4 Authorization Object. > > one of the following values: "oauth_scope" or > "oauth_rich" > > Is there a specific reason to try support both methods? I would prefer > this to be collapsed to a singular new definition for authorization, > similar to RAR, to reduce confusion. > My understanding of RAR was that it was scopes + authorization details. Is that not the case? The reason to have oauth_scope was to have a clear path for existing implementations to migrate to XAuth. A GS may ONLY support oauth_scope. > > 4. 4. Grant and Authz Lifecycle > >> At any point in time, there can only be one Grant for the GS, Client, >> and User tuple. >> >> The Grant/Authz lifecycle isn't clear for our use-case. How would the > current API handle a client getting one time authz to perform singular > financial transactions? There could be multiple of these auths for a sing= le > client at the same time. > If the Client knows all the AuthZs it needs, it can request them all in one Grant. If not, the Client can request multiple Grants, that each returns an Authorization. The Authorization lives on until it is used. Assuming a refresh or update of the Authorization is not needed, there is no need to return an AuthZ URI in the Grant. Is there a requirement to have each Grant continue on? > > 5. I am also in agreement with Annabelle that it seems better for the > Client to inform the GS on what interactions are possible and let the GS > decide. > Would you elaborate on why? I understand the flexibility of the Client and GS being able to negotiate, but I have yet to hear a use case where that is needed. > > Matt > > > On Tue, Feb 18, 2020 at 4:26 AM Richard Backman, Annabelle 40amazon.com@dmarc.ietf.org> wrote: > >> >> >> =E2=80=93 >> >> Annabelle Backman (she/her) >> >> AWS Identity >> >> https://aws.amazon.com/identity/ >> >> >> >> >> >> *From: *Txauth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Monday, February 17, 2020 at 4:22 PM >> *To: *"Richard Backman, Annabelle" >> *Cc: *"txauth@ietf.org" >> *Subject: *Re: [Txauth] XAuth -02 >> >> >> >> >> >> >> >> On Fri, Feb 14, 2020 at 6:29 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote: >> >> >> >> >> >> There are lots of reasons for wanting to support multiple modes: >> >> =C2=B7 Some people are comfortable with QR codes, some aren=E2=80= =99t. >> >> =C2=B7 Some people have smart phones that can scan them, some don= =E2=80=99t. >> >> =C2=B7 People with smart phones may want to go through the >> authentication flow on their desktop instead. >> >> =C2=B7 Some people may *have* to go through the authentication flow= on >> their desktop, because the GS thinks iPhones only support Bluetooth-base= d >> security keys and insists they cannot complete the login flow even thoug= h >> they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT >> PROTECTION PROGRAM) >> >> All of your examples are choices for the User, which the Client would >> need to present to the User. >> >> >> >> Per my comment above based on your suggestion, "qrcode" also shows the >> "code" information, which satisfies all your suggestions above. >> >> >> >> [richanna] >> >> Yes, I am justifying the value of allowing Clients to request and presen= t >> multiple interaction methods by providing these are some examples of cas= es >> where it provides clear benefit to the end user. You can see this >> implemented in the AWS CLI v2=E2=80=99s support for AWS SSO. And =E2=80= =9CScan this > code> or =E2=80=9D is a pretty common pattern fo= r anything >> involving QR codes. Where did you suggest that the =E2=80=9Cqrcode=E2=80= =9D interaction >> object would include the code information? Are you referring to your >> comment proposing a =E2=80=9Ctext only interaction type=E2=80=9D? That c= omment sounded like >> an either/or to me, as in the Client could opt for the text-only >> interaction that provides them the code or the qrcode interaction that >> provides them a short URL, not both. >> >> [/richanna] >> >> >> >> >> >> >> >> I checked what popular sites listed at >> https://ahrefs.com/blog/most-visited-websites/ use: >> >> >> - sites that use popups >> >> - pinterest >> >> - expedia >> >> - tripadvisor >> >> - nytimes >> >> - indeed.com >> >> - quora >> >> - redfin >> >> - trulia >> >> >> >> - sites that use a full page redirect >> >> - IMDB - an Amazon property =3D) >> >> >> >> Looks like most sites prefer popups and have figured out how to do it -- >> except IMDB. >> >> >> >> [richanna] >> >> I just tried using Google Sign In on Pinterest, Expedia, and IMDb, when >> accessed via a link in a Facebook post in the Facebook app. Guess which = one >> worked and which two didn=E2=80=99t? =F0=9F=98=83 This perfectly illustr= ates my point that >> popups are unreliable, and can fail in weird ways. >> >> [/richanna] >> >> >> >> >> >> Also, it=E2=80=99s 2020. Stop branching on mobile vs.. desktop. I get th= at lots >> of people still do that, but that doesn=E2=80=99t mean the protocol shou= ld cater to >> it. >> >> >> >> Mobile and desktop are different though. They don't offer the same >> experiences. >> >> >> >> On mobile, a GS may have a mobile app that can receive push >> notifications. The security parameters are different. >> >> >> >> Some implementations will want to know which platform is being used. We >> should not remove that signal for them. >> >> >> >> [richanna] >> >> My comment was aimed at the implication that Clients might opt to use a >> popup interaction mode on =E2=80=9Cdesktop=E2=80=9D but do something dif= ferent (e.g., >> redirect) on mobile. In any case, if the Client is implementing redirect >> for mobile anyway, then it is not much work for them to wrap that in a >> popup if they really want that experience on desktop. >> >> [/richanna] >> >> >> >> And again, a Client that really wants to give themselves a headache with >> popups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. The= y just have to >> provide a landing page for the GS to redirect back to that parses the >> response, passes it back to the main window, and closes itself. I don=E2= =80=99t see >> why the protocol would need to explicitly describe this mechanism. >> >> [/richanna] >> >> >> >> I think it is a useful signal for the GS in the experience it wants to >> show the user. >> >> >> >> [richanna] >> >> Useful how? The window dimensions are a better signal for how to present >> the user experience. (*cough* responsive design *cough*) >> >> [/richanna] >> >> >> >> Responsive design is one way to address things. Lots of apps still have >> an m.example.com site for mobile content. >> >> >> >> Our goal is not to decide how an app should build a user experience. We >> should give them as much useful signal as they may need to make their ow= n >> choices. >> >> >> >> [richanna] >> >> What signal though? What useful information does the GS get out of >> knowing that the Client intends to open the interaction URI in a popup, >> that it doesn=E2=80=99t already have more accurate sources for? I mentio= ned >> responsive design because the only thing I can think of is that it might >> inform how the GS presents the sign in experience, but =E2=80=9Cpopup=E2= =80=9D on its own >> doesn=E2=80=99t necessarily mean it will be a small or portrait-dimensio= ned window. >> So the GS is still just guessing until it=E2=80=99s actually loaded in t= he popup, >> and at that point it can check the actual window dimensions and use CSS >> media queries, etc. >> >> [/richanna] >> >> >> >> >> >> >> >> 3. How long should the GS wait for the Client to make the Update Grant >> request in 3.4? What should the GS do if that never happens? What is the >> path forward for the end user, at that point? >> >> >> >> 3.1 has the GS waiting for the Client as well. All the same questions >> apply to any aspect of the protocol where one party does not do the next >> step. The User is the most likely party to not continue. What do the GS = and >> Client do if the User has been sent to the GS, but walks away from their >> device? >> >> >> >> [richanna] >> >> In step 3.4, steps 6 through 8, the GS returns the Read Grant response >> (6), the Client evaluates it (7), and then the Client makes an Update Gr= ant >> request to the GS (8). Throughout this time, the end user is sitting at = the >> GS=E2=80=A6watching a spinner, I guess? How long does the AS wait for th= e Update >> Grant request? What if it never comes? I=E2=80=99m not talking about the= end user >> walking away, I=E2=80=99m talking about the Client failing to tell the G= S to >> advance the flow. >> >> [/richanna] >> >> >> >> >> >> >> >> The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for t= he Client to >> maintain a persistent, asynchronous process to make that API call.. >> >> >> >> The 3.1 flow, and all the XYZ flows where there is no redirect all have >> the same requirement of the Client. >> >> >> >> An async call to a server is pretty straight forward in all modern web >> languages. >> >> >> >> If the Client is a mobile app put to sleep, it can remake the call to th= e >> GS and get the results in a 3.1 flow. >> >> >> >> [richanna] >> >> It=E2=80=99s not just an async call to a server, it=E2=80=99s an async c= all initiated >> while handling an HTTP request and that survives the completion of that >> request. This is not trivial, and even where there are tools to help wit= h >> this they are often full of sharp edges and introduce fun new failure mo= des >> (Does your implementation fail fast when your async thread pool gets >> exhausted? No? Better hope your users like 503s=E2=80=A6). >> >> >> >> I suggest a separate thread for this one as well. >> >> [/richanna] >> >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > =E1=90=A7 --000000000000245485059ede7b7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 18, 2020 at 3:17 AM Matth= ew De Haast <matt=3D40coil.= com@dmarc.ietf.org> wrote:
T= hanks for this Dick. Appreciate the draft to be able to compare ideas to XY= Z. The rational section also helped as it answered some of the questions I = was going to ask.

1. OPTIONS for metadata. I reall= y like this way of asking for metadata on the resources.

2. We have both the Read Grant endpoint and then an explicit Token R= efresh endpoint? Is it not possible that if a client wanted to refresh the = tokens it could just do a Read against the grant? Thinking aloud, the bigge= st issue with what I propose is token lifecycle and how to handle that.
=

I was thinking a r= ead against the Grant would return everything in the Grant, which would inc= lude a refresh of all tokens, and return all claims

There is the edge case where an Authorization had been deleted directly, = and then what does a read of the Grant do. Does it create a new Authorizati= on?

A number of questions to explore here. We are = still bouncing around ideas!
=C2=A0

3. 5.5.4 Authorization Object.
<= pre>one of the following values: "oauth_scope" or "oauth_rich"
Is there a specific reason to = try support both methods? I would prefer this to be collapsed to a singular= new definition for authorization, similar to RAR, to reduce confusion.

My understanding of RA= R was that it was scopes=C2=A0+ authorization details. Is that not the case= ?

The reason to have oauth_scope was to have a cle= ar path for existing implementations to migrate to XAuth. A GS may ONLY sup= port oauth_scope.=C2=A0

=C2=A0

4. 4. Grant and Authz Lifecycle
At any point in time,=
 there can only be one Grant for the GS, Client,
   and User tuple.
The Grant/Authz lifecycle i= sn't clear for our use-case. How would the current API handle a client = getting one time authz to perform singular financial transactions? There co= uld be multiple of these auths for a single client at the same time.

If the Client knows a= ll the AuthZs it needs, it can request them all in one Grant.
If not, the Client can request multiple Grants, that each retur= ns an Authorization. The Authorization lives on until it is used.=C2=A0

Assuming a refresh or update of the Authorization is = not needed, there is no need to return an AuthZ URI in the Grant.

Is there a requirement to have each Grant continue on?
=C2=A0

= 5. I am also in agreement with Annabelle that it seems better for the Clien= t to inform the GS on what interactions are possible and let the GS decide.=

Would you elab= orate on why? I understand the flexibility of the Client and GS being able = to negotiate, but I have yet to hear a use case where that is needed.
=

=C2=A0
<= br>
Matt


On Tue, Feb 18, 2020= at 4:26 AM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org= > wrote:

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Monday, February 17, 2020 at 4:22 PM
To: "Richard Backman, Annabelle" <richanna=3D40amazon.com@dmarc.i= etf.org>
Cc: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] XAuth -02

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 14, 2020 at = 6:29 PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>= wrote:

=C2=A0

<snip>

There are lots of reasons for wanting to support multiple modes:<= /u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people are comfortable with QR codes, some= aren=E2=80=99t.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people have smart phones that can scan the= m, some don=E2=80=99t.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 People with smart phones may want to go through= the authentication flow on their desktop instead.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Some people may have to go through the a= uthentication flow on their desktop, because the GS thinks iPhones only sup= port Bluetooth-based security keys and insists they cannot complete the log= in flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROG= RAM)

All of your examples are= choices for the User, which the Client would need to present to the User.= =C2=A0

=C2=A0

Per my comment above bas= ed on your suggestion, "qrcode" also shows the "code" i= nformation, which satisfies all your suggestions above.

=C2=A0

[richanna]

Yes, I am justifying the value of allowing Clients t= o request and present multiple interaction methods by providing these are s= ome examples of cases where it provides clear benefit to the end user. You = can see this implemented in the AWS CLI v2=E2=80=99s support for AWS SSO. And =E2=80=9CScan this <QR code&g= t; or <alternate instructions>=E2=80=9D is a pretty common pattern fo= r anything involving QR codes. Where did you suggest that the =E2=80=9Cqrco= de=E2=80=9D interaction object would include the code information? Are you = referring to your comment proposing a =E2=80=9Ctext only interaction type=E2=80=9D? = That comment sounded like an either/or to me, as in the Client could opt fo= r the text-only interaction that provides them the code or the qrcode inter= action that provides them a short URL, not both.

[/richanna]

=C2=A0

<snip>

=C2=A0

I checked what popular s= ites listed at https://ahrefs.com/blog/most-visited-websites/ use:


- sites that use popups

- pinterest

- expedia<= /p>

- tripadvisor<= /u>

- nytimes<= /p>

- quora

- redfin

- trulia

=C2=A0

- sites that use a full = page redirect

- IMDB - an Amazon prope= rty =3D)

=C2=A0

Looks like most sites pr= efer popups and have figured out how to do it -- except IMDB.=

=C2=A0

[richanna]

I just tried using Google Sign In on Pinterest, Expe= dia, and IMDb, when accessed via a link in a Facebook post in the Facebook = app. Guess which one worked and which two didn=E2=80=99t? =F0=9F=98=83 This perfectly illustrates my point that popups are unreliable, and can = fail in weird ways.

[/richanna]

=C2=A0

=C2=A0

Also, it=E2=80=99s 2020. Stop branching on mobile vs.. desktop. I get that = lots of people still do that, but that doesn=E2=80=99t mean the protocol sh= ould cater to it.

=C2=A0

Mobile and desktop are d= ifferent though. They don't offer the same experiences.

=C2=A0

On mobile, a GS may have= a mobile app that can receive push notifications. The security parameters = are different.

=C2=A0

Some implementations wil= l want to know which platform is being used. We should not remove that sign= al for them.=C2=A0

=C2=A0

[richanna]

My comment was aimed at the implication that Clients= might opt to use a popup interaction mode on =E2=80=9Cdesktop=E2=80=9D but= do something different (e.g., redirect) on mobile. In any case, if the Cli= ent is implementing redirect for mobile anyway, then it is not much work for them to wrap that in a popup if they really want t= hat experience on desktop.

[/richanna]

=C2=A0

And again, a Client that really wants to give themselves a headache with po= pups can do that themselves using =E2=80=9Credirect=E2=80=9D mode. They jus= t have to provide a landing page for the GS to redirect back to that parses= the response, passes it back to the main window, and closes itself. I don=E2=80=99t see why the protocol would need to expl= icitly describe this mechanism.=C2=A0

[/richanna]

=C2=A0

I think it is a useful signal for the GS in the experience it wants to show= the user.

=C2=A0

[richanna]

Useful how? The window dimensions are a better signal for how to present th= e user experience. (*cough* responsive design *cough*)

[/richanna]

=C2=A0

Responsive design is one= way to address things. Lots of apps still have an m.example.com site f= or mobile content.

=C2=A0

Our goal is not to decid= e how an app should build a user experience. We should give them as much us= eful signal as they may need to make their own choices.

=C2=A0

[richanna]

What signal though? What useful information does the= GS get out of knowing that the Client intends to open the interaction URI = in a popup, that it doesn=E2=80=99t already have more accurate sources for?= I mentioned responsive design because the only thing I can think of is that it might inform how the GS presents the = sign in experience, but =E2=80=9Cpopup=E2=80=9D on its own doesn=E2=80=99t = necessarily mean it will be a small or portrait-dimensioned window. So the = GS is still just guessing until it=E2=80=99s actually loaded in the popup, and at that point it can check the actual window dimensions and= use CSS media queries, etc.

[/richanna]

=C2=A0

<snip>

=C2=A0

3.=C2=A0= =C2=A0 How long should the GS wait for the Client to make the= Update Grant request in 3.4? What should the GS do if that never happens? = What is the path forward for the end user, at that point?

=C2=A0

3.1 has the GS waiting f= or the Client as well. All the same questions apply to any aspect of the pr= otocol where one party does not do the next step. The User is the most like= ly party to not continue. What do the GS and Client do if the User has been sent to the GS, but walks away from = their device?

=C2=A0

[richanna]

In step 3.4, steps 6 through 8, the GS returns the R= ead Grant response (6), the Client evaluates it (7), and then the Client ma= kes an Update Grant request to the GS (8). Throughout this time, the end us= er is sitting at the GS=E2=80=A6watching a spinner, I guess? How long does the AS wait for the Update Grant request? = What if it never comes? I=E2=80=99m not talking about the end user walking = away, I=E2=80=99m talking about the Client failing to tell the GS to advanc= e the flow.

[/richanna]

=C2=A0

<snip>

=C2=A0

The issue isn=E2=80=99t the API call itself, it=E2=80=99s the need for the = Client to maintain a persistent, asynchronous process to make that API call= ..

=C2=A0

The 3.1 flow, and all th= e XYZ flows where there is no redirect all have the same requirement of the= Client.

=C2=A0

An async call to a serve= r is pretty straight forward in all modern web languages.

=C2=A0

If the Client is a mobil= e app put to sleep, it can remake the call to the GS and get the results in= a 3.1 flow.=C2=A0

=C2=A0

[richanna]

It=E2=80=99s not just an async call to a server, it= =E2=80=99s an async call initiated while handling an HTTP request and that = survives the completion of that request. This is not trivial, and even wher= e there are tools to help with this they are often full of sharp edges and introduce fun new failure modes (Does your impleme= ntation fail fast when your async thread pool gets exhausted? No? Better ho= pe your users like 503s=E2=80=A6).

=C2=A0

I suggest a separate thread for this one as well.=

[/richanna]

=E1=90= =A7

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7
--000000000000245485059ede7b7d-- From nobody Tue Feb 18 18:03:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3A12088E for ; Tue, 18 Feb 2020 18:03:21 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVhQmDRaekus for ; Tue, 18 Feb 2020 18:03:19 -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 18B1712088D for ; Tue, 18 Feb 2020 18:03:19 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id q8so25270572ljb.2 for ; Tue, 18 Feb 2020 18:03:18 -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; bh=+KBW0y3ahAEE5Q8QD1/kZ0aT6SoBuVH4H+nW5raq1mg=; b=vVuLfE6YZkA+Wqk6kGLc6XF/SqvwpCQ7ZrEtNoLw1Ul4sY2WSYItZ8Lqf/6NoN82UG SZGZnI0654mmzPr7uvu0nTEZA3+2Pi/cc+gUimi7A2katGAFZ6+2BGrLR1Rr+FpWNmKl BPe0EGPKFI92m52tHqbYgs3IRQL0klyVTRKar1SK2fC4RMJASx1O3JjzeQ9GUebIqHUO kKlG7a60Iv8vFQuUYFpLS7Njw4n0dk+4tj/tw2B6fMO5+HZRlTloPy6M7fw5Xpi7mPqC eeRmNzifb8ABQftmaYLGAehEry4/5kl7mdxu564mAVW+ZR+TQXGfnFglVcsYXi53bN7B tLhA== 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=+KBW0y3ahAEE5Q8QD1/kZ0aT6SoBuVH4H+nW5raq1mg=; b=ta+NX+e5+eCk6bt/H9dElKsosiCxcyn+PhjEidjue7HQki2+izbqMzauik6yNNVqXR gW9GWRSGaZNzlejG13pJQMZaW7XLbIAIelnZB1oGNCTvDcmvSPpRfFOUBRuIYqntFozL Cbk3AzaRlqspvq1Lj1NJewn4jxUqs6v0initKWe7l5ucOc4SGwKPSE9VEYkgBHSeKuym oNHNO5kPck0K/ieLc7eBBx4Gt1M6nC/mW6acnmBvjhnBG4AAQTcDuhwNvIWhowbSmfUi JZIRYOHNSkQU9FlM3zu4wjomX93B+b7StvTVfroC/9eX8LxU1guIoE0jPpfP9YSpzetD 0uCg== X-Gm-Message-State: APjAAAWjmGwgMd60Mf/NxY2maLVby6UuJD7ZJoO1PSKLKt/B5+7qDejg ISZBSsF7s8mi8Vpj+mfUnvuENUZnW1tfAkoQWhgJBdOy X-Google-Smtp-Source: APXvYqzJu7JX1JIMZUKH8wCXxEhe1WVQLYbr2RsL3RACcu2ZWr+5OiB4ROKS7NSAHl5qYe3yiuBHUgfy7dDZdmesESE= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr14857345ljj.212.1582077796860; Tue, 18 Feb 2020 18:03:16 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> In-Reply-To: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> From: Dick Hardt Date: Tue, 18 Feb 2020 18:02:50 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000016c782059ee4315a" Archived-At: Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 02:03:22 -0000 --00000000000016c782059ee4315a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Added in user code interaction and aligned QR code to be a superset of user code. Fixed descriptions. ---------- Forwarded message --------- From: Date: Tue, Feb 18, 2020 at 6:00 PM Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt To: Dick Hardt A new version of I-D, draft-hardt-xauth-protocol-03.txt has been successfully submitted by Dick Hardt and posted to the IETF repository. Name: draft-hardt-xauth-protocol Revision: 03 Title: The XAuth Protocol Document date: 2020-02-18 Group: Individual Submission Pages: 53 URL: https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt Status: https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol= / Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 Abstract: Client software often desires resources or identity claims that are independent of the client. This protocol allows a user and/or resource owner to delegate resource authorization and/or release of identity claims to a server. Client software can then request access to resources and/or identity claims by calling the server. The server acquires consent and authorization from the user and/or resource owner if required, and then returns to the client software the authorization and identity claims that were approved. This protocol can be extended to support alternative authorizations, claims, interactions, and client authentication mechanisms. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =E1=90=A7 --00000000000016c782059ee4315a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Added in user code interaction and aligned QR code to be a= superset of user code.
Fixed descriptions.


---------- Forwarde= d message ---------
From: <internet-drafts@ietf.org>
Date: Tue, = Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hard= t-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>



A new version of I-D, draft-hardt-xauth-protocol-03.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardt-xauth-prot= ocol-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
=C2=A0 =C2=A0Client software often desires resources or identity claims tha= t are
=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a= nd/or
=C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea= se of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re= quest access
=C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2= =A0 The
=C2=A0 =C2=A0server acquires consent and authorization from the user and/or=
=C2=A0 =C2=A0resource owner if required, and then returns to the client sof= tware
=C2=A0 =C2=A0the authorization and identity claims that were approved.=C2= =A0 This
=C2=A0 =C2=A0protocol can be extended to support alternative authorizations= ,
=C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

<= img alt=3D"" style=3D"width:0px;max-height:0px;overflow:hidden" src=3D"http= s://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&t= ype=3Dzerocontent&guid=3D533e5116-6e21-4a90-a1c9-ba7d870a87c9">=E1=90=A7
--00000000000016c782059ee4315a-- From nobody Tue Feb 18 19:33:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFEA120836 for ; Tue, 18 Feb 2020 19:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 vUOUYkFE6Rii for ; Tue, 18 Feb 2020 19:33:49 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D293A120033 for ; Tue, 18 Feb 2020 19:33:48 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01J3XkVB000806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 Feb 2020 22:33:47 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 18 Feb 2020 22:33:46 -0500 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] XYZ Update X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 03:33:52 -0000 Based on discussions on the list about including identity in the = protocol, and inspired by Aaron Parecki=E2=80=99s blog post, I=E2=80=99ve = added some simple user claims request and processing to XYZ. This is = reflected in the draft spec text: https://tools.ietf.org/html/draft-richer-transactional-authz-05 On the website (which has better explanations than what fit in the = spec): https://oauth.xyz/ And in our Java implementation of a client and AS: https://github.com/bspk/oauth.xyz-java Thanks especially to Aaron, Dick, and Annabelle for discussion of how = these things can fit together. =E2=80=94 Justin= From nobody Thu Feb 20 12:21:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF59F120112 for ; Thu, 20 Feb 2020 12:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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 T1lsoBRUuRYs for ; Thu, 20 Feb 2020 12:21:21 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (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 321A1120088 for ; Thu, 20 Feb 2020 12:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582230081; x=1613766081; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Gblm5BFBO0y1y8yDCr82GKuwtNXJkxHw3+TbERwCOF8=; b=vyw90D/f1ON/P+/Oz/z27GcJe8/ldG4RCzTALapNnQpIo2t1npumLEPR fGI2pzlnIMzzo8oQut0Wvb8iYqqGYUc/l0KvFz0oP2L7V6ir/XTxz9DXo KX+ncVok8p194Kpt984s7mr/KPVmqJ/SAEhpjWJlF+ug2elb6yXq/XuAs A=; IronPort-SDR: 9KvJUSYS51CuD0Zi/1g3xn/It92eQDlpjx238TrjlZsV1mOulT3zDapA0qHHydfIR+ZF8fEOaO z4RovTOROlTA== X-IronPort-AV: E=Sophos; i="5.70,465,1574121600"; d="scan'208,217"; a="26416954" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 20 Feb 2020 20:21:18 +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-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 8A1E8A371E; Thu, 20 Feb 2020 20:21:17 +0000 (UTC) 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; Thu, 20 Feb 2020 20:21:16 +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.1497.2; Thu, 20 Feb 2020 20:21:16 +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.1497.000; Thu, 20 Feb 2020 20:21:16 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , "txauth@ietf.org" Thread-Topic: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt Thread-Index: AQHV5sjpEbhLLf0ddUeR1uDqNGJ4aagkAu0A Date: Thu, 20 Feb 2020 20:21:16 +0000 Message-ID: <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.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.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.8] Content-Type: multipart/alternative; boundary="_000_60B4484AE05D4278899EA787836D8711amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 20:21:24 -0000 --_000_60B4484AE05D4278899EA787836D8711amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXBkYXRlLCBEaWNrISBJ4oCZbSBnb2luZyB0byBjb25maW5lIG15IGNv bW1lbnRzIGhlcmUgdG8gaW50ZXJhY3Rpb24gbW9kZSBkZXNpZ24sIHNldHRpbmcgYXNpZGUgd2hl dGhlciBvciBub3Qgd2UgbmVlZCDigJxwb3B1cOKAnS4gOkQNCg0KT25jZSB0aGUgR1MgaGFuZHMg dGhhdCBVUkkgYmFjayB0byB0aGUgQ2xpZW50LCBpdCBoYXMgemVybyBjb250cm9sIG92ZXIgaG93 IHRoZSBDbGllbnQgdXNlcyBpdC4gVGhlIENsaWVudCBjb3VsZCBwcmVzZW50IGFueSBVUkkgKG9m IGEgcmVhc29uYWJsZSBzaXplKSBpbnRvIGEgUVIgY29kZSwgb3IgcHJlc2VudCBpdCBhcyBhIGNs aWNrYWJsZSBsaW5rLCBvciByZWRpcmVjdCB0byBpdCwgb3Igb3BlbiBpdCBpbiBhbiBleHRlcm5h bCBicm93c2VyLCBvciBkbyBhbnkgbnVtYmVyIG9mIG90aGVyIGFzLXlldC1ub3QtaW52ZW50ZWQg dGhpbmdzIHdpdGggaXQuIE1vcmVvdmVyLCB0aGUgQ2xpZW50IG1heSBub3Qga25vdyB5ZXQgd2hh dCBpdCB3YW50cyB0byBkbyB3aXRoIGl0LiBTbyB3aGF0IHZhbHVlIGlzIHRoZXJlIGluIGRpc3Rp bmd1aXNoaW5nIGJldHdlZW4g4oCcSSB3YW50IGEgVVJJIGZvciBhIHJlZGlyZWN04oCdIHZzLiDi gJxJIHdhbnQgYSBVUkkgZm9yIGEgUVIgY29kZeKAnSB2cy4g4oCcSSB3YW50IGEgVVJJIGZvciA8 c29tZSBvdGhlciBtYWNoaW5lLWRyaXZlbiBpbnRlcmFjdGlvbiBtb2RlPuKAnT8NCg0KRXZlbiBp ZiB3ZSBjb25zaWRlciB0aGluZ3MgbGlrZSBRUiBjb2RlIGRhdGEgY2FwYWNpdHksIHRoYXTigJlz IHJlYWxseSBqdXN0IGEgVVJJIGxlbmd0aCBsaW1pdGF0aW9uLCB3aGljaCBjb3VsZCBhcHBseSB0 byBub24tUVIgaW50ZXJhY3Rpb24gbW9kZXMsIGUuZy4sIGlmIHRoZSBDbGllbnQgZGV2aWNlIHdh bnRzIHRvIGNvbW11bmljYXRlIHRoZSBVUkkgb3ZlciBhbiBleHRyZW1lbHkgYmFuZHdpZHRoLWNv bnN0cmFpbmVkIGNoYW5uZWwuIEFuZCBpdOKAmXMgbm90IGNsZWFyIHRvIG1lIGhvdyBpbmNsdWRp bmcgYSBVUkkgbGVuZ3RoIGxpbWl0YXRpb24gaW4gdGhlIHJlcXVlc3QgaGVscHMuIElmIGEgR1Mg aXMgY2FwYWJsZSBvZiBnZW5lcmF0aW5nIGEgc2hvcnRlciBVUkksIHdoeSB3b3VsZG7igJl0IGl0 IGFsd2F5cyByZXR1cm4gdGhhdD8gT24gdGhlIGNsaWVudCBzaWRlLCBpdCBjYW4gbG9vayBhdCB0 aGUgbGVuZ3RoIG9mIHRoZSBVUkkgcHJvdmlkZWQgYW5kIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGgg aXQgKGUuZy4sIHJlbmRlciBhIFFSIGNvZGUgb3IgZGlzcGxheSBpdCBvciBkbyBub3RoaW5nIHdp dGggaXQpLg0KDQpTbyB0aGF0IHJlYWxseSBsZWF2ZXMgdXMgd2l0aCB0d28gaW50ZXJhY3Rpb24g bW9kZXMgdGhhdCB3ZSBuZWVkOg0KDQogICogICDigJx1cmnigJ0sIHdoaWNoIHJldHVybnMgYSBm dWxsIFVSSSB0aGF0IG1heSBub3QgYmUgaHVtYW4gZnJpZW5kbHk7IGFuZA0KICAqICAg4oCcY29k ZeKAnSwgd2hpY2ggcmV0dXJucyBhIGNvZGUgYW5kIFVSSSBmb3IgYSBjb2RlIGVudHJ5IHBhZ2Us IGJvdGggb2Ygd2hpY2ggYXJlIGh1bWFuLWZyaWVuZGx5Lg0KDQpUaG9zZSBjb3VsZCBiZSBjb21i aW5hYmxlIHRvIGdldCBib3RoLCBhbmQgZXZlbiBpZiB3ZSBkb27igJl0IGdvIGRvd24gdGhlIG11 bHRpcGxlIGludGVyYWN0aW9uIG1vZGUgcm91dGUgd2UgY291bGQgYWRkIHRoZSBmdWxsIFVSSSB0 byB0aGUg4oCcY29kZeKAnSBpbnRlcmFjdGlvbiBvYmplY3QuIEl0IHdvdWxkbuKAmXQgaHVydCBh bnl0aGluZyB0byBkbyBzby4NCg0K4oCTDQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFX UyBJZGVudGl0eQ0KaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQpGcm9tOiBU eGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8 ZGljay5oYXJkdEBnbWFpbC5jb20+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAyMCBh dCA2OjA0IFBNDQpUbzogInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtUeGF1dGhdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJk dC14YXV0aC1wcm90b2NvbC0wMy50eHQNCg0KQWRkZWQgaW4gdXNlciBjb2RlIGludGVyYWN0aW9u IGFuZCBhbGlnbmVkIFFSIGNvZGUgdG8gYmUgYSBzdXBlcnNldCBvZiB1c2VyIGNvZGUuDQpGaXhl ZCBkZXNjcmlwdGlvbnMuDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0t DQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+Pg0KRGF0ZTogVHVlLCBGZWIgMTgsIDIwMjAgYXQgNjowMCBQTQ0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0w My50eHQNClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20+Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhcmR0 LXhhdXRoLXByb3RvY29sLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBEaWNrIEhhcmR0IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 ICAgICAgICAgICBkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbA0KUmV2aXNpb246ICAgICAgIDAz DQpUaXRsZTogICAgICAgICAgVGhlIFhBdXRoIFByb3RvY29sDQpEb2N1bWVudCBkYXRlOiAgMjAy MC0wMi0xOA0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAg ICAgICAgIDUzDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3Rv Y29sLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJkdC14YXV0aC1wcm90b2NvbC0wMw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wNCkRpZmY6ICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaGFyZHQteGF1 dGgtcHJvdG9jb2wtMDMNCg0KQWJzdHJhY3Q6DQogICBDbGllbnQgc29mdHdhcmUgb2Z0ZW4gZGVz aXJlcyByZXNvdXJjZXMgb3IgaWRlbnRpdHkgY2xhaW1zIHRoYXQgYXJlDQogICBpbmRlcGVuZGVu dCBvZiB0aGUgY2xpZW50LiAgVGhpcyBwcm90b2NvbCBhbGxvd3MgYSB1c2VyIGFuZC9vcg0KICAg cmVzb3VyY2Ugb3duZXIgdG8gZGVsZWdhdGUgcmVzb3VyY2UgYXV0aG9yaXphdGlvbiBhbmQvb3Ig cmVsZWFzZSBvZg0KICAgaWRlbnRpdHkgY2xhaW1zIHRvIGEgc2VydmVyLiAgQ2xpZW50IHNvZnR3 YXJlIGNhbiB0aGVuIHJlcXVlc3QgYWNjZXNzDQogICB0byByZXNvdXJjZXMgYW5kL29yIGlkZW50 aXR5IGNsYWltcyBieSBjYWxsaW5nIHRoZSBzZXJ2ZXIuICBUaGUNCiAgIHNlcnZlciBhY3F1aXJl cyBjb25zZW50IGFuZCBhdXRob3JpemF0aW9uIGZyb20gdGhlIHVzZXIgYW5kL29yDQogICByZXNv dXJjZSBvd25lciBpZiByZXF1aXJlZCwgYW5kIHRoZW4gcmV0dXJucyB0byB0aGUgY2xpZW50IHNv ZnR3YXJlDQogICB0aGUgYXV0aG9yaXphdGlvbiBhbmQgaWRlbnRpdHkgY2xhaW1zIHRoYXQgd2Vy ZSBhcHByb3ZlZC4gIFRoaXMNCiAgIHByb3RvY29sIGNhbiBiZSBleHRlbmRlZCB0byBzdXBwb3J0 IGFsdGVybmF0aXZlIGF1dGhvcml6YXRpb25zLA0KICAgY2xhaW1zLCBpbnRlcmFjdGlvbnMsIGFu ZCBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkds amF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD01MzNlNTEx Ni02ZTIxLTRhOTAtYTFjOS1iYTdkODcwYTg3Yzld4ZCnDQo= --_000_60B4484AE05D4278899EA787836D8711amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIzNjAzNzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjkxMTQ1Njk0IDE0NjI5Mjc3OTQgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgdXBkYXRlLCBE aWNrISBJ4oCZbSBnb2luZyB0byBjb25maW5lIG15IGNvbW1lbnRzIGhlcmUgdG8gaW50ZXJhY3Rp b24gbW9kZSBkZXNpZ24sIHNldHRpbmcgYXNpZGUgd2hldGhlciBvciBub3Qgd2UgbmVlZCDigJxw b3B1cOKAnS4gOkQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25jZSB0aGUgR1MgaGFuZHMgdGhh dCBVUkkgYmFjayB0byB0aGUgQ2xpZW50LCBpdCBoYXMgemVybyBjb250cm9sIG92ZXIgaG93IHRo ZSBDbGllbnQgdXNlcyBpdC4gVGhlIENsaWVudCBjb3VsZCBwcmVzZW50IGFueSBVUkkgKG9mIGEg cmVhc29uYWJsZSBzaXplKSBpbnRvIGEgUVIgY29kZSwgb3IgcHJlc2VudCBpdCBhcyBhIGNsaWNr YWJsZSBsaW5rLCBvciByZWRpcmVjdCB0byBpdCwgb3Igb3BlbiBpdCBpbg0KIGFuIGV4dGVybmFs IGJyb3dzZXIsIG9yIGRvIGFueSBudW1iZXIgb2Ygb3RoZXIgYXMteWV0LW5vdC1pbnZlbnRlZCB0 aGluZ3Mgd2l0aCBpdC4gTW9yZW92ZXIsIHRoZSBDbGllbnQgbWF5IG5vdCBrbm93IHlldCB3aGF0 IGl0IHdhbnRzIHRvIGRvIHdpdGggaXQuIFNvIHdoYXQgdmFsdWUgaXMgdGhlcmUgaW4gZGlzdGlu Z3Vpc2hpbmcgYmV0d2VlbiDigJxJIHdhbnQgYSBVUkkgZm9yIGEgcmVkaXJlY3TigJ0gdnMuIOKA nEkgd2FudCBhIFVSSSBmb3IgYSBRUg0KIGNvZGXigJ0gdnMuIOKAnEkgd2FudCBhIFVSSSBmb3Ig Jmx0O3NvbWUgb3RoZXIgbWFjaGluZS1kcml2ZW4gaW50ZXJhY3Rpb24gbW9kZSZndDvigJ0/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4gaWYgd2UgY29uc2lkZXIgdGhpbmdzIGxpa2UgUVIg Y29kZSBkYXRhIGNhcGFjaXR5LCB0aGF04oCZcyByZWFsbHkganVzdCBhIFVSSSBsZW5ndGggbGlt aXRhdGlvbiwgd2hpY2ggY291bGQgYXBwbHkgdG8gbm9uLVFSIGludGVyYWN0aW9uIG1vZGVzLCBl LmcuLCBpZiB0aGUgQ2xpZW50IGRldmljZSB3YW50cyB0byBjb21tdW5pY2F0ZSB0aGUgVVJJIG92 ZXIgYW4gZXh0cmVtZWx5IGJhbmR3aWR0aC1jb25zdHJhaW5lZA0KIGNoYW5uZWwuIEFuZCBpdOKA mXMgbm90IGNsZWFyIHRvIG1lIGhvdyBpbmNsdWRpbmcgYSBVUkkgbGVuZ3RoIGxpbWl0YXRpb24g aW4gdGhlIHJlcXVlc3QgaGVscHMuIElmIGEgR1MgaXMgY2FwYWJsZSBvZiBnZW5lcmF0aW5nIGEg c2hvcnRlciBVUkksIHdoeSB3b3VsZG7igJl0IGl0IGFsd2F5cyByZXR1cm4gdGhhdD8gT24gdGhl IGNsaWVudCBzaWRlLCBpdCBjYW4gbG9vayBhdCB0aGUgbGVuZ3RoIG9mIHRoZSBVUkkgcHJvdmlk ZWQgYW5kIGRlY2lkZSB3aGF0DQogdG8gZG8gd2l0aCBpdCAoZS5nLiwgcmVuZGVyIGEgUVIgY29k ZSBvciBkaXNwbGF5IGl0IG9yIGRvIG5vdGhpbmcgd2l0aCBpdCkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIHRoYXQgcmVhbGx5IGxlYXZlcyB1cyB3aXRoIHR3byBpbnRlcmFjdGlvbiBtb2Rl cyB0aGF0IHdlIG5lZWQ6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+4oCcdXJp4oCdLCB3aGljaCByZXR1 cm5zIGEgZnVsbCBVUkkgdGhhdCBtYXkgbm90IGJlIGh1bWFuIGZyaWVuZGx5OyBhbmQ8bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj7igJxjb2Rl4oCdLCB3aGljaCByZXR1cm5zIGEg Y29kZSBhbmQgVVJJIGZvciBhIGNvZGUgZW50cnkgcGFnZSwgYm90aCBvZiB3aGljaCBhcmUgaHVt YW4tZnJpZW5kbHkuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3NlIGNvdWxkIGJl IGNvbWJpbmFibGUgdG8gZ2V0IGJvdGgsIGFuZCBldmVuIGlmIHdlIGRvbuKAmXQgZ28gZG93biB0 aGUgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZSByb3V0ZSB3ZSBjb3VsZCBhZGQgdGhlIGZ1bGwg VVJJIHRvIHRoZSDigJxjb2Rl4oCdIGludGVyYWN0aW9uIG9iamVjdC4gSXQgd291bGRu4oCZdCBo dXJ0IGFueXRoaW5nIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVs bGUgQmFja21hbiAoc2hlL2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0 eS88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgRmVicnVhcnkgMTgsIDIwMjAgYXQgNjow NCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1 dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltUeGF1dGhdIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWRk ZWQgaW4gdXNlciBjb2RlIGludGVyYWN0aW9uIGFuZCBhbGlnbmVkIFFSIGNvZGUgdG8gYmUgYSBz dXBlcnNldCBvZiB1c2VyIGNvZGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Rml4ZWQgZGVzY3JpcHRpb25zLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LS0tLS0t LS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPiZndDs8YnI+DQpEYXRlOiBUdWUsIEZlYiAxOCwgMjAyMCBhdCA2OjAwIFBNPGJyPg0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJkdC14YXV0aC1wcm90 b2NvbC0wMy50eHQ8YnI+DQpUbzogRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFy ZHQteGF1dGgtcHJvdG9jb2wtMDMudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBEaWNrIEhhcmR0IGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5 Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbDxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzAzPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBUaGUgWEF1dGggUHJvdG9jb2w8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDIwLTAy LTE4PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlk dWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDUzPGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJk dC14YXV0aC1wcm90b2NvbC0wMy50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQ8 L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJkdC14YXV0aC1wcm90 b2NvbC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzPC9hPjxicj4NCkh0bWxp emVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWhhcmR0 LXhhdXRoLXByb3RvY29sPC9hPjxicj4NCkRpZmY6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDM8L2E+ PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO0NsaWVudCBzb2Z0d2FyZSBv ZnRlbiBkZXNpcmVzIHJlc291cmNlcyBvciBpZGVudGl0eSBjbGFpbXMgdGhhdCBhcmU8YnI+DQom bmJzcDsgJm5ic3A7aW5kZXBlbmRlbnQgb2YgdGhlIGNsaWVudC4mbmJzcDsgVGhpcyBwcm90b2Nv bCBhbGxvd3MgYSB1c2VyIGFuZC9vcjxicj4NCiZuYnNwOyAmbmJzcDtyZXNvdXJjZSBvd25lciB0 byBkZWxlZ2F0ZSByZXNvdXJjZSBhdXRob3JpemF0aW9uIGFuZC9vciByZWxlYXNlIG9mPGJyPg0K Jm5ic3A7ICZuYnNwO2lkZW50aXR5IGNsYWltcyB0byBhIHNlcnZlci4mbmJzcDsgQ2xpZW50IHNv ZnR3YXJlIGNhbiB0aGVuIHJlcXVlc3QgYWNjZXNzPGJyPg0KJm5ic3A7ICZuYnNwO3RvIHJlc291 cmNlcyBhbmQvb3IgaWRlbnRpdHkgY2xhaW1zIGJ5IGNhbGxpbmcgdGhlIHNlcnZlci4mbmJzcDsg VGhlPGJyPg0KJm5ic3A7ICZuYnNwO3NlcnZlciBhY3F1aXJlcyBjb25zZW50IGFuZCBhdXRob3Jp emF0aW9uIGZyb20gdGhlIHVzZXIgYW5kL29yPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc291cmNlIG93 bmVyIGlmIHJlcXVpcmVkLCBhbmQgdGhlbiByZXR1cm5zIHRvIHRoZSBjbGllbnQgc29mdHdhcmU8 YnI+DQombmJzcDsgJm5ic3A7dGhlIGF1dGhvcml6YXRpb24gYW5kIGlkZW50aXR5IGNsYWltcyB0 aGF0IHdlcmUgYXBwcm92ZWQuJm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2wg Y2FuIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgYWx0ZXJuYXRpdmUgYXV0aG9yaXphdGlvbnMsPGJy Pg0KJm5ic3A7ICZuYnNwO2NsYWltcywgaW50ZXJhY3Rpb25zLCBhbmQgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGltZyBib3JkZXI9IjAiIGlkPSJf eDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVy PWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1w O2d1aWQ9NTMzZTUxMTYtNmUyMS00YTkwLWExYzktYmE3ZDg3MGE4N2M5Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_60B4484AE05D4278899EA787836D8711amazoncom_-- From nobody Thu Feb 20 15:12:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67478120128 for ; Thu, 20 Feb 2020 15:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JpsarOye7wgj for ; Thu, 20 Feb 2020 15:12:22 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 DA81D1200D7 for ; Thu, 20 Feb 2020 15:12:21 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id f24so71127lfh.3 for ; Thu, 20 Feb 2020 15:12:21 -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=WqQGsL/6oAfpTvCJF9h4fk6VwL71DKKJ0RjtS5zRP8c=; b=JwfpvyJFY4OZpYN691ufe0gTcD4BCo9vir3LeoVIXNDtg3EHuxea8/VOvANOLjJjme ncoS/u7D5xVxG06QrswbIdTOjohdOP7fNSbFUMcteuYskPt1dxIodDudLQB5uFQVtkgr +cDcXwJG7qYyJ60dMnFvscADwkM8tgYaHwVu0jsMT4JWPmgd1OUJm8CReNuT+J6w7esb DsYknjp9uDMuEXv8Qk7BM4KXxBYJ/DqIRocYQbSnQJplDhemQur85vDQJYw0JZt2tloF 0zwW5yftOxWyT1X4j+yehhsnN5L26w64q3tS3T8s1Ob2k6TFQN4aj1Pk5z8MWgE/n3Ya EsSA== 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=WqQGsL/6oAfpTvCJF9h4fk6VwL71DKKJ0RjtS5zRP8c=; b=PErbKjf0BbAStvutJ+jnt4FhC02qGCnDuFFoz/Owou1+EvK4TOdBv7+aSNyMR59onA TudQajKsM6myrjatmNvEDuQHyWjehl1AWekY1bh7gcW0VZcITiIJM5zM4GYuJxqc++K0 RE1dvFavgU/xm2Dw79rOaFTXQW4JuLHLYLlKuFoUgkCov9WAz3u4Jvg/3Bfvr+vYmzt4 DlmDST4q/5rDP6yyrZyPJDAgUqpG3cynrw5hiYExSzNLd0JZq2ibZwOtWpgYoDKzfqKM sEEzxOcyJVjxuApXv7G0Xy7WijjyUFYFjD5BN92+XQ7Yia5WFcgcuVBnc2NO/MtEdNjn C0+g== X-Gm-Message-State: APjAAAUfMObD8rSK8d6U9M4mutDDWayGyBRhFkqIGgm8kx4kuoFb7111 4na73mn6+4WbrJHg8fIHhoWo2kb9gzfPIeZfZaSokuTL X-Google-Smtp-Source: APXvYqxFyIRsL+EqBHcxkClSqNUHLKuCO/EPwHl+9nD73h+snzSz9NLJSC7JUHDKm2d0xq1NeLjT6AUOnizJXJD26/E= X-Received: by 2002:a05:6512:4c6:: with SMTP id w6mr6351257lfq.157.1582240339962; Thu, 20 Feb 2020 15:12:19 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> In-Reply-To: <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> From: Dick Hardt Date: Thu, 20 Feb 2020 15:11:53 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000069b00a059f0a0998" Archived-At: Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 23:12:26 -0000 --00000000000069b00a059f0a0998 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > Thanks for the update, Dick! I=E2=80=99m going to confine my comments her= e to > interaction mode design, setting aside whether or not we need =E2=80=9Cpo= pup=E2=80=9D. :D > > > > Once the GS hands that URI back to the Client, it has zero control over > how the Client uses it. The Client could present any URI (of a reasonable > size) into a QR code, or present it as a clickable link, or redirect to i= t, > or open it in an external browser, or do any number of other > as-yet-not-invented things with it. Moreover, the Client may not know yet > what it wants to do with it. > Why would the Client not know what it wants to do with it? What would change between when the Client called the GS, and the GS responded? I think of the interaction being the Client saying "I want to do a redirect", and the GS says, "ok, here is the URI". Or the Client says, "I want to show only a code and a URI", and the GS says "ok, here is a good, and an easy to read URI for the user to type in and navigate to. I understand there are interactions that may not yet been invented yet. More on that further down. > So what value is there in distinguishing between =E2=80=9CI want a URI fo= r a > redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. = =E2=80=9CI want a URI for other machine-driven interaction mode>=E2=80=9D? > > > > Even if we consider things like QR code data capacity, that=E2=80=99s rea= lly just > a URI length limitation, which could apply to non-QR interaction modes, > e.g., if the Client device wants to communicate the URI over an extremely > bandwidth-constrained channel. > I don't understand when this would be the case. If the Client is going to do a redirect, then the URI length is not significant. > And it=E2=80=99s not clear to me how including a URI length limitation in= the > request helps. If a GS is capable of generating a shorter URI, why wouldn= =E2=80=99t > it always return that? > There may be a variety of reasons that a GS may want to provide a different URI for a QR code than a redirect, or even a popup. 1) Perhaps the GS has only been supporting redirects, and has a very long URL. They add support for a QR code, and use a 3P service that redirects from the short URL used in the QR code, the the long URL. They don't want to pay for the 3P service anymore than they have to. 2) The GS wants the QR code and user code flows to go through the same machinery that looks up the code to find the Grant. The URI in a redirect has the grant embedded in the URI. They don't want to have to use the code to Grant machinery for all URIs. 3) A QR code flow will usually be done on a phone, and the GS wants to attempt to launch a native app in some way, While you are correct, we could make all URIs be short enough that they can be easily scanned, why force that on implementors? The URI length limitation concept was for the display_uri so that a constrained device has an upper limit. A similar upper limit on QR code would allow a constrained device to know the pixel resolution it needs to show the QR code. > On the client side, it can look at the length of the URI provided and > decide what to do with it (e.g., render a QR code or display it or do > nothing with it). > Per above, why would the Client not already know what experience it wants to present to the User? A URI to be displayed, and a URI to be redirected to are likely going to be quite different. The URI for a User to enter a code will likely be a static value that is easy to type. The User will likely have to authenticate at that page, and then be prompted to enter the code. > > > So that really leaves us with two interaction modes that we need: > > - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be huma= n friendly; and > - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code entr= y page, both of > which are human-friendly. > > > > Those could be combinable to get both, and even if we don=E2=80=99t go do= wn the > multiple interaction mode route we could add the full URI to the =E2=80= =9Ccode=E2=80=9D > interaction object. It wouldn=E2=80=99t hurt anything to do so. > In the latest version, I gave each URI its own name so that the GS can be clear about how it will be used. While we could squeeze all the functionality into a couple parameters, I think it makes it harder for existing deployments to migrate to the protocol. I think we should make it easy for developers to take what they already have and use it with XAuth. wrt. not-yet-invented interactions. These interactions are for not-yet-described use cases. (if other use cases exist, then let's look at them and add the interaction mechanisms if needed) We don't know what parameters will be needed, and overloading the parameters and letting the Client do whatever it wants does not seem like it will interoperate -- the Client decides it wants to do some new interaction, and uses the parameters in a way the GS does not understand. > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Tuesday, February 18, 2020 at 6:04 PM > *To: *"txauth@ietf.org" > *Subject: *[Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > > > Added in user code interaction and aligned QR code to be a superset of > user code. > > Fixed descriptions. > > > > ---------- Forwarded message --------- > From: > Date: Tue, Feb 18, 2020 at 6:00 PM > Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt > To: Dick Hardt > > > > > A new version of I-D, draft-hardt-xauth-protocol-03.txt > has been successfully submitted by Dick Hardt and posted to the > IETF repository. > > Name: draft-hardt-xauth-protocol > Revision: 03 > Title: The XAuth Protocol > Document date: 2020-02-18 > Group: Individual Submission > Pages: 53 > URL: > https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt > Status: > https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ > Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 > > Abstract: > Client software often desires resources or identity claims that are > independent of the client. This protocol allows a user and/or > resource owner to delegate resource authorization and/or release of > identity claims to a server. Client software can then request access > to resources and/or identity claims by calling the server. The > server acquires consent and authorization from the user and/or > resource owner if required, and then returns to the client software > the authorization and identity claims that were approved. This > protocol can be extended to support alternative authorizations, > claims, interactions, and client authentication mechanisms. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > =E1=90=A7 > --00000000000069b00a059f0a0998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 20, 2020 at 12:21 PM Rich= ard Backman, Annabelle <richanna@= amazon.com> wrote:

Thanks for the update, Dick! I=E2=80=99m going to co= nfine my comments here to interaction mode design, setting aside whether or= not we need =E2=80=9Cpopup=E2=80=9D. :D

=C2=A0

Once the GS hands that URI back to the Client, it ha= s zero control over how the Client uses it. The Client could present any UR= I (of a reasonable size) into a QR code, or present it as a clickable link,= or redirect to it, or open it in an external browser, or do any number of other as-yet-not-invented things = with it. Moreover, the Client may not know yet what it wants to do with it.=


Why would the Client not = know what it wants to do with it? What would change between when the Client= called the GS, and the GS responded?

I think of t= he interaction being the Client saying "I want to do a redirect",= and the GS says, "ok, here is the URI". Or the Client says, &quo= t;I want to show only a code and a URI", and the GS says "ok, her= e is a good, and an easy to read URI for the user to type in and navigate t= o.

I understand there are interactions that may no= t yet been invented yet. More on that further down.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

So = what value is there in distinguishing between =E2=80=9CI want a URI for a r= edirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI for <some other machine-driven = interaction mode>=E2=80=9D?

=C2=A0

Even if we consider things like QR code data capacit= y, that=E2=80=99s really just a URI length limitation, which could apply to= non-QR interaction modes, e.g., if the Client device wants to communicate = the URI over an extremely bandwidth-constrained channel.


I don't unde= rstand when this would be the case. If the Client is going to do a redirect= , then the URI length is not significant.
=C2=A0

And it=E2=80= =99s not clear to me how including a URI length limitation in the request h= elps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99t = it always return that?


The= re may be a variety of reasons that a GS may want to provide a different UR= I for a QR code than a redirect, or even a popup.

= 1) Perhaps the GS has only been supporting redirects, and has a very long U= RL. They add support for a QR code, and use a 3P service that redirects fro= m the short URL used in the QR code, the the long URL. They don't want = to pay for the 3P service anymore than they have to.

2) The GS wants the QR code and user code flows to go through the same m= achinery that looks up the code to find the Grant. The URI in a redirect ha= s the grant embedded in the URI. They don't want to have to use the cod= e to Grant machinery for all URIs.

3) A QR code fl= ow will usually be done on a phone, and the GS wants to attempt to launch a= native app in some way,

While you are correct, we= could make all URIs be short enough that they can be easily scanned, why f= orce that on implementors?=C2=A0

The URI length li= mitation concept was for the display_uri so that a constrained device has a= n upper limit. A similar upper limit on QR code would allow a constrained d= evice to know the pixel resolution it needs to show the QR code.
= =C2=A0

On the client side, it can look at the length of the URI provided= and decide what to do with it (e.g., render a QR code or display it or do nothing with it)= .


Per above, why would the = Client not already know what experience it wants to present to the User?

A URI to be displayed, and a URI to be redirected to= are likely going to be quite different.=C2=A0

The= URI for a User to enter a code will likely be a static value that is easy = to type. The User will likely have to authenticate at that page, and then b= e prompted to enter the code.=C2=A0
=C2=A0

=C2=A0

So that really leaves us with two interaction modes = that we need:

  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be hu= man friendly; and
  • =E2=80=9Ccode=E2=80=9D, which = returns a code and URI for a code entry page, both of which are human-frien= dly.

=C2=A0

Those could be combinable to get both, and even if w= e don=E2=80=99t go down the multiple interaction mode route we could add th= e full URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2= =80=99t hurt anything to do so.


=
In the latest version, I gave each URI its own name so that the GS can= be clear about how it will be used.

While we coul= d squeeze all the functionality into a couple parameters, I think it makes = it harder for existing deployments to migrate to the protocol. I think we s= hould make it easy for developers to take what they already have and use it= with XAuth.

wrt. not-yet-invented interactions. T= hese interactions are for not-yet-described use cases. (if other use cases = exist, then let's look at them and add the interaction mechanisms if ne= eded) We don't know what parameters will be needed, and overloading the= parameters and letting the Client do whatever it wants does not seem like = it will interoperate -- the Client decides it wants to do some new interact= ion, and uses the parameters in a way the GS does not understand.



=C2=A0

=C2=A0

=E2=80=93

Annabelle Backman (sh= e/her)

AWS Identity

https://aws.amazon.com/identity/

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, February 18, 2020 at 6:04 PM
To: "txaut= h@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xaut= h-protocol-03.txt

=C2=A0

Added in user code inter= action and aligned QR code to be a superset of user code.

Fixed descriptions.

=C2=A0

---------- Forwarded mes= sage ---------
From: <int= ernet-drafts@ietf.org>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, draft-hardt-xauth-protocol-03.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt<= br> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracke= r.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/htm= l/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://= www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03

Abstract:
=C2=A0 =C2=A0Client software often desires resources or identity claims tha= t are
=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a= nd/or
=C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea= se of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re= quest access
=C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2= =A0 The
=C2=A0 =C2=A0server acquires consent and authorization from the user and/or=
=C2=A0 =C2=A0resource owner if required, and then returns to the client sof= tware
=C2=A0 =C2=A0the authorization and identity claims that were approved.=C2= =A0 This
=C2=A0 =C2=A0protocol can be extended to support alternative authorizations= ,
=C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=E1=90=A7

--00000000000069b00a059f0a0998-- From nobody Fri Feb 21 06:17:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C5F120033 for ; Fri, 21 Feb 2020 06:17:26 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coil.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L42HpG1HgfG for ; Fri, 21 Feb 2020 06:17:24 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 909F41200C4 for ; Fri, 21 Feb 2020 06:17:23 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id e10so2498014edv.9 for ; Fri, 21 Feb 2020 06:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u7xgPZrMswHwBsV1bm6M4kv6Xo8A5XzORp5mic/VBIA=; b=NYrJAmlmPjkf9qhRF1C0KVjgO19Ij0gHZvdjLWe1XEbZX4l7bunydAB/CuOtkRUbSH i21L4dyeOoVoM/8x/UsMpRg58q1tj8jtCCzorTYbH6qWYzLxZyWLCDMlOV57ha/LaSoO tievp0M/L0OWWuGQdEfO1Jm7V/gqffkPMVyrMqTENkSqaLrV9LdCMFWMhtrMA8Hsh7HY z1ijG4lfF8JeJhWEJCkyDE6DDtIWgj33hBPtkWqVVJU72XRRyUVSzzTRjc/v0Jru4LPA D7wFywGr+qVYwwE43QAebyDKVVOV3yI21jzi0DBApDp15UbJ9FB0l8MF1lXf+nog9stI fptw== 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=u7xgPZrMswHwBsV1bm6M4kv6Xo8A5XzORp5mic/VBIA=; b=BIjDnLqGT+n0WxLdp+tVCpnb33naYxBGkPLZW2uVWzF05mFbJ99OY+eN0jNDBdx+1z fA9CQiVqs1dvD7o7El2rb3U/N2WQ+2eH5upMNkX+C54ftCzK7/R3zvXdFN1fwrDL91fR iu8MCw6J/3Nhdh+QpQpHpGhuKzCoPn1uVzLhSeSs1RVBkXuQgcK9Zu2kd7dDu/OU+V3j MXwbib0au7TD/abEHzbY6/5rtidH93PJ4vLusRoGKkJTvk9RGfXCWbJHLtCpig0QAz+E TKSKOosK2coD9q+tlX5Bq3903WJzjUGEe2PBdzLt2exckQxeoFMI/nDdIaNqqtOIKO6w sHXA== X-Gm-Message-State: APjAAAVPx/GLkZU5/AblKCoobTaCvn5EayB5nyl8MwkxOos+yOIKwxLd 68tZrrPpg0EixKEVgO2yj2EMg6iwalnnrNDJQFnvOAL1XZ8= X-Google-Smtp-Source: APXvYqxLhSuNPwFLNdb69+56ni2T8AmutKStkq3RwvGwuCPSY9ucA1Q5mHaIt92m0xJcIPtuXOkci5FCQPw51GT3Jcc= X-Received: by 2002:a05:6402:6cc:: with SMTP id n12mr33059483edy.344.1582294641921; Fri, 21 Feb 2020 06:17:21 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: From: Matthew De Haast Date: Fri, 21 Feb 2020 16:16:40 +0200 Message-ID: To: Dick Hardt Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fe4ad059f16ae85" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:17:27 -0000 --0000000000000fe4ad059f16ae85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt wrote: > > > On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast 40coil.com@dmarc.ietf.org> wrote: > >> Thanks for this Dick. Appreciate the draft to be able to compare ideas t= o >> XYZ. The rational section also helped as it answered some of the questio= ns >> I was going to ask. >> >> 1. OPTIONS for metadata. I really like this way of asking for metadata o= n >> the resources. >> >> 2. We have both the Read Grant endpoint and then an explicit Token >> Refresh endpoint? Is it not possible that if a client wanted to refresh = the >> tokens it could just do a Read against the grant? Thinking aloud, the >> biggest issue with what I propose is token lifecycle and how to handle t= hat. >> > > I was thinking a read against the Grant would return everything in the > Grant, which would include a refresh of all tokens, and return all claims > > There is the edge case where an Authorization had been deleted directly, > and then what does a read of the Grant do. Does it create a new > Authorization? > > A number of questions to explore here. We are still bouncing around ideas= ! > It would be a far nicer API having it a single endpoint IMO. Maybe fleshing out the AuthZ and Grant relation more with some consideration to enabling this use case can be done. From the current wording it would appear if an auth was deleted the grant would return no authorization object. Not sure if that is intended. > 3. 5.5.4 Authorization Object. >> >> one of the following values: "oauth_scope" or >> "oauth_rich" >> >> Is there a specific reason to try support both methods? I would prefer >> this to be collapsed to a singular new definition for authorization, >> similar to RAR, to reduce confusion. >> > > My understanding of RAR was that it was scopes + authorization details. I= s > that not the case? > That is the case, my wording was left open ended in case we felt its datamodel didn't fully suite TxAuth. > The reason to have oauth_scope was to have a clear path for existing > implementations to migrate to XAuth. A GS may ONLY support oauth_scope. > > There is a balance that is going to have to be played between simplifying the spec and providing for the easier migration. My opinion would be to optimize for simplicity. The reason I feel that should be the priority is that we are defining a completely new spec. Lets try keep it clean whilst we have the ability too. What we can try our best doing is make the spec easy to write libraries that make migration easy. For example, writing a library that converts current oauth scopes to OauthX equivalents and back to make it easier for applications wishing to migrate. > > >> >> 4. 4. Grant and Authz Lifecycle >> >>> At any point in time, there can only be one Grant for the GS, Client, >>> and User tuple. >>> >>> The Grant/Authz lifecycle isn't clear for our use-case. How would the >> current API handle a client getting one time authz to perform singular >> financial transactions? There could be multiple of these auths for a sin= gle >> client at the same time. >> > > If the Client knows all the AuthZs it needs, it can request them all in > one Grant. > > If not, the Client can request multiple Grants, that each returns an > Authorization. The Authorization lives on until it is used. > > Assuming a refresh or update of the Authorization is not needed, there is > no need to return an AuthZ URI in the Grant. > > Is there a requirement to have each Grant continue on? > > Clients won't know all AuthZ's ahead of time. They will be requested as needed. Authorizations would need the ability to refresh the AuthZ. Which loops back to the above conversation regarding refreshing Authz by reading a grant. If only a singular grant was allowed, this wouldn't be possible if it was coupled to the Authz. I would like us to explore this more and see how to make this possible. > >> 5. I am also in agreement with Annabelle that it seems better for the >> Client to inform the GS on what interactions are possible and let the GS >> decide. >> > > Would you elaborate on why? I understand the flexibility of the Client an= d > GS being able to negotiate, but I have yet to hear a use case where that = is > needed. > > Will follow up this later. Just catching up on some more the discussion in the new thread. Matt > =E1=90=A7 > --0000000000000fe4ad059f16ae85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast <matt=3D40coil.com@dmarc.ie= tf.org> wrote:
Thanks for th= is Dick. Appreciate the draft to be able to compare ideas to XYZ. The ratio= nal section also helped as it answered some of the questions I was going to= ask.

1. OPTIONS for metadata. I really like this = way of asking for metadata on the resources.

2. We= have both the Read Grant endpoint and then an explicit Token Refresh endpo= int? Is it not possible that if a client wanted to refresh the tokens it co= uld just do a Read against the grant? Thinking aloud, the biggest issue wit= h what I propose is token lifecycle and how to handle that.
=

I was thinking a read against = the Grant would return everything in the Grant, which would include a refre= sh of all tokens, and return all claims

There is t= he edge case where an Authorization had been deleted directly, and then wha= t does a read of the Grant do. Does it create a new Authorization?

A number of questions to explore here. We are still bounci= ng around ideas!

It would= be a far nicer API having it a single endpoint IMO. Maybe fleshing out the= AuthZ and Grant relation more with some consideration to enabling this use= case can be done. From the current wording it would appear if an auth was = deleted the grant would return no authorization object. Not sure if that is= intended.
=C2=A0
3. 5.5.4 Authorization Object.
one of the following =
values: "oauth_scope" or
      "oauth_rich"
Is there a specific reason to = try support both methods? I would prefer this to be collapsed to a singular= new definition for authorization, similar to RAR, to reduce confusion.

My understanding of RA= R was that it was scopes=C2=A0+ authorization details. Is that not the case= ?

That is the case, my wo= rding was left open ended in case we felt its datamodel didn't fully su= ite TxAuth.
=C2=A0
The reason to h= ave oauth_scope was to have a clear path for existing implementations to mi= grate to XAuth. A GS may ONLY support oauth_scope.=C2=A0


There is a balance that is g= oing to have to be played between simplifying the spec and providing for th= e easier migration. My opinion would be to optimize for simplicity. The rea= son I feel that should be the priority is that we are defining a completely= new spec. Lets try keep it clean whilst we have the ability too. What we c= an try our best doing is make the spec easy to write libraries that make mi= gration easy. For example, writing a library that converts current oauth sc= opes to OauthX equivalents and back to make it easier for applications wish= ing to migrate.
=C2=A0
= =C2=A0

4. 4. Grant and A= uthz Lifecycle
= 
At any point in time, there can only be one Grant for the GS, Client,
   and User tuple.
The Grant/Authz lifecycle i= sn't clear for our use-case. How would the current API handle a client = getting one time authz to perform singular financial transactions? There co= uld be multiple of these auths for a single client at the same time.

If the Client knows a= ll the AuthZs it needs, it can request them all in one Grant.
If not, the Client can request multiple Grants, that each retur= ns an Authorization. The Authorization lives on until it is used.=C2=A0

Assuming a refresh or update of the Authorization is = not needed, there is no need to return an AuthZ URI in the Grant.

Is there a requirement to have each Grant continue on?
=C2=A0

Clients w= on't know all AuthZ's ahead of time. They will be requested as need= ed. Authorizations would need the ability to refresh the AuthZ.

Which loops back to the above conversation regarding refreshing Authz by= reading a grant. If only a singular grant was allowed, this wouldn't b= e possible if it was coupled to the Authz. I would like us to explore this = more and see how to make this possible.

=C2=A0

5. I am also in agreement with Annabelle that it se= ems better for the Client to inform the GS on what interactions are possibl= e and let the GS decide.

<= /div>
Would you elaborate on why? I understand the flexibility of the C= lient and GS being able to negotiate, but I have yet to hear a use case whe= re that is needed.


Will follow up this later. Just catching up on some more the discu= ssion in the new thread.

Matt
3D""=E1=90=A7
--0000000000000fe4ad059f16ae85-- From nobody Fri Feb 21 08:18:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64312089E for ; Fri, 21 Feb 2020 08:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 rhm6piKVP2pP for ; Fri, 21 Feb 2020 08:18:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 713AD1208AF for ; Fri, 21 Feb 2020 08:18:38 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LGIX5j025559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 11:18:34 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1C88D3AF-71C5-4193-BEF0-220609FF3650" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Feb 2020 11:18:33 -0500 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org To: Matthew De Haast References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 16:18:41 -0000 --Apple-Mail=_1C88D3AF-71C5-4193-BEF0-220609FF3650 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 21, 2020, at 9:16 AM, Matthew De Haast = wrote: >=20 >=20 > On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt > wrote: >=20 >=20 > On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast = > = wrote: > Thanks for this Dick. Appreciate the draft to be able to compare ideas = to XYZ. The rational section also helped as it answered some of the = questions I was going to ask. >=20 > 1. OPTIONS for metadata. I really like this way of asking for metadata = on the resources. >=20 > 2. We have both the Read Grant endpoint and then an explicit Token = Refresh endpoint? Is it not possible that if a client wanted to refresh = the tokens it could just do a Read against the grant? Thinking aloud, = the biggest issue with what I propose is token lifecycle and how to = handle that. >=20 > I was thinking a read against the Grant would return everything in the = Grant, which would include a refresh of all tokens, and return all = claims >=20 This isn=E2=80=99t particularly idiomatic for HTTP, where a GET request = isn=E2=80=99t supposed to create something new.=20 > There is the edge case where an Authorization had been deleted = directly, and then what does a read of the Grant do. Does it create a = new Authorization? >=20 > A number of questions to explore here. We are still bouncing around = ideas! >=20 > It would be a far nicer API having it a single endpoint IMO. Maybe = fleshing out the AuthZ and Grant relation more with some consideration = to enabling this use case can be done. =46rom the current wording it = would appear if an auth was deleted the grant would return no = authorization object. Not sure if that is intended. +1 > =20 > 3. 5.5.4 Authorization Object. > one of the following values: "oauth_scope" or > "oauth_rich" > Is there a specific reason to try support both methods? I would prefer = this to be collapsed to a singular new definition for authorization, = similar to RAR, to reduce confusion. >=20 > My understanding of RAR was that it was scopes + authorization = details. Is that not the case? >=20 > That is the case, my wording was left open ended in case we felt its = datamodel didn't fully suite TxAuth. > =20 > The reason to have oauth_scope was to have a clear path for existing = implementations to migrate to XAuth. A GS may ONLY support oauth_scope.=20= >=20 >=20 > There is a balance that is going to have to be played between = simplifying the spec and providing for the easier migration. My opinion = would be to optimize for simplicity. The reason I feel that should be = the priority is that we are defining a completely new spec. Lets try = keep it clean whilst we have the ability too. What we can try our best = doing is make the spec easy to write libraries that make migration easy. = For example, writing a library that converts current oauth scopes to = OauthX equivalents and back to make it easier for applications wishing = to migrate. Huge +1. This is our opportunity to make something new without dragging = unnecessary baggage. We can learn from the past without repeating it. = Take the best parts, the parts that will make our lives easier for the = next decade =E2=80=94 not the things that=E2=80=99ll make a migration in = 3 months from now slightly easier. This is why I favor mapping concepts = instead of reusing mechanisms.=20 > =20 > =20 >=20 > 4. 4. Grant and Authz Lifecycle > At any point in time, there can only be one Grant for the GS, Client, > and User tuple. > The Grant/Authz lifecycle isn't clear for our use-case. How would the = current API handle a client getting one time authz to perform singular = financial transactions? There could be multiple of these auths for a = single client at the same time. >=20 > If the Client knows all the AuthZs it needs, it can request them all = in one Grant. >=20 > If not, the Client can request multiple Grants, that each returns an = Authorization. The Authorization lives on until it is used.=20 >=20 > Assuming a refresh or update of the Authorization is not needed, there = is no need to return an AuthZ URI in the Grant. >=20 > Is there a requirement to have each Grant continue on? > =20 >=20 > Clients won't know all AuthZ's ahead of time. They will be requested = as needed. Authorizations would need the ability to refresh the AuthZ. >=20 > Which loops back to the above conversation regarding refreshing Authz = by reading a grant. If only a singular grant was allowed, this wouldn't = be possible if it was coupled to the Authz. I would like us to explore = this more and see how to make this possible. >=20 > =20 >=20 > 5. I am also in agreement with Annabelle that it seems better for the = Client to inform the GS on what interactions are possible and let the GS = decide. >=20 > Would you elaborate on why? I understand the flexibility of the Client = and GS being able to negotiate, but I have yet to hear a use case where = that is needed. >=20 >=20 > Will follow up this later. Just catching up on some more the = discussion in the new thread. >=20 > Matt > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_1C88D3AF-71C5-4193-BEF0-220609FF3650 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 21, 2020, at 9:16 AM, Matthew De Haast <matt=3D40coil.com@dmarc.ietf.org> wrote:


On Tue, Feb 18, 2020 at 9:14 PM Dick = Hardt <dick.hardt@gmail.com> wrote:


On Tue, Feb 18, 2020 at 3:17 AM Matthew = De Haast <matt=3D40coil.com@dmarc.ietf.org> wrote:
Thanks for this Dick. Appreciate the draft to = be able to compare ideas to XYZ. The rational section also helped as it = answered some of the questions I was going to ask.

1. OPTIONS for metadata. = I really like this way of asking for metadata on the = resources.

2. = We have both the Read Grant endpoint and then an explicit Token Refresh = endpoint? Is it not possible that if a client wanted to refresh the = tokens it could just do a Read against the grant? Thinking aloud, the = biggest issue with what I propose is token lifecycle and how to handle = that.

I was thinking a read = against the Grant would return everything in the Grant, which would = include a refresh of all tokens, and return all claims

<= div>
This isn=E2=80=99t particularly idiomatic = for HTTP, where a GET request isn=E2=80=99t supposed to create something = new. 

There is the edge case where an = Authorization had been deleted directly, and then what does a read of = the Grant do. Does it create a new Authorization?
A number of questions to explore here. = We are still bouncing around ideas!

It would be a far nicer = API having it a single endpoint IMO. Maybe fleshing out the AuthZ and = Grant relation more with some consideration to enabling this use case = can be done. =46rom the current wording it would appear if an auth was = deleted the grant would return no authorization object. Not sure if that = is intended.

+1

 
3. = 5.5.4 Authorization Object.
one of =
the following values: "oauth_scope" or
      "oauth_rich"
Is there a specific reason = to try support both methods? I would prefer this to be collapsed to a = singular new definition for authorization, similar to RAR, to reduce = confusion.

My understanding of RAR was that it was = scopes + authorization details. Is that not the = case?

That is the case, my wording was left = open ended in case we felt its datamodel didn't fully suite = TxAuth.
 
The reason to have oauth_scope was = to have a clear path for existing implementations to migrate to XAuth. A = GS may ONLY support oauth_scope. 


There is a balance that is going to = have to be played between simplifying the spec and providing for the = easier migration. My opinion would be to optimize for simplicity. The = reason I feel that should be the priority is that we are defining a = completely new spec. Lets try keep it clean whilst we have the ability = too. What we can try our best doing is make the spec easy to write = libraries that make migration easy. For example, writing a library that = converts current oauth scopes to OauthX equivalents and back to make it = easier for applications wishing to = migrate.

Huge +1. This is our opportunity to make something = new without dragging unnecessary baggage. We can learn from the past = without repeating it. Take the best parts, the parts that will make our = lives easier for the next decade =E2=80=94 not the things that=E2=80=99ll = make a migration in 3 months from now slightly easier. This is why I = favor mapping concepts instead of reusing mechanisms. 

 
 

4. 4. Grant and Authz = Lifecycle
At any point in time, there can only be one =
Grant for the GS, Client,
   and User tuple.
The = Grant/Authz lifecycle isn't clear for our use-case. How would the = current API handle a client getting one time authz to perform singular = financial transactions? There could be multiple of these auths for a = single client at the same time.

If the Client knows all the AuthZs it = needs, it can request them all in one Grant.

If not, the Client can request multiple = Grants, that each returns an Authorization. The Authorization lives on = until it is used. 

Assuming a refresh or update of the Authorization is not = needed, there is no need to return an AuthZ URI in the Grant.

Is there a requirement = to have each Grant continue on?
 

Clients won't know all = AuthZ's ahead of time. They will be requested as needed. Authorizations = would need the ability to refresh the AuthZ.

Which = loops back to the above conversation regarding refreshing Authz by = reading a grant. If only a singular grant was allowed, this wouldn't be = possible if it was coupled to the Authz. I would like us to explore this = more and see how to make this possible.

 

5. = I am also in agreement with Annabelle that it seems better for the = Client to inform the GS on what interactions are possible and let the GS = decide.

Would you elaborate on = why? I understand the flexibility of the Client and GS being able to = negotiate, but I have yet to hear a use case where that is = needed.


Will follow up this later. Just = catching up on some more the discussion in the new thread.

Matt
3D""=E1=90=A7
-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_1C88D3AF-71C5-4193-BEF0-220609FF3650-- From nobody Fri Feb 21 08:38:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AD312082D for ; Fri, 21 Feb 2020 08:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 cwyo66s8hjrM for ; Fri, 21 Feb 2020 08:38:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 BD81E12088E for ; Fri, 21 Feb 2020 08:38:39 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LGcZ2O032131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 11:38:36 -0500 From: Justin Richer Message-Id: <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_908888BD-9D9C-4DFB-BDFB-1BAA046E49F8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Feb 2020 11:38:35 -0500 In-Reply-To: <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> Cc: Dick Hardt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 16:38:42 -0000 --Apple-Mail=_908888BD-9D9C-4DFB-BDFB-1BAA046E49F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we have: - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) - code: tells the AS that the client can present a short code the user = can type (along with a static URL the user can get to, maybe by typing = the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) - callback: tells the AS that the client can receive the completion = message from a front channel interaction through a redirect. Note that = the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this = field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:. These three can be combined in different ways depending on what you want = to do at the client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 = style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D = and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain = user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code = together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D = to get the long URL and the short code not he screen at the same time.=20= On top of that, they can be combined with other methods. Maybe I can = send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. An interesting difference between XYZ and XAuth=E2=80=99s approaches is = that XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D = in the callback response (which in turn is based on the OAuth 1 = =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an = =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of = nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and = the back channel response for a given transaction =E2=80=94 and note = that I=E2=80=99m really open to having a better way to generate and = calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it. XAuth has removed the authorization code concept in its redirect return, = and clients only do polling against the GS API in order to get tokens. = While I obviously think it=E2=80=99s very valuable to remove things from = the front channel, I don=E2=80=99t think this is something we can remove = without opening up attack surfaces that have already been identified in = previous protocols. I would like to understand why XAuth is not = susceptible to the same kinds of attacks, or if it is, what mitigations = there are for them.=20 =E2=80=94 Justin > On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = wrote: >=20 > Thanks for the update, Dick! I=E2=80=99m going to confine my comments = here to interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D > =20 > Once the GS hands that URI back to the Client, it has zero control = over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of = other as-yet-not-invented things with it. Moreover, the Client may not = know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for =E2=80=9D? > =20 > Even if we consider things like QR code data capacity, that=E2=80=99s = really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. And it=E2=80=99s = not clear to me how including a URI length limitation in the request = helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99= t it always return that? On the client side, it can look at the length = of the URI provided and decide what to do with it (e.g., render a QR = code or display it or do nothing with it). > =20 > So that really leaves us with two interaction modes that we need: > =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be human = friendly; and > =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code entry = page, both of which are human-friendly. > =20 > Those could be combinable to get both, and even if we don=E2=80=99t go = down the multiple interaction mode route we could add the full URI to = the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt = anything to do so. > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth on behalf of Dick Hardt = > Date: Tuesday, February 18, 2020 at 6:04 PM > To: "txauth@ietf.org" > Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt > =20 > Added in user code interaction and aligned QR code to be a superset of = user code. > Fixed descriptions. > =20 >=20 > ---------- Forwarded message --------- > From: > > Date: Tue, Feb 18, 2020 at 6:00 PM > Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt > To: Dick Hardt > >=20 >=20 >=20 > A new version of I-D, draft-hardt-xauth-protocol-03.txt > has been successfully submitted by Dick Hardt and posted to the > IETF repository. >=20 > Name: draft-hardt-xauth-protocol > Revision: 03 > Title: The XAuth Protocol > Document date: 2020-02-18 > Group: Individual Submission > Pages: 53 > URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = > Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = > Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >=20 > Abstract: > Client software often desires resources or identity claims that are > independent of the client. This protocol allows a user and/or > resource owner to delegate resource authorization and/or release of > identity claims to a server. Client software can then request = access > to resources and/or identity claims by calling the server. The > server acquires consent and authorization from the user and/or > resource owner if required, and then returns to the client software > the authorization and identity claims that were approved. This > protocol can be extended to support alternative authorizations, > claims, interactions, and client authentication mechanisms. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_908888BD-9D9C-4DFB-BDFB-1BAA046E49F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m in complete agreement with Annabelle. In XYZ we realized that both = the QR Code and Authorization Code, and that the only difference is how = the user gets back to the client. So instead of inventing a new type of = interaction, we split them. In XYZ, we have:

 - redirect: tells the AS that the = client can send the user to an arbitrary URL (and the AS doesn=E2=80=99t = care how the client gets that info to the user; could be a redirect or = an image or send a push notification to a secondary device, we don=E2=80=99= t care as long as the user shows up in a browser at the AS =E2=80=94 so = maybe this field can be renamed to be more universally = accurate)
 - code: tells the AS that the = client can present a short code the user can type (along with a static = URL the user can get to, maybe by typing the URL manually, but it=E2=80=99= s not dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the client can receive = the completion message from a front channel interaction through a = redirect. Note that the client might have gotten to the AS through a = redirect on-device, through a QR-code off device, or through some other = magic, and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80= =99s only concerned with how to get the user :back:.

These three can be = combined in different ways depending on what you want to do at the = client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style = authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain = user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code = together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D = to get the long URL and the short code not he screen at the same = time. 

On = top of that, they can be combined with other methods. Maybe I can send = the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense.

An interesting difference between XYZ = and XAuth=E2=80=99s approaches is that XYZ keeps the concept of the = =E2=80=9Cauthorization code=E2=80=9D in the callback response (which in = turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In = XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along = with a pair of nonces generated by the client and the AS in the back = channel. This binds the front channel response to both the back channel = request and the back channel response for a given transaction =E2=80=94 = and note that I=E2=80=99m really open to having a better way to generate = and calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it.

XAuth has removed the authorization = code concept in its redirect return, and clients only do polling against = the GS API in order to get tokens. While I obviously think it=E2=80=99s = very valuable to remove things from the front channel, I don=E2=80=99t = think this is something we can remove without opening up attack surfaces = that have already been identified in previous protocols. I would like to = understand why XAuth is not susceptible to the same kinds of attacks, or = if it is, what mitigations there are for them. 

 =E2=80=94 = Justin

On Feb 20, 2020, at 3:21 PM, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

Thanks = for the update, Dick! I=E2=80=99m going to confine my comments here to = interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
 
Once the GS hands that URI back to the = Client, it has zero control over how the Client uses it. The Client = could present any URI (of a reasonable size) into a QR code, or present = it as a clickable link, or redirect to it, or open it in an external = browser, or do any number of other as-yet-not-invented things with it. = Moreover, the Client may not know yet what it wants to do with it. So = what value is there in distinguishing between =E2=80=9CI want a URI for = a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. = =E2=80=9CI want a URI for <some other machine-driven interaction = mode>=E2=80=9D?
 
Even if we consider things like QR code data capacity, = that=E2=80=99s really just a URI length limitation, which could apply to = non-QR interaction modes, e.g., if the Client device wants to = communicate the URI over an extremely bandwidth-constrained channel. And = it=E2=80=99s not clear to me how including a URI length limitation in = the request helps. If a GS is capable of generating a shorter URI, why = wouldn=E2=80=99t it always return that? On the client side, it can look = at the length of the URI provided and decide what to do with it (e.g., = render a QR code or display it or do nothing with it).
 
So that = really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI = that may not be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which = returns a code and URI for a code entry page, both of which are = human-friendly.
 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in user code = interaction and aligned QR code to be a superset of user code.
Fixed descriptions.

 

---------- Forwarded message = ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat

=E1=90=A7
-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_908888BD-9D9C-4DFB-BDFB-1BAA046E49F8-- From nobody Fri Feb 21 10:55:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8712001B for ; Fri, 21 Feb 2020 10:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vC3xfD9hwLxn for ; Fri, 21 Feb 2020 10:55:09 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450: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 E9D6C120013 for ; Fri, 21 Feb 2020 10:55:08 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id s23so2213520lfs.10 for ; Fri, 21 Feb 2020 10:55:08 -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=dIiAarjIy2d1YKlFYAOqCjZw2fyiEZ90wIenkbrpBFg=; b=pZ/Tyb0rrOneRmEEyxkMuwK4U2MF4ckLFOR3XRjGho3IPEApQ0X+DiCBoOFcfEKT6k RnukhcV7OPi7166wxRn3SsdX/6cVMhaiV2mHrT+Rbjgwa8R011yJHZZudHyS07KYkoxi VEZWTsqalMTFbF8WDgkh/PaFPJLJxGaCUfNhlVCpIyxFj2PTog/NCqnxLxtBJUs3/E0C dZXPKg2+2dnv+MWlbnwYKsgnaWPumM4VYgH4TefKJyv1LUKpy9sOz04GzU13dq5Fj+hg +J+F3J+e/waJlLmXlYRC9o71oyZkm/VMIQ6yVBUK4gauBuOGo0dyAW0GTIT5zcqESJR/ r2LQ== 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=dIiAarjIy2d1YKlFYAOqCjZw2fyiEZ90wIenkbrpBFg=; b=Y7jKfCc63CjkVN5O2hPg9ZuhwfKNvaJGHqmCjhr2PU8T1Hid9u2xhBNqvSjh617gDn bGp6I7xslC9nCcnwbNCTrSX58kP9NjmBQmJL3IaEFTDTAOa7plAv2UjnCOwnRfCoPc2S 4Vc6YxZL05UIQ83RRKFPgJFRe6cHjfdviKYP8IPpzI+TLLqBsv2lXhc6z+1wH+wHt6NN qqdAuGdOnyh6o+B/dQuuDUTzH5szcWaUd4FpwoBMue6GB0vHHIuGyO/6vY+Q+86qavlI fDpC2RmTcjmbENzilmmMxMINgjRniFKcKOLrUsCZoWlIWNTHwdFDM4aAf/o6NGlZehcv DzjQ== X-Gm-Message-State: APjAAAU43qmfJAPMlLzNrETnwn+UBBSMbqgDDdAYDVKgHAu3mgVaOBDZ UwXXgF233c2bTpR8H7i9Um4CDJWRjiziMoOlI7g= X-Google-Smtp-Source: APXvYqwlnHGLcWvF8CW8n11bwRCTOAHXxkK6DbK+ZVvYXfwgnj42pUEkMpTcLvSaZIT8ZwPBPkn1DNxBy6Ez4XmhHZE= X-Received: by 2002:a19:bece:: with SMTP id o197mr9041819lff.164.1582311306892; Fri, 21 Feb 2020 10:55:06 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> In-Reply-To: <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> From: Dick Hardt Date: Fri, 21 Feb 2020 10:54:39 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005f1a43059f1a8f90" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 18:55:13 -0000 --0000000000005f1a43059f1a8f90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2020 at 8:38 AM Justin Richer wrote: > I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized that= both > the QR Code and Authorization Code, and that the only difference is how t= he > user gets back to the client. So instead of inventing a new type of > interaction, we split them. In XYZ, we have: > This sentence looks to be missing something. > > - redirect: tells the AS that the client can send the user to an > arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that i= nfo to the > user; could be a redirect or an image or send a push notification to a > secondary device, we don=E2=80=99t care as long as the user shows up in a= browser > at the AS =E2=80=94 so maybe this field can be renamed to be more univers= ally > accurate) > As stated in this thread, it may be useful for the AS to know if the URL will be in a QR code, or in a full redirect. In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has to do, so it needs to know the difference between a popup, and a full browser redirect. This is targetted at SPAs, where an additional URL to redirect to is extra work. > - code: tells the AS that the client can present a short code the user > can type (along with a static URL the user can get to, maybe by typing th= e > URL manually, but it=E2=80=99s not dynamic/arbitrary like the redirect me= thod) > - callback: tells the AS that the client can receive the completion > message from a front channel interaction through a redirect. Note that th= e > client might have gotten to the AS through a redirect on-device, through = a > QR-code off device, or through some other magic, and this field isn=E2=80= =99t > concerned with that =E2=80=94 it=E2=80=99s only concerned with how to get= the user :back:. > In a full redirect, the Client wants the AS to send the user back so that it can continue. The only parameter in the completion message is the nonce, which seems superfluous. See below. > > These three can be combined in different ways depending on what you want > to do at the client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 st= yle authorization > code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback= =E2=80=9D together. If you=E2=80=99re doing a plain > user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re do= ing just a QR code with polling, > you use just =E2=80=9Credirect=E2=80=9D to get the long URL. If you=E2=80= =99re doing a user code > and a QR code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Cc= ode=E2=80=9D to get the long URL > and the short code not he screen at the same time. > > On top of that, they can be combined with other methods. Maybe I can send > the user to an arbitrary URL but also display a human-readable verificati= on > code (like CIBA), or send something in a push notification but also give > them a message to type, or I=E2=80=99m getting claims from an agent but I= want them > redirected back through the browser. The client gets to decide what kinds > of interaction it can do and how to use these pieces in ways that make th= e > most sense. > Per my question later in this thread, why would the Client not know what interaction it wants prior to the request? If the AS is doing CIBA, that is not a decision just for the Client. Both the AS and the Client need to know they are doing CIBA. (FWIW: I think this work supersedes CIBA) Additionally, different interactions have different risk profiles. Sophisticated ASes will use that signal in the risk assessment, and may do ask for additional authentication or verification. > > An interesting difference between XYZ and XAuth=E2=80=99s approaches is t= hat XYZ > keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in the call= back response > (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D f= ield). In XYZ, you > get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pai= r of nonces > generated by the client and the AS in the back channel. This binds the > front channel response to both the back channel request and the back > channel response for a given transaction =E2=80=94 and note that I=E2=80= =99m really open to > having a better way to generate and calculate such a binding, but I think > this works. In any event, this protects the client from session fixation > and injection on the return from the front channel that it=E2=80=99s susc= eptible to > in a pure polling model, and the hashing approach basically combines the > security parameters of the OAuth 2 authorization code and (to an extent) > state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one ele= ment. This is only > applicable if you=E2=80=99re coming back to the client and you can valida= te the > hash and present the reference parameter. If you=E2=80=99re doing just pl= ain > polling, you don=E2=80=99t have that protection =E2=80=94 but the client = and the AS are > aware of that risk, and there=E2=80=99s an option to prevent it. > > XAuth has removed the authorization code concept in its redirect return, > and clients only do polling against the GS API in order to get tokens. > While I obviously think it=E2=80=99s very valuable to remove things from = the front > channel, I don=E2=80=99t think this is something we can remove without op= ening up > attack surfaces that have already been identified in previous protocols. = I > would like to understand why XAuth is not susceptible to the same kinds o= f > attacks, or if it is, what mitigations there are for them. > Unlike OAuth 2.0, there are no parameters in the front channel response to the Client. The redirect back to the Client is only needed to return the interaction back to the Client. XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) In OAuth, the AS gives a code to the User to give to the Client that the Client then gives to the GS. In XAuth, the AS gives a "code" to the Client that givers it to the User to give to the GS. In XAuth, the "code" is either a user code, or something embedded in the URI the User is redirected to. Therefore, there is nothing to protect in the redirect back to the Client. If I'm missing an attack, please elaborate how it would happen. > > =E2=80=94 Justin > > On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < > richanna=3D40amazon.com@dmarc.ietf.org> wrote: > > Thanks for the update, Dick! I=E2=80=99m going to confine my comments her= e to > interaction mode design, setting aside whether or not we need =E2=80=9Cpo= pup=E2=80=9D. :D > > Once the GS hands that URI back to the Client, it has zero control over > how the Client uses it. The Client could present any URI (of a reasonable > size) into a QR code, or present it as a clickable link, or redirect to i= t, > or open it in an external browser, or do any number of other > as-yet-not-invented things with it. Moreover, the Client may not know yet > what it wants to do with it. So what value is there in distinguishing > between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want= a URI for a QR code=E2=80=9D vs. > =E2=80=9CI want a URI for =E2= =80=9D? > > Even if we consider things like QR code data capacity, that=E2=80=99s rea= lly just > a URI length limitation, which could apply to non-QR interaction modes, > e.g., if the Client device wants to communicate the URI over an extremely > bandwidth-constrained channel. And it=E2=80=99s not clear to me how inclu= ding a URI > length limitation in the request helps. If a GS is capable of generating = a > shorter URI, why wouldn=E2=80=99t it always return that? On the client si= de, it can > look at the length of the URI provided and decide what to do with it (e.g= ., > render a QR code or display it or do nothing with it). > > So that really leaves us with two interaction modes that we need: > > - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be huma= n friendly; and > - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code entr= y page, both of > which are human-friendly. > > > Those could be combinable to get both, and even if we don=E2=80=99t go do= wn the > multiple interaction mode route we could add the full URI to the =E2=80= =9Ccode=E2=80=9D > interaction object. It wouldn=E2=80=99t hurt anything to do so. > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Tuesday, February 18, 2020 at 6:04 PM > *To: *"txauth@ietf.org" > *Subject: *[Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > Added in user code interaction and aligned QR code to be a superset of > user code. > Fixed descriptions. > > > ---------- Forwarded message --------- > From: > Date: Tue, Feb 18, 2020 at 6:00 PM > Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt > To: Dick Hardt > > > > > A new version of I-D, draft-hardt-xauth-protocol-03.txt > has been successfully submitted by Dick Hardt and posted to the > IETF repository. > > Name: draft-hardt-xauth-protocol > Revision: 03 > Title: The XAuth Protocol > Document date: 2020-02-18 > Group: Individual Submission > Pages: 53 > URL: > https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt > Status: > https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ > Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 > > Abstract: > Client software often desires resources or identity claims that are > independent of the client. This protocol allows a user and/or > resource owner to delegate resource authorization and/or release of > identity claims to a server. Client software can then request access > to resources and/or identity claims by calling the server. The > server acquires consent and authorization from the user and/or > resource owner if required, and then returns to the client software > the authorization and identity claims that were approved. This > protocol can be extended to support alternative authorizations, > claims, interactions, and client authentication mechanisms. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000005f1a43059f1a8f90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 21, 2020 at 8:38 AM Justi= n Richer <jricher@mit.edu> wro= te:
I=E2=80=99m in complete agreement with Anna= belle. In XYZ we realized t= hat both the QR Code and Authorization Code, and that the only difference i= s how the user gets back to the client. So instead of inventing a ne= w type of interaction, we split them. In XYZ, we have:

This sent= ence looks to be missing something.
=C2=A0

=C2=A0- redirect: tells the AS that the client c= an send the user to an arbitrary URL (and the AS doesn=E2=80=99t care how t= he client gets that info to the user; could be a redirect or an image or se= nd a push notification to a secondary device, we don=E2=80=99t care as long= as the user shows up in a browser at the AS =E2=80=94 so maybe this field = can be renamed to be more universally accurate)

As stated in this thread, it may be useful for the AS to k= now if the URL will be in a QR code, or in a full redirect.

<= /div>
In XAuth, the GS(AS min XYA) closes the popup to minimize what a = Client has to do, so it needs to know the difference between a popup, and a= full browser redirect. This is targetted at SPAs, where an additional URL = to redirect to is extra work.
=C2=A0
= =C2=A0- code: tells the AS that the client can present a short code the use= r can type (along with a static URL the user can get to, maybe by typing th= e URL manually, but it=E2=80=99s not dynamic/arbitrary like the redirect me= thod)
=C2=A0- callback: tells the AS that the client can receive th= e completion message from a front channel interaction through a redirect. N= ote that the client might have gotten to the AS through a redirect on-devic= e, through a QR-code off device, or through some other magic, and this fiel= d isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only concerned w= ith how to get the user :back:.

In a full redirect, the Client wants the AS to send the user back so= that it can continue.

The only parameter in the c= ompletion message is the nonce, which seems superfluous. See below.
=C2=A0

These three can be= combined in different ways depending on what you want to do at the client.= Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style authorization code= , you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback=E2=80= =9D together. If you=E2=80=99re doing a plain user code, you=E2=80=99d use = =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re doing just a QR code with polling= , you use just =E2=80=9Credirect=E2=80=9D to get the long URL. If you=E2=80= =99re doing a user code and a QR code together, you use =E2=80=9Credirect= =E2=80=9D and =E2=80=9Ccode=E2=80=9D to get the long URL and the short code= not he screen at the same time.=C2=A0

On top of t= hat, they can be combined with other methods. Maybe I can send the user to = an arbitrary URL but also display a human-readable verification code (like = CIBA), or send something in a push notification but also give them a messag= e to type, or I=E2=80=99m getting claims from an agent but I want them redi= rected back through the browser. The client gets to decide what kinds of in= teraction it can do and how to use these pieces in ways that make the most = sense.

Per my question la= ter in this thread, why would the Client not know what interaction it wants= prior to the request?

If the AS is doing CIBA, th= at is not a decision just for the Client. Both the AS and the Client need t= o know they are doing CIBA. (FWIW: I think this work supersedes CIBA)
=

Additionally, different interactions have different ris= k profiles. Sophisticated ASes will use that signal in the risk assessment,= and may do ask for additional authentication or verification.
= =C2=A0

An interesting differ= ence between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps the conce= pt of the =E2=80=9Cauthorization code=E2=80=9D in the callback response (wh= ich in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field)= . In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed alon= g with a pair of nonces generated by the client and the AS in the back chan= nel. This binds the front channel response to both the back channel request= and the back channel response for a given transaction =E2=80=94 and note t= hat I=E2=80=99m really open to having a better way to generate and calculat= e such a binding, but I think this works. In any event, this protects the c= lient from session fixation and injection on the return from the front chan= nel that it=E2=80=99s susceptible to in a pure polling model, and the hashi= ng approach basically combines the security parameters of the OAuth 2 autho= rization code and (to an extent) state, PKCE=E2=80=99s code_challenge, and = OIDC=E2=80=99s nonce in one element. This is only applicable if you=E2=80= =99re coming back to the client and you can validate the hash and present t= he reference parameter. If you=E2=80=99re doing just plain polling, you don= =E2=80=99t have that protection =E2=80=94 but the client and the AS are awa= re of that risk, and there=E2=80=99s an option to prevent it.
XAuth has removed the authorization code concept in its redirec= t return, and clients only do polling against the GS API in order to get to= kens. While I obviously think it=E2=80=99s very valuable to remove things f= rom the front channel, I don=E2=80=99t think this is something we can remov= e without opening up attack surfaces that have already been identified in p= revious protocols. I would like to understand why XAuth is not susceptible = to the same kinds of attacks, or if it is, what mitigations there are for t= hem.=C2=A0

Unlike OAuth 2= .0, there are no parameters in the front channel response to the Client. Th= e redirect back to the Client is only needed to return the interaction back= to the Client.

XAuth (and XYZ) have a different f= low than OAuth 2.0 (or OAuth 1.0)

In OAuth, the AS= gives a code to the User to give to the Client that the Client then gives = to the GS.

In XAuth, the AS gives a "code&quo= t; to the Client that givers it to the User to give to the GS.
In XAuth, the "code" is either a user code, or somet= hing embedded in the URI the User is redirected to.

Therefore, there is nothing to protect in the redirect back to the Client= .

If I'm missing an attack, please elaborate h= ow it would happen.
=C2=A0

=C2=A0=E2=80=94 Justin

= On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <richanna=3D40a= mazon.com@dmarc.ietf.org> wrote:

=
Thanks for the update, Dick! I=E2=80=99m going to confine my comm= ents here to interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
=C2=A0
Once the GS hands that URI back to the Client, it has zer= o control over how the Client uses it. The Client could present any URI (of= a reasonable size) into a QR code, or present it as a clickable link, or r= edirect to it, or open it in an external browser, or do any number of other= as-yet-not-invented things with it. Moreover, the Client may not know yet = what it wants to do with it. So what value is there in distinguishing betwe= en =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI = for a QR code=E2=80=9D vs. =E2=80=9CI want a URI for <some other machine= -driven interaction mode>=E2=80=9D?
= =C2=A0
Even if we consider things like QR code data c= apacity, that=E2=80=99s really just a URI length limitation, which could ap= ply to non-QR interaction modes, e.g., if the Client device wants to commun= icate the URI over an extremely bandwidth-constrained channel. And it=E2=80= =99s not clear to me how including a URI length limitation in the request h= elps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99t = it always return that? On the client side, it can look at the length of the= URI provided and decide what to do with it (e.g., render a QR code or disp= lay it or do nothing with it).
=C2=A0
So that really leaves us with two interaction modes th= at we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI t= hat may not be human friendly; and
  • =E2=80=9Ccode= =E2=80=9D, which returns a code and URI for a code entry page, both of whic= h are human-friendly.
=C2=A0=
Those could be combinable to get both, and even if we don= =E2=80=99t go down the multiple interaction mode route we could add the ful= l URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t= hurt anything to do so.
=C2=A0<= /div>
=E2=80=93<= /span>
Annabelle Backman (she= /her)
AW= S Identity
=
=C2=A0
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>=
Date:=C2=A0Tuesday, February 18, 2020 at 6:04 PMTo:=C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0[Txauth] Fwd: New Version Notification for draft-hardt-xauth-protoc= ol-03.txt
=C2= =A0
Added in user code interaction a= nd aligned QR code to be a superset of user code.
<= div style=3D"margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calib= ri,sans-serif">Fixed descriptions.

=C2=A0

---= ------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 18, 2020 at 6:00= PM
Subject: New Version Notification for draft-hardt-xauth-protocol-03.= txt
To: Dick Hardt <dick.hardt@gmail.co= m>



A new version of I-D, draft-hardt-xauth-protocol-03.txt
has been succe= ssfully submitted by Dick Hardt and posted to the
IETF repository.
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol<= br>Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-hardt-xau= th-protocol-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2= =A0 =C2=A0https= ://tools.ietf.org/html/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0= =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoc= ol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdi= ff?url2=3Ddraft-hardt-xauth-protocol-03

Abstract:
=C2=A0 =C2= =A0Client software often desires resources or identity claims that are
= =C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a= nd/or
=C2=A0 =C2=A0resource owner to delegate resource authorization and= /or release of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client so= ftware can then request access
=C2=A0 =C2=A0to resources and/or identity= claims by calling the server.=C2=A0 The
=C2=A0 =C2=A0server acquires co= nsent and authorization from the user and/or
=C2=A0 =C2=A0resource owner= if required, and then returns to the client software
=C2=A0 =C2=A0the a= uthorization and identity claims that were approved.=C2=A0 This
=C2=A0 = =C2=A0protocol can be extended to support alternative authorizations,
= =C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are available at<= span>=C2=A0tools.ietf.org.

The I= ETF Secretariat

=E1=90=A7<= /span>
--=C2=A0
Txauth mailing list
Txauth@ietf.org
= https://www.ietf.org/mailma= n/listinfo/txauth

= --0000000000005f1a43059f1a8f90-- From nobody Fri Feb 21 11:15:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D17120044 for ; Fri, 21 Feb 2020 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 p0M9h6t10O9X for ; Fri, 21 Feb 2020 11:15:00 -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 8492B120026 for ; Fri, 21 Feb 2020 11:14:59 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id a13so3296665ljm.10 for ; Fri, 21 Feb 2020 11:14:59 -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=trBKnqkJq+TpJ0auFnEb7kVLbL2ptLxuDYFLRfDUHiQ=; b=T9vCK6yzV+qdO4irKAEYEgkKimLQ34VI7UR7u7IhmWu1ot6bs99BhN5r5N/Co8Tfrb AHXqCvjEhso3/ea1G7OSkw/lLJLzr06B0DgRDooEbkosmi7xKoTppIAUqMEr0vixZ2DH ZgRGekDPfELXHxkWywZaGkw9TXnEAai4PNpKA5YS/dTU68Iy3TcjrND8I65/1IyvTenX UI77nrwtCskuqOiBYirIiSIu0jC37XmNHhgr2iR1oJdMTxe6ph9c27AFLDZdrZysqoJn jQRq39T+JewkupZH0+EqUL8GFEwaBEdu8tOoOn3eIqEI1Ip0kommuo3I0bG13HNxhRQb wQFg== 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=trBKnqkJq+TpJ0auFnEb7kVLbL2ptLxuDYFLRfDUHiQ=; b=McJ5SBHeyHox3bxZl7tEgkmouMDWOgdoWeV93BI5PaV//gqIllDIYyZXpjK8I9VR+x d4aGhp7UPWoZ8kFGGCnaMucOjyVZNxGALTD66rObyHDfy6bQ61u9rOQIxo4bb46RVfMD aIlYmQJ8bhn94Br5VYDAVIbdXTiJ84QCIBMAM+jchGEQvjheroddu3t1K24fdbbW52Cp lCaok/ZieOdR3Fh9OWB/B1VZUBOohc0k4fERaRvx8lc/5JHUc6Fx/lPZxCPL+ljige/B 40ApGXKTzN8vArp5t83EVBBiwDauV1TWv2ce9TOfnkW2wrs6ut+JL7BwZ9omaXl1MQk6 AAfg== X-Gm-Message-State: APjAAAXX5a8pLeS/uoQFoHxF6KgEW5v51iPHlpEoUuF+30Csjd3Yu1+7 401WM9tYENKHRkC6QgzojebwgbpnSFUkNH5nqxi2vnoj X-Google-Smtp-Source: APXvYqxFDdIFT+qeRgYlrdkH5xx3AakVzw/r41HLGyeCq4X9EgU5+RLJnc2BDPtX5qfNER8JzN42bMQ/NFxTdQwpAzQ= X-Received: by 2002:a2e:b5b4:: with SMTP id f20mr23663557ljn.112.1582312497590; Fri, 21 Feb 2020 11:14:57 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: From: Dick Hardt Date: Fri, 21 Feb 2020 11:14:31 -0800 Message-ID: To: Matthew De Haast Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000057b6b3059f1ad639" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 19:15:03 -0000 --00000000000057b6b3059f1ad639 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2020 at 6:17 AM Matthew De Haast wrote: > > On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt wrote: > >> >> >> On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast > 40coil.com@dmarc.ietf.org> wrote: >> >>> Thanks for this Dick. Appreciate the draft to be able to compare ideas >>> to XYZ. The rational section also helped as it answered some of the >>> questions I was going to ask. >>> >>> 1. OPTIONS for metadata. I really like this way of asking for metadata >>> on the resources. >>> >>> 2. We have both the Read Grant endpoint and then an explicit Token >>> Refresh endpoint? Is it not possible that if a client wanted to refresh= the >>> tokens it could just do a Read against the grant? Thinking aloud, the >>> biggest issue with what I propose is token lifecycle and how to handle = that. >>> >> >> I was thinking a read against the Grant would return everything in the >> Grant, which would include a refresh of all tokens, and return all claim= s >> >> There is the edge case where an Authorization had been deleted directly, >> and then what does a read of the Grant do. Does it create a new >> Authorization? >> >> A number of questions to explore here. We are still bouncing around idea= s! >> > > It would be a far nicer API having it a single endpoint IMO. > Why is that? In XAuth, each grant is a new URI. > Maybe fleshing out the AuthZ and Grant relation more with some > consideration to enabling this use case can be done. > Are you referring to the refresh use case? An option would be that the Grant only contains the AuthZ URI. The Client needs to call the AuthZ URI to get an access token. Then all access token management is done at the AuthZ URI. If the access token can not be refreshed, then it is included in the Grant. Do you have other suggestions? > From the current wording it would appear if an auth was deleted the grant > would return no authorization object. Not sure if that is intended. > If we want to acquire more than one authorization at a time, and manage them independently, then we need different URIs. > > >> 3. 5.5.4 Authorization Object. >>> >>> one of the following values: "oauth_scope" or >>> "oauth_rich" >>> >>> Is there a specific reason to try support both methods? I would prefer >>> this to be collapsed to a singular new definition for authorization, >>> similar to RAR, to reduce confusion. >>> >> >> My understanding of RAR was that it was scopes + authorization details. >> Is that not the case? >> > > That is the case, my wording was left open ended in case we felt its > datamodel didn't fully suite TxAuth. > > >> The reason to have oauth_scope was to have a clear path for existing >> implementations to migrate to XAuth. A GS may ONLY support oauth_scope. >> >> > There is a balance that is going to have to be played between simplifying > the spec and providing for the easier migration. My opinion would be to > optimize for simplicity. The reason I feel that should be the priority is > that we are defining a completely new spec. Lets try keep it clean whilst > we have the ability too. What we can try our best doing is make the spec > easy to write libraries that make migration easy. For example, writing a > library that converts current oauth scopes to OauthX equivalents and back > to make it easier for applications wishing to migrate. > Libraries are not going to help an AS migrate. All their documentation and machinery is set up for scopes. While we are on the topic of scopes, there are new use cases where the existing scopes are not expressive enough, but there are fine for many use cases. Why not let everyone keep using what works and not have to learn a new way to represent resources? If it is not broken for them, why fix it? > > >> >> >>> >>> 4. 4. Grant and Authz Lifecycle >>> >>>> At any point in time, there can only be one Grant for the GS, Client, >>>> and User tuple. >>>> >>>> The Grant/Authz lifecycle isn't clear for our use-case. How would the >>> current API handle a client getting one time authz to perform singular >>> financial transactions? There could be multiple of these auths for a si= ngle >>> client at the same time. >>> >> >> If the Client knows all the AuthZs it needs, it can request them all in >> one Grant. >> >> If not, the Client can request multiple Grants, that each returns an >> Authorization. The Authorization lives on until it is used. >> >> Assuming a refresh or update of the Authorization is not needed, there i= s >> no need to return an AuthZ URI in the Grant. >> >> Is there a requirement to have each Grant continue on? >> >> > > Clients won't know all AuthZ's ahead of time. They will be requested as > needed. Authorizations would need the ability to refresh the AuthZ. > > Which loops back to the above conversation regarding refreshing Authz by > reading a grant. If only a singular grant was allowed, this wouldn't be > possible if it was coupled to the Authz. I would like us to explore this > more and see how to make this possible. > The GS can decide if an Authorization can be refreshed. It can also decide to not return an AuthZ URI with the access token. Does the suggestion above work? Return an access token in the Grant if it can not be managed. Return only an AuthZ URi if the Grant can be managed. The contents of a Grant are then static. > > >> >>> 5. I am also in agreement with Annabelle that it seems better for the >>> Client to inform the GS on what interactions are possible and let the G= S >>> decide. >>> >> >> Would you elaborate on why? I understand the flexibility of the Client >> and GS being able to negotiate, but I have yet to hear a use case where >> that is needed. >> >> > Will follow up this later. Just catching up on some more the discussion i= n > the new thread. > > Matt > >> =E1=90=A7 >> > =E1=90=A7 --00000000000057b6b3059f1ad639 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 21, 2020 at 6:17 AM Matth= ew De Haast <matt@coil.com> wrot= e:

On= Tue, Feb 18, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast <matt=3D40coil.com@dma= rc.ietf.org> wrote:
Thanks f= or this Dick. Appreciate the draft to be able to compare ideas to XYZ. The = rational section also helped as it answered some of the questions I was goi= ng to ask.

1. OPTIONS for metadata. I really like = this way of asking for metadata on the resources.

= 2. We have both the Read Grant endpoint and then an explicit Token Refresh = endpoint? Is it not possible that if a client wanted to refresh the tokens = it could just do a Read against the grant? Thinking aloud, the biggest issu= e with what I propose is token lifecycle and how to handle that.
<= /div>

I was thinking a read aga= inst the Grant would return everything in the Grant, which would include a = refresh of all tokens, and return all claims

There= is the edge case where an Authorization had been deleted directly, and the= n what does a read of the Grant do. Does it create a new Authorization?

A number of questions to explore here. We are still b= ouncing around ideas!

It = would be a far nicer API having it a single endpoint IMO.
=

Why is that? In XAuth, each grant is a new= URI.
=C2=A0
Maybe fleshing out the= AuthZ and Grant relation more with some consideration to enabling this use= case can be done.

Are yo= u referring to the refresh use case?=C2=A0

An opti= on would be that the Grant only contains the AuthZ URI. The Client needs to= call the AuthZ URI to get an access token. Then all access token managemen= t is done at the AuthZ URI. If the access token can not be refreshed, then = it is included in the Grant. Do you have other suggestions?
=C2= =A0
From the current wording it would appear = if an auth was deleted the grant would return no authorization object. Not = sure if that is intended.

If we want to acquire more than one authorization at a time, and manage th= em independently, then we need different URIs.
=C2=A0
=C2=A0
=
3. 5.5.4 Authorization Object.
one of the following val=
ues: "oauth_scope" or
      "oauth_rich"
Is there a specific reason to = try support both methods? I would prefer this to be collapsed to a singular= new definition for authorization, similar to RAR, to reduce confusion.

My understanding of RA= R was that it was scopes=C2=A0+ authorization details. Is that not the case= ?

That is the case, my wo= rding was left open ended in case we felt its datamodel didn't fully su= ite TxAuth.
=C2=A0
The reason to h= ave oauth_scope was to have a clear path for existing implementations to mi= grate to XAuth. A GS may ONLY support oauth_scope.=C2=A0


There is a balance that is g= oing to have to be played between simplifying the spec and providing for th= e easier migration. My opinion would be to optimize for simplicity. The rea= son I feel that should be the priority is that we are defining a completely= new spec. Lets try keep it clean whilst we have the ability too. What we c= an try our best doing is make the spec easy to write libraries that make mi= gration easy. For example, writing a library that converts current oauth sc= opes to OauthX equivalents and back to make it easier for applications wish= ing to migrate.

Libraries= are not going to help an AS migrate. All their documentation and machinery= is set up for scopes.

While we are on the topic o= f scopes, there are new use cases where the existing scopes are not express= ive enough, but there are fine for many use cases.=C2=A0

Why not let everyone keep using what works and not have to learn a n= ew way to represent resources? If it is not broken for them, why fix it?

=C2=A0
=C2=A0
=C2=A0

4. 4. Grant and Authz Lifecycle
At any point in time, there can only =
be one Grant for the GS, Client,
   and User tuple.
The Grant/Authz lifecycle i= sn't clear for our use-case. How would the current API handle a client = getting one time authz to perform singular financial transactions? There co= uld be multiple of these auths for a single client at the same time.

If the Client knows a= ll the AuthZs it needs, it can request them all in one Grant.
If not, the Client can request multiple Grants, that each retur= ns an Authorization. The Authorization lives on until it is used.=C2=A0

Assuming a refresh or update of the Authorization is = not needed, there is no need to return an AuthZ URI in the Grant.

Is there a requirement to have each Grant continue on?
=C2=A0

Clients w= on't know all AuthZ's ahead of time. They will be requested as need= ed. Authorizations would need the ability to refresh the AuthZ.

Which loops back to the above conversation regarding refreshing Authz by= reading a grant. If only a singular grant was allowed, this wouldn't b= e possible if it was coupled to the Authz. I would like us to explore this = more and see how to make this possible.

<= div>
The GS can decide if an Authorization can be refreshed. = It can also decide to not return an AuthZ URI with the access token.=C2=A0<= /div>

Does the suggestion above work?

Return an access token in the Grant if it can not be managed.
<= div>
Return only an AuthZ URi if the Grant can be managed.=C2= =A0

The contents of a Grant are then static.
=
=C2=A0
=C2=A0

5. I am also in agreement with Annabelle that it se= ems better for the Client to inform the GS on what interactions are possibl= e and let the GS decide.

<= /div>
Would you elaborate on why? I understand the flexibility of the C= lient and GS being able to negotiate, but I have yet to hear a use case whe= re that is needed.


Will follow up this later. Just catching up on some more the discu= ssion in the new thread.

Matt
3D""=E1=90=A7
3D""= =E1=90=A7
--00000000000057b6b3059f1ad639-- From nobody Fri Feb 21 11:16:50 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ACD120041 for ; Fri, 21 Feb 2020 11:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DtWogA__PBOG for ; Fri, 21 Feb 2020 11:16:46 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B2D12003E for ; Fri, 21 Feb 2020 11:16:46 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id e18so3290736ljn.12 for ; Fri, 21 Feb 2020 11:16:46 -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=DX+4zzKf9YePpvt0kbBFViUKH2xFKH6ZiI0fYmBpj30=; b=PNHGvqmHIpYk/OIsv7tAmasDvx79FSXj44ddUsqw2V1aTw3+IfXL9ifgk65Jl2v54I N1HSDeEcmaOJblhn7zgBAcCRF2YLis2RmDrSVbHpsEv0FxolHA4dA8d5HsgowYai2GIU ixi2b5yaNcj5v+0MZbzLWtLOZryaOpicR0A0nQHBUjqSezsnuazoHFzJi4sNcwnhPufR aIL5aSYJk9ciPSZpMw1xgci/k62QwK2R0iL34l/CYxphxfsVxVzwoadJx+4FFbpvpxmW 3+VbULn+xoENE/Jiczl93HKiWa5o7+VGiEjLGgLSv1YmDxkM25QH3HiXyfUnxvUX7bp7 PSxg== 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=DX+4zzKf9YePpvt0kbBFViUKH2xFKH6ZiI0fYmBpj30=; b=Q3hSLlI58QuBpLlhM7no/ciVOP5k9yxy/4ze0KDp8th3/vGiBj4nvSPA4DIuAWIjkQ PwHcERhiHC1yVLmhzEgyxF+v/Bm9159ckLcAZV71nhsB5BoB1O6tGzdafef8GzIKlx2p 4lJKPFCq5sI0DAr0icbi8ck4bdfYHS4k8QHlPD1lcUvcwOI3e6LLu9Ws6Fin+7tBL574 MHyDUdxzsYDjhjFiqFb86TGRY16B4KrBfIMmWdBDRFwb6nrgtrDXE3D1bKGAxuFQvcXk ZMkrjvNck2oblE+QiBxClw5uQXO9Q/jfs7H8TLEp+vmqYf6J9dItva5oiZasF4kRU+6Z 7VKw== X-Gm-Message-State: APjAAAWCL0q8cTNcswWbFgsggkCptVTqI1B8Z1BRwYw/sGzlwQnu/60Z jcYx39UljvBotIXRgHAjLDNK1iSWhdHv6rJgQPY= X-Google-Smtp-Source: APXvYqzWMpkGke/6P40cxELnIW03wy+v3i8SQmvS0VODPh1zVPS1/jmvwK5NgiBe0XTYdefBkOid5JYj23OyuHsk1uM= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr23507035ljj.212.1582312604425; Fri, 21 Feb 2020 11:16:44 -0800 (PST) MIME-Version: 1.0 References: <58F0F4E4-E9AE-45E0-92F1-60B993B75A34@amazon.com> <5F770E76-D07D-4464-A6AE-2442AE055B43@amazon.com> <0092A517-C90B-41A6-8272-D779E84E10C9@amazon.com> In-Reply-To: From: Dick Hardt Date: Fri, 21 Feb 2020 11:16:18 -0800 Message-ID: To: Justin Richer Cc: Matthew De Haast , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b5e1e1059f1adc75" Archived-At: Subject: Re: [Txauth] XAuth -02 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 19:16:48 -0000 --000000000000b5e1e1059f1adc75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2020 at 8:18 AM Justin Richer wrote: > > > On Feb 21, 2020, at 9:16 AM, Matthew De Haast < > matt=3D40coil.com@dmarc.ietf.org> wrote: > > > On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt wrote: > >> >> >> On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast > 40coil.com@dmarc.ietf.org> wrote: >> >>> Thanks for this Dick. Appreciate the draft to be able to compare ideas >>> to XYZ. The rational section also helped as it answered some of the >>> questions I was going to ask. >>> >>> 1. OPTIONS for metadata. I really like this way of asking for metadata >>> on the resources. >>> >>> 2. We have both the Read Grant endpoint and then an explicit Token >>> Refresh endpoint? Is it not possible that if a client wanted to refresh= the >>> tokens it could just do a Read against the grant? Thinking aloud, the >>> biggest issue with what I propose is token lifecycle and how to handle = that. >>> >> >> I was thinking a read against the Grant would return everything in the >> Grant, which would include a refresh of all tokens, and return all claim= s >> >> > This isn=E2=80=99t particularly idiomatic for HTTP, where a GET request i= sn=E2=80=99t > supposed to create something new. > I did not consider this a new thing, but the latest version of it. =E1=90=A7 --000000000000b5e1e1059f1adc75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 21, 2020 at 8:18 AM Justi= n Richer <jricher@mit.edu> wro= te:


On Feb 21, 2020, at 9:16 AM, Matthew De Haast <matt=3D40coil.com@dmarc.iet= f.org> wrote:


On Tue, Feb 1= 8, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:


<= div>I did not consider this a new thing, but the latest version of it. --000000000000b5e1e1059f1adc75-- From nobody Fri Feb 21 11:31:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8412008B for ; Fri, 21 Feb 2020 11:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 d0AFw4iWI_sO for ; Fri, 21 Feb 2020 11:31:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7F0481200C5 for ; Fri, 21 Feb 2020 11:31:39 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LJVY79026540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 14:31:35 -0500 From: Justin Richer Message-Id: <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_D97288F3-B575-44A3-B434-11DC03976414" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Feb 2020 14:31:34 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" To: Dick Hardt References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 19:31:56 -0000 --Apple-Mail=_D97288F3-B575-44A3-B434-11DC03976414 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote: >=20 >=20 >=20 > On Fri, Feb 21, 2020 at 8:38 AM Justin Richer > wrote: > I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we have: >=20 > This sentence looks to be missing something. Apologies: We realized they both used AS-composed URLs to get the user = to the AS in a web browser for interaction purposes. > =20 >=20 > - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) >=20 > As stated in this thread, it may be useful for the AS to know if the = URL will be in a QR code, or in a full redirect. >=20 > In XAuth, the GS(AS min XYA) closes the popup to minimize what a = Client has to do, so it needs to know the difference between a popup, = and a full browser redirect. This is targetted at SPAs, where an = additional URL to redirect to is extra work. > =20 > - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) > - callback: tells the AS that the client can receive the completion = message from a front channel interaction through a redirect. Note that = the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this = field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:. >=20 > In a full redirect, the Client wants the AS to send the user back so = that it can continue. >=20 > The only parameter in the completion message is the nonce, which seems = superfluous. See below. > =20 >=20 > These three can be combined in different ways depending on what you = want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= >=20 > On top of that, they can be combined with other methods. Maybe I can = send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. >=20 > Per my question later in this thread, why would the Client not know = what interaction it wants prior to the request? What do you mean? The client does know what it wants and that=E2=80=99s = why it=E2=80=99s asking for what it wants. We=E2=80=99re debating = different methods for the client to ask for what it wants. This question = does not make sense to me. >=20 > If the AS is doing CIBA, that is not a decision just for the Client. = Both the AS and the Client need to know they are doing CIBA. (FWIW: I = think this work supersedes CIBA) As I=E2=80=99ve stated previously, I believe the interaction methods = here can supersede CIBA. >=20 > Additionally, different interactions have different risk profiles. = Sophisticated ASes will use that signal in the risk assessment, and may = do ask for additional authentication or verification. > =20 Yes, exactly my point. Because different interactions have different = risks, the AS will need to be able to decide which interactions it=E2=80=99= s OK with for a given request. This could vary based on what=E2=80=99s = being requested, or who=E2=80=99s doing the requesting. >=20 > An interesting difference between XYZ and XAuth=E2=80=99s approaches = is that XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D = in the callback response (which in turn is based on the OAuth 1 = =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an = =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of = nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and = the back channel response for a given transaction =E2=80=94 and note = that I=E2=80=99m really open to having a better way to generate and = calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it. >=20 > XAuth has removed the authorization code concept in its redirect = return, and clients only do polling against the GS API in order to get = tokens. While I obviously think it=E2=80=99s very valuable to remove = things from the front channel, I don=E2=80=99t think this is something = we can remove without opening up attack surfaces that have already been = identified in previous protocols. I would like to understand why XAuth = is not susceptible to the same kinds of attacks, or if it is, what = mitigations there are for them.=20 >=20 > Unlike OAuth 2.0, there are no parameters in the front channel = response to the Client. The redirect back to the Client is only needed = to return the interaction back to the Client. This argument rings tautologically hollow =E2=80=94 there are no = parameters because you=E2=80=99ve defined that there aren=E2=80=99t any = in XAuth. XYZ does have parameters, to tie the front and back channel = requests together when doing redirect back and forth. If you=E2=80=99re not doing a redirect back (ie, not sending a = =E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a = polling mechanism like XAuth, the device flow, etc. There are very real = risks to this. >=20 > XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >=20 > In OAuth, the AS gives a code to the User to give to the Client that = the Client then gives to the GS. >=20 > In XAuth, the AS gives a "code" to the Client that givers it to the = User to give to the GS. >=20 > In XAuth, the "code" is either a user code, or something embedded in = the URI the User is redirected to. >=20 > Therefore, there is nothing to protect in the redirect back to the = Client. >=20 > If I'm missing an attack, please elaborate how it would happen. One form of impersonation is well documented: = https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7592= 50a0e7 OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar request = initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and = it=E2=80=99s susceptible to the same kind of issue. > =20 >=20 > =E2=80=94 Justin >=20 >> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = > wrote: >>=20 >> Thanks for the update, Dick! I=E2=80=99m going to confine my comments = here to interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D >> =20 >> Once the GS hands that URI back to the Client, it has zero control = over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of = other as-yet-not-invented things with it. Moreover, the Client may not = know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for =E2=80=9D? >> =20 >> Even if we consider things like QR code data capacity, that=E2=80=99s = really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. And it=E2=80=99s = not clear to me how including a URI length limitation in the request = helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99= t it always return that? On the client side, it can look at the length = of the URI provided and decide what to do with it (e.g., render a QR = code or display it or do nothing with it). >> =20 >> So that really leaves us with two interaction modes that we need: >> =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be human = friendly; and >> =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code entry = page, both of which are human-friendly. >> =20 >> Those could be combinable to get both, and even if we don=E2=80=99t = go down the multiple interaction mode route we could add the full URI to = the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt = anything to do so. >> =20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> =20 >> =20 >> From: Txauth > on behalf of Dick Hardt = > >> Date: Tuesday, February 18, 2020 at 6:04 PM >> To: "txauth@ietf.org " > >> Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >> =20 >> Added in user code interaction and aligned QR code to be a superset = of user code. >> Fixed descriptions. >> =20 >>=20 >> ---------- Forwarded message --------- >> From: > >> Date: Tue, Feb 18, 2020 at 6:00 PM >> Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt >> To: Dick Hardt > >>=20 >>=20 >>=20 >> A new version of I-D, draft-hardt-xauth-protocol-03.txt >> has been successfully submitted by Dick Hardt and posted to the >> IETF repository. >>=20 >> Name: draft-hardt-xauth-protocol >> Revision: 03 >> Title: The XAuth Protocol >> Document date: 2020-02-18 >> Group: Individual Submission >> Pages: 53 >> URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = >> Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = >> Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >>=20 >> Abstract: >> Client software often desires resources or identity claims that = are >> independent of the client. This protocol allows a user and/or >> resource owner to delegate resource authorization and/or release = of >> identity claims to a server. Client software can then request = access >> to resources and/or identity claims by calling the server. The >> server acquires consent and authorization from the user and/or >> resource owner if required, and then returns to the client = software >> the authorization and identity claims that were approved. This >> protocol can be extended to support alternative authorizations, >> claims, interactions, and client authentication mechanisms. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 >> =E1=90=A7 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_D97288F3-B575-44A3-B434-11DC03976414 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 21, 2020, at 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Fri, Feb 21, 2020 at 8:38 AM Justin = Richer <jricher@mit.edu> wrote:
I=E2=80=99m in complete agreement with = Annabelle. In = XYZ we realized that both the QR Code and Authorization Code, and that = the only difference is how the user gets back to the client. So = instead of inventing a new type of interaction, we split them. In XYZ, = we have:

This= sentence looks to be missing = something.

Apologies: We realized they both used AS-composed = URLs to get the user to the AS in a web browser for interaction = purposes.

 

 - redirect: tells the AS that the client can send the = user to an arbitrary URL (and the AS doesn=E2=80=99t care how the client = gets that info to the user; could be a redirect or an image or send a = push notification to a secondary device, we don=E2=80=99t care as long = as the user shows up in a browser at the AS =E2=80=94 so maybe this = field can be renamed to be more universally = accurate)

As stated in this thread, it may be = useful for the AS to know if the URL will be in a QR code, or in a full = redirect.

In = XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has = to do, so it needs to know the difference between a popup, and a full = browser redirect. This is targetted at SPAs, where an additional URL to = redirect to is extra work.
 
 - code: tells the AS that = the client can present a short code the user can type (along with a = static URL the user can get to, maybe by typing the URL manually, but = it=E2=80=99s not dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the = client can receive the completion message from a front channel = interaction through a redirect. Note that the client might have gotten = to the AS through a redirect on-device, through a QR-code off device, or = through some other magic, and this field isn=E2=80=99t concerned with = that =E2=80=94 it=E2=80=99s only concerned with how to get the user = :back:.

In a full redirect, the Client wants = the AS to send the user back so that it can continue.

The only parameter in = the completion message is the nonce, which seems superfluous. See = below.
 

These three can be combined in = different ways depending on what you want to do at the client. Let=E2=80=99= s say you=E2=80=99re doing and OAuth2 style authorization code, you=E2=80=99= d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D = together. If you=E2=80=99re doing a plain user code, you=E2=80=99d use = =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re doing just a QR code with = polling, you use just =E2=80=9Credirect=E2=80=9D to get the long URL. If = you=E2=80=99re doing a user code and a QR code together, you use = =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D to get the long = URL and the short code not he screen at the same time. 

On top of that, they can = be combined with other methods. Maybe I can send the user to an = arbitrary URL but also display a human-readable verification code (like = CIBA), or send something in a push notification but also give them a = message to type, or I=E2=80=99m getting claims from an agent but I want = them redirected back through the browser. The client gets to decide what = kinds of interaction it can do and how to use these pieces in ways that = make the most sense.

Per my question later in this thread, = why would the Client not know what interaction it wants prior to the = request?

What do you mean? The client does know what it = wants and that=E2=80=99s why it=E2=80=99s asking for what it wants. = We=E2=80=99re debating different methods for the client to ask for what = it wants. This question does not make sense to me.


If the AS is doing CIBA, that is not a = decision just for the Client. Both the AS and the Client need to know = they are doing CIBA. (FWIW: I think this work supersedes = CIBA)

As I=E2=80=99ve stated previously, I believe the = interaction methods here can supersede CIBA.


Additionally, different interactions = have different risk profiles. Sophisticated ASes will use that signal in = the risk assessment, and may do ask for additional authentication or = verification.
 

Yes, exactly my point. Because different = interactions have different risks, the AS will need to be able to decide = which interactions it=E2=80=99s OK with for a given request. This could = vary based on what=E2=80=99s being requested, or who=E2=80=99s doing the = requesting.


An interesting difference between XYZ = and XAuth=E2=80=99s approaches is that XYZ keeps the concept of the = =E2=80=9Cauthorization code=E2=80=9D in the callback response (which in = turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In = XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along = with a pair of nonces generated by the client and the AS in the back = channel. This binds the front channel response to both the back channel = request and the back channel response for a given transaction =E2=80=94 = and note that I=E2=80=99m really open to having a better way to generate = and calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it.

XAuth has removed the authorization = code concept in its redirect return, and clients only do polling against = the GS API in order to get tokens. While I obviously think it=E2=80=99s = very valuable to remove things from the front channel, I don=E2=80=99t = think this is something we can remove without opening up attack surfaces = that have already been identified in previous protocols. I would like to = understand why XAuth is not susceptible to the same kinds of attacks, or = if it is, what mitigations there are for = them. 

Unlike OAuth 2.0, there are no = parameters in the front channel response to the Client. The redirect = back to the Client is only needed to return the interaction back to the = Client.

This argument rings tautologically hollow =E2=80=94 = there are no parameters because you=E2=80=99ve defined that there = aren=E2=80=99t any in XAuth. XYZ does have parameters, to tie the front = and back channel requests together when doing redirect back and = forth.

If you=E2=80=99re not doing a = redirect back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction = block), then it=E2=80=99s a polling mechanism like XAuth, the device = flow, etc. There are very real risks to this.


XAuth (and XYZ) have a different flow = than OAuth 2.0 (or OAuth 1.0)

In OAuth, the AS gives a code to the = User to give to the Client that the Client then gives to the = GS.

In XAuth, = the AS gives a "code" to the Client that givers it to the User to give = to the GS.

In = XAuth, the "code" is either a user code, or something embedded in the = URI the User is redirected to.

Therefore, there is nothing to protect = in the redirect back to the Client.

If I'm missing an attack, please = elaborate how it would = happen.


OAuth 1.0=E2=80=99= s =E2=80=9CRequest Token=E2=80=9D is a similar request initiation step = to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s = susceptible to the same kind of issue.

 

 =E2=80=94 Justin

On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = <richanna=3D40amazon.com@dmarc.ietf.org>= ; wrote:

Thanks = for the update, Dick! I=E2=80=99m going to confine my comments here to = interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
 
Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for <some other machine-driven interaction mode>=E2=80=9D?
 
Even if we consider things like QR code data capacity, = that=E2=80=99s really just a URI length limitation, which could apply to = non-QR interaction modes, e.g., if the Client device wants to = communicate the URI over an extremely bandwidth-constrained channel. And = it=E2=80=99s not clear to me how including a URI length limitation in = the request helps. If a GS is capable of generating a shorter URI, why = wouldn=E2=80=99t it always return that? On the client side, it can look = at the length of the URI provided and decide what to do with it (e.g., = render a QR code or display it or do nothing with it).
 
So = that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a = code entry page, both of which are human-friendly.
 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in = user code interaction and aligned QR code to be a superset of user = code.
Fixed = descriptions.

 

----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat

=E1=90=A7
-- 
Txauth mailing = list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


= --Apple-Mail=_D97288F3-B575-44A3-B434-11DC03976414-- From nobody Fri Feb 21 12:40:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AFB12008A for ; Fri, 21 Feb 2020 12:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ajNZGUUZuzJo for ; Fri, 21 Feb 2020 12:40:44 -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 139DD120086 for ; Fri, 21 Feb 2020 12:40:44 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id x14so3514501ljd.13 for ; Fri, 21 Feb 2020 12:40:43 -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=aBV/n9U4+LR2xz8trZRFDMlEuMpdpwCaF/z6Eu6xFmQ=; b=VkG4ln0P+huT2s4XReqYDyO59ygFKWrlclADYG8BhU0tdaI0UQxOrZXIQNXzUN/NZI tHDUOJHi5v0le0Cl4UjIcc3RsSkcFMTP8C+joZ5lr2ry1KcyQtWCS5VUTh0llRCUK+lF kiz8yxJ/DgQAXKPSxMxnDz1m8M5tD2h1HQ10HgeuuYASuC/PNDiNxl7TOpbrD54rxNQE RhDsV6uSLXfF1VuuYnH6H6fKvZ3kNZTD0QMGHbaI5jAfcgoTaw+7l4agT9I7hhjeKxgW Ak7KI9caGpJeACwG58sC3iObI6rmDhhS5PA1VsJYR1WuH5MdC0UdCkvmzu5Xrvbvhgqk gN5Q== 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=aBV/n9U4+LR2xz8trZRFDMlEuMpdpwCaF/z6Eu6xFmQ=; b=TSwIY/UJzVogH+0G806c6FvQPAQ5KfjRtl3mH8p6lGWBjb9+zi4ZGSB2fR321c8bDX 18UOc4kXIuHVBCQbU+Tg+9jbUhram93MvPFQjSTQeWg2teKG3w4KaDD4Z9caBmejYQDo FoRtSCKhQScJmKTRnmddtxDzeyGk1E9YyEU8QNyMn1HBThym/oLMTxcTbST5m26oikjE f7s/cXBeXQDHil1LO+bAnzK4qfT+FjFOsAOCfbHKRnx2v6nhFZBOrS8TZI8yhkujgWgK D07mwyNCa20Ayr/jnblFKJzbrWJIbUCnQtdTJU5Pv3XGDIBnjkbM3XmG4H+OBnAXhhcq iUnw== X-Gm-Message-State: APjAAAW/JsJ8aDgZ0lqjOub02QnrrKUDsuZaVfi67CXPcz78YqHqrPYK IsP1Gw7tPwI03uztTjAad67/D3lew3nTl8le1YXVzbtQ X-Google-Smtp-Source: APXvYqz3N2kuO8aHJ26+smRgHB1/T5hkbi88WF3M41GsyNvQZ8Fl9WpbVZbmzg9j1wZZst5p6RmI8WAmWW9epESFD/k= X-Received: by 2002:a2e:b5b4:: with SMTP id f20mr23855119ljn.112.1582317642159; Fri, 21 Feb 2020 12:40:42 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> In-Reply-To: <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> From: Dick Hardt Date: Fri, 21 Feb 2020 12:40:12 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fb9a12059f1c08e1" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 20:40:49 -0000 --000000000000fb9a12059f1c08e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The lightbulb finally clicked on for me. Thanks for your patience. The threat you are describing is where the attacker starts a transaction at the client, and gets the victim to complete it. Correct? I still think the Client should be able to signal if it will be doing a redirect vs showing a QR code (or wants to do both). Being able to provide a completion URI even if the user is starting on a device is a great insight on how to address the threat above. I'm going to ponder how to align XAuth more with these features of XYZ. =E1=90=A7 On Fri, Feb 21, 2020 at 11:31 AM Justin Richer wrote: > On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote: > > > > > On Fri, Feb 21, 2020 at 8:38 AM Justin Richer wrote: > >> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized tha= t both >> the QR Code and Authorization Code, and that the only difference is how = the >> user gets back to the client. So instead of inventing a new type of >> interaction, we split them. In XYZ, we have: >> > > This sentence looks to be missing something. > > > Apologies: We realized they both used AS-composed URLs to get the user to > the AS in a web browser for interaction purposes. > > > >> >> - redirect: tells the AS that the client can send the user to an >> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the >> user; could be a redirect or an image or send a push notification to a >> secondary device, we don=E2=80=99t care as long as the user shows up in = a browser >> at the AS =E2=80=94 so maybe this field can be renamed to be more univer= sally >> accurate) >> > > As stated in this thread, it may be useful for the AS to know if the URL > will be in a QR code, or in a full redirect. > > In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client > has to do, so it needs to know the difference between a popup, and a full > browser redirect. This is targetted at SPAs, where an additional URL to > redirect to is extra work. > > >> - code: tells the AS that the client can present a short code the user >> can type (along with a static URL the user can get to, maybe by typing t= he >> URL manually, but it=E2=80=99s not dynamic/arbitrary like the redirect m= ethod) >> - callback: tells the AS that the client can receive the completion >> message from a front channel interaction through a redirect. Note that t= he >> client might have gotten to the AS through a redirect on-device, through= a >> QR-code off device, or through some other magic, and this field isn=E2= =80=99t >> concerned with that =E2=80=94 it=E2=80=99s only concerned with how to ge= t the user :back:. >> > > In a full redirect, the Client wants the AS to send the user back so that > it can continue. > > The only parameter in the completion message is the nonce, which seems > superfluous. See below. > > >> >> These three can be combined in different ways depending on what you want >> to do at the client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 s= tyle authorization >> code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback= =E2=80=9D together. If you=E2=80=99re doing a plain >> user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re d= oing just a QR code with polling, >> you use just =E2=80=9Credirect=E2=80=9D to get the long URL. If you=E2= =80=99re doing a user code >> and a QR code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9C= code=E2=80=9D to get the long URL >> and the short code not he screen at the same time. >> >> On top of that, they can be combined with other methods. Maybe I can sen= d >> the user to an arbitrary URL but also display a human-readable verificat= ion >> code (like CIBA), or send something in a push notification but also give >> them a message to type, or I=E2=80=99m getting claims from an agent but = I want them >> redirected back through the browser. The client gets to decide what kind= s >> of interaction it can do and how to use these pieces in ways that make t= he >> most sense. >> > > Per my question later in this thread, why would the Client not know what > interaction it wants prior to the request? > > > What do you mean? The client does know what it wants and that=E2=80=99s w= hy it=E2=80=99s > asking for what it wants. We=E2=80=99re debating different methods for th= e client > to ask for what it wants. This question does not make sense to me. > > > If the AS is doing CIBA, that is not a decision just for the Client. Both > the AS and the Client need to know they are doing CIBA. (FWIW: I think th= is > work supersedes CIBA) > > > As I=E2=80=99ve stated previously, I believe the interaction methods here= can > supersede CIBA. > > > Additionally, different interactions have different risk profiles. > Sophisticated ASes will use that signal in the risk assessment, and may d= o > ask for additional authentication or verification. > > > > Yes, exactly my point. Because different interactions have different > risks, the AS will need to be able to decide which interactions it=E2=80= =99s OK > with for a given request. This could vary based on what=E2=80=99s being r= equested, > or who=E2=80=99s doing the requesting. > > >> An interesting difference between XYZ and XAuth=E2=80=99s approaches is = that XYZ >> keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in the cal= lback response >> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D = field). In XYZ, you >> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pa= ir of nonces >> generated by the client and the AS in the back channel. This binds the >> front channel response to both the back channel request and the back >> channel response for a given transaction =E2=80=94 and note that I=E2=80= =99m really open to >> having a better way to generate and calculate such a binding, but I thin= k >> this works. In any event, this protects the client from session fixation >> and injection on the return from the front channel that it=E2=80=99s sus= ceptible to >> in a pure polling model, and the hashing approach basically combines the >> security parameters of the OAuth 2 authorization code and (to an extent) >> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one el= ement. This is only >> applicable if you=E2=80=99re coming back to the client and you can valid= ate the >> hash and present the reference parameter. If you=E2=80=99re doing just p= lain >> polling, you don=E2=80=99t have that protection =E2=80=94 but the client= and the AS are >> aware of that risk, and there=E2=80=99s an option to prevent it. >> >> XAuth has removed the authorization code concept in its redirect return, >> and clients only do polling against the GS API in order to get tokens. >> While I obviously think it=E2=80=99s very valuable to remove things from= the front >> channel, I don=E2=80=99t think this is something we can remove without o= pening up >> attack surfaces that have already been identified in previous protocols.= I >> would like to understand why XAuth is not susceptible to the same kinds = of >> attacks, or if it is, what mitigations there are for them. >> > > Unlike OAuth 2.0, there are no parameters in the front channel response t= o > the Client. The redirect back to the Client is only needed to return the > interaction back to the Client. > > > This argument rings tautologically hollow =E2=80=94 there are no paramete= rs > because you=E2=80=99ve defined that there aren=E2=80=99t any in XAuth. XY= Z does have > parameters, to tie the front and back channel requests together when doin= g > redirect back and forth. > > If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=80=9Cc= allback=E2=80=9D > interaction block), then it=E2=80=99s a polling mechanism like XAuth, the= device > flow, etc. There are very real risks to this. > > > XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) > > In OAuth, the AS gives a code to the User to give to the Client that the > Client then gives to the GS. > > In XAuth, the AS gives a "code" to the Client that givers it to the User > to give to the GS. > > In XAuth, the "code" is either a user code, or something embedded in the > URI the User is redirected to. > > Therefore, there is nothing to protect in the redirect back to the Client= . > > If I'm missing an attack, please elaborate how it would happen. > > > One form of impersonation is well documented: > https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759= 250a0e7 > > OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar request = initiation step to what > we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s susceptible t= o the same > kind of issue. > > > >> >> =E2=80=94 Justin >> >> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < >> richanna=3D40amazon.com@dmarc.ietf.org> wrote: >> >> Thanks for the update, Dick! I=E2=80=99m going to confine my comments he= re to >> interaction mode design, setting aside whether or not we need =E2=80=9Cp= opup=E2=80=9D. :D >> >> Once the GS hands that URI back to the Client, it has zero control over >> how the Client uses it. The Client could present any URI (of a reasonabl= e >> size) into a QR code, or present it as a clickable link, or redirect to = it, >> or open it in an external browser, or do any number of other >> as-yet-not-invented things with it. Moreover, the Client may not know ye= t >> what it wants to do with it. So what value is there in distinguishing >> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI wan= t a URI for a QR code=E2=80=9D vs. >> =E2=80=9CI want a URI for = =E2=80=9D? >> >> Even if we consider things like QR code data capacity, that=E2=80=99s re= ally just >> a URI length limitation, which could apply to non-QR interaction modes, >> e.g., if the Client device wants to communicate the URI over an extremel= y >> bandwidth-constrained channel. And it=E2=80=99s not clear to me how incl= uding a URI >> length limitation in the request helps. If a GS is capable of generating= a >> shorter URI, why wouldn=E2=80=99t it always return that? On the client s= ide, it can >> look at the length of the URI provided and decide what to do with it (e.= g., >> render a QR code or display it or do nothing with it). >> >> So that really leaves us with two interaction modes that we need: >> >> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be hum= an friendly; and >> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code ent= ry page, both of >> which are human-friendly. >> >> >> Those could be combinable to get both, and even if we don=E2=80=99t go d= own the >> multiple interaction mode route we could add the full URI to the =E2=80= =9Ccode=E2=80=9D >> interaction object. It wouldn=E2=80=99t hurt anything to do so. >> >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> >> >> *From: *Txauth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Tuesday, February 18, 2020 at 6:04 PM >> *To: *"txauth@ietf.org" >> *Subject: *[Txauth] Fwd: New Version Notification for >> draft-hardt-xauth-protocol-03.txt >> >> Added in user code interaction and aligned QR code to be a superset of >> user code. >> Fixed descriptions. >> >> >> ---------- Forwarded message --------- >> From: >> Date: Tue, Feb 18, 2020 at 6:00 PM >> Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt >> To: Dick Hardt >> >> >> >> >> A new version of I-D, draft-hardt-xauth-protocol-03.txt >> has been successfully submitted by Dick Hardt and posted to the >> IETF repository. >> >> Name: draft-hardt-xauth-protocol >> Revision: 03 >> Title: The XAuth Protocol >> Document date: 2020-02-18 >> Group: Individual Submission >> Pages: 53 >> URL: >> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt >> Status: >> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ >> Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-0= 3 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 >> >> Abstract: >> Client software often desires resources or identity claims that are >> independent of the client. This protocol allows a user and/or >> resource owner to delegate resource authorization and/or release of >> identity claims to a server. Client software can then request access >> to resources and/or identity claims by calling the server. The >> server acquires consent and authorization from the user and/or >> resource owner if required, and then returns to the client software >> the authorization and identity claims that were approved. This >> protocol can be extended to support alternative authorizations, >> claims, interactions, and client authentication mechanisms. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> > --000000000000fb9a12059f1c08e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The lightbulb finally clicked on for me. Thanks for your p= atience.

The threat you are describing is where the atta= cker starts a transaction at the client, and gets the victim to complete it= . Correct?

I still think the Client should be able t= o signal if it will be doing a redirect vs showing a QR code (or wants to d= o both).

Being able to provide a completion URI ev= en if the user is starting on a device is a great insight on how to address= the threat above.=C2=A0

I'm going to ponder how= to align XAuth more with these features of XYZ.
3D""=E1=90=A7
On Fri, Feb 21, 2020 at 11:31 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> 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">
On Feb 21, 2020, at 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wro= te:



On Fri, Feb 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in co= mplete agreement with Annabelle. In XYZ we realized that both the QR Code and Authorization Code, and = that the only difference is how the user gets back to the client. So= instead of inventing a new type of interaction, we split them. In XYZ, we = have:

This sentence looks to be missing something.
<= /div>

Apologies: We realized th= ey both used AS-composed URLs to get the user to the AS in a web browser fo= r interaction purposes.

=C2=A0

=C2=A0- redirect: tells t= he AS that the client can send the user to an arbitrary URL (and the AS doe= sn=E2=80=99t care how the client gets that info to the user; could be a red= irect or an image or send a push notification to a secondary device, we don= =E2=80=99t care as long as the user shows up in a browser at the AS =E2=80= =94 so maybe this field can be renamed to be more universally accurate)

As stated in this thread, it may b= e useful for the AS to know if the URL will be in a QR code, or in a full r= edirect.

In XAuth, the GS(AS min XYA) closes the p= opup to minimize what a Client has to do, so it needs to know the differenc= e between a popup, and a full browser redirect. This is targetted at SPAs, = where an additional URL to redirect to is extra work.
=C2=A0
=C2=A0- code: = tells the AS that the client can present a short code the user can type (al= ong with a static URL the user can get to, maybe by typing the URL manually= , but it=E2=80=99s not dynamic/arbitrary like the redirect method)
= =C2=A0- callback: tells the AS that the client can receive the completion m= essage from a front channel interaction through a redirect. Note that the c= lient might have gotten to the AS through a redirect on-device, through a Q= R-code off device, or through some other magic, and this field isn=E2=80=99= t concerned with that =E2=80=94 it=E2=80=99s only concerned with how to get= the user :back:.

In a fu= ll redirect, the Client wants the AS to send the user back so that it can c= ontinue.

The only parameter in the completion mess= age is the nonce, which seems superfluous. See below.
=C2=A0

These three can be combined in different ways depending on what you w= ant to do at the client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 = style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain user c= ode, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re doing just= a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D to get the= long URL. If you=E2=80=99re doing a user code and a QR code together, you = use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D to get the long U= RL and the short code not he screen at the same time.=C2=A0

<= /div>
On top of that, they can be combined with other methods. Maybe I = can send the user to an arbitrary URL but also display a human-readable ver= ification code (like CIBA), or send something in a push notification but al= so give them a message to type, or I=E2=80=99m getting claims from an agent= but I want them redirected back through the browser. The client gets to de= cide what kinds of interaction it can do and how to use these pieces in way= s that make the most sense.

Per my question later in this thread, why would the Client not know what= interaction it wants prior to the request?

What do you mean? The client does know what it wan= ts and that=E2=80=99s why it=E2=80=99s asking for what it wants. We=E2=80= =99re debating different methods for the client to ask for what it wants. T= his question does not make sense to me.

=

If the= AS is doing CIBA, that is not a decision just for the Client. Both the AS = and the Client need to know they are doing CIBA. (FWIW: I think this work s= upersedes CIBA)

As = I=E2=80=99ve stated previously, I believe the interaction methods here can = supersede CIBA.


Additionally, different intera= ctions have different risk profiles. Sophisticated ASes will use that signa= l in the risk assessment, and may do ask for additional authentication or v= erification.
=C2=A0

=
Yes, exactly my point. Because different interactions have diffe= rent risks, the AS will need to be able to decide which interactions it=E2= =80=99s OK with for a given request. This could vary based on what=E2=80=99= s being requested, or who=E2=80=99s doing the requesting.


An = interesting difference between XYZ and XAuth=E2=80=99s approaches is that X= YZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in the cal= lback response (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifi= er=E2=80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D wh= ich is hashed along with a pair of nonces generated by the client and the A= S in the back channel. This binds the front channel response to both the ba= ck channel request and the back channel response for a given transaction = =E2=80=94 and note that I=E2=80=99m really open to having a better way to g= enerate and calculate such a binding, but I think this works. In any event,= this protects the client from session fixation and injection on the return= from the front channel that it=E2=80=99s susceptible to in a pure polling = model, and the hashing approach basically combines the security parameters = of the OAuth 2 authorization code and (to an extent) state, PKCE=E2=80=99s = code_challenge, and OIDC=E2=80=99s nonce in one element. This is only appli= cable if you=E2=80=99re coming back to the client and you can validate the = hash and present the reference parameter. If you=E2=80=99re doing just plai= n polling, you don=E2=80=99t have that protection =E2=80=94 but the client = and the AS are aware of that risk, and there=E2=80=99s an option to prevent= it.

XAuth has removed the authorization code conc= ept in its redirect return, and clients only do polling against the GS API = in order to get tokens. While I obviously think it=E2=80=99s very valuable = to remove things from the front channel, I don=E2=80=99t think this is some= thing we can remove without opening up attack surfaces that have already be= en identified in previous protocols. I would like to understand why XAuth i= s not susceptible to the same kinds of attacks, or if it is, what mitigatio= ns there are for them.=C2=A0

<= div>Unlike OAuth 2.0, there are no parameters in the front channel response= to the Client. The redirect back to the Client is only needed to return th= e interaction back to the Client.
=
This argument rings tautologically hollow =E2=80=94 there ar= e no parameters because you=E2=80=99ve defined that there aren=E2=80=99t an= y in XAuth. XYZ does have parameters, to tie the front and back channel req= uests together when doing redirect back and forth.

If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=80=9Cca= llback=E2=80=9D interaction block), then it=E2=80=99s a polling mechanism l= ike XAuth, the device flow, etc. There are very real risks to this.

XAuth (and XYZ) have a different flow than OAuth 2.0 = (or OAuth 1.0)

In OAuth, the AS gives a code to th= e User to give to the Client that the Client then gives to the GS.

In XAuth, the AS gives a "code" to the Client th= at givers it to the User to give to the GS.

In XAu= th, the "code" is either a user code, or something embedded in th= e URI the User is redirected to.

Therefore, there = is nothing to protect in the redirect back to the Client.

If I'm missing an attack, please elaborate how it would happen.=



=C2=A0

Thanks for the update, Dick! I=E2=80=99m g= oing to confine my comments here to interaction mode design, setting aside = whether or not we need =E2=80=9Cpopup=E2=80=9D. :D
=C2=A0
Once the GS hands that URI back to= the Client, it has zero control over how the Client uses it. The Client co= uld present any URI (of a reasonable size) into a QR code, or present it as= a clickable link, or redirect to it, or open it in an external browser, or= do any number of other as-yet-not-invented things with it. Moreover, the C= lient may not know yet what it wants to do with it. So what value is there = in distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs.= =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI for= <some other machine-driven interaction mode>=E2=80=9D?=
=C2=A0
Even if we consider thi= ngs like QR code data capacity, that=E2=80=99s really just a URI length lim= itation, which could apply to non-QR interaction modes, e.g., if the Client= device wants to communicate the URI over an extremely bandwidth-constraine= d channel. And it=E2=80=99s not clear to me how including a URI length limi= tation in the request helps. If a GS is capable of generating a shorter URI= , why wouldn=E2=80=99t it always return that? On the client side, it can lo= ok at the length of the URI provided and decide what to do with it (e.g., r= ender a QR code or display it or do nothing with it).
=C2=A0
So that really leaves us with t= wo interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, whi= ch returns a full URI that may not be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code e= ntry page, both of which are human-friendly.
=C2=A0
Those could be combinable to get bot= h, and even if we don=E2=80=99t go down the multiple interaction mode route= we could add the full URI to the =E2=80=9Ccode=E2=80=9D interaction object= . It wouldn=E2=80=99t hurt anything to do so.
= =C2=A0
=E2= =80=93
A= nnabelle Backman (she/her)
AWS Identity
=C2=A0
= =C2=A0
From:=C2=A0= Txauth <txauth-bounces@ietf.org> on behalf of Di= ck Hardt <dick= .hardt@gmail.com>
Date:=C2=A0Tuesday, Februar= y 18, 2020 at 6:04 PM
To:=C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0[Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt
=C2=A0
Added in u= ser code interaction and aligned QR code to be a superset of user code.<= /u>
Fixed descriptions.

=C2=A0

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, = Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for draft-hard= t-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, draft-hardt-xauth-protocol-03.t= xt
has been successfully submitted by Dick Hardt and posted to the
IE= TF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-h= ardt-xauth-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 = 2020-02-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submissio= n
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/internet-draf= ts/draft-hardt-xauth-protocol-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:= =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-h= ardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03

Abstrac= t:
=C2=A0 =C2=A0Client software often desires resources or identity clai= ms that are
=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol = allows a user and/or
=C2=A0 =C2=A0resource owner to delegate resource au= thorization and/or release of
=C2=A0 =C2=A0identity claims to a server.= =C2=A0 Client software can then request access
=C2=A0 =C2=A0to resources= and/or identity claims by calling the server.=C2=A0 The
=C2=A0 =C2=A0se= rver acquires consent and authorization from the user and/or
=C2=A0 =C2= =A0resource owner if required, and then returns to the client software
= =C2=A0 =C2=A0the authorization and identity claims that were approved.=C2= =A0 This
=C2=A0 =C2=A0protocol can be extended to support alternative au= thorizations,
=C2=A0 =C2=A0claims, interactions, and client authenticati= on mechanisms.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized version and diff = are available at=C2=A0tools.ietf.org<= /a>.

The IETF Secretariat

--=C2=A0
T= xauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--000000000000fb9a12059f1c08e1-- From nobody Fri Feb 21 12:52:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C18120089 for ; Fri, 21 Feb 2020 12:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 TgZtr626Ly3g for ; Fri, 21 Feb 2020 12:52:44 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72200120086 for ; Fri, 21 Feb 2020 12:52:43 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id x14so3545510ljd.13 for ; Fri, 21 Feb 2020 12:52:43 -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=Kc3ZFlWselK0EXnbiWsYHjdTLZe2zeOnwOQAYiH1TP0=; b=J/CpSYoS0gUz2VogSop+8G+NHELps9DxNvhhr54sw4aJVIpaUsI4ooK6l9Kom4/Dew 8ZpshZzglXAZcFlWP0Tt0XicHMLK2G5+qMI5PpiHQfFFLgaush36PbhSyfG3ew9q4bGN Pba+XCM+Ldaif6yQ+PxBmnPWzRE5L7J7WzbvLVZUMCjxuqxvgR/A4EZK27kfBzps3TkN irNy/xS9YxWa5Mx7SJIObkl5B0U7WhYKnUYouTsGmh0vHrC7AfjJTH6+puiSzkjS2F0t ufUSF4dzLz0MsO/Y/0n8UDmQFcoihxk5OMfeX65OJrob3Y2ssHh+USPmXfmtkgqHl9BA oOyg== 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=Kc3ZFlWselK0EXnbiWsYHjdTLZe2zeOnwOQAYiH1TP0=; b=ipid/QzlgR6SsXV5xS8WUpos3vR/LNQ+k4WIjcFnBnxSArNnEo6ya6dtoI5gJtvDls t6NNgCR4nRvO3MWL7KZFVjVrlLuo58pqNGaWSmsZIZ6J9L3hoOsiGsviFsiKdo/ppL3o ruj1B5BdyZZdWb45NckHiy+do23BD0RO9xCjkE5Xnm3N758HBsZctuVBCtDnRtk5Ac6V PK42ksu9roTQQHXxiQSVpMTWRpx/0QArOcP8otLkKkJeJZxZhTeIhgukNpcwd/SKK6T+ c0gQaTae8SgvqBdXc7F2ot627m45YjJL7Z5biHC3FGkUh5yLzdDaUM6SHLe8XDCv4Y0s yz/g== X-Gm-Message-State: APjAAAXc4q5GhhDD/Za2neq9PCNzHQ0V2O8p5jn7rgwOorbKAYIFF67G +z3d13biAUcxZFoudxt1Gj9QLN5TSoj92baYDRs= X-Google-Smtp-Source: APXvYqw3pucNbTddTf57OWIPSRfZkNDhG4r8vlCASrqNXcNVKeqIubGA8IOl4ozOYrsykMUfzKTggu7JwfzSFgVmKq8= X-Received: by 2002:a2e:808a:: with SMTP id i10mr22904249ljg.151.1582318361512; Fri, 21 Feb 2020 12:52:41 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 21 Feb 2020 12:52:15 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dc1016059f1c33b7" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 20:52:50 -0000 --000000000000dc1016059f1c33b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I got ahead of myself. A completion URI protects the User only if the User is sent back to the same channel the transaction started so the Client can confirm it is the same User that started the transaction. so this does not help the security: "Being able to provide a completion URI even if the user is starting on a device is a great insight on how to address the threat above." =E1=90=A7 On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt wrote: > The lightbulb finally clicked on for me. Thanks for your patience. > > The threat you are describing is where the attacker starts a transaction > at the client, and gets the victim to complete it. Correct? > > I still think the Client should be able to signal if it will be doing a > redirect vs showing a QR code (or wants to do both). > > Being able to provide a completion URI even if the user is starting on a > device is a great insight on how to address the threat above. > > I'm going to ponder how to align XAuth more with these features of XYZ. > =E1=90=A7 > > On Fri, Feb 21, 2020 at 11:31 AM Justin Richer wrote: > >> On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote: >> >> >> >> >> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer wrote: >> >>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized th= at both >>> the QR Code and Authorization Code, and that the only difference is how= the >>> user gets back to the client. So instead of inventing a new type of >>> interaction, we split them. In XYZ, we have: >>> >> >> This sentence looks to be missing something. >> >> >> Apologies: We realized they both used AS-composed URLs to get the user t= o >> the AS in a web browser for interaction purposes. >> >> >> >>> >>> - redirect: tells the AS that the client can send the user to an >>> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that= info to the >>> user; could be a redirect or an image or send a push notification to a >>> secondary device, we don=E2=80=99t care as long as the user shows up in= a browser >>> at the AS =E2=80=94 so maybe this field can be renamed to be more unive= rsally >>> accurate) >>> >> >> As stated in this thread, it may be useful for the AS to know if the URL >> will be in a QR code, or in a full redirect. >> >> In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client >> has to do, so it needs to know the difference between a popup, and a ful= l >> browser redirect. This is targetted at SPAs, where an additional URL to >> redirect to is extra work. >> >> >>> - code: tells the AS that the client can present a short code the user >>> can type (along with a static URL the user can get to, maybe by typing = the >>> URL manually, but it=E2=80=99s not dynamic/arbitrary like the redirect = method) >>> - callback: tells the AS that the client can receive the completion >>> message from a front channel interaction through a redirect. Note that = the >>> client might have gotten to the AS through a redirect on-device, throug= h a >>> QR-code off device, or through some other magic, and this field isn=E2= =80=99t >>> concerned with that =E2=80=94 it=E2=80=99s only concerned with how to g= et the user :back:. >>> >> >> In a full redirect, the Client wants the AS to send the user back so tha= t >> it can continue. >> >> The only parameter in the completion message is the nonce, which seems >> superfluous. See below. >> >> >>> >>> These three can be combined in different ways depending on what you wan= t >>> to do at the client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 = style authorization >>> code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallbac= k=E2=80=9D together. If you=E2=80=99re doing a plain >>> user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, >>> you use just =E2=80=9Credirect=E2=80=9D to get the long URL. If you=E2= =80=99re doing a user code >>> and a QR code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80= =9Ccode=E2=80=9D to get the long URL >>> and the short code not he screen at the same time. >>> >>> On top of that, they can be combined with other methods. Maybe I can >>> send the user to an arbitrary URL but also display a human-readable >>> verification code (like CIBA), or send something in a push notification= but >>> also give them a message to type, or I=E2=80=99m getting claims from an= agent but I >>> want them redirected back through the browser. The client gets to decid= e >>> what kinds of interaction it can do and how to use these pieces in ways >>> that make the most sense. >>> >> >> Per my question later in this thread, why would the Client not know what >> interaction it wants prior to the request? >> >> >> What do you mean? The client does know what it wants and that=E2=80=99s = why it=E2=80=99s >> asking for what it wants. We=E2=80=99re debating different methods for t= he client >> to ask for what it wants. This question does not make sense to me. >> >> >> If the AS is doing CIBA, that is not a decision just for the Client. Bot= h >> the AS and the Client need to know they are doing CIBA. (FWIW: I think t= his >> work supersedes CIBA) >> >> >> As I=E2=80=99ve stated previously, I believe the interaction methods her= e can >> supersede CIBA. >> >> >> Additionally, different interactions have different risk profiles. >> Sophisticated ASes will use that signal in the risk assessment, and may = do >> ask for additional authentication or verification. >> >> >> >> Yes, exactly my point. Because different interactions have different >> risks, the AS will need to be able to decide which interactions it=E2=80= =99s OK >> with for a given request. This could vary based on what=E2=80=99s being = requested, >> or who=E2=80=99s doing the requesting. >> >> >>> An interesting difference between XYZ and XAuth=E2=80=99s approaches is= that XYZ >>> keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in the ca= llback response >>> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D= field). In XYZ, you >>> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a p= air of nonces >>> generated by the client and the AS in the back channel. This binds the >>> front channel response to both the back channel request and the back >>> channel response for a given transaction =E2=80=94 and note that I=E2= =80=99m really open to >>> having a better way to generate and calculate such a binding, but I thi= nk >>> this works. In any event, this protects the client from session fixatio= n >>> and injection on the return from the front channel that it=E2=80=99s su= sceptible to >>> in a pure polling model, and the hashing approach basically combines th= e >>> security parameters of the OAuth 2 authorization code and (to an extent= ) >>> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one e= lement. This is only >>> applicable if you=E2=80=99re coming back to the client and you can vali= date the >>> hash and present the reference parameter. If you=E2=80=99re doing just = plain >>> polling, you don=E2=80=99t have that protection =E2=80=94 but the clien= t and the AS are >>> aware of that risk, and there=E2=80=99s an option to prevent it. >>> >>> XAuth has removed the authorization code concept in its redirect return= , >>> and clients only do polling against the GS API in order to get tokens. >>> While I obviously think it=E2=80=99s very valuable to remove things fro= m the front >>> channel, I don=E2=80=99t think this is something we can remove without = opening up >>> attack surfaces that have already been identified in previous protocols= . I >>> would like to understand why XAuth is not susceptible to the same kinds= of >>> attacks, or if it is, what mitigations there are for them. >>> >> >> Unlike OAuth 2.0, there are no parameters in the front channel response >> to the Client. The redirect back to the Client is only needed to return = the >> interaction back to the Client. >> >> >> This argument rings tautologically hollow =E2=80=94 there are no paramet= ers >> because you=E2=80=99ve defined that there aren=E2=80=99t any in XAuth. X= YZ does have >> parameters, to tie the front and back channel requests together when doi= ng >> redirect back and forth. >> >> If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=80=9C= callback=E2=80=9D >> interaction block), then it=E2=80=99s a polling mechanism like XAuth, th= e device >> flow, etc. There are very real risks to this. >> >> >> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >> >> In OAuth, the AS gives a code to the User to give to the Client that the >> Client then gives to the GS. >> >> In XAuth, the AS gives a "code" to the Client that givers it to the User >> to give to the GS. >> >> In XAuth, the "code" is either a user code, or something embedded in the >> URI the User is redirected to. >> >> Therefore, there is nothing to protect in the redirect back to the Clien= t. >> >> If I'm missing an attack, please elaborate how it would happen. >> >> >> One form of impersonation is well documented: >> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa75= 9250a0e7 >> >> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar request= initiation step to what >> we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s susceptible = to the same >> kind of issue. >> >> >> >>> >>> =E2=80=94 Justin >>> >>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < >>> richanna=3D40amazon.com@dmarc.ietf.org> wrote: >>> >>> Thanks for the update, Dick! I=E2=80=99m going to confine my comments h= ere to >>> interaction mode design, setting aside whether or not we need =E2=80=9C= popup=E2=80=9D. :D >>> >>> Once the GS hands that URI back to the Client, it has zero control over >>> how the Client uses it. The Client could present any URI (of a reasonab= le >>> size) into a QR code, or present it as a clickable link, or redirect to= it, >>> or open it in an external browser, or do any number of other >>> as-yet-not-invented things with it. Moreover, the Client may not know y= et >>> what it wants to do with it. So what value is there in distinguishing >>> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI wa= nt a URI for a QR code=E2=80=9D vs. >>> =E2=80=9CI want a URI for = =E2=80=9D? >>> >>> Even if we consider things like QR code data capacity, that=E2=80=99s r= eally >>> just a URI length limitation, which could apply to non-QR interaction >>> modes, e.g., if the Client device wants to communicate the URI over an >>> extremely bandwidth-constrained channel. And it=E2=80=99s not clear to = me how >>> including a URI length limitation in the request helps. If a GS is capa= ble >>> of generating a shorter URI, why wouldn=E2=80=99t it always return that= ? On the >>> client side, it can look at the length of the URI provided and decide w= hat >>> to do with it (e.g., render a QR code or display it or do nothing with = it). >>> >>> So that really leaves us with two interaction modes that we need: >>> >>> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be hu= man friendly; and >>> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code en= try page, both >>> of which are human-friendly. >>> >>> >>> Those could be combinable to get both, and even if we don=E2=80=99t go = down the >>> multiple interaction mode route we could add the full URI to the =E2=80= =9Ccode=E2=80=9D >>> interaction object. It wouldn=E2=80=99t hurt anything to do so. >>> >>> =E2=80=93 >>> Annabelle Backman (she/her) >>> AWS Identity >>> https://aws.amazon.com/identity/ >>> >>> >>> *From: *Txauth on behalf of Dick Hardt < >>> dick.hardt@gmail.com> >>> *Date: *Tuesday, February 18, 2020 at 6:04 PM >>> *To: *"txauth@ietf.org" >>> *Subject: *[Txauth] Fwd: New Version Notification for >>> draft-hardt-xauth-protocol-03.txt >>> >>> Added in user code interaction and aligned QR code to be a superset of >>> user code. >>> Fixed descriptions. >>> >>> >>> ---------- Forwarded message --------- >>> From: >>> Date: Tue, Feb 18, 2020 at 6:00 PM >>> Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt >>> To: Dick Hardt >>> >>> >>> >>> >>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>> has been successfully submitted by Dick Hardt and posted to the >>> IETF repository. >>> >>> Name: draft-hardt-xauth-protocol >>> Revision: 03 >>> Title: The XAuth Protocol >>> Document date: 2020-02-18 >>> Group: Individual Submission >>> Pages: 53 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 >>> >>> Abstract: >>> Client software often desires resources or identity claims that are >>> independent of the client. This protocol allows a user and/or >>> resource owner to delegate resource authorization and/or release of >>> identity claims to a server. Client software can then request acces= s >>> to resources and/or identity claims by calling the server. The >>> server acquires consent and authorization from the user and/or >>> resource owner if required, and then returns to the client software >>> the authorization and identity claims that were approved. This >>> protocol can be extended to support alternative authorizations, >>> claims, interactions, and client authentication mechanisms. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> =E1=90=A7 >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >> --000000000000dc1016059f1c33b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I got ahead of myself. A completion URI protects the User = only if the User is sent back to the same channel the transaction started s= o the Client can confirm it is the same User that started the transaction.<= br>

so this does not help the security:

"Being able to provide a completion URI even if the user is s= tarting on a device is a great insight on how to address the threat above.&= quot;

3D""=E1=90=A7

On Fri, Feb 21= , 2020 at 12:40 PM Dick Hardt <d= ick.hardt@gmail.com> wrote:
The lightbulb finally clicked on for me= . Thanks for your patience.

The threat you are describin= g is where the attacker starts a transaction at the client, and gets the vi= ctim to complete it. Correct?

I still think the Clie= nt should be able to signal if it will be doing a redirect vs showing a QR = code (or wants to do both).

Being able to provide = a completion URI even if the user is starting on a device is a great insigh= t on how to address the threat above.=C2=A0

I'm = going to ponder how to align XAuth more with these features of XYZ.
=E1=90=A7

On Fri, Feb 21, 2020 at 11:3= 1 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at 1:54 PM, Dick Hardt <dick.hardt@gmail.com>= ; wrote:



On Fri, Feb 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote= :
I=E2=80= =99m in complete agreement with Annabelle. In XYZ we realized that both the QR Code and Authorization = Code, and that the only difference is how the user gets back to the client.= So instead of inventing a new type of interaction, we split them. I= n XYZ, we have:

This sentence looks to be missing something.

Apologies: We r= ealized they both used AS-composed URLs to get the user to the AS in a web = browser for interaction purposes.

<= div dir=3D"ltr">
=C2=A0

=C2=A0- redirec= t: tells the AS that the client can send the user to an arbitrary URL (and = the AS doesn=E2=80=99t care how the client gets that info to the user; coul= d be a redirect or an image or send a push notification to a secondary devi= ce, we don=E2=80=99t care as long as the user shows up in a browser at the = AS =E2=80=94 so maybe this field can be renamed to be more universally accu= rate)

As stated in this thread,= it may be useful for the AS to know if the URL will be in a QR code, or in= a full redirect.

In XAuth, the GS(AS min XYA) clo= ses the popup to minimize what a Client has to do, so it needs to know the = difference between a popup, and a full browser redirect. This is targetted = at SPAs, where an additional URL to redirect to is extra work.
= =C2=A0
=C2= =A0- code: tells the AS that the client can present a short code the user c= an type (along with a static URL the user can get to, maybe by typing the U= RL manually, but it=E2=80=99s not dynamic/arbitrary like the redirect metho= d)
=C2=A0- callback: tells the AS that the client can receive the c= ompletion message from a front channel interaction through a redirect. Note= that the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this field i= sn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only concerned with= how to get the user :back:.

<= div>In a full redirect, the Client wants the AS to send the user back so th= at it can continue.

The only parameter in the comp= letion message is the nonce, which seems superfluous. See below.
= =C2=A0

These three can be combined in different ways depending on= what you want to do at the client. Let=E2=80=99s say you=E2=80=99re doing = and OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2= =80=9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a p= lain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re= doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code tog= ether, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D to get= the long URL and the short code not he screen at the same time.=C2=A0

On top of that, they can be combined with other method= s. Maybe I can send the user to an arbitrary URL but also display a human-r= eadable verification code (like CIBA), or send something in a push notifica= tion but also give them a message to type, or I=E2=80=99m getting claims fr= om an agent but I want them redirected back through the browser. The client= gets to decide what kinds of interaction it can do and how to use these pi= eces in ways that make the most sense.
<= br>
Per my question later in this thread, why would the Client no= t know what interaction it wants prior to the request?

What do you mean? The client does know = what it wants and that=E2=80=99s why it=E2=80=99s asking for what it wants.= We=E2=80=99re debating different methods for the client to ask for what it= wants. This question does not make sense to me.


<= div>If the AS is doing CIBA, that is not a decision just for the Client. Bo= th the AS and the Client need to know they are doing CIBA. (FWIW: I think t= his work supersedes CIBA)

As I=E2=80=99ve stated previously, I believe the interaction methods= here can supersede CIBA.


Additionally, diffe= rent interactions have different risk profiles. Sophisticated ASes will use= that signal in the risk assessment, and may do ask for additional authenti= cation or verification.
=C2=A0

Yes, exactly my point. Because different interactions= have different risks, the AS will need to be able to decide which interact= ions it=E2=80=99s OK with for a given request. This could vary based on wha= t=E2=80=99s being requested, or who=E2=80=99s doing the requesting.

An interesting difference between XYZ and XAuth=E2=80=99s approaches= is that XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D = in the callback response (which in turn is based on the OAuth 1 =E2=80=9Coa= uth_verifier=E2=80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref= =E2=80=9D which is hashed along with a pair of nonces generated by the clie= nt and the AS in the back channel. This binds the front channel response to= both the back channel request and the back channel response for a given tr= ansaction =E2=80=94 and note that I=E2=80=99m really open to having a bette= r way to generate and calculate such a binding, but I think this works. In = any event, this protects the client from session fixation and injection on = the return from the front channel that it=E2=80=99s susceptible to in a pur= e polling model, and the hashing approach basically combines the security p= arameters of the OAuth 2 authorization code and (to an extent) state, PKCE= =E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. This is= only applicable if you=E2=80=99re coming back to the client and you can va= lidate the hash and present the reference parameter. If you=E2=80=99re doin= g just plain polling, you don=E2=80=99t have that protection =E2=80=94 but = the client and the AS are aware of that risk, and there=E2=80=99s an option= to prevent it.

XAuth has removed the authorizatio= n code concept in its redirect return, and clients only do polling against = the GS API in order to get tokens. While I obviously think it=E2=80=99s ver= y valuable to remove things from the front channel, I don=E2=80=99t think t= his is something we can remove without opening up attack surfaces that have= already been identified in previous protocols. I would like to understand = why XAuth is not susceptible to the same kinds of attacks, or if it is, wha= t mitigations there are for them.=C2=A0
=
Unlike OAuth 2.0, there are no parameters in the front chann= el response to the Client. The redirect back to the Client is only needed t= o return the interaction back to the Client.

This argument rings tautologically hollow =E2=80= =94 there are no parameters because you=E2=80=99ve defined that there aren= =E2=80=99t any in XAuth. XYZ does have parameters, to tie the front and bac= k channel requests together when doing redirect back and forth.
<= br>
If you=E2=80=99re not doing a redirect back (ie, not sending = a =E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a pollin= g mechanism like XAuth, the device flow, etc. There are very real risks to = this.


XAuth (and XYZ) have a different flow = than OAuth 2.0 (or OAuth 1.0)

In OAuth, the AS giv= es a code to the User to give to the Client that the Client then gives to t= he GS.

In XAuth, the AS gives a "code" t= o the Client that givers it to the User to give to the GS.

In XAuth, the "code" is either a user code, or something= embedded in the URI the User is redirected to.

Th= erefore, there is nothing to protect in the redirect back to the Client.

If I'm missing an attack, please elaborate how i= t would happen.


OAuth 1.0=E2=80=99s =E2=80=9CRe= quest Token=E2=80=9D is a similar request initiation step to what we see in= XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s susceptible to the same = kind of issue.

=C2=A0

=C2=A0=E2=80=94 Justin

On Feb 20, 2020, at 3:21 PM, Richard B= ackman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote= :

Thanks for the update, Dick!= I=E2=80=99m going to confine my comments here to interaction mode design, = setting aside whether or not we need =E2=80=9Cpopup=E2=80=9D. :D<= /u>
=C2=A0
Once the GS hands th= at URI back to the Client, it has zero control over how the Client uses it.= The Client could present any URI (of a reasonable size) into a QR code, or= present it as a clickable link, or redirect to it, or open it in an extern= al browser, or do any number of other as-yet-not-invented things with it. M= oreover, the Client may not know yet what it wants to do with it. So what v= alue is there in distinguishing between =E2=80=9CI want a URI for a redirec= t=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI = want a URI for <some other machine-driven interaction mode>=E2=80=9D?=
=C2=A0
Even if w= e consider things like QR code data capacity, that=E2=80=99s really just a = URI length limitation, which could apply to non-QR interaction modes, e.g.,= if the Client device wants to communicate the URI over an extremely bandwi= dth-constrained channel. And it=E2=80=99s not clear to me how including a U= RI length limitation in the request helps. If a GS is capable of generating= a shorter URI, why wouldn=E2=80=99t it always return that? On the client s= ide, it can look at the length of the URI provided and decide what to do wi= th it (e.g., render a QR code or display it or do nothing with it).<= u>
=C2=A0
So that really le= aves us with two interaction modes that we need:
  • =E2=80=9Curi= =E2=80=9D, which returns a full URI that may not be human friendly; and<= /u>
  • =E2=80=9Ccode=E2=80=9D, which returns a code and UR= I for a code entry page, both of which are human-friendly.
=C2=A0
Those could be combina= ble to get both, and even if we don=E2=80=99t go down the multiple interact= ion mode route we could add the full URI to the =E2=80=9Ccode=E2=80=9D inte= raction object. It wouldn=E2=80=99t hurt anything to do so.
=C2=A0
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
=C2=A0

=C2=A0

---------- Forwarded message ---------
From:= <internet-drafts@ietf.org>
= Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notification for= draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, draft-hardt-xauth-p= rotocol-03.txt
has been successfully submitted by Dick Hardt and posted = to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0draft-hardt-xauth-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003<= br>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
Document = date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/int= ernet-drafts/draft-hardt-xauth-protocol-03.txt
Status:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protoco= l-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/ht= ml/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03
Abstract:
=C2=A0 =C2=A0Client software often desires resources or i= dentity claims that are
=C2=A0 =C2=A0independent of the client.=C2=A0 Th= is protocol allows a user and/or
=C2=A0 =C2=A0resource owner to delegate= resource authorization and/or release of
=C2=A0 =C2=A0identity claims t= o a server.=C2=A0 Client software can then request access
=C2=A0 =C2=A0t= o resources and/or identity claims by calling the server.=C2=A0 The
=C2= =A0 =C2=A0server acquires consent and authorization from the user and/or=C2=A0 =C2=A0resource owner if required, and then returns to the client so= ftware
=C2=A0 =C2=A0the authorization and identity claims that were appr= oved.=C2=A0 This
=C2=A0 =C2=A0protocol can be extended to support altern= ative authorizations,
=C2=A0 =C2=A0claims, interactions, and client auth= entication mechanisms.




Please note that it may take a co= uple of minutes from the time of submission
until the htmlized version a= nd diff are available at=C2=A0tools.i= etf.org.

The IETF Secretariat

=E1= =90=A7
--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.or= g/mailman/listinfo/txauth


--000000000000dc1016059f1c33b7-- From nobody Fri Feb 21 13:02:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ECB12009C for ; Fri, 21 Feb 2020 13:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 lAAocqwapoHT for ; Fri, 21 Feb 2020 13:02:02 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B45A812008B for ; Fri, 21 Feb 2020 13:02:01 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LL1vB9029310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 16:01:58 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_58C89CE0-AEC9-4A10-83CC-D7F91E976204" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Feb 2020 16:01:57 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" To: Dick Hardt References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:02:06 -0000 --Apple-Mail=_58C89CE0-AEC9-4A10-83CC-D7F91E976204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, = which is a very common case. For cases where the client doesn=E2=80=99t = expect the user to come back on the same channel, then they don=E2=80=99t = use the callback mechanism. They might use the =E2=80=9Cfinish = message=E2=80=9D URL that Annabelle mentioned in the other thread, or = they might just print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at = the AS, which is common today. XYZ=E2=80=99s interaction structure allows the composition of these = things, under the control of the client. This is exactly why it=E2=80=99s = important to be able to specify how to get to the AS and how to get back = as separate items, so that the client can compose the combination that = makes the most sense for that client. =E2=80=94 Justin > On Feb 21, 2020, at 3:52 PM, Dick Hardt wrote: >=20 > I got ahead of myself. A completion URI protects the User only if the = User is sent back to the same channel the transaction started so the = Client can confirm it is the same User that started the transaction. >=20 > so this does not help the security: >=20 > "Being able to provide a completion URI even if the user is starting = on a device is a great insight on how to address the threat above." >=20 > =E1=90=A7 >=20 > On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt > wrote: > The lightbulb finally clicked on for me. Thanks for your patience. >=20 > The threat you are describing is where the attacker starts a = transaction at the client, and gets the victim to complete it. Correct? >=20 > I still think the Client should be able to signal if it will be doing = a redirect vs showing a QR code (or wants to do both). >=20 > Being able to provide a completion URI even if the user is starting on = a device is a great insight on how to address the threat above.=20 >=20 > I'm going to ponder how to align XAuth more with these features of = XYZ. > =E1=90=A7 >=20 > On Fri, Feb 21, 2020 at 11:31 AM Justin Richer > wrote: > On Feb 21, 2020, at 1:54 PM, Dick Hardt > wrote: >>=20 >>=20 >>=20 >> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer > wrote: >> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we have: >>=20 >> This sentence looks to be missing something. >=20 > Apologies: We realized they both used AS-composed URLs to get the user = to the AS in a web browser for interaction purposes. >=20 >> =20 >>=20 >> - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) >>=20 >> As stated in this thread, it may be useful for the AS to know if the = URL will be in a QR code, or in a full redirect. >>=20 >> In XAuth, the GS(AS min XYA) closes the popup to minimize what a = Client has to do, so it needs to know the difference between a popup, = and a full browser redirect. This is targetted at SPAs, where an = additional URL to redirect to is extra work. >> =20 >> - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) >> - callback: tells the AS that the client can receive the completion = message from a front channel interaction through a redirect. Note that = the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this = field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:. >>=20 >> In a full redirect, the Client wants the AS to send the user back so = that it can continue. >>=20 >> The only parameter in the completion message is the nonce, which = seems superfluous. See below. >> =20 >>=20 >> These three can be combined in different ways depending on what you = want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= >>=20 >> On top of that, they can be combined with other methods. Maybe I can = send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. >>=20 >> Per my question later in this thread, why would the Client not know = what interaction it wants prior to the request? >=20 > What do you mean? The client does know what it wants and that=E2=80=99s = why it=E2=80=99s asking for what it wants. We=E2=80=99re debating = different methods for the client to ask for what it wants. This question = does not make sense to me. >=20 >>=20 >> If the AS is doing CIBA, that is not a decision just for the Client. = Both the AS and the Client need to know they are doing CIBA. (FWIW: I = think this work supersedes CIBA) >=20 > As I=E2=80=99ve stated previously, I believe the interaction methods = here can supersede CIBA. >=20 >>=20 >> Additionally, different interactions have different risk profiles. = Sophisticated ASes will use that signal in the risk assessment, and may = do ask for additional authentication or verification. >> =20 >=20 > Yes, exactly my point. Because different interactions have different = risks, the AS will need to be able to decide which interactions it=E2=80=99= s OK with for a given request. This could vary based on what=E2=80=99s = being requested, or who=E2=80=99s doing the requesting. >=20 >>=20 >> An interesting difference between XYZ and XAuth=E2=80=99s approaches = is that XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D = in the callback response (which in turn is based on the OAuth 1 = =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an = =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of = nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and = the back channel response for a given transaction =E2=80=94 and note = that I=E2=80=99m really open to having a better way to generate and = calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it. >>=20 >> XAuth has removed the authorization code concept in its redirect = return, and clients only do polling against the GS API in order to get = tokens. While I obviously think it=E2=80=99s very valuable to remove = things from the front channel, I don=E2=80=99t think this is something = we can remove without opening up attack surfaces that have already been = identified in previous protocols. I would like to understand why XAuth = is not susceptible to the same kinds of attacks, or if it is, what = mitigations there are for them.=20 >>=20 >> Unlike OAuth 2.0, there are no parameters in the front channel = response to the Client. The redirect back to the Client is only needed = to return the interaction back to the Client. >=20 > This argument rings tautologically hollow =E2=80=94 there are no = parameters because you=E2=80=99ve defined that there aren=E2=80=99t any = in XAuth. XYZ does have parameters, to tie the front and back channel = requests together when doing redirect back and forth. >=20 > If you=E2=80=99re not doing a redirect back (ie, not sending a = =E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a = polling mechanism like XAuth, the device flow, etc. There are very real = risks to this. >=20 >>=20 >> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>=20 >> In OAuth, the AS gives a code to the User to give to the Client that = the Client then gives to the GS. >>=20 >> In XAuth, the AS gives a "code" to the Client that givers it to the = User to give to the GS. >>=20 >> In XAuth, the "code" is either a user code, or something embedded in = the URI the User is redirected to. >>=20 >> Therefore, there is nothing to protect in the redirect back to the = Client. >>=20 >> If I'm missing an attack, please elaborate how it would happen. >=20 > One form of impersonation is well documented: = https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7592= 50a0e7 = >=20 > OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar = request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, = etc, and it=E2=80=99s susceptible to the same kind of issue. >=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = > wrote: >>>=20 >>> Thanks for the update, Dick! I=E2=80=99m going to confine my = comments here to interaction mode design, setting aside whether or not = we need =E2=80=9Cpopup=E2=80=9D. :D >>> =20 >>> Once the GS hands that URI back to the Client, it has zero control = over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of = other as-yet-not-invented things with it. Moreover, the Client may not = know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for =E2=80=9D? >>> =20 >>> Even if we consider things like QR code data capacity, that=E2=80=99s = really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. And it=E2=80=99s = not clear to me how including a URI length limitation in the request = helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99= t it always return that? On the client side, it can look at the length = of the URI provided and decide what to do with it (e.g., render a QR = code or display it or do nothing with it). >>> =20 >>> So that really leaves us with two interaction modes that we need: >>> =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be = human friendly; and >>> =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code = entry page, both of which are human-friendly. >>> =20 >>> Those could be combinable to get both, and even if we don=E2=80=99t = go down the multiple interaction mode route we could add the full URI to = the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt = anything to do so. >>> =20 >>> =E2=80=93 >>> Annabelle Backman (she/her) >>> AWS Identity >>> https://aws.amazon.com/identity/ >>> =20 >>> =20 >>> From: Txauth > on behalf of Dick Hardt = > >>> Date: Tuesday, February 18, 2020 at 6:04 PM >>> To: "txauth@ietf.org " > >>> Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>> =20 >>> Added in user code interaction and aligned QR code to be a superset = of user code. >>> Fixed descriptions. >>> =20 >>>=20 >>> ---------- Forwarded message --------- >>> From: > >>> Date: Tue, Feb 18, 2020 at 6:00 PM >>> Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>> To: Dick Hardt > >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>> has been successfully submitted by Dick Hardt and posted to the >>> IETF repository. >>>=20 >>> Name: draft-hardt-xauth-protocol >>> Revision: 03 >>> Title: The XAuth Protocol >>> Document date: 2020-02-18 >>> Group: Individual Submission >>> Pages: 53 >>> URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = >>> Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >>>=20 >>> Abstract: >>> Client software often desires resources or identity claims that = are >>> independent of the client. This protocol allows a user and/or >>> resource owner to delegate resource authorization and/or release = of >>> identity claims to a server. Client software can then request = access >>> to resources and/or identity claims by calling the server. The >>> server acquires consent and authorization from the user and/or >>> resource owner if required, and then returns to the client = software >>> the authorization and identity claims that were approved. This >>> protocol can be extended to support alternative authorizations, >>> claims, interactions, and client authentication mechanisms. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>> =E1=90=A7 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_58C89CE0-AEC9-4A10-83CC-D7F91E976204 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 But = that=E2=80=99s exactly the point =E2=80=94 it helps in that case, which = is a very common case. For cases where the client doesn=E2=80=99t expect = the user to come back on the same channel, then they don=E2=80=99t use = the callback mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D= URL that Annabelle mentioned in the other thread, or they might just = print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is = common today.

XYZ=E2=80= =99s interaction structure allows the composition of these things, under = the control of the client. This is exactly why it=E2=80=99s important to = be able to specify how to get to the AS and how to get back as separate = items, so that the client can compose the combination that makes the = most sense for that client.

 =E2=80=94 Justin


On Feb 21, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I got ahead of myself. A = completion URI protects the User only if the User is sent back to the = same channel the transaction started so the Client can confirm it is the = same User that started the transaction.

so this does not help the = security:

"Being= able to provide a completion URI even if the user is starting on a = device is a great insight on how to address the threat above."

3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The = lightbulb finally clicked on for me. Thanks for your patience.

The threat you are = describing is where the attacker starts a transaction at the client, and = gets the victim to complete it. Correct?
I still think the Client should be = able to signal if it will be doing a redirect vs showing a QR code (or = wants to do both).

Being able to provide a completion URI even if the user is = starting on a device is a great insight on how to address the threat = above. 

I'm going to ponder how to align XAuth more with these = features of XYZ.
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at = 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Fri, Feb = 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in = complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we = have:

This= sentence looks to be missing = something.

Apologies: We realized they both used = AS-composed URLs to get the user to the AS in a web browser for = interaction purposes.

 

 - redirect: tells = the AS that the client can send the user to an arbitrary URL (and the AS = doesn=E2=80=99t care how the client gets that info to the user; could be = a redirect or an image or send a push notification to a secondary = device, we don=E2=80=99t care as long as the user shows up in a browser = at the AS =E2=80=94 so maybe this field can be renamed to be more = universally accurate)

As stated in this thread, it may be = useful for the AS to know if the URL will be in a QR code, or in a full = redirect.

In = XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has = to do, so it needs to know the difference between a popup, and a full = browser redirect. This is targetted at SPAs, where an additional URL to = redirect to is extra work.
 
 - code: tells the AS that the client can present a = short code the user can type (along with a static URL the user can get = to, maybe by typing the URL manually, but it=E2=80=99s not = dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the client can receive = the completion message from a front channel interaction through a = redirect. Note that the client might have gotten to the AS through a = redirect on-device, through a QR-code off device, or through some other = magic, and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80= =99s only concerned with how to get the user = :back:.

In a full redirect, the Client wants = the AS to send the user back so that it can continue.

The only parameter in = the completion message is the nonce, which seems superfluous. See = below.
 

These three can be = combined in different ways depending on what you want to do at the = client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style = authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain = user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code = together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D = to get the long URL and the short code not he screen at the same = time. 

On = top of that, they can be combined with other methods. Maybe I can send = the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most = sense.

Per my question later in this thread, = why would the Client not know what interaction it wants prior to the = request?

What do you mean? The client does know = what it wants and that=E2=80=99s why it=E2=80=99s asking for what it = wants. We=E2=80=99re debating different methods for the client to ask = for what it wants. This question does not make sense to me.


If the AS is doing CIBA, that is not a = decision just for the Client. Both the AS and the Client need to know = they are doing CIBA. (FWIW: I think this work supersedes = CIBA)

As I=E2=80=99ve stated previously, I = believe the interaction methods here can supersede CIBA.


Additionally, different interactions = have different risk profiles. Sophisticated ASes will use that signal in = the risk assessment, and may do ask for additional authentication or = verification.
 

Yes, exactly my point. Because = different interactions have different risks, the AS will need to be able = to decide which interactions it=E2=80=99s OK with for a given request. = This could vary based on what=E2=80=99s being requested, or who=E2=80=99s = doing the requesting.


An interesting = difference between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps = the concept of the =E2=80=9Cauthorization code=E2=80=9D in the callback = response (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2= =80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D = which is hashed along with a pair of nonces generated by the client and = the AS in the back channel. This binds the front channel response to = both the back channel request and the back channel response for a given = transaction =E2=80=94 and note that I=E2=80=99m really open to having a = better way to generate and calculate such a binding, but I think this = works. In any event, this protects the client from session fixation and = injection on the return from the front channel that it=E2=80=99s = susceptible to in a pure polling model, and the hashing approach = basically combines the security parameters of the OAuth 2 authorization = code and (to an extent) state, PKCE=E2=80=99s code_challenge, and = OIDC=E2=80=99s nonce in one element. This is only applicable if you=E2=80=99= re coming back to the client and you can validate the hash and present = the reference parameter. If you=E2=80=99re doing just plain polling, you = don=E2=80=99t have that protection =E2=80=94 but the client and the AS = are aware of that risk, and there=E2=80=99s an option to prevent = it.

XAuth has = removed the authorization code concept in its redirect return, and = clients only do polling against the GS API in order to get tokens. While = I obviously think it=E2=80=99s very valuable to remove things from the = front channel, I don=E2=80=99t think this is something we can remove = without opening up attack surfaces that have already been identified in = previous protocols. I would like to understand why XAuth is not = susceptible to the same kinds of attacks, or if it is, what mitigations = there are for them. 

Unlike OAuth 2.0, there = are no parameters in the front channel response to the Client. The = redirect back to the Client is only needed to return the interaction = back to the Client.

This argument rings = tautologically hollow =E2=80=94 there are no parameters because you=E2=80=99= ve defined that there aren=E2=80=99t any in XAuth. XYZ does have = parameters, to tie the front and back channel requests together when = doing redirect back and forth.

If you=E2=80=99re not doing a redirect = back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), = then it=E2=80=99s a polling mechanism like XAuth, the device flow, etc. = There are very real risks to this.


XAuth (and XYZ) have a different flow than OAuth 2.0 (or = OAuth 1.0)

In = OAuth, the AS gives a code to the User to give to the Client that the = Client then gives to the GS.

In XAuth, the AS gives a "code" to the = Client that givers it to the User to give to the GS.

In XAuth, the "code" is = either a user code, or something embedded in the URI the User is = redirected to.

Therefore, there is nothing to protect in the redirect back = to the Client.

If I'm missing an attack, please elaborate how it would = happen.

One form of impersonation is well = documented: https://hueniverse.com/explaining-the-oauth-session-fixation-at= tack-aa759250a0e7

OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a = similar request initiation step to what we see in XYZ, XAuth, PAR, = FAPI/OBUK, etc, and it=E2=80=99s susceptible to the same kind of = issue.

 

 =E2=80=94 = Justin

On Feb 20, 2020, at 3:21 PM, = Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

Thanks = for the update, Dick! I=E2=80=99m going to confine my comments here to = interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
 
Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for <some other machine-driven interaction mode>=E2=80=9D?
 
Even if we consider things like QR code data capacity, = that=E2=80=99s really just a URI length limitation, which could apply to = non-QR interaction modes, e.g., if the Client device wants to = communicate the URI over an extremely bandwidth-constrained channel. And = it=E2=80=99s not clear to me how including a URI length limitation in = the request helps. If a GS is capable of generating a shorter URI, why = wouldn=E2=80=99t it always return that? On the client side, it can look = at the length of the URI provided and decide what to do with it (e.g., = render a QR code or display it or do nothing with it).
 
So = that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a = code entry page, both of which are human-friendly.
 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in = user code interaction and aligned QR code to be a superset of user = code.
Fixed = descriptions.

 

----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat

=E1=90=A7
-- 
Txauth mailing = list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth



= --Apple-Mail=_58C89CE0-AEC9-4A10-83CC-D7F91E976204-- From nobody Fri Feb 21 13:15:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3475812008A for ; Fri, 21 Feb 2020 13:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RftG6ehgG-lY for ; Fri, 21 Feb 2020 13:15:26 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 8DA2D12006B for ; Fri, 21 Feb 2020 13:15:25 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id 7so2474843lfz.11 for ; Fri, 21 Feb 2020 13:15:25 -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=6NmYMxf/vx5evytKFEyJpantVKKhEm6EHkCanM5BEA0=; b=QvSpDSFLlAX3Aju3rUIlL+bqZW6qt+YhPNBG7pWtuHsMdfLw9zWEKAV+N+mHxpqaAa RfKP3IetSq9gxqxwVZFa7IJkgsoTEgOY5mS/FioNuRz/DhPf3QEvDNf9TQXE8rPAveGe 1ac7+xCt+OjtnYYmOtWwhsX6f+puZlraxyYSK+2LGCo/MzOfySC3+K4RURSccDtCdIh3 84Ir2bt6oYJG5HppORS88zBAUNfTY2wnQlud2J4VggucIgL1sU7IOYpO0Xwwod0xVUsK sIEcEh/j0hevfNMmDzf/gPGj0AkNRbblFDcAE41LtH5WKWrZgbDpcWDASSBnNqEv31ad 6mqQ== 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=6NmYMxf/vx5evytKFEyJpantVKKhEm6EHkCanM5BEA0=; b=lUfSSP1LYD7F3gN4OCp0xdugMMsLb5kS9HMn6X2AOWVY/ZrOprp5mfKI7S8JUDNt0u by4CPYoKaKu7QXlLyhj8gdrm33lKICOxBz6GE3ksOEnYcGcjntkjnBEWZYulOnDSD9kw mS0hhcoNzWAzzxHRx7HhTUTM2AaLiKu4S39CnalAVKi6ZZwiSbNSaOizWD9NanyFRHdr VQPRv9IV7e9SH5NLXY/PLiJPCaWiUQfKDQkanpvBMTokknmvMvLpdfhA98TnSMg6TnYW 5mPG2JyQQQSGNUfS/d09pPjDuCSpqR0GNVmWtOODyHqEHdZHEaPwdaW9yBc4yOhcQNNm HGhQ== X-Gm-Message-State: APjAAAVt1mMsxkIbXKsOzn/snlm9VcSViK2iQ/o+weTrUGhwHKmwR+Yl 2PYF09XSTRw38Io66liUBSiF2F/M8KYOedWkX1k= X-Google-Smtp-Source: APXvYqy6pJogHuQSZdsm4a2ErQeXlNwScVtyxAC5ERTtlsoCPAD53W2gTfZoNw9AX1o8MszxjvsJuXV2/bCVQhzvF/M= X-Received: by 2002:a05:6512:4c6:: with SMTP id w6mr9178160lfq.157.1582319723555; Fri, 21 Feb 2020 13:15:23 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 21 Feb 2020 13:14:57 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000b321c059f1c8560" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:15:30 -0000 --0000000000000b321c059f1c8560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I can see the value of the interact_ref (aka interaction_ref) in the return URI that allows the Client to ensure the user that started the transaction is the same one that interacted at the AS, I don't understand why a hash is required. Would you elaborate? =E1=90=A7 On Fri, Feb 21, 2020 at 1:02 PM Justin Richer wrote: > But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, whi= ch is a very > common case. For cases where the client doesn=E2=80=99t expect the user t= o come > back on the same channel, then they don=E2=80=99t use the callback mechan= ism. They > might use the =E2=80=9Cfinish message=E2=80=9D URL that Annabelle mention= ed in the other > thread, or they might just print out =E2=80=9Cyou=E2=80=99re done now!=E2= =80=9D at the AS, which is > common today. > > XYZ=E2=80=99s interaction structure allows the composition of these thing= s, under > the control of the client. This is exactly why it=E2=80=99s important to = be able to > specify how to get to the AS and how to get back as separate items, so th= at > the client can compose the combination that makes the most sense for that > client. > > =E2=80=94 Justin > > > On Feb 21, 2020, at 3:52 PM, Dick Hardt wrote: > > I got ahead of myself. A completion URI protects the User only if the Use= r > is sent back to the same channel the transaction started so the Client ca= n > confirm it is the same User that started the transaction. > > so this does not help the security: > > "Being able to provide a completion URI even if the user is starting on a > device is a great insight on how to address the threat above." > > =E1=90=A7 > > On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt wrote: > >> The lightbulb finally clicked on for me. Thanks for your patience. >> >> The threat you are describing is where the attacker starts a transaction >> at the client, and gets the victim to complete it. Correct? >> >> I still think the Client should be able to signal if it will be doing a >> redirect vs showing a QR code (or wants to do both). >> >> Being able to provide a completion URI even if the user is starting on a >> device is a great insight on how to address the threat above. >> >> I'm going to ponder how to align XAuth more with these features of XYZ. >> =E1=90=A7 >> >> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer wrote: >> >>> On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote: >>> >>> >>> >>> >>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer wrote: >>> >>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized t= hat both >>>> the QR Code and Authorization Code, and that the only difference is ho= w the >>>> user gets back to the client. So instead of inventing a new type of >>>> interaction, we split them. In XYZ, we have: >>>> >>> >>> This sentence looks to be missing something. >>> >>> >>> Apologies: We realized they both used AS-composed URLs to get the user >>> to the AS in a web browser for interaction purposes. >>> >>> >>> >>>> >>>> - redirect: tells the AS that the client can send the user to an >>>> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets tha= t info to the >>>> user; could be a redirect or an image or send a push notification to a >>>> secondary device, we don=E2=80=99t care as long as the user shows up i= n a browser >>>> at the AS =E2=80=94 so maybe this field can be renamed to be more univ= ersally >>>> accurate) >>>> >>> >>> As stated in this thread, it may be useful for the AS to know if the UR= L >>> will be in a QR code, or in a full redirect. >>> >>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client >>> has to do, so it needs to know the difference between a popup, and a fu= ll >>> browser redirect. This is targetted at SPAs, where an additional URL to >>> redirect to is extra work. >>> >>> >>>> - code: tells the AS that the client can present a short code the use= r >>>> can type (along with a static URL the user can get to, maybe by typing= the >>>> URL manually, but it=E2=80=99s not dynamic/arbitrary like the redirect= method) >>>> - callback: tells the AS that the client can receive the completion >>>> message from a front channel interaction through a redirect. Note that= the >>>> client might have gotten to the AS through a redirect on-device, throu= gh a >>>> QR-code off device, or through some other magic, and this field isn=E2= =80=99t >>>> concerned with that =E2=80=94 it=E2=80=99s only concerned with how to = get the user :back:. >>>> >>> >>> In a full redirect, the Client wants the AS to send the user back so >>> that it can continue. >>> >>> The only parameter in the completion message is the nonce, which seems >>> superfluous. See below. >>> >>> >>>> >>>> These three can be combined in different ways depending on what you >>>> want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and O= Auth2 style >>>> authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re >>>> doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If = you=E2=80=99re doing just a QR code >>>> with polling, you use just =E2=80=9Credirect=E2=80=9D to get the long = URL. If you=E2=80=99re doing >>>> a user code and a QR code together, you use =E2=80=9Credirect=E2=80=9D= and =E2=80=9Ccode=E2=80=9D to get >>>> the long URL and the short code not he screen at the same time. >>>> >>>> On top of that, they can be combined with other methods. Maybe I can >>>> send the user to an arbitrary URL but also display a human-readable >>>> verification code (like CIBA), or send something in a push notificatio= n but >>>> also give them a message to type, or I=E2=80=99m getting claims from a= n agent but I >>>> want them redirected back through the browser. The client gets to deci= de >>>> what kinds of interaction it can do and how to use these pieces in way= s >>>> that make the most sense. >>>> >>> >>> Per my question later in this thread, why would the Client not know wha= t >>> interaction it wants prior to the request? >>> >>> >>> What do you mean? The client does know what it wants and that=E2=80=99s= why it=E2=80=99s >>> asking for what it wants. We=E2=80=99re debating different methods for = the client >>> to ask for what it wants. This question does not make sense to me. >>> >>> >>> If the AS is doing CIBA, that is not a decision just for the Client. >>> Both the AS and the Client need to know they are doing CIBA. (FWIW: I t= hink >>> this work supersedes CIBA) >>> >>> >>> As I=E2=80=99ve stated previously, I believe the interaction methods he= re can >>> supersede CIBA. >>> >>> >>> Additionally, different interactions have different risk profiles. >>> Sophisticated ASes will use that signal in the risk assessment, and may= do >>> ask for additional authentication or verification. >>> >>> >>> >>> Yes, exactly my point. Because different interactions have different >>> risks, the AS will need to be able to decide which interactions it=E2= =80=99s OK >>> with for a given request. This could vary based on what=E2=80=99s being= requested, >>> or who=E2=80=99s doing the requesting. >>> >>> >>>> An interesting difference between XYZ and XAuth=E2=80=99s approaches i= s that >>>> XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in t= he callback response >>>> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80= =9D field). In XYZ, you >>>> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a = pair of nonces >>>> generated by the client and the AS in the back channel. This binds the >>>> front channel response to both the back channel request and the back >>>> channel response for a given transaction =E2=80=94 and note that I=E2= =80=99m really open to >>>> having a better way to generate and calculate such a binding, but I th= ink >>>> this works. In any event, this protects the client from session fixati= on >>>> and injection on the return from the front channel that it=E2=80=99s s= usceptible to >>>> in a pure polling model, and the hashing approach basically combines t= he >>>> security parameters of the OAuth 2 authorization code and (to an exten= t) >>>> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one = element. This is only >>>> applicable if you=E2=80=99re coming back to the client and you can val= idate the >>>> hash and present the reference parameter. If you=E2=80=99re doing just= plain >>>> polling, you don=E2=80=99t have that protection =E2=80=94 but the clie= nt and the AS are >>>> aware of that risk, and there=E2=80=99s an option to prevent it. >>>> >>>> XAuth has removed the authorization code concept in its redirect >>>> return, and clients only do polling against the GS API in order to get >>>> tokens. While I obviously think it=E2=80=99s very valuable to remove t= hings from >>>> the front channel, I don=E2=80=99t think this is something we can remo= ve without >>>> opening up attack surfaces that have already been identified in previo= us >>>> protocols. I would like to understand why XAuth is not susceptible to = the >>>> same kinds of attacks, or if it is, what mitigations there are for the= m. >>>> >>> >>> Unlike OAuth 2.0, there are no parameters in the front channel response >>> to the Client. The redirect back to the Client is only needed to return= the >>> interaction back to the Client. >>> >>> >>> This argument rings tautologically hollow =E2=80=94 there are no parame= ters >>> because you=E2=80=99ve defined that there aren=E2=80=99t any in XAuth. = XYZ does have >>> parameters, to tie the front and back channel requests together when do= ing >>> redirect back and forth. >>> >>> If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=80= =9Ccallback=E2=80=9D >>> interaction block), then it=E2=80=99s a polling mechanism like XAuth, t= he device >>> flow, etc. There are very real risks to this. >>> >>> >>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>> >>> In OAuth, the AS gives a code to the User to give to the Client that th= e >>> Client then gives to the GS. >>> >>> In XAuth, the AS gives a "code" to the Client that givers it to the Use= r >>> to give to the GS. >>> >>> In XAuth, the "code" is either a user code, or something embedded in th= e >>> URI the User is redirected to. >>> >>> Therefore, there is nothing to protect in the redirect back to the >>> Client. >>> >>> If I'm missing an attack, please elaborate how it would happen. >>> >>> >>> One form of impersonation is well documented: >>> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7= 59250a0e7 >>> >>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar reques= t initiation step to what >>> we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s susceptible= to the same >>> kind of issue. >>> >>> >>> >>>> >>>> =E2=80=94 Justin >>>> >>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < >>>> richanna=3D40amazon.com@dmarc.ietf.org> wrote: >>>> >>>> Thanks for the update, Dick! I=E2=80=99m going to confine my comments = here to >>>> interaction mode design, setting aside whether or not we need =E2=80= =9Cpopup=E2=80=9D. :D >>>> >>>> Once the GS hands that URI back to the Client, it has zero control ove= r >>>> how the Client uses it. The Client could present any URI (of a reasona= ble >>>> size) into a QR code, or present it as a clickable link, or redirect t= o it, >>>> or open it in an external browser, or do any number of other >>>> as-yet-not-invented things with it. Moreover, the Client may not know = yet >>>> what it wants to do with it. So what value is there in distinguishing >>>> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI w= ant a URI for a QR code=E2=80=9D vs. >>>> =E2=80=9CI want a URI for = =E2=80=9D? >>>> >>>> Even if we consider things like QR code data capacity, that=E2=80=99s = really >>>> just a URI length limitation, which could apply to non-QR interaction >>>> modes, e.g., if the Client device wants to communicate the URI over an >>>> extremely bandwidth-constrained channel. And it=E2=80=99s not clear to= me how >>>> including a URI length limitation in the request helps. If a GS is cap= able >>>> of generating a shorter URI, why wouldn=E2=80=99t it always return tha= t? On the >>>> client side, it can look at the length of the URI provided and decide = what >>>> to do with it (e.g., render a QR code or display it or do nothing with= it). >>>> >>>> So that really leaves us with two interaction modes that we need: >>>> >>>> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be h= uman friendly; >>>> and >>>> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code e= ntry page, both >>>> of which are human-friendly. >>>> >>>> >>>> Those could be combinable to get both, and even if we don=E2=80=99t go= down the >>>> multiple interaction mode route we could add the full URI to the =E2= =80=9Ccode=E2=80=9D >>>> interaction object. It wouldn=E2=80=99t hurt anything to do so. >>>> >>>> =E2=80=93 >>>> Annabelle Backman (she/her) >>>> AWS Identity >>>> https://aws.amazon.com/identity/ >>>> >>>> >>>> *From: *Txauth on behalf of Dick Hardt < >>>> dick.hardt@gmail.com> >>>> *Date: *Tuesday, February 18, 2020 at 6:04 PM >>>> *To: *"txauth@ietf.org" >>>> *Subject: *[Txauth] Fwd: New Version Notification for >>>> draft-hardt-xauth-protocol-03.txt >>>> >>>> Added in user code interaction and aligned QR code to be a superset of >>>> user code. >>>> Fixed descriptions. >>>> >>>> >>>> ---------- Forwarded message --------- >>>> From: >>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>> Subject: New Version Notification for draft-hardt-xauth-protocol-03.tx= t >>>> To: Dick Hardt >>>> >>>> >>>> >>>> >>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>> has been successfully submitted by Dick Hardt and posted to the >>>> IETF repository. >>>> >>>> Name: draft-hardt-xauth-protocol >>>> Revision: 03 >>>> Title: The XAuth Protocol >>>> Document date: 2020-02-18 >>>> Group: Individual Submission >>>> Pages: 53 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol >>>> Diff: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 >>>> >>>> Abstract: >>>> Client software often desires resources or identity claims that are >>>> independent of the client. This protocol allows a user and/or >>>> resource owner to delegate resource authorization and/or release of >>>> identity claims to a server. Client software can then request acce= ss >>>> to resources and/or identity claims by calling the server. The >>>> server acquires consent and authorization from the user and/or >>>> resource owner if required, and then returns to the client software >>>> the authorization and identity claims that were approved. This >>>> protocol can be extended to support alternative authorizations, >>>> claims, interactions, and client authentication mechanisms. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> =E1=90=A7 >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>> > --0000000000000b321c059f1c8560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I can see the value of the interact_ref (aka interac= tion_ref) in the return URI that allows the Client to ensure the user that = started the transaction is the same one that interacted at the AS, I don= 9;t understand why a hash is required. Would you elaborate?
3D""=E1=90=A7
--0000000000000b321c059f1c8560-- From nobody Fri Feb 21 13:52:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBF912008A for ; Fri, 21 Feb 2020 13:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 UsZJ3Nwj7ElM for ; Fri, 21 Feb 2020 13:51:54 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 75DA51200B9 for ; Fri, 21 Feb 2020 13:51:53 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01LLpl6a024813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 16:51:48 -0500 From: Justin Richer Message-Id: <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_9851B76A-C4A4-452E-8369-E4D638B359C5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Feb 2020 16:51:47 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" To: Dick Hardt References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:51:58 -0000 --Apple-Mail=_9851B76A-C4A4-452E-8369-E4D638B359C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The hash offers the same kinds of protections to the client that the = OIDC nonce does =E2=80=94 it binds the front channel return to something = you get from the back channel.=20 In other words, the client can be sure that the return value that it=E2=80= =99s getting is related to the request it made in the first place, and = not another one. Clients using per-request redirect URIs can also help = with this, but this is something that the server can provide directly. =E2=80=94 Justin > On Feb 21, 2020, at 4:14 PM, Dick Hardt wrote: >=20 > While I can see the value of the interact_ref (aka interaction_ref) in = the return URI that allows the Client to ensure the user that started = the transaction is the same one that interacted at the AS, I don't = understand why a hash is required. Would you elaborate? > =E1=90=A7 >=20 > On Fri, Feb 21, 2020 at 1:02 PM Justin Richer > wrote: > But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, = which is a very common case. For cases where the client doesn=E2=80=99t = expect the user to come back on the same channel, then they don=E2=80=99t = use the callback mechanism. They might use the =E2=80=9Cfinish = message=E2=80=9D URL that Annabelle mentioned in the other thread, or = they might just print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at = the AS, which is common today. >=20 > XYZ=E2=80=99s interaction structure allows the composition of these = things, under the control of the client. This is exactly why it=E2=80=99s = important to be able to specify how to get to the AS and how to get back = as separate items, so that the client can compose the combination that = makes the most sense for that client. >=20 > =E2=80=94 Justin >=20 >=20 >> On Feb 21, 2020, at 3:52 PM, Dick Hardt > wrote: >>=20 >> I got ahead of myself. A completion URI protects the User only if the = User is sent back to the same channel the transaction started so the = Client can confirm it is the same User that started the transaction. >>=20 >> so this does not help the security: >>=20 >> "Being able to provide a completion URI even if the user is starting = on a device is a great insight on how to address the threat above." >>=20 >> =E1=90=A7 >>=20 >> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt > wrote: >> The lightbulb finally clicked on for me. Thanks for your patience. >>=20 >> The threat you are describing is where the attacker starts a = transaction at the client, and gets the victim to complete it. Correct? >>=20 >> I still think the Client should be able to signal if it will be doing = a redirect vs showing a QR code (or wants to do both). >>=20 >> Being able to provide a completion URI even if the user is starting = on a device is a great insight on how to address the threat above.=20 >>=20 >> I'm going to ponder how to align XAuth more with these features of = XYZ. >> =E1=90=A7 >>=20 >> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer > wrote: >> On Feb 21, 2020, at 1:54 PM, Dick Hardt > wrote: >>>=20 >>>=20 >>>=20 >>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer > wrote: >>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we have: >>>=20 >>> This sentence looks to be missing something. >>=20 >> Apologies: We realized they both used AS-composed URLs to get the = user to the AS in a web browser for interaction purposes. >>=20 >>> =20 >>>=20 >>> - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) >>>=20 >>> As stated in this thread, it may be useful for the AS to know if the = URL will be in a QR code, or in a full redirect. >>>=20 >>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a = Client has to do, so it needs to know the difference between a popup, = and a full browser redirect. This is targetted at SPAs, where an = additional URL to redirect to is extra work. >>> =20 >>> - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) >>> - callback: tells the AS that the client can receive the completion = message from a front channel interaction through a redirect. Note that = the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this = field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:. >>>=20 >>> In a full redirect, the Client wants the AS to send the user back so = that it can continue. >>>=20 >>> The only parameter in the completion message is the nonce, which = seems superfluous. See below. >>> =20 >>>=20 >>> These three can be combined in different ways depending on what you = want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= >>>=20 >>> On top of that, they can be combined with other methods. Maybe I can = send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. >>>=20 >>> Per my question later in this thread, why would the Client not know = what interaction it wants prior to the request? >>=20 >> What do you mean? The client does know what it wants and that=E2=80=99s= why it=E2=80=99s asking for what it wants. We=E2=80=99re debating = different methods for the client to ask for what it wants. This question = does not make sense to me. >>=20 >>>=20 >>> If the AS is doing CIBA, that is not a decision just for the Client. = Both the AS and the Client need to know they are doing CIBA. (FWIW: I = think this work supersedes CIBA) >>=20 >> As I=E2=80=99ve stated previously, I believe the interaction methods = here can supersede CIBA. >>=20 >>>=20 >>> Additionally, different interactions have different risk profiles. = Sophisticated ASes will use that signal in the risk assessment, and may = do ask for additional authentication or verification. >>> =20 >>=20 >> Yes, exactly my point. Because different interactions have different = risks, the AS will need to be able to decide which interactions it=E2=80=99= s OK with for a given request. This could vary based on what=E2=80=99s = being requested, or who=E2=80=99s doing the requesting. >>=20 >>>=20 >>> An interesting difference between XYZ and XAuth=E2=80=99s approaches = is that XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D = in the callback response (which in turn is based on the OAuth 1 = =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an = =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of = nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and = the back channel response for a given transaction =E2=80=94 and note = that I=E2=80=99m really open to having a better way to generate and = calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it. >>>=20 >>> XAuth has removed the authorization code concept in its redirect = return, and clients only do polling against the GS API in order to get = tokens. While I obviously think it=E2=80=99s very valuable to remove = things from the front channel, I don=E2=80=99t think this is something = we can remove without opening up attack surfaces that have already been = identified in previous protocols. I would like to understand why XAuth = is not susceptible to the same kinds of attacks, or if it is, what = mitigations there are for them.=20 >>>=20 >>> Unlike OAuth 2.0, there are no parameters in the front channel = response to the Client. The redirect back to the Client is only needed = to return the interaction back to the Client. >>=20 >> This argument rings tautologically hollow =E2=80=94 there are no = parameters because you=E2=80=99ve defined that there aren=E2=80=99t any = in XAuth. XYZ does have parameters, to tie the front and back channel = requests together when doing redirect back and forth. >>=20 >> If you=E2=80=99re not doing a redirect back (ie, not sending a = =E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a = polling mechanism like XAuth, the device flow, etc. There are very real = risks to this. >>=20 >>>=20 >>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>>=20 >>> In OAuth, the AS gives a code to the User to give to the Client that = the Client then gives to the GS. >>>=20 >>> In XAuth, the AS gives a "code" to the Client that givers it to the = User to give to the GS. >>>=20 >>> In XAuth, the "code" is either a user code, or something embedded in = the URI the User is redirected to. >>>=20 >>> Therefore, there is nothing to protect in the redirect back to the = Client. >>>=20 >>> If I'm missing an attack, please elaborate how it would happen. >>=20 >> One form of impersonation is well documented: = https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7592= 50a0e7 = >>=20 >> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar = request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, = etc, and it=E2=80=99s susceptible to the same kind of issue. >>=20 >>> =20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = > wrote: >>>>=20 >>>> Thanks for the update, Dick! I=E2=80=99m going to confine my = comments here to interaction mode design, setting aside whether or not = we need =E2=80=9Cpopup=E2=80=9D. :D >>>> =20 >>>> Once the GS hands that URI back to the Client, it has zero control = over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of = other as-yet-not-invented things with it. Moreover, the Client may not = know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for =E2=80=9D? >>>> =20 >>>> Even if we consider things like QR code data capacity, that=E2=80=99s= really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. And it=E2=80=99s = not clear to me how including a URI length limitation in the request = helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99= t it always return that? On the client side, it can look at the length = of the URI provided and decide what to do with it (e.g., render a QR = code or display it or do nothing with it). >>>> =20 >>>> So that really leaves us with two interaction modes that we need: >>>> =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be = human friendly; and >>>> =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code = entry page, both of which are human-friendly. >>>> =20 >>>> Those could be combinable to get both, and even if we don=E2=80=99t = go down the multiple interaction mode route we could add the full URI to = the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt = anything to do so. >>>> =20 >>>> =E2=80=93 >>>> Annabelle Backman (she/her) >>>> AWS Identity >>>> https://aws.amazon.com/identity/ >>>> =20 >>>> =20 >>>> From: Txauth > on behalf of Dick Hardt = > >>>> Date: Tuesday, February 18, 2020 at 6:04 PM >>>> To: "txauth@ietf.org " > >>>> Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>>> =20 >>>> Added in user code interaction and aligned QR code to be a superset = of user code. >>>> Fixed descriptions. >>>> =20 >>>>=20 >>>> ---------- Forwarded message --------- >>>> From: > >>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>> Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>>> To: Dick Hardt > >>>>=20 >>>>=20 >>>>=20 >>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>> has been successfully submitted by Dick Hardt and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-hardt-xauth-protocol >>>> Revision: 03 >>>> Title: The XAuth Protocol >>>> Document date: 2020-02-18 >>>> Group: Individual Submission >>>> Pages: 53 >>>> URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = >>>> Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = >>>> Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = >>>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = >>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >>>>=20 >>>> Abstract: >>>> Client software often desires resources or identity claims that = are >>>> independent of the client. This protocol allows a user and/or >>>> resource owner to delegate resource authorization and/or release = of >>>> identity claims to a server. Client software can then request = access >>>> to resources and/or identity claims by calling the server. The >>>> server acquires consent and authorization from the user and/or >>>> resource owner if required, and then returns to the client = software >>>> the authorization and identity claims that were approved. This >>>> protocol can be extended to support alternative authorizations, >>>> claims, interactions, and client authentication mechanisms. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at tools.ietf.org = . >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>> =E1=90=A7 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 --Apple-Mail=_9851B76A-C4A4-452E-8369-E4D638B359C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = hash offers the same kinds of protections to the client that the OIDC = nonce does =E2=80=94 it binds the front channel return to something you = get from the back channel. 

In other words, the client can be sure that the return value = that it=E2=80=99s getting is related to the request it made in the first = place, and not another one. Clients using per-request redirect URIs can = also help with this, but this is something that the server can provide = directly.

 =E2=80=94 Justin

On Feb = 21, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

While I can see the value of the = interact_ref (aka interaction_ref) in the return URI that allows the = Client to ensure the user that started the transaction is the same one = that interacted at the AS, I don't understand why a hash is required. = Would you elaborate?
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
But that=E2=80=99s exactly the point =E2=80=94 = it helps in that case, which is a very common case. For cases where the = client doesn=E2=80=99t expect the user to come back on the same channel, = then they don=E2=80=99t use the callback mechanism. They might use the = =E2=80=9Cfinish message=E2=80=9D URL that Annabelle mentioned in the = other thread, or they might just print out =E2=80=9Cyou=E2=80=99re done = now!=E2=80=9D at the AS, which is common today.

XYZ=E2=80=99s interaction structure = allows the composition of these things, under the control of the client. = This is exactly why it=E2=80=99s important to be able to specify how to = get to the AS and how to get back as separate items, so that the client = can compose the combination that makes the most sense for that = client.

 =E2=80=94 Justin


On Feb 21, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I got ahead of myself. A = completion URI protects the User only if the User is sent back to the = same channel the transaction started so the Client can confirm it is the = same User that started the transaction.

so this does not help the = security:

"Being= able to provide a completion URI even if the user is starting on a = device is a great insight on how to address the threat above."

3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The = lightbulb finally clicked on for me. Thanks for your patience.

The threat you are = describing is where the attacker starts a transaction at the client, and = gets the victim to complete it. Correct?
I still think the Client should be = able to signal if it will be doing a redirect vs showing a QR code (or = wants to do both).

Being able to provide a completion URI even if the user is = starting on a device is a great insight on how to address the threat = above. 

I'm going to ponder how to align XAuth more with these = features of XYZ.
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at = 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Fri, Feb = 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in = complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we = have:

This= sentence looks to be missing = something.

Apologies: We realized they both used = AS-composed URLs to get the user to the AS in a web browser for = interaction purposes.

 

 - redirect: tells = the AS that the client can send the user to an arbitrary URL (and the AS = doesn=E2=80=99t care how the client gets that info to the user; could be = a redirect or an image or send a push notification to a secondary = device, we don=E2=80=99t care as long as the user shows up in a browser = at the AS =E2=80=94 so maybe this field can be renamed to be more = universally accurate)

As stated in this thread, it may be = useful for the AS to know if the URL will be in a QR code, or in a full = redirect.

In = XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has = to do, so it needs to know the difference between a popup, and a full = browser redirect. This is targetted at SPAs, where an additional URL to = redirect to is extra work.
 
 - code: tells the AS that the client can present a = short code the user can type (along with a static URL the user can get = to, maybe by typing the URL manually, but it=E2=80=99s not = dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the client can receive = the completion message from a front channel interaction through a = redirect. Note that the client might have gotten to the AS through a = redirect on-device, through a QR-code off device, or through some other = magic, and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80= =99s only concerned with how to get the user = :back:.

In a full redirect, the Client wants = the AS to send the user back so that it can continue.

The only parameter in = the completion message is the nonce, which seems superfluous. See = below.
 

These three can be = combined in different ways depending on what you want to do at the = client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style = authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain = user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code = together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D = to get the long URL and the short code not he screen at the same = time. 

On = top of that, they can be combined with other methods. Maybe I can send = the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most = sense.

Per my question later in this thread, = why would the Client not know what interaction it wants prior to the = request?

What do you mean? The client does know = what it wants and that=E2=80=99s why it=E2=80=99s asking for what it = wants. We=E2=80=99re debating different methods for the client to ask = for what it wants. This question does not make sense to me.


If the AS is doing CIBA, that is not a = decision just for the Client. Both the AS and the Client need to know = they are doing CIBA. (FWIW: I think this work supersedes = CIBA)

As I=E2=80=99ve stated previously, I = believe the interaction methods here can supersede CIBA.


Additionally, different interactions = have different risk profiles. Sophisticated ASes will use that signal in = the risk assessment, and may do ask for additional authentication or = verification.
 

Yes, exactly my point. Because = different interactions have different risks, the AS will need to be able = to decide which interactions it=E2=80=99s OK with for a given request. = This could vary based on what=E2=80=99s being requested, or who=E2=80=99s = doing the requesting.


An interesting = difference between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps = the concept of the =E2=80=9Cauthorization code=E2=80=9D in the callback = response (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2= =80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D = which is hashed along with a pair of nonces generated by the client and = the AS in the back channel. This binds the front channel response to = both the back channel request and the back channel response for a given = transaction =E2=80=94 and note that I=E2=80=99m really open to having a = better way to generate and calculate such a binding, but I think this = works. In any event, this protects the client from session fixation and = injection on the return from the front channel that it=E2=80=99s = susceptible to in a pure polling model, and the hashing approach = basically combines the security parameters of the OAuth 2 authorization = code and (to an extent) state, PKCE=E2=80=99s code_challenge, and = OIDC=E2=80=99s nonce in one element. This is only applicable if you=E2=80=99= re coming back to the client and you can validate the hash and present = the reference parameter. If you=E2=80=99re doing just plain polling, you = don=E2=80=99t have that protection =E2=80=94 but the client and the AS = are aware of that risk, and there=E2=80=99s an option to prevent = it.

XAuth has = removed the authorization code concept in its redirect return, and = clients only do polling against the GS API in order to get tokens. While = I obviously think it=E2=80=99s very valuable to remove things from the = front channel, I don=E2=80=99t think this is something we can remove = without opening up attack surfaces that have already been identified in = previous protocols. I would like to understand why XAuth is not = susceptible to the same kinds of attacks, or if it is, what mitigations = there are for them. 

Unlike OAuth 2.0, there = are no parameters in the front channel response to the Client. The = redirect back to the Client is only needed to return the interaction = back to the Client.

This argument rings = tautologically hollow =E2=80=94 there are no parameters because you=E2=80=99= ve defined that there aren=E2=80=99t any in XAuth. XYZ does have = parameters, to tie the front and back channel requests together when = doing redirect back and forth.

If you=E2=80=99re not doing a redirect = back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), = then it=E2=80=99s a polling mechanism like XAuth, the device flow, etc. = There are very real risks to this.


XAuth (and XYZ) have a different flow than OAuth 2.0 (or = OAuth 1.0)

In = OAuth, the AS gives a code to the User to give to the Client that the = Client then gives to the GS.

In XAuth, the AS gives a "code" to the = Client that givers it to the User to give to the GS.

In XAuth, the "code" is = either a user code, or something embedded in the URI the User is = redirected to.

Therefore, there is nothing to protect in the redirect back = to the Client.

If I'm missing an attack, please elaborate how it would = happen.

One form of impersonation is well = documented: https://hueniverse.com/explaining-the-oauth-session-fixation-at= tack-aa759250a0e7

OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a = similar request initiation step to what we see in XYZ, XAuth, PAR, = FAPI/OBUK, etc, and it=E2=80=99s susceptible to the same kind of = issue.

 

 =E2=80=94 = Justin

On Feb 20, 2020, at 3:21 PM, = Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

Thanks = for the update, Dick! I=E2=80=99m going to confine my comments here to = interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
 
Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for <some other machine-driven interaction mode>=E2=80=9D?
 
Even if we consider things like QR code data capacity, = that=E2=80=99s really just a URI length limitation, which could apply to = non-QR interaction modes, e.g., if the Client device wants to = communicate the URI over an extremely bandwidth-constrained channel. And = it=E2=80=99s not clear to me how including a URI length limitation in = the request helps. If a GS is capable of generating a shorter URI, why = wouldn=E2=80=99t it always return that? On the client side, it can look = at the length of the URI provided and decide what to do with it (e.g., = render a QR code or display it or do nothing with it).
 
So = that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a = code entry page, both of which are human-friendly.
 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in = user code interaction and aligned QR code to be a superset of user = code.
Fixed = descriptions.

 

----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat

=E1=90=A7
-- 
Txauth mailing = list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth




= --Apple-Mail=_9851B76A-C4A4-452E-8369-E4D638B359C5-- From nobody Fri Feb 21 16:46:18 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78B112006B for ; Fri, 21 Feb 2020 16:46:16 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8p617oSQh1P for ; Fri, 21 Feb 2020 16:46:12 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 0B4901200E5 for ; Fri, 21 Feb 2020 16:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582332372; x=1613868372; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tCqVgZcwEs/2pnWYn9wzlOJtnVVqDoiYQyR8Rc0+62A=; b=tidRGOkCVHlf6M1pmA+IljEjl+vmHUnn26Att5eIjDkAxQqBKWevj4N0 wvhXDx8nyufkgKmhrFdvF3z8HLAMkrhWyujF32TdDy+PBF4SOXITVWgrC gJNU9cBEubBMDUbQ2i59a9ZlMrk3zkoofC48dXDgvBcWFnzLxOEPKl1aq Q=; IronPort-SDR: mKjgUL2pTITNRNWB+XAkpcbHUBldAHnMx8trjomba4BmVsv/ERp7j1Yl3Vy5mE7dKzDBolvnNH 0lS1/Ia3Y2sw== X-IronPort-AV: E=Sophos; i="5.70,470,1574121600"; d="scan'208,217"; a="28189914" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 22 Feb 2020 00:46:10 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (Postfix) with ESMTPS id 21B8CA2A62; Sat, 22 Feb 2020 00:46:08 +0000 (UTC) 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; Sat, 22 Feb 2020 00:46:08 +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.1497.2; Sat, 22 Feb 2020 00:46:08 +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.1497.000; Sat, 22 Feb 2020 00:46:08 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt CC: "txauth@ietf.org" Thread-Topic: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt Thread-Index: AQHV5sjpEbhLLf0ddUeR1uDqNGJ4aagkAu0AgAC1x4CAASaNgA== Date: Sat, 22 Feb 2020 00:46:07 +0000 Message-ID: <02197105-4C5F-41F1-8A84-8972F25C5132@amazon.com> References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@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.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.50] Content-Type: multipart/alternative; boundary="_000_021971054C5F41F18A848972F25C5132amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 00:46:17 -0000 --_000_021971054C5F41F18A848972F25C5132amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2theSwgeW914oCZdmUgY29udmluY2VkIG1lIHRoYXQgdGhlcmUgYXJlIHVzZSBjYXNlcyBmb3Ig YSBHUyB0byBzb21ldGltZXMgcHJvdmlkZSBhIHNob3J0ZXIgVVJJIGFuZCBzb21ldGltZXMgYSBs b25nZXIgVVJJLiBMZXTigJlzIHNlZSBpZiBJIGNhbiBjb252aW5jZSB5b3UgdGhhdCBpbnRlcmFj dGlvbiBtb2RlIHNlbGVjdGlvbiBpcyBsZXNzIGRldGVybWluaXN0aWMgdGhhbiB5b3UgdGhpbmsu IDpEDQoNCkkgKnRoaW5rKiB0aGUgQ2xpZW50IGNhbiBiZSBleHBlY3RlZCB0byBrbm93IGlmIGl0 IHdpbGwgdHJhbnNmZXIgaW50ZXJhY3Rpb24gdG8gdGhlIEdTIHdpdGhpbiB0aGUgc2FtZSB1c2Vy IGFnZW50IHRoZSBlbmQgdXNlciBpcyBhY2Nlc3NpbmcgQ2xpZW50IHRocm91Z2guIEluIG90aGVy IHdvcmRzLCBJIHRoaW5rIHRoZXJlIGFyZSB0d28gcmVsaWFibHkgZGlmZmVyZW50aWFibGUgbW9k ZXM6IHNhbWUgVUEgKDMwWCByZWRpcmVjdCwgb3BlbiBpbiBzYW1lIHdpbmRvdywgb3BlbiBpbiBu ZXcpLCBhbmQgZGlmZmVyZW50IFVBIChjb2RlLCBRUiBjb2RlLCBvcGVuaW5nIFVSSSBpbiBleHRl cm5hbCBicm93c2VyLCBldGMuKS4gSG93ZXZlciwgd2l0aGluIGVhY2ggbW9kZSwgdGhlIENsaWVu dCBtYXkgbm90IGtub3cgd2hpY2ggbWVjaGFuaXNtIHdpbGwgYmUgdXNlZC4gKGUuZy4sIGZvciDi gJxzYW1lIFVB4oCdOiB3aWxsIHRoZSBDbGllbnQgb3BlbiB0aGUgVVJJIGluIHRoZSBzYW1lIHdp bmRvdyBvciBhIG5ldyBvbmU7IGZvciDigJxkaWZmZXJlbnQgVUHigJ06IHdpbGwgdGhlIGVuZCB1 c2VyIHNjYW4gYSBRUiBjb2RlIG9yIGVudGVyIGEgY29kZSBvciB0YXAgb24gYSBVUkkgaW4gYW4g U01TKQ0KDQpUaGUgbm9uLWRldGVybWluaXNtIGNvbWVzIGZyb20gdHdvIHNvdXJjZXM6DQoNCiAg MS4gIEVudmlyb25tZW50YWwgY29uZGl0aW9ucw0KICAgICAqICAgQSBjb25zb2xlIGFwcCBtaWdo dCBiZSBhYmxlIHRvIGRpcmVjdGx5IG9wZW4gYSBVUkkgaW4gdGhlIHN5c3RlbeKAmXMgYnJvd3Nl ciAoZS5nLiwgd2hlbiBydW5uaW5nIGluIGEgdGVybWluYWwgd2luZG93IG9uIGEgZGVza3RvcCks IG9yIGl0IG1pZ2h0IG5vdCAoZS5nLiwgb24gYSBoZWFkbGVzcyBzeXN0ZW0pLiBUaGUgYXBwIG1h eSBub3Qga25vdyB0aGUgYW5zd2VyIHVudGlsIGl0IHRyaWVzIGl0Lg0KICAgICAqICAgVGhhdCBz YW1lIGNvbnNvbGUgYXBwIG1pZ2h0IGJlIHJ1bm5pbmcgaW4gYSByZW1vdGUgdGVybWluYWwsIHN1 Y2ggdGhhdCB0aGUgZW5kIHVzZXIgd291bGQgYmUgYWJsZSB0byBjbGljayBvciBjb3B5IGFuZCBw YXN0ZSBhIFVSSSBwcmludGVkIGJ5IHRoZSBhcHAuDQogICAgICogICBBbiBTUEEgbWlnaHQgYmUg YWJsZSB0byBvcGVuIGEgcG9wdXAsIG9yIGl0IG1pZ2h0IGZhaWwgZm9yIHZhcmlvdXMgcmVhc29u cy4gSXQgbWlnaHQgZGVjaWRlIHRvIGZhbGwgYmFjayB0byBhIHJlZGlyZWN0IGlmIGl0IGRldGVj dHMgdGhhdCB0aGUgcG9wdXAgZmFpbGVkIHRvIG9wZW4uIEl0IG1pZ2h0IHdhbnQgdGhlIOKAnHBv cHVw4oCdIHRvIGdyYWNlZnVsbHkgZmFsbCBiYWNrIHRvIGEgcmVkaXJlY3QtbGlrZSBleHBlcmll bmNlIGluIGNhc2UgdGhlIHVzZXIgYWdlbnQgb25seSBzdXBwb3J0cyBhIHNpbmdsZSB3aW5kb3cg YXQgYSB0aW1lIChlLmcuLCBlbWJlZGRlZCB1c2VyIGFnZW50cyBpbiBhcHBzIGxpa2UgRmFjZWJv b2sgYW5kIFR3aXR0ZXIpLg0KICAgICAqICAgRW52aXJvbm1lbnRhbCBjb25kaXRpb25zIG1heSBt YWtlIGl0IGRpZmZpY3VsdCB0byBzY2FuIGEgUVIgY29kZSAoZS5nLiwgdGhlIHNjcmVlbiBpcyBk aXJ0eSwgZm9nZ3ksIGNyYWNrZWQsIG9yIHVuZGVyIGRpcmVjdCBzdW5saWdodCksIGJ1dCBzdGls bCBhbGxvdyBmb3IgYSBwZXJzb24gdG8gcmVhZCBhIHNob3J0IGNvZGUuIFRoZSBDbGllbnQgbGlr ZWx5IGhhcyBubyB3YXkgb2YgZGV0ZWN0aW5nIHN1Y2ggdGhpbmdzLg0KICAyLiAgRW5kIHVzZXIg Y2FwYWJpbGl0aWVzIGFuZCBwcmVmZXJlbmNlcw0KICAgICAqICAgVGhleSBtYXkgaGF2ZSBhIHBo eXNpY2FsIGRpc2FiaWxpdHkgb3Igb3RoZXIgY29uZGl0aW9uIHRoYXQgbWFrZXMgaXQgZGlmZmlj dWx0IHRvIGltcG9zc2libGUgZm9yIHRoZW0gdG8gc2NhbiBhIFFSIGNvZGUuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGku ICAgICAgVGhleSBtYXkgYmUgY2FwYWJsZSBvZiByZWFkaW5nIGFuZCBjb3B5aW5nIGEgc2hvcnQg Y29kZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGlpLiAgICAgIFRoZXkgbWF5IGJlIGNhcGFibGUgb2YgbGlzdGVuaW5nIHRv IGFuZCBlbnRlcmluZyBhIHNob3J0IGNvZGUgc3Bva2VuIGJ5IHRoZSBkZXZpY2UuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWlp LiAgICAgIFRoZXkgbWF5IGJlIGNhcGFibGUgb2YgZm9sbG93aW5nIGEgbGluayBzZW50IHRvIHRo ZW0gdmlhIHRleHQgb3IgZW1haWwsIHdoaWNoIHRoZXkgY2FuIGFjY2VzcyBvbiBhIGRldmljZSB3 aXRoIGdyZWF0ZXIgYWNjZXNzaWJpbGl0eSBvcHRpb25zLg0KDQogICAgICogICBUaGV5IG1heSBu b3QgaGF2ZSBhIGRldmljZSBjYXBhYmxlIG9mIHNjYW5uaW5nIGEgUVIgY29kZSwgb3IgdGhlIGRl dmljZSBtYXkgbm90IGJlIGZ1bmN0aW9uaW5nLCBvciB0aGUgZGV2aWNlIG1heSBiZSB0aGUgb25l IHRoYXQgdGhlIGNvZGUgaXMgYmVpbmcgZGlzcGxheWVkIG9uLg0KICAgICAqICAgVGhleSBtYXkg bm90IGtub3cgd2hhdCBhIFFSIGNvZGUgaXMsIG9yIHVuZGVyc3RhbmQgaG93IHRvIHVzZSBvbmUu DQogICAgICogICBUaGV5IG1heSB3YW50IHRvIGNvbXBsZXRlIHRoZSBmbG93IG9uIGEgZGV2aWNl IHRoYXQgaXMgaW5jYXBhYmxlIG9mIHNjYW5uaW5nIHRoZSBRUiBjb2RlIChlLmcuLCB0aGVpciBk ZXNrdG9wKS4NCiAgICAgKiAgIFRoZXkgbWF5IHByZWZlciB0byBoYXZlIHRoZSBVUkkgdGV4dGVk IG9yIGVtYWlsZWQgdG8gdGhlbSwgcmF0aGVyIHRoYW4gaGF2aW5nIHRvIHNjYW4gb3IgY29weSBh IGNvZGUuDQogICAgICogICBUaGV5IG1heSBub3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIGNvbXBhbmlv biBhcHAgdGhhdCB0aGUgQ2xpZW50IHRyYW5zbWl0dGVkIHRoZSBVUkkgdG8gKGUuZy4sIGJlY2F1 c2UgaXTigJlzIG9uIHRoZSBzaGFyZWQgZmFtaWx5IHRhYmxldCwgYW5kIGl04oCZcyB0aGVpciBz aWJsaW5n4oCZcyB0dXJuIHRvIHVzZSBpdCkuDQoNCklmIHdlIGFsbG93IHRoYXQgdGhlIEdTIG1p Z2h0IHdhbnQgdG8gaXNzdWUgbG9uZyBVUklzIHdoZW4gcG9zc2libGUsIHRoZW4gdGhlcmXigJlz IGJhc2ljYWxseSB0aHJlZSB0aGluZ3MgYSBDbGllbnQgbWlnaHQgd2FudCwgaW4gYW55IGNvbWJp bmF0aW9uOg0KDQogICogICBVUkksIG5vIGxlbmd0aCByZXN0cmljdGlvbg0KICAqICAgVVJJLCB3 aXRoIHNvbWUgbWF4IGxlbmd0aCAoZS5nLiwgYmVjYXVzZSBvZiBRUiBjb2RlIGRhdGEgY2FwYWNp dHksIFNNUyBtZXNzYWdlIHNpemUgbGltaXRzLCBkaXNwbGF5IGNvbnN0cmFpbnRzLCBldGMuKQ0K ICAqICAgU2hvcnQgY29kZSBhbmQgY29kZSBlbnRyeSBVUkksIGJvdGggaHVtYW4tZnJpZW5kbHkN Cg0KVGhlIEdTIGNhbuKAmXQgZW5mb3JjZSBob3cgdGhlc2UgYXJlIHVzZWQ7IHRoZXkgY2FuIG9u bHkgY29udHJvbCB3aGF0IHRoZXkgaXNzdWUsIGFuZCBob3cgdGhleSByZXNwb25kIHdoZW4gaW50 ZXJhY3Rpb24gaXMgdHJhbnNmZXJyZWQgdG8gdGhlbS4gRGVmaW5pbmcgaW50ZXJhY3Rpb24gb2Jq ZWN0IHByb3BlcnRpZXMgaW4gdGVybXMgb2YgdXNhZ2UgaW1wbGllcyBjb25zdHJhaW50cyBhbmQg Z3VhcmFudGVlcyB0aGF0IGRvbuKAmXQgZXhpc3QsIGFuZCBDbGllbnRzIGFyZSBnb2luZyB0byBk aXNyZWdhcmQgb3VyIHByZXNjcmliZWQgdXNlcyBhbnl3YXkgKGUuZy4sIGJ5IHNlbmRpbmcgYSDi gJxxcmNvZGXigJ0gVVJJIGluIGFuIFNNUykuDQoNCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4gKHNo ZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvDQoN Cg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2Rh eSwgRmVicnVhcnkgMjAsIDIwMjAgYXQgMzoxMyBQTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+DQpDYzogInR4YXV0aEBpZXRmLm9yZyIgPHR4 YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMudHh0DQoNCg0KDQpP biBUaHUsIEZlYiAyMCwgMjAyMCBhdCAxMjoyMSBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3Rl Og0KVGhhbmtzIGZvciB0aGUgdXBkYXRlLCBEaWNrISBJ4oCZbSBnb2luZyB0byBjb25maW5lIG15 IGNvbW1lbnRzIGhlcmUgdG8gaW50ZXJhY3Rpb24gbW9kZSBkZXNpZ24sIHNldHRpbmcgYXNpZGUg d2hldGhlciBvciBub3Qgd2UgbmVlZCDigJxwb3B1cOKAnS4gOkQNCg0KT25jZSB0aGUgR1MgaGFu ZHMgdGhhdCBVUkkgYmFjayB0byB0aGUgQ2xpZW50LCBpdCBoYXMgemVybyBjb250cm9sIG92ZXIg aG93IHRoZSBDbGllbnQgdXNlcyBpdC4gVGhlIENsaWVudCBjb3VsZCBwcmVzZW50IGFueSBVUkkg KG9mIGEgcmVhc29uYWJsZSBzaXplKSBpbnRvIGEgUVIgY29kZSwgb3IgcHJlc2VudCBpdCBhcyBh IGNsaWNrYWJsZSBsaW5rLCBvciByZWRpcmVjdCB0byBpdCwgb3Igb3BlbiBpdCBpbiBhbiBleHRl cm5hbCBicm93c2VyLCBvciBkbyBhbnkgbnVtYmVyIG9mIG90aGVyIGFzLXlldC1ub3QtaW52ZW50 ZWQgdGhpbmdzIHdpdGggaXQuIE1vcmVvdmVyLCB0aGUgQ2xpZW50IG1heSBub3Qga25vdyB5ZXQg d2hhdCBpdCB3YW50cyB0byBkbyB3aXRoIGl0Lg0KDQpXaHkgd291bGQgdGhlIENsaWVudCBub3Qg a25vdyB3aGF0IGl0IHdhbnRzIHRvIGRvIHdpdGggaXQ/IFdoYXQgd291bGQgY2hhbmdlIGJldHdl ZW4gd2hlbiB0aGUgQ2xpZW50IGNhbGxlZCB0aGUgR1MsIGFuZCB0aGUgR1MgcmVzcG9uZGVkPw0K DQpJIHRoaW5rIG9mIHRoZSBpbnRlcmFjdGlvbiBiZWluZyB0aGUgQ2xpZW50IHNheWluZyAiSSB3 YW50IHRvIGRvIGEgcmVkaXJlY3QiLCBhbmQgdGhlIEdTIHNheXMsICJvaywgaGVyZSBpcyB0aGUg VVJJIi4gT3IgdGhlIENsaWVudCBzYXlzLCAiSSB3YW50IHRvIHNob3cgb25seSBhIGNvZGUgYW5k IGEgVVJJIiwgYW5kIHRoZSBHUyBzYXlzICJvaywgaGVyZSBpcyBhIGdvb2QsIGFuZCBhbiBlYXN5 IHRvIHJlYWQgVVJJIGZvciB0aGUgdXNlciB0byB0eXBlIGluIGFuZCBuYXZpZ2F0ZSB0by4NCg0K SSB1bmRlcnN0YW5kIHRoZXJlIGFyZSBpbnRlcmFjdGlvbnMgdGhhdCBtYXkgbm90IHlldCBiZWVu IGludmVudGVkIHlldC4gTW9yZSBvbiB0aGF0IGZ1cnRoZXIgZG93bi4NCg0KU28gd2hhdCB2YWx1 ZSBpcyB0aGVyZSBpbiBkaXN0aW5ndWlzaGluZyBiZXR3ZWVuIOKAnEkgd2FudCBhIFVSSSBmb3Ig YSByZWRpcmVjdOKAnSB2cy4g4oCcSSB3YW50IGEgVVJJIGZvciBhIFFSIGNvZGXigJ0gdnMuIOKA nEkgd2FudCBhIFVSSSBmb3IgPHNvbWUgb3RoZXIgbWFjaGluZS1kcml2ZW4gaW50ZXJhY3Rpb24g bW9kZT7igJ0/DQoNCkV2ZW4gaWYgd2UgY29uc2lkZXIgdGhpbmdzIGxpa2UgUVIgY29kZSBkYXRh IGNhcGFjaXR5LCB0aGF04oCZcyByZWFsbHkganVzdCBhIFVSSSBsZW5ndGggbGltaXRhdGlvbiwg d2hpY2ggY291bGQgYXBwbHkgdG8gbm9uLVFSIGludGVyYWN0aW9uIG1vZGVzLCBlLmcuLCBpZiB0 aGUgQ2xpZW50IGRldmljZSB3YW50cyB0byBjb21tdW5pY2F0ZSB0aGUgVVJJIG92ZXIgYW4gZXh0 cmVtZWx5IGJhbmR3aWR0aC1jb25zdHJhaW5lZCBjaGFubmVsLg0KDQpJIGRvbid0IHVuZGVyc3Rh bmQgd2hlbiB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlLiBJZiB0aGUgQ2xpZW50IGlzIGdvaW5nIHRv IGRvIGEgcmVkaXJlY3QsIHRoZW4gdGhlIFVSSSBsZW5ndGggaXMgbm90IHNpZ25pZmljYW50Lg0K DQpBbmQgaXTigJlzIG5vdCBjbGVhciB0byBtZSBob3cgaW5jbHVkaW5nIGEgVVJJIGxlbmd0aCBs aW1pdGF0aW9uIGluIHRoZSByZXF1ZXN0IGhlbHBzLiBJZiBhIEdTIGlzIGNhcGFibGUgb2YgZ2Vu ZXJhdGluZyBhIHNob3J0ZXIgVVJJLCB3aHkgd291bGRu4oCZdCBpdCBhbHdheXMgcmV0dXJuIHRo YXQ/DQoNClRoZXJlIG1heSBiZSBhIHZhcmlldHkgb2YgcmVhc29ucyB0aGF0IGEgR1MgbWF5IHdh bnQgdG8gcHJvdmlkZSBhIGRpZmZlcmVudCBVUkkgZm9yIGEgUVIgY29kZSB0aGFuIGEgcmVkaXJl Y3QsIG9yIGV2ZW4gYSBwb3B1cC4NCg0KMSkgUGVyaGFwcyB0aGUgR1MgaGFzIG9ubHkgYmVlbiBz dXBwb3J0aW5nIHJlZGlyZWN0cywgYW5kIGhhcyBhIHZlcnkgbG9uZyBVUkwuIFRoZXkgYWRkIHN1 cHBvcnQgZm9yIGEgUVIgY29kZSwgYW5kIHVzZSBhIDNQIHNlcnZpY2UgdGhhdCByZWRpcmVjdHMg ZnJvbSB0aGUgc2hvcnQgVVJMIHVzZWQgaW4gdGhlIFFSIGNvZGUsIHRoZSB0aGUgbG9uZyBVUkwu IFRoZXkgZG9uJ3Qgd2FudCB0byBwYXkgZm9yIHRoZSAzUCBzZXJ2aWNlIGFueW1vcmUgdGhhbiB0 aGV5IGhhdmUgdG8uDQoNCjIpIFRoZSBHUyB3YW50cyB0aGUgUVIgY29kZSBhbmQgdXNlciBjb2Rl IGZsb3dzIHRvIGdvIHRocm91Z2ggdGhlIHNhbWUgbWFjaGluZXJ5IHRoYXQgbG9va3MgdXAgdGhl IGNvZGUgdG8gZmluZCB0aGUgR3JhbnQuIFRoZSBVUkkgaW4gYSByZWRpcmVjdCBoYXMgdGhlIGdy YW50IGVtYmVkZGVkIGluIHRoZSBVUkkuIFRoZXkgZG9uJ3Qgd2FudCB0byBoYXZlIHRvIHVzZSB0 aGUgY29kZSB0byBHcmFudCBtYWNoaW5lcnkgZm9yIGFsbCBVUklzLg0KDQozKSBBIFFSIGNvZGUg ZmxvdyB3aWxsIHVzdWFsbHkgYmUgZG9uZSBvbiBhIHBob25lLCBhbmQgdGhlIEdTIHdhbnRzIHRv IGF0dGVtcHQgdG8gbGF1bmNoIGEgbmF0aXZlIGFwcCBpbiBzb21lIHdheSwNCg0KV2hpbGUgeW91 IGFyZSBjb3JyZWN0LCB3ZSBjb3VsZCBtYWtlIGFsbCBVUklzIGJlIHNob3J0IGVub3VnaCB0aGF0 IHRoZXkgY2FuIGJlIGVhc2lseSBzY2FubmVkLCB3aHkgZm9yY2UgdGhhdCBvbiBpbXBsZW1lbnRv cnM/DQoNClRoZSBVUkkgbGVuZ3RoIGxpbWl0YXRpb24gY29uY2VwdCB3YXMgZm9yIHRoZSBkaXNw bGF5X3VyaSBzbyB0aGF0IGEgY29uc3RyYWluZWQgZGV2aWNlIGhhcyBhbiB1cHBlciBsaW1pdC4g QSBzaW1pbGFyIHVwcGVyIGxpbWl0IG9uIFFSIGNvZGUgd291bGQgYWxsb3cgYSBjb25zdHJhaW5l ZCBkZXZpY2UgdG8ga25vdyB0aGUgcGl4ZWwgcmVzb2x1dGlvbiBpdCBuZWVkcyB0byBzaG93IHRo ZSBRUiBjb2RlLg0KDQpPbiB0aGUgY2xpZW50IHNpZGUsIGl0IGNhbiBsb29rIGF0IHRoZSBsZW5n dGggb2YgdGhlIFVSSSBwcm92aWRlZCBhbmQgZGVjaWRlIHdoYXQgdG8gZG8gd2l0aCBpdCAoZS5n LiwgcmVuZGVyIGEgUVIgY29kZSBvciBkaXNwbGF5IGl0IG9yIGRvIG5vdGhpbmcgd2l0aCBpdCku DQoNClBlciBhYm92ZSwgd2h5IHdvdWxkIHRoZSBDbGllbnQgbm90IGFscmVhZHkga25vdyB3aGF0 IGV4cGVyaWVuY2UgaXQgd2FudHMgdG8gcHJlc2VudCB0byB0aGUgVXNlcj8NCg0KQSBVUkkgdG8g YmUgZGlzcGxheWVkLCBhbmQgYSBVUkkgdG8gYmUgcmVkaXJlY3RlZCB0byBhcmUgbGlrZWx5IGdv aW5nIHRvIGJlIHF1aXRlIGRpZmZlcmVudC4NCg0KVGhlIFVSSSBmb3IgYSBVc2VyIHRvIGVudGVy IGEgY29kZSB3aWxsIGxpa2VseSBiZSBhIHN0YXRpYyB2YWx1ZSB0aGF0IGlzIGVhc3kgdG8gdHlw ZS4gVGhlIFVzZXIgd2lsbCBsaWtlbHkgaGF2ZSB0byBhdXRoZW50aWNhdGUgYXQgdGhhdCBwYWdl LCBhbmQgdGhlbiBiZSBwcm9tcHRlZCB0byBlbnRlciB0aGUgY29kZS4NCg0KDQpTbyB0aGF0IHJl YWxseSBsZWF2ZXMgdXMgd2l0aCB0d28gaW50ZXJhY3Rpb24gbW9kZXMgdGhhdCB3ZSBuZWVkOg0K DQrCtyAgICAgIOKAnHVyaeKAnSwgd2hpY2ggcmV0dXJucyBhIGZ1bGwgVVJJIHRoYXQgbWF5IG5v dCBiZSBodW1hbiBmcmllbmRseTsgYW5kDQoNCsK3ICAgICAg4oCcY29kZeKAnSwgd2hpY2ggcmV0 dXJucyBhIGNvZGUgYW5kIFVSSSBmb3IgYSBjb2RlIGVudHJ5IHBhZ2UsIGJvdGggb2Ygd2hpY2gg YXJlIGh1bWFuLWZyaWVuZGx5Lg0KDQpUaG9zZSBjb3VsZCBiZSBjb21iaW5hYmxlIHRvIGdldCBi b3RoLCBhbmQgZXZlbiBpZiB3ZSBkb27igJl0IGdvIGRvd24gdGhlIG11bHRpcGxlIGludGVyYWN0 aW9uIG1vZGUgcm91dGUgd2UgY291bGQgYWRkIHRoZSBmdWxsIFVSSSB0byB0aGUg4oCcY29kZeKA nSBpbnRlcmFjdGlvbiBvYmplY3QuIEl0IHdvdWxkbuKAmXQgaHVydCBhbnl0aGluZyB0byBkbyBz by4NCg0KSW4gdGhlIGxhdGVzdCB2ZXJzaW9uLCBJIGdhdmUgZWFjaCBVUkkgaXRzIG93biBuYW1l IHNvIHRoYXQgdGhlIEdTIGNhbiBiZSBjbGVhciBhYm91dCBob3cgaXQgd2lsbCBiZSB1c2VkLg0K DQpXaGlsZSB3ZSBjb3VsZCBzcXVlZXplIGFsbCB0aGUgZnVuY3Rpb25hbGl0eSBpbnRvIGEgY291 cGxlIHBhcmFtZXRlcnMsIEkgdGhpbmsgaXQgbWFrZXMgaXQgaGFyZGVyIGZvciBleGlzdGluZyBk ZXBsb3ltZW50cyB0byBtaWdyYXRlIHRvIHRoZSBwcm90b2NvbC4gSSB0aGluayB3ZSBzaG91bGQg bWFrZSBpdCBlYXN5IGZvciBkZXZlbG9wZXJzIHRvIHRha2Ugd2hhdCB0aGV5IGFscmVhZHkgaGF2 ZSBhbmQgdXNlIGl0IHdpdGggWEF1dGguDQoNCndydC4gbm90LXlldC1pbnZlbnRlZCBpbnRlcmFj dGlvbnMuIFRoZXNlIGludGVyYWN0aW9ucyBhcmUgZm9yIG5vdC15ZXQtZGVzY3JpYmVkIHVzZSBj YXNlcy4gKGlmIG90aGVyIHVzZSBjYXNlcyBleGlzdCwgdGhlbiBsZXQncyBsb29rIGF0IHRoZW0g YW5kIGFkZCB0aGUgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpZiBuZWVkZWQpIFdlIGRvbid0IGtu b3cgd2hhdCBwYXJhbWV0ZXJzIHdpbGwgYmUgbmVlZGVkLCBhbmQgb3ZlcmxvYWRpbmcgdGhlIHBh cmFtZXRlcnMgYW5kIGxldHRpbmcgdGhlIENsaWVudCBkbyB3aGF0ZXZlciBpdCB3YW50cyBkb2Vz IG5vdCBzZWVtIGxpa2UgaXQgd2lsbCBpbnRlcm9wZXJhdGUgLS0gdGhlIENsaWVudCBkZWNpZGVz IGl0IHdhbnRzIHRvIGRvIHNvbWUgbmV3IGludGVyYWN0aW9uLCBhbmQgdXNlcyB0aGUgcGFyYW1l dGVycyBpbiBhIHdheSB0aGUgR1MgZG9lcyBub3QgdW5kZXJzdGFuZC4NCg0KDQoNCg0KDQrigJMN CkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5h bWF6b24uY29tL2lkZW50aXR5Lw0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sg SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+ DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAyMCBhdCA2OjA0IFBNDQpUbzogInR4YXV0 aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRmLm9yZzxtYWls dG86dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFtUeGF1dGhdIEZ3ZDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQNCg0KQWRk ZWQgaW4gdXNlciBjb2RlIGludGVyYWN0aW9uIGFuZCBhbGlnbmVkIFFSIGNvZGUgdG8gYmUgYSBz dXBlcnNldCBvZiB1c2VyIGNvZGUuDQpGaXhlZCBkZXNjcmlwdGlvbnMuDQoNCi0tLS0tLS0tLS0g Rm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlLCBGZWIgMTgs IDIwMjAgYXQgNjowMCBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQNClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhh cmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KDQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEaWNrIEhhcmR0IGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1oYXJkdC14YXV0aC1w cm90b2NvbA0KUmV2aXNpb246ICAgICAgIDAzDQpUaXRsZTogICAgICAgICAgVGhlIFhBdXRoIFBy b3RvY29sDQpEb2N1bWVudCBkYXRlOiAgMjAyMC0wMi0xOA0KR3JvdXA6ICAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDUzDQpVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3Rv Y29sLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMw0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGFy ZHQteGF1dGgtcHJvdG9jb2wNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMNCg0KQWJzdHJhY3Q6DQog ICBDbGllbnQgc29mdHdhcmUgb2Z0ZW4gZGVzaXJlcyByZXNvdXJjZXMgb3IgaWRlbnRpdHkgY2xh aW1zIHRoYXQgYXJlDQogICBpbmRlcGVuZGVudCBvZiB0aGUgY2xpZW50LiAgVGhpcyBwcm90b2Nv bCBhbGxvd3MgYSB1c2VyIGFuZC9vcg0KICAgcmVzb3VyY2Ugb3duZXIgdG8gZGVsZWdhdGUgcmVz b3VyY2UgYXV0aG9yaXphdGlvbiBhbmQvb3IgcmVsZWFzZSBvZg0KICAgaWRlbnRpdHkgY2xhaW1z IHRvIGEgc2VydmVyLiAgQ2xpZW50IHNvZnR3YXJlIGNhbiB0aGVuIHJlcXVlc3QgYWNjZXNzDQog ICB0byByZXNvdXJjZXMgYW5kL29yIGlkZW50aXR5IGNsYWltcyBieSBjYWxsaW5nIHRoZSBzZXJ2 ZXIuICBUaGUNCiAgIHNlcnZlciBhY3F1aXJlcyBjb25zZW50IGFuZCBhdXRob3JpemF0aW9uIGZy b20gdGhlIHVzZXIgYW5kL29yDQogICByZXNvdXJjZSBvd25lciBpZiByZXF1aXJlZCwgYW5kIHRo ZW4gcmV0dXJucyB0byB0aGUgY2xpZW50IHNvZnR3YXJlDQogICB0aGUgYXV0aG9yaXphdGlvbiBh bmQgaWRlbnRpdHkgY2xhaW1zIHRoYXQgd2VyZSBhcHByb3ZlZC4gIFRoaXMNCiAgIHByb3RvY29s IGNhbiBiZSBleHRlbmRlZCB0byBzdXBwb3J0IGFsdGVybmF0aXZlIGF1dGhvcml6YXRpb25zLA0K ICAgY2xhaW1zLCBpbnRlcmFjdGlvbnMsIGFuZCBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtcy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9v bHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KW2h0dHBzOi8vbWFpbGZvb2dh ZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5 cGU9emVyb2NvbnRlbnQmZ3VpZD01MzNlNTExNi02ZTIxLTRhOTAtYTFjOS1iYTdkODcwYTg3Yzld 4ZCnDQo= --_000_021971054C5F41F18A848972F25C5132amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <348D581B6494DE48894B4C0A2D7C7512@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW04NDU2MjQ3OTUxMTgzMDY0ODY1bXNvbGlz dHBhcmFncmFwaCwgbGkuZ21haWwtbTg0NTYyNDc5NTExODMwNjQ4NjVtc29saXN0cGFyYWdyYXBo LCBkaXYuZ21haWwtbTg0NTYyNDc5NTExODMwNjQ4NjVtc29saXN0cGFyYWdyYXBoDQoJe21zby1z dHlsZS1uYW1lOmdtYWlsLW1fODQ1NjI0Nzk1MTE4MzA2NDg2NW1zb2xpc3RwYXJhZ3JhcGg7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYzOTE5Njg2Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAxNDEzMTAwNiA2NzY5 ODcwMyA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MQ0KCXttc28tbGlzdC1pZDo2MDgxMjQyNTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0xOTMxMDI0NzkwIC0xNzYzODEyODA2IDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjEyMDQxNzA2NDI7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMjkxOTQ4NTQg LTE3OTMyNzgyMjggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Ik1TIE1pbmNobyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7 bXNvLWxpc3QtaWQ6MTU5Njc0MDQ4NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMzOTU5NDg4 Mjt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Pa2F5LCB5b3XigJl2ZSBjb252aW5jZWQgbWUgdGhhdCB0aGVyZSBhcmUgdXNlIGNhc2Vz IGZvciBhIEdTIHRvIHNvbWV0aW1lcyBwcm92aWRlIGEgc2hvcnRlciBVUkkgYW5kIHNvbWV0aW1l cyBhIGxvbmdlciBVUkkuIExldOKAmXMgc2VlIGlmIEkgY2FuIGNvbnZpbmNlIHlvdSB0aGF0IGlu dGVyYWN0aW9uIG1vZGUgc2VsZWN0aW9uIGlzIGxlc3MgZGV0ZXJtaW5pc3RpYyB0aGFuIHlvdSB0 aGluay4gOkQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSAqPGI+dGhpbms8L2I+KiB0aGUgQ2xp ZW50IGNhbiBiZSBleHBlY3RlZCB0byBrbm93IGlmIGl0IHdpbGwgdHJhbnNmZXIgaW50ZXJhY3Rp b24gdG8gdGhlIEdTIHdpdGhpbiB0aGUgc2FtZSB1c2VyIGFnZW50IHRoZSBlbmQgdXNlciBpcyBh Y2Nlc3NpbmcgQ2xpZW50IHRocm91Z2guIEluIG90aGVyIHdvcmRzLCBJIHRoaW5rIHRoZXJlIGFy ZSB0d28gcmVsaWFibHkgZGlmZmVyZW50aWFibGUgbW9kZXM6IHNhbWUNCiBVQSAoMzBYIHJlZGly ZWN0LCBvcGVuIGluIHNhbWUgd2luZG93LCBvcGVuIGluIG5ldyksIGFuZCBkaWZmZXJlbnQgVUEg KGNvZGUsIFFSIGNvZGUsIG9wZW5pbmcgVVJJIGluIGV4dGVybmFsIGJyb3dzZXIsIGV0Yy4pLiBI b3dldmVyLCB3aXRoaW4gZWFjaCBtb2RlLCB0aGUgQ2xpZW50IG1heSBub3Qga25vdyB3aGljaCBt ZWNoYW5pc20gd2lsbCBiZSB1c2VkLiAoZS5nLiwgZm9yIOKAnHNhbWUgVUHigJ06IHdpbGwgdGhl IENsaWVudCBvcGVuIHRoZSBVUkkNCiBpbiB0aGUgc2FtZSB3aW5kb3cgb3IgYSBuZXcgb25lOyBm b3Ig4oCcZGlmZmVyZW50IFVB4oCdOiB3aWxsIHRoZSBlbmQgdXNlciBzY2FuIGEgUVIgY29kZSBv ciBlbnRlciBhIGNvZGUgb3IgdGFwIG9uIGEgVVJJIGluIGFuIFNNUyk8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIG5vbi1kZXRlcm1pbmlzbSBjb21lcyBmcm9tIHR3byBzb3VyY2VzOjxvOnA+ PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwxIGxldmVsMSBsZm8zIj5FbnZpcm9ubWVudGFsIGNvbmRpdGlvbnM8bzpwPjwvbzpw Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwx IGxldmVsMiBsZm8zIj5BIGNvbnNvbGUgYXBwIG1pZ2h0IGJlIGFibGUgdG8gZGlyZWN0bHkgb3Bl biBhIFVSSSBpbiB0aGUgc3lzdGVt4oCZcyBicm93c2VyIChlLmcuLCB3aGVuIHJ1bm5pbmcgaW4g YSB0ZXJtaW5hbCB3aW5kb3cgb24gYSBkZXNrdG9wKSwgb3IgaXQgbWlnaHQgbm90IChlLmcuLCBv biBhIGhlYWRsZXNzIHN5c3RlbSkuIFRoZQ0KIGFwcCBtYXkgbm90IGtub3cgdGhlIGFuc3dlciB1 bnRpbCBpdCB0cmllcyBpdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8zIj5UaGF0 IHNhbWUgY29uc29sZSBhcHAgbWlnaHQgYmUgcnVubmluZyBpbiBhIHJlbW90ZSB0ZXJtaW5hbCwg c3VjaCB0aGF0IHRoZSBlbmQgdXNlciB3b3VsZCBiZSBhYmxlIHRvIGNsaWNrIG9yIGNvcHkgYW5k IHBhc3RlIGEgVVJJIHByaW50ZWQgYnkgdGhlIGFwcC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxl dmVsMiBsZm8zIj5BbiBTUEEgbWlnaHQgYmUgYWJsZSB0byBvcGVuIGEgcG9wdXAsIG9yIGl0IG1p Z2h0IGZhaWwgZm9yIHZhcmlvdXMgcmVhc29ucy4gSXQgbWlnaHQgZGVjaWRlIHRvIGZhbGwgYmFj ayB0byBhIHJlZGlyZWN0IGlmIGl0IGRldGVjdHMgdGhhdCB0aGUgcG9wdXAgZmFpbGVkIHRvIG9w ZW4uIEl0IG1pZ2h0IHdhbnQgdGhlDQog4oCccG9wdXDigJ0gdG8gZ3JhY2VmdWxseSBmYWxsIGJh Y2sgdG8gYSByZWRpcmVjdC1saWtlIGV4cGVyaWVuY2UgaW4gY2FzZSB0aGUgdXNlciBhZ2VudCBv bmx5IHN1cHBvcnRzIGEgc2luZ2xlIHdpbmRvdyBhdCBhIHRpbWUgKGUuZy4sIGVtYmVkZGVkIHVz ZXIgYWdlbnRzIGluIGFwcHMgbGlrZSBGYWNlYm9vayBhbmQgVHdpdHRlcikuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+RW52aXJvbm1lbnRhbCBjb25kaXRpb25zIG1heSBtYWtl IGl0IGRpZmZpY3VsdCB0byBzY2FuIGEgUVIgY29kZSAoZS5nLiwgdGhlIHNjcmVlbiBpcyBkaXJ0 eSwgZm9nZ3ksIGNyYWNrZWQsIG9yIHVuZGVyIGRpcmVjdCBzdW5saWdodCksIGJ1dCBzdGlsbCBh bGxvdyBmb3IgYSBwZXJzb24gdG8gcmVhZCBhIHNob3J0DQogY29kZS4gVGhlIENsaWVudCBsaWtl bHkgaGFzIG5vIHdheSBvZiBkZXRlY3Rpbmcgc3VjaCB0aGluZ3MuPG86cD48L286cD48L2xpPjwv b2w+DQo8L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+RW5kIHVzZXIgY2FwYWJpbGl0aWVzIGFuZCBw cmVmZXJlbmNlczxvOnA+PC9vOnA+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0i MSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPlRoZXkgbWF5IGhhdmUgYSBwaHlzaWNh bCBkaXNhYmlsaXR5IG9yIG90aGVyIGNvbmRpdGlvbiB0aGF0IG1ha2VzIGl0IGRpZmZpY3VsdCB0 byBpbXBvc3NpYmxlIGZvciB0aGVtIHRvIHNjYW4gYSBRUiBjb2RlLjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotMS41aW47bXNvLXRleHQtaW5kZW50LWFsdDotOS4w cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwzIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj5pLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRo ZXkgbWF5IGJlIGNhcGFibGUgb2YgcmVhZGluZyBhbmQgY29weWluZyBhIHNob3J0IGNvZGUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0xLjVpbjttc28tdGV4dC1pbmRlbnQtYWx0Oi05LjBwdDtt c28tbGlzdDpsMSBsZXZlbDMgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlpLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZXkgbWF5IGJlIGNhcGFi bGUgb2YgbGlzdGVuaW5nIHRvIGFuZCBlbnRlcmluZyBhIHNob3J0IGNvZGUgc3Bva2VuIGJ5IHRo ZSBkZXZpY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0xLjVpbjttc28tdGV4dC1pbmRlbnQt YWx0Oi05LjBwdDttc28tbGlzdDpsMSBsZXZlbDMgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmlpaS48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGV5IG1heSBiZSBjYXBh YmxlIG9mIGZvbGxvd2luZyBhIGxpbmsgc2VudCB0byB0aGVtIHZpYSB0ZXh0IG9yIGVtYWlsLCB3 aGljaCB0aGV5IGNhbiBhY2Nlc3Mgb24gYSBkZXZpY2Ugd2l0aCBncmVhdGVyIGFjY2Vzc2liaWxp dHkgb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIyIiB0eXBlPSIxIj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIyIiB0 eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+VGhleSBtYXkgbm90IGhhdmUgYSBkZXZpY2Ug Y2FwYWJsZSBvZiBzY2FubmluZyBhIFFSIGNvZGUsIG9yIHRoZSBkZXZpY2UgbWF5IG5vdCBiZSBm dW5jdGlvbmluZywgb3IgdGhlIGRldmljZSBtYXkgYmUgdGhlIG9uZSB0aGF0IHRoZSBjb2RlIGlz IGJlaW5nIGRpc3BsYXllZCBvbi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8zIj5U aGV5IG1heSBub3Qga25vdyB3aGF0IGEgUVIgY29kZSBpcywgb3IgdW5kZXJzdGFuZCBob3cgdG8g dXNlIG9uZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8zIj5UaGV5IG1heSB3YW50 IHRvIGNvbXBsZXRlIHRoZSBmbG93IG9uIGEgZGV2aWNlIHRoYXQgaXMgaW5jYXBhYmxlIG9mIHNj YW5uaW5nIHRoZSBRUiBjb2RlIChlLmcuLCB0aGVpciBkZXNrdG9wKS48bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwxIGxldmVsMiBsZm8zIj5UaGV5IG1heSBwcmVmZXIgdG8gaGF2ZSB0aGUgVVJJIHRleHRl ZCBvciBlbWFpbGVkIHRvIHRoZW0sIHJhdGhlciB0aGFuIGhhdmluZyB0byBzY2FuIG9yIGNvcHkg YSBjb2RlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPlRoZXkgbWF5IG5vdCBo YXZlIGFjY2VzcyB0byB0aGUgY29tcGFuaW9uIGFwcCB0aGF0IHRoZSBDbGllbnQgdHJhbnNtaXR0 ZWQgdGhlIFVSSSB0byAoZS5nLiwgYmVjYXVzZSBpdOKAmXMgb24gdGhlIHNoYXJlZCBmYW1pbHkg dGFibGV0LCBhbmQgaXTigJlzIHRoZWlyIHNpYmxpbmfigJlzIHR1cm4gdG8gdXNlIGl0KS48bzpw PjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGFsbG93IHRoYXQgdGhlIEdT IG1pZ2h0IHdhbnQgdG8gaXNzdWUgbG9uZyBVUklzIHdoZW4gcG9zc2libGUsIHRoZW4gdGhlcmXi gJlzIGJhc2ljYWxseSB0aHJlZSB0aGluZ3MgYSBDbGllbnQgbWlnaHQgd2FudCwgaW4gYW55IGNv bWJpbmF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPlVSSSwgbm8gbGVuZ3RoIHJlc3RyaWN0aW9u PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+VVJJLCB3aXRoIHNvbWUgbWF4IGxl bmd0aCAoZS5nLiwgYmVjYXVzZSBvZiBRUiBjb2RlIGRhdGEgY2FwYWNpdHksIFNNUyBtZXNzYWdl IHNpemUgbGltaXRzLCBkaXNwbGF5IGNvbnN0cmFpbnRzLCBldGMuKTxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzQiPlNob3J0IGNvZGUgYW5kIGNvZGUgZW50cnkgVVJJLCBib3RoIGh1 bWFuLWZyaWVuZGx5PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBHUyBjYW7igJl0 IGVuZm9yY2UgaG93IHRoZXNlIGFyZSB1c2VkOyB0aGV5IGNhbiBvbmx5IGNvbnRyb2wgd2hhdCB0 aGV5IGlzc3VlLCBhbmQgaG93IHRoZXkgcmVzcG9uZCB3aGVuIGludGVyYWN0aW9uIGlzIHRyYW5z ZmVycmVkIHRvIHRoZW0uIERlZmluaW5nIGludGVyYWN0aW9uIG9iamVjdCBwcm9wZXJ0aWVzIGlu IHRlcm1zIG9mIHVzYWdlIGltcGxpZXMgY29uc3RyYWludHMgYW5kIGd1YXJhbnRlZXMgdGhhdA0K IGRvbuKAmXQgZXhpc3QsIGFuZCBDbGllbnRzIGFyZSBnb2luZyB0byBkaXNyZWdhcmQgb3VyIHBy ZXNjcmliZWQgdXNlcyBhbnl3YXkgKGUuZy4sIGJ5IHNlbmRpbmcgYSDigJxxcmNvZGXigJ0gVVJJ IGluIGFuIFNNUykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+4oCTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBCYWNrbWFu IChzaGUvaGVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lzwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBGZWJydWFyeSAyMCwgMjAyMCBhdCAzOjEzIFBN PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAm bHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBp ZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW1R4YXV0aF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhh cmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIFRodSwgRmViIDIwLCAyMDIwIGF0IDEyOjIxIFBNIFJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9u LmNvbSI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQpUaGFua3MgZm9yIHRoZSB1cGRhdGUsIERpY2shIEnigJltIGdv aW5nIHRvIGNvbmZpbmUgbXkgY29tbWVudHMgaGVyZSB0byBpbnRlcmFjdGlvbiBtb2RlIGRlc2ln biwgc2V0dGluZyBhc2lkZSB3aGV0aGVyIG9yIG5vdCB3ZSBuZWVkIOKAnHBvcHVw4oCdLiA6RDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQpPbmNlIHRoZSBHUyBoYW5kcyB0aGF0IFVSSSBiYWNrIHRvIHRoZSBDbGllbnQsIGl0 IGhhcyB6ZXJvIGNvbnRyb2wgb3ZlciBob3cgdGhlIENsaWVudCB1c2VzIGl0LiBUaGUgQ2xpZW50 IGNvdWxkIHByZXNlbnQgYW55IFVSSSAob2YgYSByZWFzb25hYmxlIHNpemUpIGludG8gYSBRUiBj b2RlLCBvciBwcmVzZW50IGl0IGFzIGEgY2xpY2thYmxlIGxpbmssIG9yIHJlZGlyZWN0IHRvIGl0 LCBvciBvcGVuIGl0IGluIGFuIGV4dGVybmFsIGJyb3dzZXIsDQogb3IgZG8gYW55IG51bWJlciBv ZiBvdGhlciBhcy15ZXQtbm90LWludmVudGVkIHRoaW5ncyB3aXRoIGl0LiBNb3Jlb3ZlciwgdGhl IENsaWVudCBtYXkgbm90IGtub3cgeWV0IHdoYXQgaXQgd2FudHMgdG8gZG8gd2l0aCBpdC4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+V2h5IHdvdWxkIHRoZSBDbGllbnQgbm90IGtub3cgd2hhdCBpdCB3YW50cyB0 byBkbyB3aXRoIGl0PyBXaGF0IHdvdWxkIGNoYW5nZSBiZXR3ZWVuIHdoZW4gdGhlIENsaWVudCBj YWxsZWQgdGhlIEdTLCBhbmQgdGhlIEdTIHJlc3BvbmRlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhpbmsgb2YgdGhl IGludGVyYWN0aW9uIGJlaW5nIHRoZSBDbGllbnQgc2F5aW5nICZxdW90O0kgd2FudCB0byBkbyBh IHJlZGlyZWN0JnF1b3Q7LCBhbmQgdGhlIEdTIHNheXMsICZxdW90O29rLCBoZXJlIGlzIHRoZSBV UkkmcXVvdDsuIE9yIHRoZSBDbGllbnQgc2F5cywgJnF1b3Q7SSB3YW50IHRvIHNob3cgb25seSBh IGNvZGUgYW5kIGEgVVJJJnF1b3Q7LCBhbmQgdGhlIEdTIHNheXMgJnF1b3Q7b2ssIGhlcmUgaXMg YSBnb29kLA0KIGFuZCBhbiBlYXN5IHRvIHJlYWQgVVJJIGZvciB0aGUgdXNlciB0byB0eXBlIGlu IGFuZCBuYXZpZ2F0ZSB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdW5kZXJzdGFuZCB0aGVy ZSBhcmUgaW50ZXJhY3Rpb25zIHRoYXQgbWF5IG5vdCB5ZXQgYmVlbiBpbnZlbnRlZCB5ZXQuIE1v cmUgb24gdGhhdCBmdXJ0aGVyIGRvd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NClNvIHdoYXQgdmFsdWUgaXMgdGhlcmUgaW4g ZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiDigJxJIHdhbnQgYSBVUkkgZm9yIGEgcmVkaXJlY3TigJ0g dnMuIOKAnEkgd2FudCBhIFVSSSBmb3IgYSBRUiBjb2Rl4oCdIHZzLiDigJxJIHdhbnQgYSBVUkkg Zm9yICZsdDtzb21lIG90aGVyIG1hY2hpbmUtZHJpdmVuIGludGVyYWN0aW9uIG1vZGUmZ3Q74oCd PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQpFdmVuIGlmIHdlIGNvbnNpZGVyIHRoaW5ncyBsaWtlIFFSIGNvZGUgZGF0YSBj YXBhY2l0eSwgdGhhdOKAmXMgcmVhbGx5IGp1c3QgYSBVUkkgbGVuZ3RoIGxpbWl0YXRpb24sIHdo aWNoIGNvdWxkIGFwcGx5IHRvIG5vbi1RUiBpbnRlcmFjdGlvbiBtb2RlcywgZS5nLiwgaWYgdGhl IENsaWVudCBkZXZpY2Ugd2FudHMgdG8gY29tbXVuaWNhdGUgdGhlIFVSSSBvdmVyIGFuIGV4dHJl bWVseSBiYW5kd2lkdGgtY29uc3RyYWluZWQgY2hhbm5lbC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkb24n dCB1bmRlcnN0YW5kIHdoZW4gdGhpcyB3b3VsZCBiZSB0aGUgY2FzZS4gSWYgdGhlIENsaWVudCBp cyBnb2luZyB0byBkbyBhIHJlZGlyZWN0LCB0aGVuIHRoZSBVUkkgbGVuZ3RoIGlzIG5vdCBzaWdu aWZpY2FudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KQW5kIGl04oCZcyBub3QgY2xlYXIgdG8gbWUgaG93IGluY2x1ZGluZyBh IFVSSSBsZW5ndGggbGltaXRhdGlvbiBpbiB0aGUgcmVxdWVzdCBoZWxwcy4gSWYgYSBHUyBpcyBj YXBhYmxlIG9mIGdlbmVyYXRpbmcgYSBzaG9ydGVyIFVSSSwgd2h5IHdvdWxkbuKAmXQgaXQgYWx3 YXlzIHJldHVybiB0aGF0Pw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVyZSBtYXkgYmUgYSB2YXJpZXR5IG9m IHJlYXNvbnMgdGhhdCBhIEdTIG1heSB3YW50IHRvIHByb3ZpZGUgYSBkaWZmZXJlbnQgVVJJIGZv ciBhIFFSIGNvZGUgdGhhbiBhIHJlZGlyZWN0LCBvciBldmVuIGEgcG9wdXAuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MSkgUGVyaGFwcyB0aGUgR1MgaGFz IG9ubHkgYmVlbiBzdXBwb3J0aW5nIHJlZGlyZWN0cywgYW5kIGhhcyBhIHZlcnkgbG9uZyBVUkwu IFRoZXkgYWRkIHN1cHBvcnQgZm9yIGEgUVIgY29kZSwgYW5kIHVzZSBhIDNQIHNlcnZpY2UgdGhh dCByZWRpcmVjdHMgZnJvbSB0aGUgc2hvcnQgVVJMIHVzZWQgaW4gdGhlIFFSIGNvZGUsIHRoZSB0 aGUgbG9uZyBVUkwuIFRoZXkgZG9uJ3QNCiB3YW50IHRvIHBheSBmb3IgdGhlIDNQIHNlcnZpY2Ug YW55bW9yZSB0aGFuIHRoZXkgaGF2ZSB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4yKSBUaGUgR1Mgd2FudHMgdGhlIFFSIGNvZGUgYW5kIHVzZXIgY29k ZSBmbG93cyB0byBnbyB0aHJvdWdoIHRoZSBzYW1lIG1hY2hpbmVyeSB0aGF0IGxvb2tzIHVwIHRo ZSBjb2RlIHRvIGZpbmQgdGhlIEdyYW50LiBUaGUgVVJJIGluIGEgcmVkaXJlY3QgaGFzIHRoZSBn cmFudCBlbWJlZGRlZCBpbiB0aGUgVVJJLiBUaGV5IGRvbid0IHdhbnQgdG8gaGF2ZSB0byB1c2UN CiB0aGUgY29kZSB0byBHcmFudCBtYWNoaW5lcnkgZm9yIGFsbCBVUklzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjMpIEEgUVIgY29kZSBmbG93IHdpbGwg dXN1YWxseSBiZSBkb25lIG9uIGEgcGhvbmUsIGFuZCB0aGUgR1Mgd2FudHMgdG8gYXR0ZW1wdCB0 byBsYXVuY2ggYSBuYXRpdmUgYXBwIGluIHNvbWUgd2F5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldoaWxlIHlvdSBhcmUgY29ycmVjdCwgd2UgY291bGQg bWFrZSBhbGwgVVJJcyBiZSBzaG9ydCBlbm91Z2ggdGhhdCB0aGV5IGNhbiBiZSBlYXNpbHkgc2Nh bm5lZCwgd2h5IGZvcmNlIHRoYXQgb24gaW1wbGVtZW50b3JzPyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBVUkkgbGVuZ3RoIGxpbWl0YXRp b24gY29uY2VwdCB3YXMgZm9yIHRoZSBkaXNwbGF5X3VyaSBzbyB0aGF0IGEgY29uc3RyYWluZWQg ZGV2aWNlIGhhcyBhbiB1cHBlciBsaW1pdC4gQSBzaW1pbGFyIHVwcGVyIGxpbWl0IG9uIFFSIGNv ZGUgd291bGQgYWxsb3cgYSBjb25zdHJhaW5lZCBkZXZpY2UgdG8ga25vdyB0aGUgcGl4ZWwgcmVz b2x1dGlvbiBpdCBuZWVkcw0KIHRvIHNob3cgdGhlIFFSIGNvZGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCk9uIHRoZSBjbGll bnQgc2lkZSwgaXQgY2FuIGxvb2sgYXQgdGhlIGxlbmd0aCBvZiB0aGUgVVJJIHByb3ZpZGVkIGFu ZCBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIGl0IChlLmcuLCByZW5kZXIgYSBRUiBjb2RlIG9yIGRp c3BsYXkgaXQgb3IgZG8gbm90aGluZyB3aXRoIGl0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBlciBhYm92ZSwg d2h5IHdvdWxkIHRoZSBDbGllbnQgbm90IGFscmVhZHkga25vdyB3aGF0IGV4cGVyaWVuY2UgaXQg d2FudHMgdG8gcHJlc2VudCB0byB0aGUgVXNlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5BIFVSSSB0byBiZSBkaXNwbGF5ZWQsIGFuZCBhIFVSSSB0byBi ZSByZWRpcmVjdGVkIHRvIGFyZSBsaWtlbHkgZ29pbmcgdG8gYmUgcXVpdGUgZGlmZmVyZW50LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBV UkkgZm9yIGEgVXNlciB0byBlbnRlciBhIGNvZGUgd2lsbCBsaWtlbHkgYmUgYSBzdGF0aWMgdmFs dWUgdGhhdCBpcyBlYXN5IHRvIHR5cGUuIFRoZSBVc2VyIHdpbGwgbGlrZWx5IGhhdmUgdG8gYXV0 aGVudGljYXRlIGF0IHRoYXQgcGFnZSwgYW5kIHRoZW4gYmUgcHJvbXB0ZWQgdG8gZW50ZXIgdGhl IGNvZGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KU28gdGhhdCByZWFsbHkgbGVhdmVzIHVzIHdpdGgg dHdvIGludGVyYWN0aW9uIG1vZGVzIHRoYXQgd2UgbmVlZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tODQ1NjI0Nzk1MTE4MzA2NDg2NW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+4oCc dXJp4oCdLCB3aGljaCByZXR1cm5zIGEgZnVsbCBVUkkgdGhhdCBtYXkgbm90IGJlIGh1bWFuIGZy aWVuZGx5OyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tODQ1NjI0Nzk1MTE4 MzA2NDg2NW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+4oCcY29kZeKAnSwgd2hpY2ggcmV0dXJucyBh IGNvZGUgYW5kIFVSSSBmb3IgYSBjb2RlIGVudHJ5IHBhZ2UsIGJvdGggb2Ygd2hpY2ggYXJlIGh1 bWFuLWZyaWVuZGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpUaG9zZSBjb3VsZCBiZSBjb21iaW5hYmxlIHRvIGdldCBi b3RoLCBhbmQgZXZlbiBpZiB3ZSBkb27igJl0IGdvIGRvd24gdGhlIG11bHRpcGxlIGludGVyYWN0 aW9uIG1vZGUgcm91dGUgd2UgY291bGQgYWRkIHRoZSBmdWxsIFVSSSB0byB0aGUg4oCcY29kZeKA nSBpbnRlcmFjdGlvbiBvYmplY3QuIEl0IHdvdWxkbuKAmXQgaHVydCBhbnl0aGluZyB0byBkbyBz by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkluIHRoZSBsYXRlc3QgdmVyc2lvbiwgSSBnYXZlIGVhY2ggVVJJIGl0 cyBvd24gbmFtZSBzbyB0aGF0IHRoZSBHUyBjYW4gYmUgY2xlYXIgYWJvdXQgaG93IGl0IHdpbGwg YmUgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5X aGlsZSB3ZSBjb3VsZCBzcXVlZXplIGFsbCB0aGUgZnVuY3Rpb25hbGl0eSBpbnRvIGEgY291cGxl IHBhcmFtZXRlcnMsIEkgdGhpbmsgaXQgbWFrZXMgaXQgaGFyZGVyIGZvciBleGlzdGluZyBkZXBs b3ltZW50cyB0byBtaWdyYXRlIHRvIHRoZSBwcm90b2NvbC4gSSB0aGluayB3ZSBzaG91bGQgbWFr ZSBpdCBlYXN5IGZvciBkZXZlbG9wZXJzIHRvIHRha2Ugd2hhdCB0aGV5DQogYWxyZWFkeSBoYXZl IGFuZCB1c2UgaXQgd2l0aCBYQXV0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj53cnQuIG5vdC15ZXQtaW52ZW50ZWQgaW50ZXJhY3Rpb25zLiBUaGVzZSBp bnRlcmFjdGlvbnMgYXJlIGZvciBub3QteWV0LWRlc2NyaWJlZCB1c2UgY2FzZXMuIChpZiBvdGhl ciB1c2UgY2FzZXMgZXhpc3QsIHRoZW4gbGV0J3MgbG9vayBhdCB0aGVtIGFuZCBhZGQgdGhlIGlu dGVyYWN0aW9uIG1lY2hhbmlzbXMgaWYgbmVlZGVkKSBXZSBkb24ndCBrbm93IHdoYXQgcGFyYW1l dGVycw0KIHdpbGwgYmUgbmVlZGVkLCBhbmQgb3ZlcmxvYWRpbmcgdGhlIHBhcmFtZXRlcnMgYW5k IGxldHRpbmcgdGhlIENsaWVudCBkbyB3aGF0ZXZlciBpdCB3YW50cyBkb2VzIG5vdCBzZWVtIGxp a2UgaXQgd2lsbCBpbnRlcm9wZXJhdGUgLS0gdGhlIENsaWVudCBkZWNpZGVzIGl0IHdhbnRzIHRv IGRvIHNvbWUgbmV3IGludGVyYWN0aW9uLCBhbmQgdXNlcyB0aGUgcGFyYW1ldGVycyBpbiBhIHdh eSB0aGUgR1MgZG9lcyBub3QgdW5kZXJzdGFuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hl L2hlcik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8v YXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwNTYzQzEiPmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvPC9zcGFuPjwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4i Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0 aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVz ZGF5LCBGZWJydWFyeSAxOCwgMjAyMCBhdCA2OjA0IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PltUeGF1dGhdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJkdC14 YXV0aC1wcm90b2NvbC0wMy50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MS4waW4iPg0KQWRkZWQgaW4gdXNlciBjb2RlIGludGVyYWN0aW9uIGFuZCBhbGlnbmVkIFFS IGNvZGUgdG8gYmUgYSBzdXBlcnNldCBvZiB1c2VyIGNvZGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KRml4ZWQgZGVz Y3JpcHRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KLS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogVHVlLCBGZWIgMTgsIDIwMjAgYXQgNjowMCBQ TTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZHQt eGF1dGgtcHJvdG9jb2wtMDMudHh0PGJyPg0KVG86IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21h aWwuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21h cmdpbi1sZWZ0OjEuMGluIj4NCjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IERpY2sgSGFyZHQgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRG IHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sPGJyPg0KUmV2aXNpb246Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDM8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRoZSBYQXV0aCBQcm90b2NvbDxicj4NCkRvY3VtZW50IGRhdGU6Jm5i c3A7IDIwMjAtMDItMTg8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgNTM8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3Rv Y29sLTAzLnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmR0 LXhhdXRoLXByb3RvY29sLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLzwvYT48YnI+DQpIdG1saXplZDom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDM8L2E+ PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2Nv bCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2w8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1oYXJkdC14YXV0aC1wcm90 b2NvbC0wMzwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7Q2xpZW50 IHNvZnR3YXJlIG9mdGVuIGRlc2lyZXMgcmVzb3VyY2VzIG9yIGlkZW50aXR5IGNsYWltcyB0aGF0 IGFyZTxicj4NCiZuYnNwOyAmbmJzcDtpbmRlcGVuZGVudCBvZiB0aGUgY2xpZW50LiZuYnNwOyBU aGlzIHByb3RvY29sIGFsbG93cyBhIHVzZXIgYW5kL29yPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc291 cmNlIG93bmVyIHRvIGRlbGVnYXRlIHJlc291cmNlIGF1dGhvcml6YXRpb24gYW5kL29yIHJlbGVh c2Ugb2Y8YnI+DQombmJzcDsgJm5ic3A7aWRlbnRpdHkgY2xhaW1zIHRvIGEgc2VydmVyLiZuYnNw OyBDbGllbnQgc29mdHdhcmUgY2FuIHRoZW4gcmVxdWVzdCBhY2Nlc3M8YnI+DQombmJzcDsgJm5i c3A7dG8gcmVzb3VyY2VzIGFuZC9vciBpZGVudGl0eSBjbGFpbXMgYnkgY2FsbGluZyB0aGUgc2Vy dmVyLiZuYnNwOyBUaGU8YnI+DQombmJzcDsgJm5ic3A7c2VydmVyIGFjcXVpcmVzIGNvbnNlbnQg YW5kIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgdXNlciBhbmQvb3I8YnI+DQombmJzcDsgJm5ic3A7 cmVzb3VyY2Ugb3duZXIgaWYgcmVxdWlyZWQsIGFuZCB0aGVuIHJldHVybnMgdG8gdGhlIGNsaWVu dCBzb2Z0d2FyZTxicj4NCiZuYnNwOyAmbmJzcDt0aGUgYXV0aG9yaXphdGlvbiBhbmQgaWRlbnRp dHkgY2xhaW1zIHRoYXQgd2VyZSBhcHByb3ZlZC4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJz cDtwcm90b2NvbCBjYW4gYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCBhbHRlcm5hdGl2ZSBhdXRob3Jp emF0aW9ucyw8YnI+DQombmJzcDsgJm5ic3A7Y2xhaW1zLCBpbnRlcmFjdGlvbnMsIGFuZCBjbGll bnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBT ZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8aW1nIGJvcmRlcj0i MCIgaWQ9ImdtYWlsLW1fODQ1NjI0Nzk1MTE4MzA2NDg2NV94MDA1Zl94MDAwMF9pMTAyNSIgc3Jj PSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD01MzNlNTExNi02 ZTIxLTRhOTAtYTFjOS1iYTdkODcwYTg3YzkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQ pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_021971054C5F41F18A848972F25C5132amazoncom_-- From nobody Fri Feb 21 17:13:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9A1200F6 for ; Fri, 21 Feb 2020 17:13:00 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZOT6qzdC-YD for ; Fri, 21 Feb 2020 17:12:55 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17741200F4 for ; Fri, 21 Feb 2020 17:12:54 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id x7so4117150ljc.1 for ; Fri, 21 Feb 2020 17:12:54 -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=EsAaIn7P1VpPls288FXC3BI0itqXWgh/GZHkGyzobRM=; b=CE5ezxWtz/KC4AzLGnli5Ti1Ja2JTyhjuZkwvZQZd4jWJT/ZfSHfzt9CQctGLfmufi K5wShbWudiyO4RYizlROSiHh+HXXateSosLA0M4VJc4On623LS4awCWjf1/PMMI/saeM wVV5sUQwhz783cMlZ/cwPwmOuQuzKtPpJk5mUtT1I8t7tj3BQ/Tzs8ck085qcGNxZ0uX sIv7z58ixWKGwR1JlOSIJUkqSjFZyO2ao97ZP2c6MELI95SIff2FrRTRc6GPNnjqgVYH Cobq/gVsot10eQrmT95mpbNWGQOvoQUAmierQHEoB3zC8PSWEXI7/JD3PccUhQqvbQ/v SnWQ== 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=EsAaIn7P1VpPls288FXC3BI0itqXWgh/GZHkGyzobRM=; b=DcGctzEIGvYlXsyRCL6qEkuSvNxplnkImFIVd8iN0YvayLP4Lb4tf0gUVsRQO5TG+z eXDIXzwF7NpO1pghzi2Af7McDOiWii+l9nlj1npq4tcvQKc9aFEjbzAaqJp0krSnPQeT rG8H4hoejxS2bVdhTOxphgWKvZnWgwtwqhHXS17ywjaJwxeU8kOut55HESqts10uJRig tMG9Xi5YXeUj+CDDbKtGet1yl51svWtRdLEmVJvM621Qm9URpYvEYgGEi50W1Cl+XHRH 6ql06+EdkQxpbHmFKmXfT3ECHKkFjR/adeeXduU9oGOoFhFz+zuDtjOl01ZUACdZInUq jBiA== X-Gm-Message-State: APjAAAWzMuTG0PeMFG0ai6WtMGrWSbm+gAJlsahZqKGwbtEV+KAMdwgv shsNPi6soQoWblQqmb+kSDzqZVCel5slY0KXuS/sjxcu X-Google-Smtp-Source: APXvYqycOWuVQfP3vWO+2ThqcaHZSbOtHnxTlbpwNN9MHYuW47XatsSP8byAEauIVm/YwTwi0SbBgK2O5mZs8S0FoaE= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr23985597ljh.138.1582333972807; Fri, 21 Feb 2020 17:12:52 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> In-Reply-To: <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> From: Dick Hardt Date: Fri, 21 Feb 2020 17:12:26 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005d8621059f1fd658" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 01:13:00 -0000 --0000000000005d8621059f1fd658 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Client presents the interact_ref to the AS with the transaction handle. The AS will be able to tell the Client if the interact_ref belongs to the transaction. Why is that enough? =E1=90=A7 On Fri, Feb 21, 2020 at 1:51 PM Justin Richer wrote: > The hash offers the same kinds of protections to the client that the OIDC > nonce does =E2=80=94 it binds the front channel return to something you g= et from > the back channel. > > In other words, the client can be sure that the return value that it=E2= =80=99s > getting is related to the request it made in the first place, and not > another one. Clients using per-request redirect URIs can also help with > this, but this is something that the server can provide directly. > > =E2=80=94 Justin > > On Feb 21, 2020, at 4:14 PM, Dick Hardt wrote: > > While I can see the value of the interact_ref (aka interaction_ref) in th= e > return URI that allows the Client to ensure the user that started the > transaction is the same one that interacted at the AS, I don't understand > why a hash is required. Would you elaborate? > =E1=90=A7 > > On Fri, Feb 21, 2020 at 1:02 PM Justin Richer wrote: > >> But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, wh= ich is a very >> common case. For cases where the client doesn=E2=80=99t expect the user = to come >> back on the same channel, then they don=E2=80=99t use the callback mecha= nism. They >> might use the =E2=80=9Cfinish message=E2=80=9D URL that Annabelle mentio= ned in the other >> thread, or they might just print out =E2=80=9Cyou=E2=80=99re done now!= =E2=80=9D at the AS, which is >> common today. >> >> XYZ=E2=80=99s interaction structure allows the composition of these thin= gs, under >> the control of the client. This is exactly why it=E2=80=99s important to= be able to >> specify how to get to the AS and how to get back as separate items, so t= hat >> the client can compose the combination that makes the most sense for tha= t >> client. >> >> =E2=80=94 Justin >> >> >> On Feb 21, 2020, at 3:52 PM, Dick Hardt wrote: >> >> I got ahead of myself. A completion URI protects the User only if the >> User is sent back to the same channel the transaction started so the Cli= ent >> can confirm it is the same User that started the transaction. >> >> so this does not help the security: >> >> "Being able to provide a completion URI even if the user is starting on = a >> device is a great insight on how to address the threat above." >> >> =E1=90=A7 >> >> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt wrote= : >> >>> The lightbulb finally clicked on for me. Thanks for your patience. >>> >>> The threat you are describing is where the attacker starts a transactio= n >>> at the client, and gets the victim to complete it. Correct? >>> >>> I still think the Client should be able to signal if it will be doing a >>> redirect vs showing a QR code (or wants to do both). >>> >>> Being able to provide a completion URI even if the user is starting on = a >>> device is a great insight on how to address the threat above. >>> >>> I'm going to ponder how to align XAuth more with these features of XYZ. >>> =E1=90=A7 >>> >>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer wrote: >>> >>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote: >>>> >>>> >>>> >>>> >>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer wrote: >>>> >>>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized = that >>>>> both the QR Code and Authorization Code, and that the only difference= is >>>>> how the user gets back to the client. So instead of inventing a new >>>>> type of interaction, we split them. In XYZ, we have: >>>>> >>>> >>>> This sentence looks to be missing something. >>>> >>>> >>>> Apologies: We realized they both used AS-composed URLs to get the user >>>> to the AS in a web browser for interaction purposes. >>>> >>>> >>>> >>>>> >>>>> - redirect: tells the AS that the client can send the user to an >>>>> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets th= at info to the >>>>> user; could be a redirect or an image or send a push notification to = a >>>>> secondary device, we don=E2=80=99t care as long as the user shows up = in a browser >>>>> at the AS =E2=80=94 so maybe this field can be renamed to be more uni= versally >>>>> accurate) >>>>> >>>> >>>> As stated in this thread, it may be useful for the AS to know if the >>>> URL will be in a QR code, or in a full redirect. >>>> >>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a Clien= t >>>> has to do, so it needs to know the difference between a popup, and a f= ull >>>> browser redirect. This is targetted at SPAs, where an additional URL t= o >>>> redirect to is extra work. >>>> >>>> >>>>> - code: tells the AS that the client can present a short code the >>>>> user can type (along with a static URL the user can get to, maybe by = typing >>>>> the URL manually, but it=E2=80=99s not dynamic/arbitrary like the red= irect method) >>>>> - callback: tells the AS that the client can receive the completion >>>>> message from a front channel interaction through a redirect. Note tha= t the >>>>> client might have gotten to the AS through a redirect on-device, thro= ugh a >>>>> QR-code off device, or through some other magic, and this field isn= =E2=80=99t >>>>> concerned with that =E2=80=94 it=E2=80=99s only concerned with how to= get the user :back:. >>>>> >>>> >>>> In a full redirect, the Client wants the AS to send the user back so >>>> that it can continue. >>>> >>>> The only parameter in the completion message is the nonce, which seems >>>> superfluous. See below. >>>> >>>> >>>>> >>>>> These three can be combined in different ways depending on what you >>>>> want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style >>>>> authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re >>>>> doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If= you=E2=80=99re doing just a QR code >>>>> with polling, you use just =E2=80=9Credirect=E2=80=9D to get the long= URL. If you=E2=80=99re doing >>>>> a user code and a QR code together, you use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccode=E2=80=9D to get >>>>> the long URL and the short code not he screen at the same time. >>>>> >>>>> On top of that, they can be combined with other methods. Maybe I can >>>>> send the user to an arbitrary URL but also display a human-readable >>>>> verification code (like CIBA), or send something in a push notificati= on but >>>>> also give them a message to type, or I=E2=80=99m getting claims from = an agent but I >>>>> want them redirected back through the browser. The client gets to dec= ide >>>>> what kinds of interaction it can do and how to use these pieces in wa= ys >>>>> that make the most sense. >>>>> >>>> >>>> Per my question later in this thread, why would the Client not know >>>> what interaction it wants prior to the request? >>>> >>>> >>>> What do you mean? The client does know what it wants and that=E2=80=99= s why >>>> it=E2=80=99s asking for what it wants. We=E2=80=99re debating differen= t methods for the >>>> client to ask for what it wants. This question does not make sense to = me. >>>> >>>> >>>> If the AS is doing CIBA, that is not a decision just for the Client. >>>> Both the AS and the Client need to know they are doing CIBA. (FWIW: I = think >>>> this work supersedes CIBA) >>>> >>>> >>>> As I=E2=80=99ve stated previously, I believe the interaction methods h= ere can >>>> supersede CIBA. >>>> >>>> >>>> Additionally, different interactions have different risk profiles. >>>> Sophisticated ASes will use that signal in the risk assessment, and ma= y do >>>> ask for additional authentication or verification. >>>> >>>> >>>> >>>> Yes, exactly my point. Because different interactions have different >>>> risks, the AS will need to be able to decide which interactions it=E2= =80=99s OK >>>> with for a given request. This could vary based on what=E2=80=99s bein= g requested, >>>> or who=E2=80=99s doing the requesting. >>>> >>>> >>>>> An interesting difference between XYZ and XAuth=E2=80=99s approaches = is that >>>>> XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in = the callback response >>>>> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80= =9D field). In XYZ, you >>>>> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a= pair of nonces >>>>> generated by the client and the AS in the back channel. This binds th= e >>>>> front channel response to both the back channel request and the back >>>>> channel response for a given transaction =E2=80=94 and note that I=E2= =80=99m really open to >>>>> having a better way to generate and calculate such a binding, but I t= hink >>>>> this works. In any event, this protects the client from session fixat= ion >>>>> and injection on the return from the front channel that it=E2=80=99s = susceptible to >>>>> in a pure polling model, and the hashing approach basically combines = the >>>>> security parameters of the OAuth 2 authorization code and (to an exte= nt) >>>>> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one= element. This is only >>>>> applicable if you=E2=80=99re coming back to the client and you can va= lidate the >>>>> hash and present the reference parameter. If you=E2=80=99re doing jus= t plain >>>>> polling, you don=E2=80=99t have that protection =E2=80=94 but the cli= ent and the AS are >>>>> aware of that risk, and there=E2=80=99s an option to prevent it. >>>>> >>>>> XAuth has removed the authorization code concept in its redirect >>>>> return, and clients only do polling against the GS API in order to ge= t >>>>> tokens. While I obviously think it=E2=80=99s very valuable to remove = things from >>>>> the front channel, I don=E2=80=99t think this is something we can rem= ove without >>>>> opening up attack surfaces that have already been identified in previ= ous >>>>> protocols. I would like to understand why XAuth is not susceptible to= the >>>>> same kinds of attacks, or if it is, what mitigations there are for th= em. >>>>> >>>> >>>> Unlike OAuth 2.0, there are no parameters in the front channel respons= e >>>> to the Client. The redirect back to the Client is only needed to retur= n the >>>> interaction back to the Client. >>>> >>>> >>>> This argument rings tautologically hollow =E2=80=94 there are no param= eters >>>> because you=E2=80=99ve defined that there aren=E2=80=99t any in XAuth.= XYZ does have >>>> parameters, to tie the front and back channel requests together when d= oing >>>> redirect back and forth. >>>> >>>> If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=80= =9Ccallback=E2=80=9D >>>> interaction block), then it=E2=80=99s a polling mechanism like XAuth, = the device >>>> flow, etc. There are very real risks to this. >>>> >>>> >>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>>> >>>> In OAuth, the AS gives a code to the User to give to the Client that >>>> the Client then gives to the GS. >>>> >>>> In XAuth, the AS gives a "code" to the Client that givers it to the >>>> User to give to the GS. >>>> >>>> In XAuth, the "code" is either a user code, or something embedded in >>>> the URI the User is redirected to. >>>> >>>> Therefore, there is nothing to protect in the redirect back to the >>>> Client. >>>> >>>> If I'm missing an attack, please elaborate how it would happen. >>>> >>>> >>>> One form of impersonation is well documented: >>>> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa= 759250a0e7 >>>> >>>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar reque= st initiation step to >>>> what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s susce= ptible to the >>>> same kind of issue. >>>> >>>> >>>> >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < >>>>> richanna=3D40amazon.com@dmarc.ietf.org> wrote: >>>>> >>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my comments= here to >>>>> interaction mode design, setting aside whether or not we need =E2=80= =9Cpopup=E2=80=9D. :D >>>>> >>>>> Once the GS hands that URI back to the Client, it has zero control >>>>> over how the Client uses it. The Client could present any URI (of a >>>>> reasonable size) into a QR code, or present it as a clickable link, o= r >>>>> redirect to it, or open it in an external browser, or do any number o= f >>>>> other as-yet-not-invented things with it. Moreover, the Client may no= t know >>>>> yet what it wants to do with it. So what value is there in distinguis= hing >>>>> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI = want a URI for a QR code=E2=80=9D vs. >>>>> =E2=80=9CI want a URI for =E2=80=9D? >>>>> >>>>> Even if we consider things like QR code data capacity, that=E2=80=99s= really >>>>> just a URI length limitation, which could apply to non-QR interaction >>>>> modes, e.g., if the Client device wants to communicate the URI over a= n >>>>> extremely bandwidth-constrained channel. And it=E2=80=99s not clear t= o me how >>>>> including a URI length limitation in the request helps. If a GS is ca= pable >>>>> of generating a shorter URI, why wouldn=E2=80=99t it always return th= at? On the >>>>> client side, it can look at the length of the URI provided and decide= what >>>>> to do with it (e.g., render a QR code or display it or do nothing wit= h it). >>>>> >>>>> So that really leaves us with two interaction modes that we need: >>>>> >>>>> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be = human friendly; >>>>> and >>>>> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code = entry page, both >>>>> of which are human-friendly. >>>>> >>>>> >>>>> Those could be combinable to get both, and even if we don=E2=80=99t g= o down >>>>> the multiple interaction mode route we could add the full URI to the = =E2=80=9Ccode=E2=80=9D >>>>> interaction object. It wouldn=E2=80=99t hurt anything to do so. >>>>> >>>>> =E2=80=93 >>>>> Annabelle Backman (she/her) >>>>> AWS Identity >>>>> https://aws.amazon.com/identity/ >>>>> >>>>> >>>>> *From: *Txauth on behalf of Dick Hardt < >>>>> dick.hardt@gmail.com> >>>>> *Date: *Tuesday, February 18, 2020 at 6:04 PM >>>>> *To: *"txauth@ietf.org" >>>>> *Subject: *[Txauth] Fwd: New Version Notification for >>>>> draft-hardt-xauth-protocol-03.txt >>>>> >>>>> Added in user code interaction and aligned QR code to be a superset o= f >>>>> user code. >>>>> Fixed descriptions. >>>>> >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: >>>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>>> Subject: New Version Notification for draft-hardt-xauth-protocol-03.t= xt >>>>> To: Dick Hardt >>>>> >>>>> >>>>> >>>>> >>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>>> has been successfully submitted by Dick Hardt and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-hardt-xauth-protocol >>>>> Revision: 03 >>>>> Title: The XAuth Protocol >>>>> Document date: 2020-02-18 >>>>> Group: Individual Submission >>>>> Pages: 53 >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.tx= t >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 >>>>> Htmlized: >>>>> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol >>>>> Diff: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 >>>>> >>>>> Abstract: >>>>> Client software often desires resources or identity claims that ar= e >>>>> independent of the client. This protocol allows a user and/or >>>>> resource owner to delegate resource authorization and/or release o= f >>>>> identity claims to a server. Client software can then request >>>>> access >>>>> to resources and/or identity claims by calling the server. The >>>>> server acquires consent and authorization from the user and/or >>>>> resource owner if required, and then returns to the client softwar= e >>>>> the authorization and identity claims that were approved. This >>>>> protocol can be extended to support alternative authorizations, >>>>> claims, interactions, and client authentication mechanisms. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> =E1=90=A7 >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> >>>> >> > --0000000000005d8621059f1fd658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The Client presents the interact_ref t= o the AS with the transaction handle. The AS will be able to tell the Clien= t if the interact_ref belongs to the transaction.

= Why is that enough?
3D""=E1=90=A7

On Fri, Feb 21, 202= 0 at 1:51 PM Justin Richer <jricher@m= it.edu> wrote:
The hash offers the same ki= nds of protections to the client that the OIDC nonce does =E2=80=94 it bind= s the front channel return to something you get from the back channel.=C2= =A0

In other words, the client can be sure that the retu= rn value that it=E2=80=99s getting is related to the request it made in the= first place, and not another one. Clients using per-request redirect URIs = can also help with this, but this is something that the server can provide = directly.

=C2=A0=E2=80=94 Justin

On Feb 21, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

While I can see the value of t= he interact_ref (aka interaction_ref) in the return URI that allows the Cli= ent to ensure the user that started the transaction is the same one that in= teracted at the AS, I don't understand why a hash is required. Would yo= u elaborate?
<= img alt=3D"" style=3D"width: 0px; max-height: 0px; overflow: hidden;" src= =3D"https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3De3bf8260-cb09-4907-892b-79cc0952f307">= =E1=90=A7

On Fri, Feb 21, 2020 at = 1:02 PM Justin Richer <jricher@mit.edu> wrote:
But that=E2=80=99s exactly the point =E2=80=94 it h= elps in that case, which is a very common case. For cases where the client = doesn=E2=80=99t expect the user to come back on the same channel, then they= don=E2=80=99t use the callback mechanism. They might use the =E2=80=9Cfini= sh message=E2=80=9D URL that Annabelle mentioned in the other thread, or th= ey might just print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at the A= S, which is common today.

XYZ=E2=80=99s interaction stru= cture allows the composition of these things, under the control of the clie= nt. This is exactly why it=E2=80=99s important to be able to specify how to= get to the AS and how to get back as separate items, so that the client ca= n compose the combination that makes the most sense for that client.
<= div>
=C2=A0=E2=80=94 Justin


On Feb 21, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com>= ; wrote:

I got ahead of myself. A completion= URI protects the User only if the User is sent back to the same channel th= e transaction started so the Client can confirm it is the same User that st= arted the transaction.

so this does not help the sec= urity:

"Being able to provide a completion UR= I even if the user is starting on a device is a great insight on how to add= ress the threat above."

3D""=E1=90=A7

On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com>= ; wrote:
The lightbulb finally clicked on for me. Thanks for your patience= .

The threat you are describing is where the attacker st= arts a transaction at the client, and gets the victim to complete it. Corre= ct?

I still think the Client should be able to signa= l if it will be doing a redirect vs showing a QR code (or wants to do both)= .

Being able to provide a completion URI even if t= he user is starting on a device is a great insight on how to address the th= reat above.=C2=A0

I'm going to ponder how to ali= gn XAuth more with these features of XYZ.
3D""=E1=90=A7

On Fri, Feb 21, 2020 at 11:31 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:
On = Feb 21, 2020, at 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


On Fri, F= eb 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in complete agreement wi= th Annabelle. In XYZ we rea= lized that both the QR Code and Authorization Code, and that the only diffe= rence is how the user gets back to the client. So instead of inventi= ng a new type of interaction, we split them. In XYZ, we have:

Th= is sentence looks to be missing something.

Apologies: We realized they both used AS-com= posed URLs to get the user to the AS in a web browser for interaction purpo= ses.

=C2=A0

=C2=A0- redirect: tells the AS that the clie= nt can send the user to an arbitrary URL (and the AS doesn=E2=80=99t care h= ow the client gets that info to the user; could be a redirect or an image o= r send a push notification to a secondary device, we don=E2=80=99t care as = long as the user shows up in a browser at the AS =E2=80=94 so maybe this fi= eld can be renamed to be more universally accurate)

As stated in this thread, it may be useful for the AS = to know if the URL will be in a QR code, or in a full redirect.
<= br>
In XAuth, the GS(AS min XYA) closes the popup to minimize wha= t a Client has to do, so it needs to know the difference between a popup, a= nd a full browser redirect. This is targetted at SPAs, where an additional = URL to redirect to is extra work.
=C2=A0
=C2=A0- code: tells the AS that = the client can present a short code the user can type (along with a static = URL the user can get to, maybe by typing the URL manually, but it=E2=80=99s= not dynamic/arbitrary like the redirect method)
=C2=A0- callback: = tells the AS that the client can receive the completion message from a fron= t channel interaction through a redirect. Note that the client might have g= otten to the AS through a redirect on-device, through a QR-code off device,= or through some other magic, and this field isn=E2=80=99t concerned with t= hat =E2=80=94 it=E2=80=99s only concerned with how to get the user :back:.<= /div>

In a full redirect, the C= lient wants the AS to send the user back so that it can continue.

The only parameter in the completion message is the nonce, = which seems superfluous. See below.
=C2=A0

These three = can be combined in different ways depending on what you want to do at the c= lient. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style authorizatio= n code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback= =E2=80=9D together. If you=E2=80=99re doing a plain user code, you=E2=80=99= d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re doing just a QR code with p= olling, you use just =E2=80=9Credirect=E2=80=9D to get the long URL. If you= =E2=80=99re doing a user code and a QR code together, you use =E2=80=9Credi= rect=E2=80=9D and =E2=80=9Ccode=E2=80=9D to get the long URL and the short = code not he screen at the same time.=C2=A0

On top = of that, they can be combined with other methods. Maybe I can send the user= to an arbitrary URL but also display a human-readable verification code (l= ike CIBA), or send something in a push notification but also give them a me= ssage to type, or I=E2=80=99m getting claims from an agent but I want them = redirected back through the browser. The client gets to decide what kinds o= f interaction it can do and how to use these pieces in ways that make the m= ost sense.

Per my questio= n later in this thread, why would the Client not know what interaction it w= ants prior to the request?

What do you mean? The client does know what it wants and that=E2=80= =99s why it=E2=80=99s asking for what it wants. We=E2=80=99re debating diff= erent methods for the client to ask for what it wants. This question does n= ot make sense to me.


If the AS is doing CIBA, = that is not a decision just for the Client. Both the AS and the Client need= to know they are doing CIBA. (FWIW: I think this work supersedes CIBA)

As I=E2=80=99ve stated= previously, I believe the interaction methods here can supersede CIBA.

Additionally, different interactions have differe= nt risk profiles. Sophisticated ASes will use that signal in the risk asses= sment, and may do ask for additional authentication or verification.
<= div>=C2=A0

Yes, exa= ctly my point. Because different interactions have different risks, the AS = will need to be able to decide which interactions it=E2=80=99s OK with for = a given request. This could vary based on what=E2=80=99s being requested, o= r who=E2=80=99s doing the requesting.


An interesting differen= ce between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps the concept= of the =E2=80=9Cauthorization code=E2=80=9D in the callback response (whic= h in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). = In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along = with a pair of nonces generated by the client and the AS in the back channe= l. This binds the front channel response to both the back channel request a= nd the back channel response for a given transaction =E2=80=94 and note tha= t I=E2=80=99m really open to having a better way to generate and calculate = such a binding, but I think this works. In any event, this protects the cli= ent from session fixation and injection on the return from the front channe= l that it=E2=80=99s susceptible to in a pure polling model, and the hashing= approach basically combines the security parameters of the OAuth 2 authori= zation code and (to an extent) state, PKCE=E2=80=99s code_challenge, and OI= DC=E2=80=99s nonce in one element. This is only applicable if you=E2=80=99r= e coming back to the client and you can validate the hash and present the r= eference parameter. If you=E2=80=99re doing just plain polling, you don=E2= =80=99t have that protection =E2=80=94 but the client and the AS are aware = of that risk, and there=E2=80=99s an option to prevent it.

XAuth has removed the authorization code concept in its redirect r= eturn, and clients only do polling against the GS API in order to get token= s. While I obviously think it=E2=80=99s very valuable to remove things from= the front channel, I don=E2=80=99t think this is something we can remove w= ithout opening up attack surfaces that have already been identified in prev= ious protocols. I would like to understand why XAuth is not susceptible to = the same kinds of attacks, or if it is, what mitigations there are for them= .=C2=A0

Unlike OAuth 2.0,= there are no parameters in the front channel response to the Client. The r= edirect back to the Client is only needed to return the interaction back to= the Client.

This a= rgument rings tautologically hollow =E2=80=94 there are no parameters becau= se you=E2=80=99ve defined that there aren=E2=80=99t any in XAuth. XYZ does = have parameters, to tie the front and back channel requests together when d= oing redirect back and forth.

If you=E2=80=99re no= t doing a redirect back (ie, not sending a =E2=80=9Ccallback=E2=80=9D inter= action block), then it=E2=80=99s a polling mechanism like XAuth, the device= flow, etc. There are very real risks to this.


XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0)
<= div>
In OAuth, the AS gives a code to the User to give to the= Client that the Client then gives to the GS.

In X= Auth, the AS gives a "code" to the Client that givers it to the U= ser to give to the GS.

In XAuth, the "code&qu= ot; is either a user code, or something embedded in the URI the User is red= irected to.

Therefore, there is nothing to protect= in the redirect back to the Client.

If I'm mi= ssing an attack, please elaborate how it would happen.


OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar re= quest initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, an= d it=E2=80=99s susceptible to the same kind of issue.

=C2=A0<= /div>

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

On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <richanna=3D40= amazon.com@dmarc.ietf.org> wrote:

Thanks for the update, Dick! I=E2=80=99m going to confine my com= ments here to interaction mode design, setting aside whether or not we need= =E2=80=9Cpopup=E2=80=9D. :D
=C2=A0<= /u>
Once the GS hands that URI back to the Client, it has ze= ro control over how the Client uses it. The Client could present any URI (o= f a reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of othe= r as-yet-not-invented things with it. Moreover, the Client may not know yet= what it wants to do with it. So what value is there in distinguishing betw= een =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI= for a QR code=E2=80=9D vs. =E2=80=9CI want a URI for <some other machin= e-driven interaction mode>=E2=80=9D?
=C2=A0
Even if we consider things like QR code data = capacity, that=E2=80=99s really just a URI length limitation, which could a= pply to non-QR interaction modes, e.g., if the Client device wants to commu= nicate the URI over an extremely bandwidth-constrained channel. And it=E2= =80=99s not clear to me how including a URI length limitation in the reques= t helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80= =99t it always return that? On the client side, it can look at the length o= f the URI provided and decide what to do with it (e.g., render a QR code or= display it or do nothing with it).
=C2= =A0
So that really leaves us with two interaction mod= es that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full = URI that may not be human friendly; and
  • =E2=80= =9Ccode=E2=80=9D, which returns a code and URI for a code entry page, both = of which are human-friendly.
=C2=A0=
Those could be combinable to get both, and even if w= e don=E2=80=99t go down the multiple interaction mode route we could add th= e full URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2= =80=99t hurt anything to do so.
=C2=A0<= u>
=E2=80=93<= u>
Annabelle Backm= an (she/her)
AWS Identity
=C2=A0
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
Date:=C2=A0Tuesday, February 18, 2020 at 6:= 04 PM
To:=C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:= =C2=A0[Txauth] Fwd: New Version Notification for draft-hardt-xau= th-protocol-03.txt
= =C2=A0
Added in user code intera= ction and aligned QR code to be a superset of user code.
Fixed descriptions.

=C2=A0

internet-drafts@ietf.org>
Date: Tue, Feb 18, 2020 at= 6:00 PM
Subject: New Version Notification for draft-hardt-xauth-protoco= l-03.txt
To: Dick Hardt <dick.hardt@gma= il.com>


<= br>
A new version of I-D, draft-hardt-xauth-protocol-03.txt
has been = successfully submitted by Dick Hardt and posted to the
IETF repository.<= br>
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-prot= ocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-02-18
= Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-hardt= -xauth-protocol-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatra= cker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0= =C2=A0 =C2=A0h= ttps://tools.ietf.org/html/draft-hardt-xauth-protocol-03
Htmlized:= =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hardt-xauth-= protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org= /rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03

Abstract:
=C2= =A0 =C2=A0Client software often desires resources or identity claims that a= re
=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a = user and/or
=C2=A0 =C2=A0resource owner to delegate resource authorizati= on and/or release of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Cli= ent software can then request access
=C2=A0 =C2=A0to resources and/or id= entity claims by calling the server.=C2=A0 The
=C2=A0 =C2=A0server acqui= res consent and authorization from the user and/or
=C2=A0 =C2=A0resource= owner if required, and then returns to the client software
=C2=A0 =C2= =A0the authorization and identity claims that were approved.=C2=A0 This
= =C2=A0 =C2=A0protocol can be extended to support alternative authorizations= ,
=C2=A0 =C2=A0claims, interactions, and client authentication mechanism= s.




Please note that it may take a couple of minutes from= the time of submission
until the htmlized version and diff are availabl= e at=C2=A0tools.ietf.org.

= The IETF Secretariat

=E1=90=A7
--=C2=A0
Tx= auth mailing list
Txaut= h@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=




--0000000000005d8621059f1fd658-- From nobody Fri Feb 21 17:36:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA91200F6 for ; Fri, 21 Feb 2020 17:36:46 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnbGTeqDjai4 for ; Fri, 21 Feb 2020 17:36:42 -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 734A512006B for ; Fri, 21 Feb 2020 17:36:41 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id n18so4120631ljo.7 for ; Fri, 21 Feb 2020 17:36:41 -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=wKv0eXAEzTp0gRX23tDB+dFYOAtY1/+fXSH4c5phjGQ=; b=X7c6SuJHUOh5qIJwSTlMi9STNQUQ4pKxO7J+fIkSdzH5UnG5JrmtZWGRrF003S3p0W VgLNWpZPeD/PBBy8B12FWoaGhC1Nx4NCDSVjtoiBoYOa11g/7AORjqiAnLTpzd4Wz5P8 n1/dHU1l4q0FNoMA9sR/o84T2FdKx62vNQwjImCawSrSlFM37tpau1CVzXrwCRnTWvZJ ObBHcEgwXDPRSollTTeKAFEhFEuleqYlYCYNcDuR5l0W0bKeQAMhjnGM4wVND/uFqGr/ DwwDA5qkV6DFo0mKBZetzqNbgo/D2bTuHuINQPQC8jLkdem6pr7k7JiLpIrXjjvjg8jz GU7w== 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=wKv0eXAEzTp0gRX23tDB+dFYOAtY1/+fXSH4c5phjGQ=; b=gnbk51JOIbTZLLnQ8yercCWglXmZ8x9SNWBZzuh+aA/CreNyZ0sHJQGRRDZDyOOicL 7Ul/vCqFQzGGatEKRga7M8EW/k86PqWspaRoGueFXJi6rqTC/74v2dmVRBJAZ5T65P5+ GRWucQBMjt1vq//tMJQqgMDFIoUUPdlU1eT4ufohnfbG8z40Yx50iXk4Kd3hgp89FJJJ 0GctUUPU47VsNvoyZAO7xHJzbx8gpLgJozzxgrwF2ARFAEr/AClOrES/+c1gU+9jX9xV YT/d72IcOOKkpFWGNlAtlXk69GLBJYfdJtL1itme+m46urz/OoC/M7920uQL2GPneQ9M YXJw== X-Gm-Message-State: APjAAAWg9nbwlEJcByTsh2XnepWWp1bFd55uNlaewHhFr5rzsbpmRLsi /J1IbKMPLMAbCTm3ZXM6ig5YJ0tvEhoIg+uphuE= X-Google-Smtp-Source: APXvYqytAcvNNL/PnixbiEXIUyY49QuWAam5cxU35g/Hg/5jZMn2EGerXfT5N6lVc7QazL81MmUPh9FhaaWxjMUNQgw= X-Received: by 2002:a2e:9d89:: with SMTP id c9mr24278430ljj.212.1582335399513; Fri, 21 Feb 2020 17:36:39 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <02197105-4C5F-41F1-8A84-8972F25C5132@amazon.com> In-Reply-To: <02197105-4C5F-41F1-8A84-8972F25C5132@amazon.com> From: Dick Hardt Date: Fri, 21 Feb 2020 17:36:12 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000675439059f202b99" Archived-At: Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 01:36:47 -0000 --000000000000675439059f202b99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Annabelle. FYI: With the requirement to have a interact_ref value come back from the GS to the Client, the popup and redirect are now the same -- so we can move past the popup discussion. To summarize your examples, 1) the Client may need to fallback to a different method than it initially had planned on 2) the Client may want to offer the User a broader choice of methods (1) could be solved by the Client making a new request of the GS (2) requires the Client to receive multiple methods so it can offer the User a choice. Am I following along correctly A short URI and a long URI are functionally equivalent -- so there does not seem to be a requirement to have both. For example, the Client may request a URI, with an optional max length? So that let's the Client ask for one or both of: - a URI with an optional max length ( indicate it has a static max length) - a short code and code entry URI If and when new mechanism for the Client to transfer interactions to the GS, new parameters are defined. Q: what is MTI? Q: Is there a minimum length of the short URI? ( think that specifying a short URI max length will make it easier for Clients and GS as it is not negotiated) /Dick =E1=90=A7 On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > Okay, you=E2=80=99ve convinced me that there are use cases for a GS to so= metimes > provide a shorter URI and sometimes a longer URI. Let=E2=80=99s see if I = can > convince you that interaction mode selection is less deterministic than y= ou > think. :D > > > > I **think** the Client can be expected to know if it will transfer > interaction to the GS within the same user agent the end user is accessin= g > Client through. In other words, I think there are two reliably > differentiable modes: same UA (30X redirect, open in same window, open in > new), and different UA (code, QR code, opening URI in external browser, > etc.). However, within each mode, the Client may not know which mechanism > will be used. (e.g., for =E2=80=9Csame UA=E2=80=9D: will the Client open = the URI in the > same window or a new one; for =E2=80=9Cdifferent UA=E2=80=9D: will the en= d user scan a QR > code or enter a code or tap on a URI in an SMS) > > > > The non-determinism comes from two sources: > > 1. Environmental conditions > 1. A console app might be able to directly open a URI in the > system=E2=80=99s browser (e.g., when running in a terminal window o= n a desktop), or > it might not (e.g., on a headless system). The app may not know the= answer > until it tries it. > 2. That same console app might be running in a remote terminal, > such that the end user would be able to click or copy and paste a U= RI > printed by the app. > 3. An SPA might be able to open a popup, or it might fail for > various reasons. It might decide to fall back to a redirect if it d= etects > that the popup failed to open. It might want the =E2=80=9Cpopup=E2= =80=9D to gracefully fall > back to a redirect-like experience in case the user agent only supp= orts a > single window at a time (e.g., embedded user agents in apps like Fa= cebook > and Twitter). > 4. Environmental conditions may make it difficult to scan a QR code > (e.g., the screen is dirty, foggy, cracked, or under direct sunligh= t), but > still allow for a person to read a short code. The Client likely ha= s no way > of detecting such things. > 2. End user capabilities and preferences > 1. They may have a physical disability or other condition that > makes it difficult to impossible for them to scan a QR code. > > i. Th= ey > may be capable of reading and copying a short code. > > ii. The= y > may be capable of listening to and entering a short code spoken by the > device. > > iii. They > may be capable of following a link sent to them via text or email, which > they can access on a device with greater accessibility options. > > 1. They may not have a device capable of scanning a QR code, or the > device may not be functioning, or the device may be the one that th= e code > is being displayed on. > 2. They may not know what a QR code is, or understand how to use > one. > 3. They may want to complete the flow on a device that is incapable > of scanning the QR code (e.g., their desktop). > 4. They may prefer to have the URI texted or emailed to them, > rather than having to scan or copy a code. > 5. They may not have access to the companion app that the Client > transmitted the URI to (e.g., because it=E2=80=99s on the shared fa= mily tablet, and > it=E2=80=99s their sibling=E2=80=99s turn to use it). > > > > If we allow that the GS might want to issue long URIs when possible, then > there=E2=80=99s basically three things a Client might want, in any combin= ation: > > - URI, no length restriction > - URI, with some max length (e.g., because of QR code data capacity, > SMS message size limits, display constraints, etc.) > - Short code and code entry URI, both human-friendly > > > > The GS can=E2=80=99t enforce how these are used; they can only control wh= at they > issue, and how they respond when interaction is transferred to them. > Defining interaction object properties in terms of usage implies > constraints and guarantees that don=E2=80=99t exist, and Clients are goin= g to > disregard our prescribed uses anyway (e.g., by sending a =E2=80=9Cqrcode= =E2=80=9D URI in an > SMS). > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Dick Hardt > *Date: *Thursday, February 20, 2020 at 3:13 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > > > > > > > On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Thanks for the update, Dick! I=E2=80=99m going to confine my comments her= e to > interaction mode design, setting aside whether or not we need =E2=80=9Cpo= pup=E2=80=9D. :D > > > > Once the GS hands that URI back to the Client, it has zero control over > how the Client uses it. The Client could present any URI (of a reasonable > size) into a QR code, or present it as a clickable link, or redirect to i= t, > or open it in an external browser, or do any number of other > as-yet-not-invented things with it. Moreover, the Client may not know yet > what it wants to do with it. > > > > Why would the Client not know what it wants to do with it? What would > change between when the Client called the GS, and the GS responded? > > > > I think of the interaction being the Client saying "I want to do a > redirect", and the GS says, "ok, here is the URI". Or the Client says, "I > want to show only a code and a URI", and the GS says "ok, here is a good, > and an easy to read URI for the user to type in and navigate to. > > > > I understand there are interactions that may not yet been invented yet. > More on that further down. > > > > So what value is there in distinguishing between =E2=80=9CI want a URI fo= r a > redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. = =E2=80=9CI want a URI for other machine-driven interaction mode>=E2=80=9D? > > > > Even if we consider things like QR code data capacity, that=E2=80=99s rea= lly just > a URI length limitation, which could apply to non-QR interaction modes, > e.g., if the Client device wants to communicate the URI over an extremely > bandwidth-constrained channel. > > > > I don't understand when this would be the case. If the Client is going to > do a redirect, then the URI length is not significant. > > > > And it=E2=80=99s not clear to me how including a URI length limitation in= the > request helps. If a GS is capable of generating a shorter URI, why wouldn= =E2=80=99t > it always return that? > > > > There may be a variety of reasons that a GS may want to provide a > different URI for a QR code than a redirect, or even a popup. > > > > 1) Perhaps the GS has only been supporting redirects, and has a very long > URL. They add support for a QR code, and use a 3P service that redirects > from the short URL used in the QR code, the the long URL. They don't want > to pay for the 3P service anymore than they have to. > > > > 2) The GS wants the QR code and user code flows to go through the same > machinery that looks up the code to find the Grant. The URI in a redirect > has the grant embedded in the URI. They don't want to have to use the cod= e > to Grant machinery for all URIs. > > > > 3) A QR code flow will usually be done on a phone, and the GS wants to > attempt to launch a native app in some way, > > > > While you are correct, we could make all URIs be short enough that they > can be easily scanned, why force that on implementors? > > > > The URI length limitation concept was for the display_uri so that a > constrained device has an upper limit. A similar upper limit on QR code > would allow a constrained device to know the pixel resolution it needs to > show the QR code. > > > > On the client side, it can look at the length of the URI provided and > decide what to do with it (e.g., render a QR code or display it or do > nothing with it). > > > > Per above, why would the Client not already know what experience it wants > to present to the User? > > > > A URI to be displayed, and a URI to be redirected to are likely going to > be quite different. > > > > The URI for a User to enter a code will likely be a static value that is > easy to type. The User will likely have to authenticate at that page, and > then be prompted to enter the code. > > > > > > So that really leaves us with two interaction modes that we need: > > =C2=B7 =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and > > =C2=B7 =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a co= de entry page, both > of which are human-friendly. > > > > Those could be combinable to get both, and even if we don=E2=80=99t go do= wn the > multiple interaction mode route we could add the full URI to the =E2=80= =9Ccode=E2=80=9D > interaction object. It wouldn=E2=80=99t hurt anything to do so. > > > > In the latest version, I gave each URI its own name so that the GS can be > clear about how it will be used. > > > > While we could squeeze all the functionality into a couple parameters, I > think it makes it harder for existing deployments to migrate to the > protocol. I think we should make it easy for developers to take what they > already have and use it with XAuth. > > > > wrt. not-yet-invented interactions. These interactions are for > not-yet-described use cases. (if other use cases exist, then let's look a= t > them and add the interaction mechanisms if needed) We don't know what > parameters will be needed, and overloading the parameters and letting the > Client do whatever it wants does not seem like it will interoperate -- th= e > Client decides it wants to do some new interaction, and uses the paramete= rs > in a way the GS does not understand. > > > > > > > > > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Tuesday, February 18, 2020 at 6:04 PM > *To: *"txauth@ietf.org" > *Subject: *[Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > > > Added in user code interaction and aligned QR code to be a superset of > user code. > > Fixed descriptions. > > > > ---------- Forwarded message --------- > From: > Date: Tue, Feb 18, 2020 at 6:00 PM > Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt > To: Dick Hardt > > > > > A new version of I-D, draft-hardt-xauth-protocol-03.txt > has been successfully submitted by Dick Hardt and posted to the > IETF repository. > > Name: draft-hardt-xauth-protocol > Revision: 03 > Title: The XAuth Protocol > Document date: 2020-02-18 > Group: Individual Submission > Pages: 53 > URL: > https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt > Status: > https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ > Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 > > Abstract: > Client software often desires resources or identity claims that are > independent of the client. This protocol allows a user and/or > resource owner to delegate resource authorization and/or release of > identity claims to a server. Client software can then request access > to resources and/or identity claims by calling the server. The > server acquires consent and authorization from the user and/or > resource owner if required, and then returns to the client software > the authorization and identity claims that were approved. This > protocol can be extended to support alternative authorizations, > claims, interactions, and client authentication mechanisms. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > =E1=90=A7 > > --000000000000675439059f202b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Annabelle.

FYI: With the require= ment to have a interact_ref value come back from the GS to the Client, the = popup and redirect are now the same -- so we can move past the popup discus= sion.

To summarize your examples,
1= ) the Client may need to fallback to a different method than it initially h= ad planned on=C2=A0
2) the Client may want to offer the Use= r a broader choice of methods

(1) could be solved = by the Client making a new request of the GS

(2) r= equires the Client to receive=C2=A0multiple methods so it can offer the Use= r a choice.

Am I following=C2=A0along correctly

A short URI and a long URI are functionally equivale= nt -- so there does not seem to be a requirement to have both.=C2=A0
<= div>For example, the Client may request a URI, with an optional max length?=

So that let's the Client ask for one or both = of:

- a URI with an optional max length ( indicate= it has a static max length)
- a short code and code entry URI

If and when new mechanism for the Client to transfer= interactions to the GS, new parameters are defined.=C2=A0

Q: what is MTI?

Q: Is there a minimum len= gth of the short URI? ( think that specifying a short URI max length will m= ake it easier for Clients and GS as it is not negotiated)


/Dick

3D""=E1=90=A7

On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

Okay, you=E2=80=99ve convinced me that there are use= cases for a GS to sometimes provide a shorter URI and sometimes a longer U= RI. Let=E2=80=99s see if I can convince you that interaction mode selection= is less deterministic than you think. :D

=C2=A0

I *think* the Client can be expected to know = if it will transfer interaction to the GS within the same user agent the en= d user is accessing Client through. In other words, I think there are two r= eliably differentiable modes: same UA (30X redirect, open in same window, open in new), and different UA (cod= e, QR code, opening URI in external browser, etc.). However, within each mo= de, the Client may not know which mechanism will be used. (e.g., for =E2=80= =9Csame UA=E2=80=9D: will the Client open the URI in the same window or a new one; for =E2=80=9Cdifferent UA=E2=80=9D: will = the end user scan a QR code or enter a code or tap on a URI in an SMS)

=C2=A0

The non-determinism comes from two sources:

  1. Environmental conditions
    1. A console app might be able to directly open a URI in the system= =E2=80=99s browser (e.g., when running in a terminal window on a desktop), = or it might not (e.g., on a headless system). The app may not know the answer until it tries it.
    2. = That same console app might be running in a remote terminal, such that the = end user would be able to click or copy and paste a URI printed by the app.=
    3. An SPA might be able to open a popup, or it mig= ht fail for various reasons. It might decide to fall back to a redirect if = it detects that the popup failed to open. It might want the =E2=80=9Cpopup=E2=80=9D to gracefully fall back to a redirect-like experie= nce in case the user agent only supports a single window at a time (e.g., e= mbedded user agents in apps like Facebook and Twitter).
      4. <= li class=3D"gmail-m_7186334850828860648MsoListParagraph" style=3D"margin-le= ft:0in">Environmental conditions may make it difficult to scan a QR code (e= .g., the screen is dirty, foggy, cracked, or under direct sunlight), but st= ill allow for a person to read a short code. The Client likely has no way of detecting such things.=
  2. End user capabilities and preferences
    1. They may have a physical disability or other condition that makes = it difficult to impossible for them to scan a QR code.

    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 They may be capable of reading and = copying a short code.

    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 They may be capable of listening to= and entering a short code spoken by the device.

    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iii.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 They may be capable of following= a link sent to them via text or email, which they can access on a device w= ith greater accessibility options.

      1. They may not have a device capable of scanning a QR code, or the d= evice may not be functioning, or the device may be the one that the code is= being displayed on.
      2. They may not know what a QR= code is, or understand how to use one.
      3. They may= want to complete the flow on a device that is incapable of scanning the QR= code (e.g., their desktop).
      4. They may prefer to = have the URI texted or emailed to them, rather than having to scan or copy = a code.
      5. They may not have access to the companio= n app that the Client transmitted the URI to (e.g., because it=E2=80=99s on= the shared family tablet, and it=E2=80=99s their sibling=E2=80=99s turn to= use it).

    =C2=A0

    If we allow that the GS might want to issue long URI= s when possible, then there=E2=80=99s basically three things a Client might= want, in any combination:

    • URI, no length restriction
    • URI, with so= me max length (e.g., because of QR code data capacity, SMS message size lim= its, display constraints, etc.)
    • Short code and c= ode entry URI, both human-friendly

    =C2=A0

    The GS can=E2=80=99t enforce how these are used; the= y can only control what they issue, and how they respond when interaction i= s transferred to them. Defining interaction object properties in terms of u= sage implies constraints and guarantees that don=E2=80=99t exist, and Clients are going to disregard our prescribed use= s anyway (e.g., by sending a =E2=80=9Cqrcode=E2=80=9D URI in an SMS).

    =C2=A0

    =E2=80=93

    Annabelle Backman (sh= e/her)

    AWS Identity

    https://aws.amazon.com/identity/

    =C2=A0

    =C2=A0

    From: Dick Hardt <dick.hardt@gmail.com>
    Date: Thursday, February 20, 2020 at 3:13 PM
    To: "Richard Backman, Annabelle" <    richanna@amazon.com>
    Cc: "txaut= h@ietf.org" <txauth@ietf.org>
    Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-= xauth-protocol-03.txt

    =C2=A0

    =C2=A0

    =C2=A0

    On Thu, Feb 20, 2020 at = 12:21 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

    Thanks for the update, Dick! I=E2=80=99m going to confine my comments here = to interaction mode design, setting aside whether or not we need =E2=80=9Cp= opup=E2=80=9D. :D

    =C2=A0

    Once the GS hands that URI back to the Client, it has zero control over how= the Client uses it. The Client could present any URI (of a reasonable size= ) into a QR code, or present it as a clickable link, or redirect to it, or = open it in an external browser, or do any number of other as-yet-not-invented things with it. Moreover, th= e Client may not know yet what it wants to do with it.

    =C2=A0

    Why would the Client not= know what it wants to do with it? What would change between when the Clien= t called the GS, and the GS responded?

    =C2=A0

    I think of the interacti= on being the Client saying "I want to do a redirect", and the GS = says, "ok, here is the URI". Or the Client says, "I want to = show only a code and a URI", and the GS says "ok, here is a good, and an easy to read URI for the user to type in and navigate to.=

    =C2=A0

    I understand there are i= nteractions that may not yet been invented yet. More on that further down.<= u>

    =C2=A0

    So what value is there in distinguishing between =E2=80=9CI want a URI for = a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. = =E2=80=9CI want a URI for <some other machine-driven interaction mode>= ;=E2=80=9D?

    =C2=A0

    Even if we consider things like QR code data capacity, that=E2=80=99s reall= y just a URI length limitation, which could apply to non-QR interaction mod= es, e.g., if the Client device wants to communicate the URI over an extreme= ly bandwidth-constrained channel.

    =C2=A0

    I don't understand w= hen this would be the case. If the Client is going to do a redirect, then t= he URI length is not significant.

    =C2=A0

    And it=E2=80=99s not clear to me how including a URI length limitation in t= he request helps. If a GS is capable of generating a shorter URI, why would= n=E2=80=99t it always return that?

    =C2=A0

    There may be a variety o= f reasons that a GS may want to provide a different URI for a QR code than = a redirect, or even a popup.

    =C2=A0

    1) Perhaps the GS has on= ly been supporting redirects, and has a very long URL. They add support for= a QR code, and use a 3P service that redirects from the short URL used in = the QR code, the the long URL. They don't want to pay for the 3P service anymore than they have to.

    =C2=A0

    2) The GS wants the QR c= ode and user code flows to go through the same machinery that looks up the = code to find the Grant. The URI in a redirect has the grant embedded in the= URI. They don't want to have to use the code to Grant machinery for all URIs.

    =C2=A0

    3) A QR code flow will u= sually be done on a phone, and the GS wants to attempt to launch a native a= pp in some way,

    =C2=A0

    While you are correct, w= e could make all URIs be short enough that they can be easily scanned, why = force that on implementors?=C2=A0

    =C2=A0

    The URI length limitatio= n concept was for the display_uri so that a constrained device has an upper= limit. A similar upper limit on QR code would allow a constrained device t= o know the pixel resolution it needs to show the QR code.

    =C2=A0

    On the client side, it can look at the length of the URI provided and decid= e what to do with it (e.g., render a QR code or display it or do nothing wi= th it).

    =C2=A0

    Per above, why would the= Client not already know what experience it wants to present to the User?

    =C2=A0

    A URI to be displayed, a= nd a URI to be redirected to are likely going to be quite different.=C2=A0<= u>

    =C2=A0

    The URI for a User to en= ter a code will likely be a static value that is easy to type. The User wil= l likely have to authenticate at that page, and then be prompted to enter t= he code.=C2=A0

    =C2=A0

    =C2=A0

    So that really leaves us with two interaction modes that we need:=

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =E2=80=9Curi=E2=80=9D, which returns a full URI= that may not be human friendly; and

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =E2=80=9Ccode=E2=80=9D, which returns a code an= d URI for a code entry page, both of which are human-friendly.

    =C2=A0

    Those could be combinable to get both, and even if we don=E2=80=99t go down= the multiple interaction mode route we could add the full URI to the =E2= =80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt anything t= o do so.

    =C2=A0

    In the latest version, I= gave each URI its own name so that the GS can be clear about how it will b= e used.

    =C2=A0

    While we could squeeze a= ll the functionality into a couple parameters, I think it makes it harder f= or existing deployments to migrate to the protocol. I think we should make = it easy for developers to take what they already have and use it with XAuth.

    =C2=A0

    wrt. not-yet-invented in= teractions. These interactions are for not-yet-described use cases. (if oth= er use cases exist, then let's look at them and add the interaction mec= hanisms if needed) We don't know what parameters will be needed, and overloading the parameters and letting the Client do w= hatever it wants does not seem like it will interoperate -- the Client deci= des it wants to do some new interaction, and uses the parameters in a way t= he GS does not understand.

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =E2=80=93

    Annabelle Backman (she/her)=

    AWS Identity

    https://aws.amazon.c= om/identity/

    =C2=A0

    =C2=A0

    From: Txauth <txauth-bounces@ietf.org> on behalf of D= ick Hardt <dic= k.hardt@gmail.com>
    Date: Tuesday, February 18, 2020 at 6:04 PM
    To: "txaut= h@ietf.org" <txauth@ietf.org>
    Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xaut= h-protocol-03.txt

    =C2=A0

    Added in user code interaction and aligned QR code to be a superset of user= code.

    Fixed descriptions.

    =C2=A0

    ---------- Forwarded message ---------
    From: <int= ernet-drafts@ietf.org>
    Date: Tue, Feb 18, 2020 at 6:00 PM
    Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
    To: Dick Hardt <dick.hardt@gmail.com>




    A new version of I-D, draft-hardt-xauth-protocol-03.txt
    has been successfully submitted by Dick Hardt and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
    Document date:=C2=A0 2020-02-18
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt<= br> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracke= r.ietf.org/doc/draft-hardt-xauth-protocol/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/htm= l/draft-hardt-xauth-protocol-03
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/html/draft-hardt-xauth-protocol
    Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://= www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03

    Abstract:
    =C2=A0 =C2=A0Client software often desires resources or identity claims tha= t are
    =C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a= nd/or
    =C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea= se of
    =C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re= quest access
    =C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2= =A0 The
    =C2=A0 =C2=A0server acquires consent and authorization from the user and/or=
    =C2=A0 =C2=A0resource owner if required, and then returns to the client sof= tware
    =C2=A0 =C2=A0the authorization and identity claims that were approved.=C2= =A0 This
    =C2=A0 =C2=A0protocol can be extended to support alternative authorizations= ,
    =C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.



    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

    =E1=90=A7

--000000000000675439059f202b99-- From nobody Fri Feb 21 23:04:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAEB120130 for ; Fri, 21 Feb 2020 23:04:21 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqqjIjd99eTx for ; Fri, 21 Feb 2020 23:04:19 -0800 (PST) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBD3120123 for ; Fri, 21 Feb 2020 23:04:19 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 661E0385BBB; Sat, 22 Feb 2020 07:04:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1582355057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6YemFNEJ9Q/g/tsNtbt8jnudBLszkwd8/UNG9fvbSvc=; b=O8ny4PYcXiNk1Fx5rPaRxrObd5J72+8TtwVPK35F2fUBIFeLjKlzxkctLxKTJJGCjzsA4u O1m0tDMQGBqOATE6t9irK+O6/vh57Rp4avgzDfrY7Yrc+bqk9+VFeaRws6cpwwIQjd2qut /zv9v3BPRCuaJ73e/AuATRsnYr/Ki5g= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 From: David Waite In-Reply-To: <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> Date: Sat, 22 Feb 2020 00:04:15 -0700 Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> To: Justin Richer ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1582355058; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6YemFNEJ9Q/g/tsNtbt8jnudBLszkwd8/UNG9fvbSvc=; b=NQMIIVzrVwKKSfFHL04IGJ0sjIsJT9diFvThTl2hYSifUx3c0tqkjD8h/C6EC4LDCQpIQR JfvYqtWjn4YNmujV+z0Gm+5e0obaH4zfAchX+I/P/eprx/KPTEEPkwLd09RQNSfBbQRD5f KOY/zhUbzW19NMCoKhwmMOhuJjEMODI= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1582355058; a=rsa-sha256; cv=none; b=e+aBWAc3pwJNhgomh6JhTvs9XFB/L7MOSuJp74SdEMsKGnXyiji14oD5h2+9Mpj7MQLl7H RqczGoEeBzX1450CKDal9PEiWgnjmrdJxtbub2P/JbAzygVAJqPWyt/tAMrTes9ysc4c2B 1VKqpAueO8IQuYqfZQGMXdEKm+k9Vxk= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 07:04:22 -0000 > On Feb 21, 2020, at 9:38 AM, Justin Richer wrote: >=20 > - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) This is going to need a different name :-) > - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) > - callback: tells the AS that the client can receive the completion = message from a front channel interaction through a redirect. Note that = the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this = field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:. >=20 > These three can be combined in different ways depending on what you = want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= Some implementations may have the redirect and device code + static URL = be the same URLs, but some may actually be de-optimizing for the device = cases where the user may need to type the values in by hand or to reduce = QR code complexity for scanning from across a room on a television. = Having redirect and QR code interaction URLs be the same seems limiting = in this regard. The semantics of trying to leverage the QR code and browser = redirect/callback also make me nervous w.r.t implementations, as in one = case the callback may go back to a local context (e.g. single-page web = application or native app) while the short code/QR code entry case would = have the authentication/consent and subsequent callback happen = =E2=80=9Cunsolicited=E2=80=9D on another device. Thats not to say that these initiation and resumption aspects couldn=E2=80= =99t be split, I=E2=80=99m just concerned about these particular lines = being ambitious. > On top of that, they can be combined with other methods. Maybe I can = send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. There needs to be fixed semantics for combining interaction facets, = however. Would your client send a prioritized list where the AS chooses = one that they support, or would the expectation be that you would then = need to present the user the option to continue with either a redirect = or via a QR code on another device? -DW From nobody Mon Feb 24 13:18:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8A3A135C for ; Mon, 24 Feb 2020 13:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 xe02T46R0Uq6 for ; Mon, 24 Feb 2020 13:18:36 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (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 5710F3A135D for ; Mon, 24 Feb 2020 13:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582579116; x=1614115116; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JCHtUTsN8BcV5nfXdEGufLBzjooBdZVSx1vYBq6/xTU=; b=dV9NAEl5FyHgb82ajI3ERo1Kv9GZ/exwV6Xbb4JB4xKPHr72uqfGw1bh KVW5HQuXHXnDYopsjX0b5lC1Dgecnzo8FZSJUatk0UPerJ0BBEAJIAlaQ q9gRQWYJmr2Rny5jM9zcItFfdE6IpxXqNct0HNjvo0oct1+MkR55dWqjg A=; IronPort-SDR: LqYj8D2UpPjMNmHSLu3liLmMzA3BhGizbE9E/LG6Se5NRe1PEhQW34CESqAIHBVLgHUAc/wZSD aZYbg+JEglWw== X-IronPort-AV: E=Sophos; i="5.70,481,1574121600"; d="scan'208,217"; a="18834030" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 24 Feb 2020 21:18:33 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (Postfix) with ESMTPS id 1C8E2A1C1D; Mon, 24 Feb 2020 21:18:33 +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; Mon, 24 Feb 2020 21:18:32 +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.1497.2; Mon, 24 Feb 2020 21:18:32 +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.1497.006; Mon, 24 Feb 2020 21:18:32 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt CC: "txauth@ietf.org" Thread-Topic: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt Thread-Index: AQHV5sjpEbhLLf0ddUeR1uDqNGJ4aagkAu0AgAC1x4CAASaNgIAAlBoAgAPo5IA= Date: Mon, 24 Feb 2020 21:18:32 +0000 Message-ID: <72D44F53-6AB7-43C8-A337-623B31FB584B@amazon.com> References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <02197105-4C5F-41F1-8A84-8972F25C5132@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.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.53] Content-Type: multipart/alternative; boundary="_000_72D44F536AB743C8A337623B31FB584Bamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 21:18:39 -0000 --_000_72D44F536AB743C8A337623B31FB584Bamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB5b3VyIHN1bW1hcnkgaXMgYWNjdXJhdGUsIGJ1dCB0aGUgbGluZSBiZXR3ZWVuIHlv dXIgdHdvIHJlYXNvbnMgZ2V0cyBwcmV0dHkgYmx1cnJ5LiBUaGUgQ2xpZW50IG1heSBub3QgYmUg YWJsZSB0byBkZXRlY3Qgb24gaXRzIG93biB3aGV0aGVyIGl0cyBwcmVmZXJyZWQgbWV0aG9kIGlz IHdvcmtpbmcsIHNvIHlvdXIgcHJvcG9zYWwgdGhhdCB0aGUgQ2xpZW50IGNvdWxkIHN3aXRjaCBt ZXRob2RzIGJ5IG1ha2luZyBhIG5ldyByZXF1ZXN0IHdvdWxkIHJlcXVpcmUgdGhlIGVuZCB1c2Vy IHRvIHByb3ZpZGUgc29tZSBpbnB1dC4gRm9yIGV4YW1wbGU6DQoNCiAgKiAgIElmIGEgd2ViIGJy b3dzZXIgaXMgYXZhaWxhYmxlIGJ1dCB0aGUgZmlyZXdhbGwgYmxvY2tzIG91dGJvdW5kIEhUVFAg KG5vdCB1bnJlYXNvbmFibGUgZm9yIGEgc2VydmVyIGhvc3QpLCB0aGUgQ2xpZW50IHdvdWxkIHRo aW5rIHRoYXQgaXQgc3VjY2Vzc2Z1bGx5IG9wZW5lZCB0aGUgVVJJLg0KICAqICAgSWYgdGhlIGxv Y2FsIGJyb3dzZXIgbGFja3MgdGhlIGFjY2Vzc2liaWxpdHkgZmVhdHVyZXMgbmVlZGVkIGJ5IHRo ZSBlbmQgdXNlciwgdGhlIENsaWVudCB3b3VsZCBzdWNjZXNzZnVsbHkgb3BlbiB0aGUgVVJJLCBi dXQgaXQgd291bGQgbm90IGJlIHVzYWJsZSBieSB0aGUgZW5kIHVzZXIuDQogICogICBJbiB0aGUg 4oCcc2hhcmVkIGZhbWlseSB0YWJsZXTigJ0gZXhhbXBsZSBpbiBteSBwcmV2aW91cyBlbWFpbCwg dGhlIENsaWVudCB3b3VsZCBub3QgYmUgYXdhcmUgdGhhdCB0aGUgZW5kIHVzZXIgaXMgdW5hYmxl IHRvIGludGVyYWN0IHdpdGggdGhlIGNvbXBhbmlvbiBhcHAuDQoNClNvIGl04oCZcyBlYXNpZXIg Zm9yIGJvdGggQ2xpZW50IGFuZCBlbmQgdXNlciwgYW5kIG1vcmUgZ2VuZXJhbGx5IGFwcGxpY2Fi bGUgaWYgdGhlIENsaWVudCBjYW4gcmVxdWVzdCBtdWx0aXBsZSBpbnRlcmFjdGlvbiBtb2RlcyBh bmQgcHJlc2VudCB0aGVtIGF0IHRoZSBzYW1lIHRpbWUuDQoNCklmIHdlIG9ubHkgaGF2ZSBhIHNp bmdsZSDigJx1cmnigJ0gcGFyYW1ldGVyLCB0aGUgbWF4IGxlbmd0aCBpbiB0aGUgcmVxdWVzdCBz aG91bGQgYmUgYWR2aXNvcnkuIEkuZS4sIHRoZSBHUyBTSEFMTCByZXR1cm4gYSBVUkksIGFuZCBp dCBTSE9VTEQgcmV0dXJuIG9uZSB0aGF0IG1lZXRzIHRoZSBtYXggbGVuZ3RoIHJlc3RyaWN0aW9u IGlmIGl0IGNhbi4gQ2xpZW50IGJlaGF2aW9yIGlzIGVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzIGlm IGl0IHdlcmUgdHJlYXRlZCBhcyBhIGhhcmQgcmVxdWlyZW1lbnQ7IHRoZSBvbmx5IGRpZmZlcmVu Y2UgaXMgdGhhdCB0aGUgQ2xpZW50IGNvZGUgYnJhbmNoZXMgYmFzZWQgb24gdGhlIGFjdHVhbCBs ZW5ndGggb2YgdGhlIFVSSSByZXR1cm5lZCAod2hpY2ggaXQgYWxyZWFkeSBuZWVkcyB0byBjaGVj aykgcmF0aGVyIHRoYW4gYmFzZWQgb24gdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgYSBVUkks IG9yIGFuIGVycm9yIHJlc3BvbnNlIGZyb20gdGhlIEdTLiBDbGllbnRzIHRoYXQgY2FuIHN0aWxs IG1ha2UgdXNlIG9mIGEgbG9uZ2VyIFVSSSBhcmUgc2F2ZWQgdGhlIGV4dHJhIHJvdW5kIHRyaXAg dG8gcmVxdWVzdCBvbmUuDQoNCkkgdGhpbmsgYm90aCDigJx1cmnigJ0gYW5kIOKAnGNvZGXigJ0g c2hvdWxkIGJlIE1USSwgYnV0IHRoYXQgZG9lcyBub3QgbWVhbiB0aGV5IGFyZSBtYW5kYXRvcnkg dG8gZGVwbG95LiBUaGVyZeKAmXMgbG90cyBvZiBjYXNlcyB3aGVyZSBhIEdTIHdpbGwgb25seSBl dmVyIGRlYWwgd2l0aCBzcGVjaWZpYyB0eXBlcyBvZiBDbGllbnRzIHN1Y2ggdGhhdCB0aGV54oCZ bGwgYWx3YXlzIHVzZSBvbmUgb3IgdGhlIG90aGVyLCBidXQgaW4gdGhvc2UgY2FzZXMgdGhlIEdT IGlzIGV4cGxpY2l0bHkgbm90IGNvbmNlcm5lZCBvdmVybXVjaCB3aXRoIGludGVyb3BlcmFiaWxp dHkuDQoNCldlIG5lZWQgdG8gYmUgY2FyZWZ1bCBhYm91dCBkZWZpbmluZyBhIG1heGltdW0gbGVu Z3RoIGZvciB0aGUgY29kZSBlbnRyeSBVUkkuIERvbWFpbiBuYW1lcyBjb3N0IG1vbmV5IHRvIHJl Z2lzdGVyIGFuZCBtYWludGFpbiwgc28gYSBtYXhpbXVtIGxlbmd0aCB0aGF0IGlzIHRvbyBsb3cg d291bGQgZWZmZWN0aXZlbHkgaW1wb3NlIGEgbW9uZXRhcnkgYmFycmllciB0byBkZXBsb3llcnMg d2hvIGhhdmUgbG9uZyBkb21haW4gbmFtZXMuIFdlIHdvdWxkIGFsc28gaGF2ZSB0byBtYWtlIHRo aXMgYSBtYXhpbXVtIFVuaWNvZGUgY2hhcmFjdGVyIGxlbmd0aCB3aXRoIHRoZSBkb21haW4gbmFt ZSBleHByZXNzZWQgaW4gSUROIGZvcm0sIG5vdCBBU0NJSSBmb3JtLiBVc2VycyBvZiBub24tV2Vz dGVybiBzY3JpcHRzIHNob3VsZCBub3QgYmUgcGVuYWxpemVkIGJ5IHRoZSBuZWVkIHRvIHVzZSBQ dW55Y29kZS4NCg0K4oCTDQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0 eQ0KaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQpGcm9tOiBUeGF1dGggPHR4 YXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJk dEBnbWFpbC5jb20+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDIwIGF0IDU6MzcgUE0N ClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPg0K Q2M6ICJ0eGF1dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1R4 YXV0aF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmR0LXhhdXRo LXByb3RvY29sLTAzLnR4dA0KDQpUaGFua3MgQW5uYWJlbGxlLg0KDQpGWUk6IFdpdGggdGhlIHJl cXVpcmVtZW50IHRvIGhhdmUgYSBpbnRlcmFjdF9yZWYgdmFsdWUgY29tZSBiYWNrIGZyb20gdGhl IEdTIHRvIHRoZSBDbGllbnQsIHRoZSBwb3B1cCBhbmQgcmVkaXJlY3QgYXJlIG5vdyB0aGUgc2Ft ZSAtLSBzbyB3ZSBjYW4gbW92ZSBwYXN0IHRoZSBwb3B1cCBkaXNjdXNzaW9uLg0KDQpUbyBzdW1t YXJpemUgeW91ciBleGFtcGxlcywNCjEpIHRoZSBDbGllbnQgbWF5IG5lZWQgdG8gZmFsbGJhY2sg dG8gYSBkaWZmZXJlbnQgbWV0aG9kIHRoYW4gaXQgaW5pdGlhbGx5IGhhZCBwbGFubmVkIG9uDQoy KSB0aGUgQ2xpZW50IG1heSB3YW50IHRvIG9mZmVyIHRoZSBVc2VyIGEgYnJvYWRlciBjaG9pY2Ug b2YgbWV0aG9kcw0KDQooMSkgY291bGQgYmUgc29sdmVkIGJ5IHRoZSBDbGllbnQgbWFraW5nIGEg bmV3IHJlcXVlc3Qgb2YgdGhlIEdTDQoNCigyKSByZXF1aXJlcyB0aGUgQ2xpZW50IHRvIHJlY2Vp dmUgbXVsdGlwbGUgbWV0aG9kcyBzbyBpdCBjYW4gb2ZmZXIgdGhlIFVzZXIgYSBjaG9pY2UuDQoN CkFtIEkgZm9sbG93aW5nIGFsb25nIGNvcnJlY3RseQ0KDQpBIHNob3J0IFVSSSBhbmQgYSBsb25n IFVSSSBhcmUgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgLS0gc28gdGhlcmUgZG9lcyBub3Qgc2Vl bSB0byBiZSBhIHJlcXVpcmVtZW50IHRvIGhhdmUgYm90aC4NCkZvciBleGFtcGxlLCB0aGUgQ2xp ZW50IG1heSByZXF1ZXN0IGEgVVJJLCB3aXRoIGFuIG9wdGlvbmFsIG1heCBsZW5ndGg/DQoNClNv IHRoYXQgbGV0J3MgdGhlIENsaWVudCBhc2sgZm9yIG9uZSBvciBib3RoIG9mOg0KDQotIGEgVVJJ IHdpdGggYW4gb3B0aW9uYWwgbWF4IGxlbmd0aCAoIGluZGljYXRlIGl0IGhhcyBhIHN0YXRpYyBt YXggbGVuZ3RoKQ0KLSBhIHNob3J0IGNvZGUgYW5kIGNvZGUgZW50cnkgVVJJDQoNCklmIGFuZCB3 aGVuIG5ldyBtZWNoYW5pc20gZm9yIHRoZSBDbGllbnQgdG8gdHJhbnNmZXIgaW50ZXJhY3Rpb25z IHRvIHRoZSBHUywgbmV3IHBhcmFtZXRlcnMgYXJlIGRlZmluZWQuDQoNClE6IHdoYXQgaXMgTVRJ Pw0KDQpROiBJcyB0aGVyZSBhIG1pbmltdW0gbGVuZ3RoIG9mIHRoZSBzaG9ydCBVUkk/ICggdGhp bmsgdGhhdCBzcGVjaWZ5aW5nIGEgc2hvcnQgVVJJIG1heCBsZW5ndGggd2lsbCBtYWtlIGl0IGVh c2llciBmb3IgQ2xpZW50cyBhbmQgR1MgYXMgaXQgaXMgbm90IG5lZ290aWF0ZWQpDQoNCg0KL0Rp Y2sNCg0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9Z WEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD00MTA2NzlhNC04MjRj LTRmYzMtODJhMS02OTg0MmE0N2EwNTFd4ZCnDQoNCk9uIEZyaSwgRmViIDIxLCAyMDIwIGF0IDQ6 NDYgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFp bHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCk9rYXksIHlvdeKAmXZlIGNvbnZpbmNl ZCBtZSB0aGF0IHRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIGEgR1MgdG8gc29tZXRpbWVzIHByb3Zp ZGUgYSBzaG9ydGVyIFVSSSBhbmQgc29tZXRpbWVzIGEgbG9uZ2VyIFVSSS4gTGV04oCZcyBzZWUg aWYgSSBjYW4gY29udmluY2UgeW91IHRoYXQgaW50ZXJhY3Rpb24gbW9kZSBzZWxlY3Rpb24gaXMg bGVzcyBkZXRlcm1pbmlzdGljIHRoYW4geW91IHRoaW5rLiA6RA0KDQpJICp0aGluayogdGhlIENs aWVudCBjYW4gYmUgZXhwZWN0ZWQgdG8ga25vdyBpZiBpdCB3aWxsIHRyYW5zZmVyIGludGVyYWN0 aW9uIHRvIHRoZSBHUyB3aXRoaW4gdGhlIHNhbWUgdXNlciBhZ2VudCB0aGUgZW5kIHVzZXIgaXMg YWNjZXNzaW5nIENsaWVudCB0aHJvdWdoLiBJbiBvdGhlciB3b3JkcywgSSB0aGluayB0aGVyZSBh cmUgdHdvIHJlbGlhYmx5IGRpZmZlcmVudGlhYmxlIG1vZGVzOiBzYW1lIFVBICgzMFggcmVkaXJl Y3QsIG9wZW4gaW4gc2FtZSB3aW5kb3csIG9wZW4gaW4gbmV3KSwgYW5kIGRpZmZlcmVudCBVQSAo Y29kZSwgUVIgY29kZSwgb3BlbmluZyBVUkkgaW4gZXh0ZXJuYWwgYnJvd3NlciwgZXRjLikuIEhv d2V2ZXIsIHdpdGhpbiBlYWNoIG1vZGUsIHRoZSBDbGllbnQgbWF5IG5vdCBrbm93IHdoaWNoIG1l Y2hhbmlzbSB3aWxsIGJlIHVzZWQuIChlLmcuLCBmb3Ig4oCcc2FtZSBVQeKAnTogd2lsbCB0aGUg Q2xpZW50IG9wZW4gdGhlIFVSSSBpbiB0aGUgc2FtZSB3aW5kb3cgb3IgYSBuZXcgb25lOyBmb3Ig 4oCcZGlmZmVyZW50IFVB4oCdOiB3aWxsIHRoZSBlbmQgdXNlciBzY2FuIGEgUVIgY29kZSBvciBl bnRlciBhIGNvZGUgb3IgdGFwIG9uIGEgVVJJIGluIGFuIFNNUykNCg0KVGhlIG5vbi1kZXRlcm1p bmlzbSBjb21lcyBmcm9tIHR3byBzb3VyY2VzOg0KDQoxLiAgIEVudmlyb25tZW50YWwgY29uZGl0 aW9ucw0KDQphLiAgICBBIGNvbnNvbGUgYXBwIG1pZ2h0IGJlIGFibGUgdG8gZGlyZWN0bHkgb3Bl biBhIFVSSSBpbiB0aGUgc3lzdGVt4oCZcyBicm93c2VyIChlLmcuLCB3aGVuIHJ1bm5pbmcgaW4g YSB0ZXJtaW5hbCB3aW5kb3cgb24gYSBkZXNrdG9wKSwgb3IgaXQgbWlnaHQgbm90IChlLmcuLCBv biBhIGhlYWRsZXNzIHN5c3RlbSkuIFRoZSBhcHAgbWF5IG5vdCBrbm93IHRoZSBhbnN3ZXIgdW50 aWwgaXQgdHJpZXMgaXQuDQoNCmIuICAgVGhhdCBzYW1lIGNvbnNvbGUgYXBwIG1pZ2h0IGJlIHJ1 bm5pbmcgaW4gYSByZW1vdGUgdGVybWluYWwsIHN1Y2ggdGhhdCB0aGUgZW5kIHVzZXIgd291bGQg YmUgYWJsZSB0byBjbGljayBvciBjb3B5IGFuZCBwYXN0ZSBhIFVSSSBwcmludGVkIGJ5IHRoZSBh cHAuDQoNCmMuICAgIEFuIFNQQSBtaWdodCBiZSBhYmxlIHRvIG9wZW4gYSBwb3B1cCwgb3IgaXQg bWlnaHQgZmFpbCBmb3IgdmFyaW91cyByZWFzb25zLiBJdCBtaWdodCBkZWNpZGUgdG8gZmFsbCBi YWNrIHRvIGEgcmVkaXJlY3QgaWYgaXQgZGV0ZWN0cyB0aGF0IHRoZSBwb3B1cCBmYWlsZWQgdG8g b3Blbi4gSXQgbWlnaHQgd2FudCB0aGUg4oCccG9wdXDigJ0gdG8gZ3JhY2VmdWxseSBmYWxsIGJh Y2sgdG8gYSByZWRpcmVjdC1saWtlIGV4cGVyaWVuY2UgaW4gY2FzZSB0aGUgdXNlciBhZ2VudCBv bmx5IHN1cHBvcnRzIGEgc2luZ2xlIHdpbmRvdyBhdCBhIHRpbWUgKGUuZy4sIGVtYmVkZGVkIHVz ZXIgYWdlbnRzIGluIGFwcHMgbGlrZSBGYWNlYm9vayBhbmQgVHdpdHRlcikuDQoNCmQuICAgRW52 aXJvbm1lbnRhbCBjb25kaXRpb25zIG1heSBtYWtlIGl0IGRpZmZpY3VsdCB0byBzY2FuIGEgUVIg Y29kZSAoZS4uZy4sIHRoZSBzY3JlZW4gaXMgZGlydHksIGZvZ2d5LCBjcmFja2VkLCBvciB1bmRl ciBkaXJlY3Qgc3VubGlnaHQpLCBidXQgc3RpbGwgYWxsb3cgZm9yIGEgcGVyc29uIHRvIHJlYWQg YSBzaG9ydCBjb2RlLiBUaGUgQ2xpZW50IGxpa2VseSBoYXMgbm8gd2F5IG9mIGRldGVjdGluZyBz dWNoIHRoaW5ncy4NCg0KMi4gICBFbmQgdXNlciBjYXBhYmlsaXRpZXMgYW5kIHByZWZlcmVuY2Vz DQoNCmEuICAgIFRoZXkgbWF5IGhhdmUgYSBwaHlzaWNhbCBkaXNhYmlsaXR5IG9yIG90aGVyIGNv bmRpdGlvbiB0aGF0IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBpbXBvc3NpYmxlIGZvciB0aGVtIHRv IHNjYW4gYSBRUiBjb2RlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBpLiAgICAgIFRoZXkgbWF5IGJlIGNhcGFibGUgb2Yg cmVhZGluZyBhbmQgY29weWluZyBhIHNob3J0IGNvZGUuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpaS4gICAgICBUaGV5IG1h eSBiZSBjYXBhYmxlIG9mIGxpc3RlbmluZyB0byBhbmQgZW50ZXJpbmcgYSBzaG9ydCBjb2RlIHNw b2tlbiBieSB0aGUgZGV2aWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGlpaS4gICAgICBUaGV5IG1heSBiZSBjYXBhYmxlIG9m IGZvbGxvd2luZyBhIGxpbmsgc2VudCB0byB0aGVtIHZpYSB0ZXh0IG9yIGVtYWlsLCB3aGljaCB0 aGV5IGNhbiBhY2Nlc3Mgb24gYSBkZXZpY2Ugd2l0aCBncmVhdGVyIGFjY2Vzc2liaWxpdHkgb3B0 aW9ucy4NCg0KYi4gICBUaGV5IG1heSBub3QgaGF2ZSBhIGRldmljZSBjYXBhYmxlIG9mIHNjYW5u aW5nIGEgUVIgY29kZSwgb3IgdGhlIGRldmljZSBtYXkgbm90IGJlIGZ1bmN0aW9uaW5nLCBvciB0 aGUgZGV2aWNlIG1heSBiZSB0aGUgb25lIHRoYXQgdGhlIGNvZGUgaXMgYmVpbmcgZGlzcGxheWVk IG9uLg0KDQpjLiAgICBUaGV5IG1heSBub3Qga25vdyB3aGF0IGEgUVIgY29kZSBpcywgb3IgdW5k ZXJzdGFuZCBob3cgdG8gdXNlIG9uZS4NCg0KZC4gICBUaGV5IG1heSB3YW50IHRvIGNvbXBsZXRl IHRoZSBmbG93IG9uIGEgZGV2aWNlIHRoYXQgaXMgaW5jYXBhYmxlIG9mIHNjYW5uaW5nIHRoZSBR UiBjb2RlIChlLmcuLCB0aGVpciBkZXNrdG9wKS4NCg0KZS4gICAgVGhleSBtYXkgcHJlZmVyIHRv IGhhdmUgdGhlIFVSSSB0ZXh0ZWQgb3IgZW1haWxlZCB0byB0aGVtLCByYXRoZXIgdGhhbiBoYXZp bmcgdG8gc2NhbiBvciBjb3B5IGEgY29kZS4NCg0KZi4gICAgIFRoZXkgbWF5IG5vdCBoYXZlIGFj Y2VzcyB0byB0aGUgY29tcGFuaW9uIGFwcCB0aGF0IHRoZSBDbGllbnQgdHJhbnNtaXR0ZWQgdGhl IFVSSSB0byAoZS5nLiwgYmVjYXVzZSBpdOKAmXMgb24gdGhlIHNoYXJlZCBmYW1pbHkgdGFibGV0 LCBhbmQgaXTigJlzIHRoZWlyIHNpYmxpbmfigJlzIHR1cm4gdG8gdXNlIGl0KS4NCg0KSWYgd2Ug YWxsb3cgdGhhdCB0aGUgR1MgbWlnaHQgd2FudCB0byBpc3N1ZSBsb25nIFVSSXMgd2hlbiBwb3Nz aWJsZSwgdGhlbiB0aGVyZeKAmXMgYmFzaWNhbGx5IHRocmVlIHRoaW5ncyBhIENsaWVudCBtaWdo dCB3YW50LCBpbiBhbnkgY29tYmluYXRpb246DQoNCsK3ICAgICAgVVJJLCBubyBsZW5ndGggcmVz dHJpY3Rpb24NCg0KwrcgICAgICBVUkksIHdpdGggc29tZSBtYXggbGVuZ3RoIChlLmcuLCBiZWNh dXNlIG9mIFFSIGNvZGUgZGF0YSBjYXBhY2l0eSwgU01TIG1lc3NhZ2Ugc2l6ZSBsaW1pdHMsIGRp c3BsYXkgY29uc3RyYWludHMsIGV0Yy4pDQoNCsK3ICAgICAgU2hvcnQgY29kZSBhbmQgY29kZSBl bnRyeSBVUkksIGJvdGggaHVtYW4tZnJpZW5kbHkNCg0KVGhlIEdTIGNhbuKAmXQgZW5mb3JjZSBo b3cgdGhlc2UgYXJlIHVzZWQ7IHRoZXkgY2FuIG9ubHkgY29udHJvbCB3aGF0IHRoZXkgaXNzdWUs IGFuZCBob3cgdGhleSByZXNwb25kIHdoZW4gaW50ZXJhY3Rpb24gaXMgdHJhbnNmZXJyZWQgdG8g dGhlbS4gRGVmaW5pbmcgaW50ZXJhY3Rpb24gb2JqZWN0IHByb3BlcnRpZXMgaW4gdGVybXMgb2Yg dXNhZ2UgaW1wbGllcyBjb25zdHJhaW50cyBhbmQgZ3VhcmFudGVlcyB0aGF0IGRvbuKAmXQgZXhp c3QsIGFuZCBDbGllbnRzIGFyZSBnb2luZyB0byBkaXNyZWdhcmQgb3VyIHByZXNjcmliZWQgdXNl cyBhbnl3YXkgKGUuZy4sIGJ5IHNlbmRpbmcgYSDigJxxcmNvZGXigJ0gVVJJIGluIGFuIFNNUyku DQoNCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBz Oi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvDQoNCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IFRodXJz ZGF5LCBGZWJydWFyeSAyMCwgMjAyMCBhdCAzOjEzIFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bT4+DQpDYzogInR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0 aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbVHhhdXRo XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZHQteGF1dGgtcHJv dG9jb2wtMDMudHh0DQoNCg0KDQpPbiBUaHUsIEZlYiAyMCwgMjAyMCBhdCAxMjoyMSBQTSBSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlLCBEaWNrISBJ4oCZ bSBnb2luZyB0byBjb25maW5lIG15IGNvbW1lbnRzIGhlcmUgdG8gaW50ZXJhY3Rpb24gbW9kZSBk ZXNpZ24sIHNldHRpbmcgYXNpZGUgd2hldGhlciBvciBub3Qgd2UgbmVlZCDigJxwb3B1cOKAnS4g OkQNCg0KT25jZSB0aGUgR1MgaGFuZHMgdGhhdCBVUkkgYmFjayB0byB0aGUgQ2xpZW50LCBpdCBo YXMgemVybyBjb250cm9sIG92ZXIgaG93IHRoZSBDbGllbnQgdXNlcyBpdC4gVGhlIENsaWVudCBj b3VsZCBwcmVzZW50IGFueSBVUkkgKG9mIGEgcmVhc29uYWJsZSBzaXplKSBpbnRvIGEgUVIgY29k ZSwgb3IgcHJlc2VudCBpdCBhcyBhIGNsaWNrYWJsZSBsaW5rLCBvciByZWRpcmVjdCB0byBpdCwg b3Igb3BlbiBpdCBpbiBhbiBleHRlcm5hbCBicm93c2VyLCBvciBkbyBhbnkgbnVtYmVyIG9mIG90 aGVyIGFzLXlldC1ub3QtaW52ZW50ZWQgdGhpbmdzIHdpdGggaXQuIE1vcmVvdmVyLCB0aGUgQ2xp ZW50IG1heSBub3Qga25vdyB5ZXQgd2hhdCBpdCB3YW50cyB0byBkbyB3aXRoIGl0Lg0KDQpXaHkg d291bGQgdGhlIENsaWVudCBub3Qga25vdyB3aGF0IGl0IHdhbnRzIHRvIGRvIHdpdGggaXQ/IFdo YXQgd291bGQgY2hhbmdlIGJldHdlZW4gd2hlbiB0aGUgQ2xpZW50IGNhbGxlZCB0aGUgR1MsIGFu ZCB0aGUgR1MgcmVzcG9uZGVkPw0KDQpJIHRoaW5rIG9mIHRoZSBpbnRlcmFjdGlvbiBiZWluZyB0 aGUgQ2xpZW50IHNheWluZyAiSSB3YW50IHRvIGRvIGEgcmVkaXJlY3QiLCBhbmQgdGhlIEdTIHNh eXMsICJvaywgaGVyZSBpcyB0aGUgVVJJIi4gT3IgdGhlIENsaWVudCBzYXlzLCAiSSB3YW50IHRv IHNob3cgb25seSBhIGNvZGUgYW5kIGEgVVJJIiwgYW5kIHRoZSBHUyBzYXlzICJvaywgaGVyZSBp cyBhIGdvb2QsIGFuZCBhbiBlYXN5IHRvIHJlYWQgVVJJIGZvciB0aGUgdXNlciB0byB0eXBlIGlu IGFuZCBuYXZpZ2F0ZSB0by4NCg0KSSB1bmRlcnN0YW5kIHRoZXJlIGFyZSBpbnRlcmFjdGlvbnMg dGhhdCBtYXkgbm90IHlldCBiZWVuIGludmVudGVkIHlldC4gTW9yZSBvbiB0aGF0IGZ1cnRoZXIg ZG93bi4NCg0KU28gd2hhdCB2YWx1ZSBpcyB0aGVyZSBpbiBkaXN0aW5ndWlzaGluZyBiZXR3ZWVu IOKAnEkgd2FudCBhIFVSSSBmb3IgYSByZWRpcmVjdOKAnSB2cy4g4oCcSSB3YW50IGEgVVJJIGZv ciBhIFFSIGNvZGXigJ0gdnMuIOKAnEkgd2FudCBhIFVSSSBmb3IgPHNvbWUgb3RoZXIgbWFjaGlu ZS1kcml2ZW4gaW50ZXJhY3Rpb24gbW9kZT7igJ0/DQoNCkV2ZW4gaWYgd2UgY29uc2lkZXIgdGhp bmdzIGxpa2UgUVIgY29kZSBkYXRhIGNhcGFjaXR5LCB0aGF04oCZcyByZWFsbHkganVzdCBhIFVS SSBsZW5ndGggbGltaXRhdGlvbiwgd2hpY2ggY291bGQgYXBwbHkgdG8gbm9uLVFSIGludGVyYWN0 aW9uIG1vZGVzLCBlLmcuLCBpZiB0aGUgQ2xpZW50IGRldmljZSB3YW50cyB0byBjb21tdW5pY2F0 ZSB0aGUgVVJJIG92ZXIgYW4gZXh0cmVtZWx5IGJhbmR3aWR0aC1jb25zdHJhaW5lZCBjaGFubmVs Lg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgd2hlbiB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlLiBJZiB0 aGUgQ2xpZW50IGlzIGdvaW5nIHRvIGRvIGEgcmVkaXJlY3QsIHRoZW4gdGhlIFVSSSBsZW5ndGgg aXMgbm90IHNpZ25pZmljYW50Lg0KDQpBbmQgaXTigJlzIG5vdCBjbGVhciB0byBtZSBob3cgaW5j bHVkaW5nIGEgVVJJIGxlbmd0aCBsaW1pdGF0aW9uIGluIHRoZSByZXF1ZXN0IGhlbHBzLiBJZiBh IEdTIGlzIGNhcGFibGUgb2YgZ2VuZXJhdGluZyBhIHNob3J0ZXIgVVJJLCB3aHkgd291bGRu4oCZ dCBpdCBhbHdheXMgcmV0dXJuIHRoYXQ/DQoNClRoZXJlIG1heSBiZSBhIHZhcmlldHkgb2YgcmVh c29ucyB0aGF0IGEgR1MgbWF5IHdhbnQgdG8gcHJvdmlkZSBhIGRpZmZlcmVudCBVUkkgZm9yIGEg UVIgY29kZSB0aGFuIGEgcmVkaXJlY3QsIG9yIGV2ZW4gYSBwb3B1cC4NCg0KMSkgUGVyaGFwcyB0 aGUgR1MgaGFzIG9ubHkgYmVlbiBzdXBwb3J0aW5nIHJlZGlyZWN0cywgYW5kIGhhcyBhIHZlcnkg bG9uZyBVUkwuIFRoZXkgYWRkIHN1cHBvcnQgZm9yIGEgUVIgY29kZSwgYW5kIHVzZSBhIDNQIHNl cnZpY2UgdGhhdCByZWRpcmVjdHMgZnJvbSB0aGUgc2hvcnQgVVJMIHVzZWQgaW4gdGhlIFFSIGNv ZGUsIHRoZSB0aGUgbG9uZyBVUkwuIFRoZXkgZG9uJ3Qgd2FudCB0byBwYXkgZm9yIHRoZSAzUCBz ZXJ2aWNlIGFueW1vcmUgdGhhbiB0aGV5IGhhdmUgdG8uDQoNCjIpIFRoZSBHUyB3YW50cyB0aGUg UVIgY29kZSBhbmQgdXNlciBjb2RlIGZsb3dzIHRvIGdvIHRocm91Z2ggdGhlIHNhbWUgbWFjaGlu ZXJ5IHRoYXQgbG9va3MgdXAgdGhlIGNvZGUgdG8gZmluZCB0aGUgR3JhbnQuIFRoZSBVUkkgaW4g YSByZWRpcmVjdCBoYXMgdGhlIGdyYW50IGVtYmVkZGVkIGluIHRoZSBVUkkuIFRoZXkgZG9uJ3Qg d2FudCB0byBoYXZlIHRvIHVzZSB0aGUgY29kZSB0byBHcmFudCBtYWNoaW5lcnkgZm9yIGFsbCBV UklzLg0KDQozKSBBIFFSIGNvZGUgZmxvdyB3aWxsIHVzdWFsbHkgYmUgZG9uZSBvbiBhIHBob25l LCBhbmQgdGhlIEdTIHdhbnRzIHRvIGF0dGVtcHQgdG8gbGF1bmNoIGEgbmF0aXZlIGFwcCBpbiBz b21lIHdheSwNCg0KV2hpbGUgeW91IGFyZSBjb3JyZWN0LCB3ZSBjb3VsZCBtYWtlIGFsbCBVUklz IGJlIHNob3J0IGVub3VnaCB0aGF0IHRoZXkgY2FuIGJlIGVhc2lseSBzY2FubmVkLCB3aHkgZm9y Y2UgdGhhdCBvbiBpbXBsZW1lbnRvcnM/DQoNClRoZSBVUkkgbGVuZ3RoIGxpbWl0YXRpb24gY29u Y2VwdCB3YXMgZm9yIHRoZSBkaXNwbGF5X3VyaSBzbyB0aGF0IGEgY29uc3RyYWluZWQgZGV2aWNl IGhhcyBhbiB1cHBlciBsaW1pdC4gQSBzaW1pbGFyIHVwcGVyIGxpbWl0IG9uIFFSIGNvZGUgd291 bGQgYWxsb3cgYSBjb25zdHJhaW5lZCBkZXZpY2UgdG8ga25vdyB0aGUgcGl4ZWwgcmVzb2x1dGlv biBpdCBuZWVkcyB0byBzaG93IHRoZSBRUiBjb2RlLg0KDQpPbiB0aGUgY2xpZW50IHNpZGUsIGl0 IGNhbiBsb29rIGF0IHRoZSBsZW5ndGggb2YgdGhlIFVSSSBwcm92aWRlZCBhbmQgZGVjaWRlIHdo YXQgdG8gZG8gd2l0aCBpdCAoZS5nLiwgcmVuZGVyIGEgUVIgY29kZSBvciBkaXNwbGF5IGl0IG9y IGRvIG5vdGhpbmcgd2l0aCBpdCkuDQoNClBlciBhYm92ZSwgd2h5IHdvdWxkIHRoZSBDbGllbnQg bm90IGFscmVhZHkga25vdyB3aGF0IGV4cGVyaWVuY2UgaXQgd2FudHMgdG8gcHJlc2VudCB0byB0 aGUgVXNlcj8NCg0KQSBVUkkgdG8gYmUgZGlzcGxheWVkLCBhbmQgYSBVUkkgdG8gYmUgcmVkaXJl Y3RlZCB0byBhcmUgbGlrZWx5IGdvaW5nIHRvIGJlIHF1aXRlIGRpZmZlcmVudC4NCg0KVGhlIFVS SSBmb3IgYSBVc2VyIHRvIGVudGVyIGEgY29kZSB3aWxsIGxpa2VseSBiZSBhIHN0YXRpYyB2YWx1 ZSB0aGF0IGlzIGVhc3kgdG8gdHlwZS4gVGhlIFVzZXIgd2lsbCBsaWtlbHkgaGF2ZSB0byBhdXRo ZW50aWNhdGUgYXQgdGhhdCBwYWdlLCBhbmQgdGhlbiBiZSBwcm9tcHRlZCB0byBlbnRlciB0aGUg Y29kZS4NCg0KDQpTbyB0aGF0IHJlYWxseSBsZWF2ZXMgdXMgd2l0aCB0d28gaW50ZXJhY3Rpb24g bW9kZXMgdGhhdCB3ZSBuZWVkOg0KDQrigKIgICAgICDigJx1cmnigJ0sIHdoaWNoIHJldHVybnMg YSBmdWxsIFVSSSB0aGF0IG1heSBub3QgYmUgaHVtYW4gZnJpZW5kbHk7IGFuZA0KDQrigKIgICAg ICDigJxjb2Rl4oCdLCB3aGljaCByZXR1cm5zIGEgY29kZSBhbmQgVVJJIGZvciBhIGNvZGUgZW50 cnkgcGFnZSwgYm90aCBvZiB3aGljaCBhcmUgaHVtYW4tZnJpZW5kbHkuDQoNClRob3NlIGNvdWxk IGJlIGNvbWJpbmFibGUgdG8gZ2V0IGJvdGgsIGFuZCBldmVuIGlmIHdlIGRvbuKAmXQgZ28gZG93 biB0aGUgbXVsdGlwbGUgaW50ZXJhY3Rpb24gbW9kZSByb3V0ZSB3ZSBjb3VsZCBhZGQgdGhlIGZ1 bGwgVVJJIHRvIHRoZSDigJxjb2Rl4oCdIGludGVyYWN0aW9uIG9iamVjdC4gSXQgd291bGRu4oCZ dCBodXJ0IGFueXRoaW5nIHRvIGRvIHNvLg0KDQpJbiB0aGUgbGF0ZXN0IHZlcnNpb24sIEkgZ2F2 ZSBlYWNoIFVSSSBpdHMgb3duIG5hbWUgc28gdGhhdCB0aGUgR1MgY2FuIGJlIGNsZWFyIGFib3V0 IGhvdyBpdCB3aWxsIGJlIHVzZWQuDQoNCldoaWxlIHdlIGNvdWxkIHNxdWVlemUgYWxsIHRoZSBm dW5jdGlvbmFsaXR5IGludG8gYSBjb3VwbGUgcGFyYW1ldGVycywgSSB0aGluayBpdCBtYWtlcyBp dCBoYXJkZXIgZm9yIGV4aXN0aW5nIGRlcGxveW1lbnRzIHRvIG1pZ3JhdGUgdG8gdGhlIHByb3Rv Y29sLiBJIHRoaW5rIHdlIHNob3VsZCBtYWtlIGl0IGVhc3kgZm9yIGRldmVsb3BlcnMgdG8gdGFr ZSB3aGF0IHRoZXkgYWxyZWFkeSBoYXZlIGFuZCB1c2UgaXQgd2l0aCBYQXV0aC4NCg0Kd3J0LiBu b3QteWV0LWludmVudGVkIGludGVyYWN0aW9ucy4gVGhlc2UgaW50ZXJhY3Rpb25zIGFyZSBmb3Ig bm90LXlldC1kZXNjcmliZWQgdXNlIGNhc2VzLiAoaWYgb3RoZXIgdXNlIGNhc2VzIGV4aXN0LCB0 aGVuIGxldCdzIGxvb2sgYXQgdGhlbSBhbmQgYWRkIHRoZSBpbnRlcmFjdGlvbiBtZWNoYW5pc21z IGlmIG5lZWRlZCkgV2UgZG9uJ3Qga25vdyB3aGF0IHBhcmFtZXRlcnMgd2lsbCBiZSBuZWVkZWQs IGFuZCBvdmVybG9hZGluZyB0aGUgcGFyYW1ldGVycyBhbmQgbGV0dGluZyB0aGUgQ2xpZW50IGRv IHdoYXRldmVyIGl0IHdhbnRzIGRvZXMgbm90IHNlZW0gbGlrZSBpdCB3aWxsIGludGVyb3BlcmF0 ZSAtLSB0aGUgQ2xpZW50IGRlY2lkZXMgaXQgd2FudHMgdG8gZG8gc29tZSBuZXcgaW50ZXJhY3Rp b24sIGFuZCB1c2VzIHRoZSBwYXJhbWV0ZXJzIGluIGEgd2F5IHRoZSBHUyBkb2VzIG5vdCB1bmRl cnN0YW5kLg0KDQoNCg0KDQoNCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpDQpBV1Mg SWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvDQoNCg0KRnJvbTogVHhh dXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5v cmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE4LCAyMDIw IGF0IDY6MDQgUE0NClRvOiAidHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+ IiA8dHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1R4 YXV0aF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmR0LXhhdXRo LXByb3RvY29sLTAzLnR4dA0KDQpBZGRlZCBpbiB1c2VyIGNvZGUgaW50ZXJhY3Rpb24gYW5kIGFs aWduZWQgUVIgY29kZSB0byBiZSBhIHN1cGVyc2V0IG9mIHVzZXIgY29kZS4NCkZpeGVkIGRlc2Ny aXB0aW9ucy4NCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0NCkZyb206 IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4+DQpEYXRlOiBUdWUsIEZlYiAxOCwgMjAyMCBhdCA2OjAwIFBNDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dA0K VG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFyZHQteGF1dGgt cHJvdG9jb2wtMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERpY2sg SGFyZHQgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAg ICAgIGRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sDQpSZXZpc2lvbjogICAgICAgMDMNClRpdGxl OiAgICAgICAgICBUaGUgWEF1dGggUHJvdG9jb2wNCkRvY3VtZW50IGRhdGU6ICAyMDIwLTAyLTE4 DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAg NTMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wvDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhh dXRoLXByb3RvY29sLTAzDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci4uaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2w8aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbD4NCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaGFyZHQt eGF1dGgtcHJvdG9jb2wtMDMNCg0KQWJzdHJhY3Q6DQogICBDbGllbnQgc29mdHdhcmUgb2Z0ZW4g ZGVzaXJlcyByZXNvdXJjZXMgb3IgaWRlbnRpdHkgY2xhaW1zIHRoYXQgYXJlDQogICBpbmRlcGVu ZGVudCBvZiB0aGUgY2xpZW50LiAgVGhpcyBwcm90b2NvbCBhbGxvd3MgYSB1c2VyIGFuZC9vcg0K ICAgcmVzb3VyY2Ugb3duZXIgdG8gZGVsZWdhdGUgcmVzb3VyY2UgYXV0aG9yaXphdGlvbiBhbmQv b3IgcmVsZWFzZSBvZg0KICAgaWRlbnRpdHkgY2xhaW1zIHRvIGEgc2VydmVyLiAgQ2xpZW50IHNv ZnR3YXJlIGNhbiB0aGVuIHJlcXVlc3QgYWNjZXNzDQogICB0byByZXNvdXJjZXMgYW5kL29yIGlk ZW50aXR5IGNsYWltcyBieSBjYWxsaW5nIHRoZSBzZXJ2ZXIuICBUaGUNCiAgIHNlcnZlciBhY3F1 aXJlcyBjb25zZW50IGFuZCBhdXRob3JpemF0aW9uIGZyb20gdGhlIHVzZXIgYW5kL29yDQogICBy ZXNvdXJjZSBvd25lciBpZiByZXF1aXJlZCwgYW5kIHRoZW4gcmV0dXJucyB0byB0aGUgY2xpZW50 IHNvZnR3YXJlDQogICB0aGUgYXV0aG9yaXphdGlvbiBhbmQgaWRlbnRpdHkgY2xhaW1zIHRoYXQg d2VyZSBhcHByb3ZlZC4gIFRoaXMNCiAgIHByb3RvY29sIGNhbiBiZSBleHRlbmRlZCB0byBzdXBw b3J0IGFsdGVybmF0aXZlIGF1dGhvcml6YXRpb25zLA0KICAgY2xhaW1zLCBpbnRlcmFjdGlvbnMs IGFuZCBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy4NCg0KDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1h WkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD01MzNl NTExNi02ZTIxLTRhOTAtYTFjOS1iYTdkODcwYTg3Yzld4ZCnDQo= --_000_72D44F536AB743C8A337623B31FB584Bamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <72D2BAC01034EE43B962BEC22DD86369@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW03MTg2MzM0ODUwODI4ODYwNjQ4bXNvbGlz dHBhcmFncmFwaCwgbGkuZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0cGFyYWdyYXBo LCBkaXYuZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0cGFyYWdyYXBoDQoJe21zby1z dHlsZS1uYW1lOmdtYWlsLW1fNzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3RwYXJhZ3JhcGg7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW03MTg2MzM0ODUw ODI4ODYwNjQ4Z21haWwtbTg0NTYyNDc5NTExODMwNjQ4NjVtc29saXN0cGFyYWdyYXBoLCBsaS5n bWFpbC1tNzE4NjMzNDg1MDgyODg2MDY0OGdtYWlsLW04NDU2MjQ3OTUxMTgzMDY0ODY1bXNvbGlz dHBhcmFncmFwaCwgZGl2LmdtYWlsLW03MTg2MzM0ODUwODI4ODYwNjQ4Z21haWwtbTg0NTYyNDc5 NTExODMwNjQ4NjVtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNzE4 NjMzNDg1MDgyODg2MDY0OGdtYWlsLW04NDU2MjQ3OTUxMTgzMDY0ODY1bXNvbGlzdHBhcmFncmFw aDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzQ4NDg0NTY0Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjQzMDk1NTk0 IDY3OTI0OTE2NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0Ojg7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiTVMgTWluY2hvIjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzAyMTU2ODY3Ow0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczo1MTcyMTk5NjI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1p ZDoxNzAyMDQ2ODI0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjExMDI5MTA4O30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDkzMTU5MjcwOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNjExMDI5MTA4O30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3VyIHN1bW1h cnkgaXMgYWNjdXJhdGUsIGJ1dCB0aGUgbGluZSBiZXR3ZWVuIHlvdXIgdHdvIHJlYXNvbnMgZ2V0 cyBwcmV0dHkgYmx1cnJ5LiBUaGUgQ2xpZW50IG1heSBub3QgYmUgYWJsZSB0byBkZXRlY3Qgb24g aXRzIG93biB3aGV0aGVyIGl0cyBwcmVmZXJyZWQgbWV0aG9kIGlzIHdvcmtpbmcsIHNvIHlvdXIg cHJvcG9zYWwgdGhhdCB0aGUgQ2xpZW50IGNvdWxkIHN3aXRjaCBtZXRob2RzIGJ5DQogbWFraW5n IGEgbmV3IHJlcXVlc3Qgd291bGQgcmVxdWlyZSB0aGUgZW5kIHVzZXIgdG8gcHJvdmlkZSBzb21l IGlucHV0LiBGb3IgZXhhbXBsZTo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm81Ij5JZiBhIHdlYiBicm93c2Vy IGlzIGF2YWlsYWJsZSBidXQgdGhlIGZpcmV3YWxsIGJsb2NrcyBvdXRib3VuZCBIVFRQIChub3Qg dW5yZWFzb25hYmxlIGZvciBhIHNlcnZlciBob3N0KSwgdGhlIENsaWVudCB3b3VsZCB0aGluayB0 aGF0IGl0IHN1Y2Nlc3NmdWxseSBvcGVuZWQgdGhlIFVSSS48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm81Ij5JZiB0aGUgbG9jYWwgYnJvd3NlciBsYWNrcyB0aGUgYWNjZXNzaWJpbGl0 eSBmZWF0dXJlcyBuZWVkZWQgYnkgdGhlIGVuZCB1c2VyLCB0aGUgQ2xpZW50IHdvdWxkIHN1Y2Nl c3NmdWxseSBvcGVuIHRoZSBVUkksIGJ1dCBpdCB3b3VsZCBub3QgYmUgdXNhYmxlIGJ5IHRoZSBl bmQgdXNlci48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm81Ij5JbiB0aGUg4oCcc2hh cmVkIGZhbWlseSB0YWJsZXTigJ0gZXhhbXBsZSBpbiBteSBwcmV2aW91cyBlbWFpbCwgdGhlIENs aWVudCB3b3VsZCBub3QgYmUgYXdhcmUgdGhhdCB0aGUgZW5kIHVzZXIgaXMgdW5hYmxlIHRvIGlu dGVyYWN0IHdpdGggdGhlIGNvbXBhbmlvbiBhcHAuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvIGl04oCZcyBlYXNpZXIgZm9yIGJvdGggQ2xpZW50IGFuZCBlbmQgdXNlciwgYW5kIG1v cmUgZ2VuZXJhbGx5IGFwcGxpY2FibGUgaWYgdGhlIENsaWVudCBjYW4gcmVxdWVzdCBtdWx0aXBs ZSBpbnRlcmFjdGlvbiBtb2RlcyBhbmQgcHJlc2VudCB0aGVtIGF0IHRoZSBzYW1lIHRpbWUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIG9ubHkgaGF2ZSBhIHNpbmdsZSDigJx1cmnigJ0g cGFyYW1ldGVyLCB0aGUgbWF4IGxlbmd0aCBpbiB0aGUgcmVxdWVzdCBzaG91bGQgYmUgYWR2aXNv cnkuIEkuZS4sIHRoZSBHUyBTSEFMTCByZXR1cm4gYSBVUkksIGFuZCBpdCBTSE9VTEQgcmV0dXJu IG9uZSB0aGF0IG1lZXRzIHRoZSBtYXggbGVuZ3RoIHJlc3RyaWN0aW9uIGlmIGl0IGNhbi4gQ2xp ZW50IGJlaGF2aW9yIGlzIGVmZmVjdGl2ZWx5IHRoZSBzYW1lDQogYXMgaWYgaXQgd2VyZSB0cmVh dGVkIGFzIGEgaGFyZCByZXF1aXJlbWVudDsgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IHRo ZSBDbGllbnQgY29kZSBicmFuY2hlcyBiYXNlZCBvbiB0aGUgYWN0dWFsIGxlbmd0aCBvZiB0aGUg VVJJIHJldHVybmVkICh3aGljaCBpdCBhbHJlYWR5IG5lZWRzIHRvIGNoZWNrKSByYXRoZXIgdGhh biBiYXNlZCBvbiB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiBhIFVSSSwgb3IgYW4gZXJyb3Ig cmVzcG9uc2UgZnJvbQ0KIHRoZSBHUy4gQ2xpZW50cyB0aGF0IGNhbiBzdGlsbCBtYWtlIHVzZSBv ZiBhIGxvbmdlciBVUkkgYXJlIHNhdmVkIHRoZSBleHRyYSByb3VuZCB0cmlwIHRvIHJlcXVlc3Qg b25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGJvdGgg4oCcdXJp4oCdIGFuZCDi gJxjb2Rl4oCdIHNob3VsZCBiZSBNVEksIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gdGhleSBhcmUg bWFuZGF0b3J5IHRvIGRlcGxveS4gVGhlcmXigJlzIGxvdHMgb2YgY2FzZXMgd2hlcmUgYSBHUyB3 aWxsIG9ubHkgZXZlciBkZWFsIHdpdGggc3BlY2lmaWMgdHlwZXMgb2YgQ2xpZW50cyBzdWNoIHRo YXQgdGhleeKAmWxsIGFsd2F5cyB1c2Ugb25lIG9yIHRoZSBvdGhlciwgYnV0IGluDQogdGhvc2Ug Y2FzZXMgdGhlIEdTIGlzIGV4cGxpY2l0bHkgbm90IGNvbmNlcm5lZCBvdmVybXVjaCB3aXRoIGlu dGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG5lZWQgdG8gYmUgY2Fy ZWZ1bCBhYm91dCBkZWZpbmluZyBhIG1heGltdW0gbGVuZ3RoIGZvciB0aGUgY29kZSBlbnRyeSBV UkkuIERvbWFpbiBuYW1lcyBjb3N0IG1vbmV5IHRvIHJlZ2lzdGVyIGFuZCBtYWludGFpbiwgc28g YSBtYXhpbXVtIGxlbmd0aCB0aGF0IGlzIHRvbyBsb3cgd291bGQgZWZmZWN0aXZlbHkgaW1wb3Nl IGEgbW9uZXRhcnkgYmFycmllciB0byBkZXBsb3llcnMgd2hvIGhhdmUgbG9uZyBkb21haW4NCiBu YW1lcy4gV2Ugd291bGQgYWxzbyBoYXZlIHRvIG1ha2UgdGhpcyBhIG1heGltdW0gVW5pY29kZSBj aGFyYWN0ZXIgbGVuZ3RoIHdpdGggdGhlIGRvbWFpbiBuYW1lIGV4cHJlc3NlZCBpbiBJRE4gZm9y bSwgbm90IEFTQ0lJIGZvcm0uIFVzZXJzIG9mIG5vbi1XZXN0ZXJuIHNjcmlwdHMgc2hvdWxkIG5v dCBiZSBwZW5hbGl6ZWQgYnkgdGhlIG5lZWQgdG8gdXNlIFB1bnljb2RlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vYXdzLmFt YXpvbi5jb20vaWRlbnRpdHkvIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9h d3MuYW1hem9uLmNvbS9pZGVudGl0eS88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAm bHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZs dDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBGZWJy dWFyeSAyMSwgMjAyMCBhdCA1OjM3IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MgQW5u YWJlbGxlLiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RllJOiBXaXRo IHRoZSByZXF1aXJlbWVudCB0byBoYXZlIGEgaW50ZXJhY3RfcmVmIHZhbHVlIGNvbWUgYmFjayBm cm9tIHRoZSBHUyB0byB0aGUgQ2xpZW50LCB0aGUgcG9wdXAgYW5kIHJlZGlyZWN0IGFyZSBub3cg dGhlIHNhbWUgLS0gc28gd2UgY2FuIG1vdmUgcGFzdCB0aGUgcG9wdXAgZGlzY3Vzc2lvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VG8gc3Vt bWFyaXplIHlvdXIgZXhhbXBsZXMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MSkgdGhlIENsaWVudCBt YXkgbmVlZCB0byBmYWxsYmFjayB0byBhIGRpZmZlcmVudCBtZXRob2QgdGhhbiBpdCBpbml0aWFs bHkgaGFkIHBsYW5uZWQgb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjIpIHRo ZSBDbGllbnQgbWF5IHdhbnQgdG8gb2ZmZXIgdGhlIFVzZXIgYSBicm9hZGVyIGNob2ljZSBvZiBt ZXRob2RzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KDEp IGNvdWxkIGJlIHNvbHZlZCBieSB0aGUgQ2xpZW50IG1ha2luZyBhIG5ldyByZXF1ZXN0IG9mIHRo ZSBHUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPigyKSBy ZXF1aXJlcyB0aGUgQ2xpZW50IHRvIHJlY2VpdmUmbmJzcDttdWx0aXBsZSBtZXRob2RzIHNvIGl0 IGNhbiBvZmZlciB0aGUgVXNlciBhIGNob2ljZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5BbSBJIGZvbGxvd2luZyZuYnNwO2Fsb25nIGNvcnJlY3RseTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkEgc2hvcnQgVVJJ IGFuZCBhIGxvbmcgVVJJIGFyZSBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCAtLSBzbyB0aGVyZSBk b2VzIG5vdCBzZWVtIHRvIGJlIGEgcmVxdWlyZW1lbnQgdG8gaGF2ZSBib3RoLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkZvciBleGFtcGxlLCB0aGUgQ2xpZW50IG1heSByZXF1ZXN0IGEgVVJJ LCB3aXRoIGFuIG9wdGlvbmFsIG1heCBsZW5ndGg/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U28gdGhhdCBsZXQncyB0aGUgQ2xpZW50IGFzayBmb3Igb25l IG9yIGJvdGggb2Y6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+LSBhIFVSSSB3aXRoIGFuIG9wdGlvbmFsIG1heCBsZW5ndGggKCBpbmRpY2F0ZSBpdCBoYXMg YSBzdGF0aWMgbWF4IGxlbmd0aCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tIGEgc2hvcnQgY29kZSBh bmQgY29kZSBlbnRyeSBVUkk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JZiBhbmQgd2hlbiBuZXcgbWVjaGFuaXNtIGZvciB0aGUgQ2xpZW50IHRvIHRyYW5z ZmVyIGludGVyYWN0aW9ucyB0byB0aGUgR1MsIG5ldyBwYXJhbWV0ZXJzIGFyZSBkZWZpbmVkLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlE6IHdo YXQgaXMgTVRJPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlE6IElzIHRoZXJlIGEgbWluaW11bSBsZW5ndGggb2YgdGhlIHNob3J0IFVSST8gKCB0aGluayB0 aGF0IHNwZWNpZnlpbmcgYSBzaG9ydCBVUkkgbWF4IGxlbmd0aCB3aWxsIG1ha2UgaXQgZWFzaWVy IGZvciBDbGllbnRzIGFuZCBHUyBhcyBpdCBpcyBub3QgbmVnb3RpYXRlZCk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cHM6Ly9t YWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpi MjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9NDEwNjc5YTQtODI0Yy00ZmMzLTgy YTEtNjk4NDJhNDdhMDUxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIEZyaSwgRmViIDIxLCAyMDIw IGF0IDQ6NDYgUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCk9rYXksIHlvdeKAmXZlIGNvbnZp bmNlZCBtZSB0aGF0IHRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIGEgR1MgdG8gc29tZXRpbWVzIHBy b3ZpZGUgYSBzaG9ydGVyIFVSSSBhbmQgc29tZXRpbWVzIGEgbG9uZ2VyIFVSSS4gTGV04oCZcyBz ZWUgaWYgSSBjYW4gY29udmluY2UgeW91IHRoYXQgaW50ZXJhY3Rpb24gbW9kZSBzZWxlY3Rpb24g aXMgbGVzcyBkZXRlcm1pbmlzdGljIHRoYW4geW91IHRoaW5rLiA6RDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpJICo8Yj50 aGluazwvYj4qIHRoZSBDbGllbnQgY2FuIGJlIGV4cGVjdGVkIHRvIGtub3cgaWYgaXQgd2lsbCB0 cmFuc2ZlciBpbnRlcmFjdGlvbiB0byB0aGUgR1Mgd2l0aGluIHRoZSBzYW1lIHVzZXIgYWdlbnQg dGhlIGVuZCB1c2VyIGlzIGFjY2Vzc2luZyBDbGllbnQgdGhyb3VnaC4gSW4gb3RoZXIgd29yZHMs IEkgdGhpbmsgdGhlcmUgYXJlIHR3byByZWxpYWJseSBkaWZmZXJlbnRpYWJsZSBtb2Rlczogc2Ft ZSBVQSAoMzBYIHJlZGlyZWN0LCBvcGVuDQogaW4gc2FtZSB3aW5kb3csIG9wZW4gaW4gbmV3KSwg YW5kIGRpZmZlcmVudCBVQSAoY29kZSwgUVIgY29kZSwgb3BlbmluZyBVUkkgaW4gZXh0ZXJuYWwg YnJvd3NlciwgZXRjLikuIEhvd2V2ZXIsIHdpdGhpbiBlYWNoIG1vZGUsIHRoZSBDbGllbnQgbWF5 IG5vdCBrbm93IHdoaWNoIG1lY2hhbmlzbSB3aWxsIGJlIHVzZWQuIChlLmcuLCBmb3Ig4oCcc2Ft ZSBVQeKAnTogd2lsbCB0aGUgQ2xpZW50IG9wZW4gdGhlIFVSSSBpbiB0aGUgc2FtZSB3aW5kb3cg b3INCiBhIG5ldyBvbmU7IGZvciDigJxkaWZmZXJlbnQgVUHigJ06IHdpbGwgdGhlIGVuZCB1c2Vy IHNjYW4gYSBRUiBjb2RlIG9yIGVudGVyIGEgY29kZSBvciB0YXAgb24gYSBVUkkgaW4gYW4gU01T KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQpUaGUgbm9uLWRldGVybWluaXNtIGNvbWVzIGZyb20gdHdvIHNvdXJjZXM6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwzIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkVu dmlyb25tZW50YWwgY29uZGl0aW9ucyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t NzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDox LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QSBjb25zb2xlIGFwcCBtaWdodCBiZSBhYmxl IHRvIGRpcmVjdGx5IG9wZW4gYSBVUkkgaW4gdGhlIHN5c3RlbeKAmXMgYnJvd3NlciAoZS5nLiwg d2hlbiBydW5uaW5nIGluIGEgdGVybWluYWwgd2luZG93IG9uIGEgZGVza3RvcCksIG9yIGl0IG1p Z2h0IG5vdCAoZS5nLiwgb24gYSBoZWFkbGVzcyBzeXN0ZW0pLiBUaGUgYXBwIG1heSBub3Qga25v dyB0aGUgYW5zd2VyIHVudGlsIGl0IHRyaWVzIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW03MTg2MzM0ODUwODI4ODYwNjQ4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZlbDIgbGZvMSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGF0IHNhbWUgY29uc29sZSBhcHAgbWln aHQgYmUgcnVubmluZyBpbiBhIHJlbW90ZSB0ZXJtaW5hbCwgc3VjaCB0aGF0IHRoZSBlbmQgdXNl ciB3b3VsZCBiZSBhYmxlIHRvIGNsaWNrIG9yIGNvcHkgYW5kIHBhc3RlIGEgVVJJIHByaW50ZWQg YnkgdGhlIGFwcC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMzNDg1MDgy ODg2MDY0OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yy48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+QW4gU1BBIG1pZ2h0IGJlIGFibGUgdG8gb3BlbiBhIHBvcHVwLCBv ciBpdCBtaWdodCBmYWlsIGZvciB2YXJpb3VzIHJlYXNvbnMuIEl0IG1pZ2h0IGRlY2lkZSB0byBm YWxsIGJhY2sgdG8gYSByZWRpcmVjdCBpZiBpdCBkZXRlY3RzIHRoYXQgdGhlIHBvcHVwIGZhaWxl ZCB0byBvcGVuLiBJdCBtaWdodCB3YW50IHRoZSDigJxwb3B1cOKAnSB0byBncmFjZWZ1bGx5IGZh bGwgYmFjayB0byBhIHJlZGlyZWN0LWxpa2UNCiBleHBlcmllbmNlIGluIGNhc2UgdGhlIHVzZXIg YWdlbnQgb25seSBzdXBwb3J0cyBhIHNpbmdsZSB3aW5kb3cgYXQgYSB0aW1lIChlLmcuLCBlbWJl ZGRlZCB1c2VyIGFnZW50cyBpbiBhcHBzIGxpa2UgRmFjZWJvb2sgYW5kIFR3aXR0ZXIpLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW03MTg2MzM0ODUwODI4ODYwNjQ4bXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMyBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5kLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5FbnZp cm9ubWVudGFsIGNvbmRpdGlvbnMgbWF5IG1ha2UgaXQgZGlmZmljdWx0IHRvIHNjYW4gYSBRUiBj b2RlIChlLi5nLiwgdGhlIHNjcmVlbiBpcyBkaXJ0eSwgZm9nZ3ksIGNyYWNrZWQsIG9yIHVuZGVy IGRpcmVjdCBzdW5saWdodCksIGJ1dCBzdGlsbCBhbGxvdyBmb3IgYSBwZXJzb24gdG8gcmVhZCBh IHNob3J0IGNvZGUuIFRoZSBDbGllbnQgbGlrZWx5IGhhcyBubyB3YXkgb2YgZGV0ZWN0aW5nIHN1 Y2gNCiB0aGluZ3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTcxODYzMzQ4NTA4 Mjg4NjA2NDhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwzIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPkVuZCB1c2VyIGNhcGFiaWxpdGllcyBhbmQgcHJlZmVyZW5jZXMgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0cGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwzIGxldmVsMiBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlRoZXkgbWF5IGhhdmUgYSBwaHlzaWNhbCBkaXNhYmlsaXR5IG9yIG90aGVyIGNvbmRpdGlvbiB0 aGF0IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBpbXBvc3NpYmxlIGZvciB0aGVtIHRvIHNjYW4gYSBR UiBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW03MTg2MzM0ODUwODI4ODYw NjQ4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMGluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+aS48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NClRoZXkg bWF5IGJlIGNhcGFibGUgb2YgcmVhZGluZyBhbmQgY29weWluZyBhIHNob3J0IGNvZGUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0cGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5paS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+VGhleSBtYXkgYmUgY2FwYWJsZSBvZiBsaXN0ZW5p bmcgdG8gYW5kIGVudGVyaW5nIGEgc2hvcnQgY29kZSBzcG9rZW4gYnkgdGhlIGRldmljZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3Rw YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPmlpaS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+VGhleSBtYXkgYmUgY2FwYWJsZSBvZiBmb2xsb3dpbmcgYSBsaW5r IHNlbnQgdG8gdGhlbSB2aWEgdGV4dCBvciBlbWFpbCwgd2hpY2ggdGhleSBjYW4gYWNjZXNzIG9u IGEgZGV2aWNlIHdpdGggZ3JlYXRlciBhY2Nlc3NpYmlsaXR5IG9wdGlvbnMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0cGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwy IGxldmVsMiBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZXkgbWF5IG5v dCBoYXZlIGEgZGV2aWNlIGNhcGFibGUgb2Ygc2Nhbm5pbmcgYSBRUiBjb2RlLCBvciB0aGUgZGV2 aWNlIG1heSBub3QgYmUgZnVuY3Rpb25pbmcsIG9yIHRoZSBkZXZpY2UgbWF5IGJlIHRoZSBvbmUg dGhhdCB0aGUgY29kZSBpcyBiZWluZyBkaXNwbGF5ZWQgb24uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iZ21haWwtbTcxODYzMzQ4NTA4Mjg4NjA2NDhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMiBs Zm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZXkgbWF5IG5vdCBr bm93IHdoYXQgYSBRUiBjb2RlIGlzLCBvciB1bmRlcnN0YW5kIGhvdyB0byB1c2Ugb25lLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW03MTg2MzM0ODUwODI4ODYwNjQ4bXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMiBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5kLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGV5 IG1heSB3YW50IHRvIGNvbXBsZXRlIHRoZSBmbG93IG9uIGEgZGV2aWNlIHRoYXQgaXMgaW5jYXBh YmxlIG9mIHNjYW5uaW5nIHRoZSBRUiBjb2RlIChlLmcuLCB0aGVpciBkZXNrdG9wKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDIgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+ZS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ VGhleSBtYXkgcHJlZmVyIHRvIGhhdmUgdGhlIFVSSSB0ZXh0ZWQgb3IgZW1haWxlZCB0byB0aGVt LCByYXRoZXIgdGhhbiBoYXZpbmcgdG8gc2NhbiBvciBjb3B5IGEgY29kZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3RwYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIg bGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Zi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ VGhleSBtYXkgbm90IGhhdmUgYWNjZXNzIHRvIHRoZSBjb21wYW5pb24gYXBwIHRoYXQgdGhlIENs aWVudCB0cmFuc21pdHRlZCB0aGUgVVJJIHRvIChlLmcuLCBiZWNhdXNlIGl04oCZcyBvbiB0aGUg c2hhcmVkIGZhbWlseSB0YWJsZXQsIGFuZCBpdOKAmXMgdGhlaXIgc2libGluZ+KAmXMgdHVybiB0 byB1c2UgaXQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQpJZiB3ZSBhbGxvdyB0aGF0IHRoZSBHUyBtaWdodCB3YW50IHRv IGlzc3VlIGxvbmcgVVJJcyB3aGVuIHBvc3NpYmxlLCB0aGVuIHRoZXJl4oCZcyBiYXNpY2FsbHkg dGhyZWUgdGhpbmdzIGEgQ2xpZW50IG1pZ2h0IHdhbnQsIGluIGFueSBjb21iaW5hdGlvbjo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3Rw YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+VVJJLCBubyBsZW5ndGggcmVzdHJpY3Rpb248bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMzNDg1MDgyODg2MDY0OG1zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7C tzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+VVJJLCB3aXRoIHNvbWUgbWF4IGxlbmd0aCAoZS5nLiwgYmVjYXVzZSBvZiBRUiBjb2RlIGRh dGEgY2FwYWNpdHksIFNNUyBtZXNzYWdlIHNpemUgbGltaXRzLCBkaXNwbGF5IGNvbnN0cmFpbnRz LCBldGMuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW03MTg2MzM0ODUwODI4ODYw NjQ4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TaG9ydCBjb2RlIGFuZCBjb2RlIGVudHJ5IFVSSSwg Ym90aCBodW1hbi1mcmllbmRseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpUaGUgR1MgY2Fu4oCZdCBlbmZvcmNlIGhvdyB0 aGVzZSBhcmUgdXNlZDsgdGhleSBjYW4gb25seSBjb250cm9sIHdoYXQgdGhleSBpc3N1ZSwgYW5k IGhvdyB0aGV5IHJlc3BvbmQgd2hlbiBpbnRlcmFjdGlvbiBpcyB0cmFuc2ZlcnJlZCB0byB0aGVt LiBEZWZpbmluZyBpbnRlcmFjdGlvbiBvYmplY3QgcHJvcGVydGllcyBpbiB0ZXJtcyBvZiB1c2Fn ZSBpbXBsaWVzIGNvbnN0cmFpbnRzIGFuZCBndWFyYW50ZWVzIHRoYXQgZG9u4oCZdCBleGlzdCwg YW5kIENsaWVudHMNCiBhcmUgZ29pbmcgdG8gZGlzcmVnYXJkIG91ciBwcmVzY3JpYmVkIHVzZXMg YW55d2F5IChlLmcuLCBieSBzZW5kaW5nIGEg4oCccXJjb2Rl4oCdIFVSSSBpbiBhbiBTTVMpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hl cik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vYXdz LmFtYXpvbi5jb20vaWRlbnRpdHkvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwNTYzQzEiPmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvPC9zcGFuPjwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkRpY2sgSGFy ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNk YXksIEZlYnJ1YXJ5IDIwLCAyMDIwIGF0IDM6MTMgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1Jp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1R4YXV0aF0gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDox LjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCk9uIFRodSwgRmViIDIwLCAyMDIwIGF0IDEy OjIxIFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlLCBEaWNr ISBJ4oCZbSBnb2luZyB0byBjb25maW5lIG15IGNvbW1lbnRzIGhlcmUgdG8gaW50ZXJhY3Rpb24g bW9kZSBkZXNpZ24sIHNldHRpbmcgYXNpZGUgd2hldGhlciBvciBub3Qgd2UgbmVlZCDigJxwb3B1 cOKAnS4gOkQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDoxLjBpbiI+DQpPbmNlIHRoZSBHUyBoYW5kcyB0aGF0IFVSSSBiYWNrIHRvIHRo ZSBDbGllbnQsIGl0IGhhcyB6ZXJvIGNvbnRyb2wgb3ZlciBob3cgdGhlIENsaWVudCB1c2VzIGl0 LiBUaGUgQ2xpZW50IGNvdWxkIHByZXNlbnQgYW55IFVSSSAob2YgYSByZWFzb25hYmxlIHNpemUp IGludG8gYSBRUiBjb2RlLCBvciBwcmVzZW50IGl0IGFzIGEgY2xpY2thYmxlIGxpbmssIG9yIHJl ZGlyZWN0IHRvIGl0LCBvciBvcGVuIGl0IGluIGFuIGV4dGVybmFsIGJyb3dzZXIsDQogb3IgZG8g YW55IG51bWJlciBvZiBvdGhlciBhcy15ZXQtbm90LWludmVudGVkIHRoaW5ncyB3aXRoIGl0LiBN b3Jlb3ZlciwgdGhlIENsaWVudCBtYXkgbm90IGtub3cgeWV0IHdoYXQgaXQgd2FudHMgdG8gZG8g d2l0aCBpdC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MS4waW4iPg0KV2h5IHdvdWxkIHRoZSBDbGllbnQgbm90IGtub3cgd2hhdCBpdCB3 YW50cyB0byBkbyB3aXRoIGl0PyBXaGF0IHdvdWxkIGNoYW5nZSBiZXR3ZWVuIHdoZW4gdGhlIENs aWVudCBjYWxsZWQgdGhlIEdTLCBhbmQgdGhlIEdTIHJlc3BvbmRlZD88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjEuMGluIj4NCkkgdGhpbmsgb2YgdGhlIGludGVyYWN0aW9uIGJlaW5nIHRoZSBDbGllbnQgc2F5 aW5nICZxdW90O0kgd2FudCB0byBkbyBhIHJlZGlyZWN0JnF1b3Q7LCBhbmQgdGhlIEdTIHNheXMs ICZxdW90O29rLCBoZXJlIGlzIHRoZSBVUkkmcXVvdDsuIE9yIHRoZSBDbGllbnQgc2F5cywgJnF1 b3Q7SSB3YW50IHRvIHNob3cgb25seSBhIGNvZGUgYW5kIGEgVVJJJnF1b3Q7LCBhbmQgdGhlIEdT IHNheXMgJnF1b3Q7b2ssIGhlcmUgaXMgYSBnb29kLCBhbmQgYW4gZWFzeSB0byByZWFkIFVSSSBm b3IgdGhlIHVzZXIgdG8gdHlwZQ0KIGluIGFuZCBuYXZpZ2F0ZSB0by48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCkkgdW5kZXJzdGFuZCB0aGVyZSBhcmUgaW50ZXJhY3Rp b25zIHRoYXQgbWF5IG5vdCB5ZXQgYmVlbiBpbnZlbnRlZCB5ZXQuIE1vcmUgb24gdGhhdCBmdXJ0 aGVyIGRvd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NClNvIHdo YXQgdmFsdWUgaXMgdGhlcmUgaW4gZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiDigJxJIHdhbnQgYSBV UkkgZm9yIGEgcmVkaXJlY3TigJ0gdnMuIOKAnEkgd2FudCBhIFVSSSBmb3IgYSBRUiBjb2Rl4oCd IHZzLiDigJxJIHdhbnQgYSBVUkkgZm9yICZsdDtzb21lIG90aGVyIG1hY2hpbmUtZHJpdmVuIGlu dGVyYWN0aW9uIG1vZGUmZ3Q74oCdPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCkV2ZW4gaWYgd2UgY29uc2lkZXIgdGhp bmdzIGxpa2UgUVIgY29kZSBkYXRhIGNhcGFjaXR5LCB0aGF04oCZcyByZWFsbHkganVzdCBhIFVS SSBsZW5ndGggbGltaXRhdGlvbiwgd2hpY2ggY291bGQgYXBwbHkgdG8gbm9uLVFSIGludGVyYWN0 aW9uIG1vZGVzLCBlLmcuLCBpZiB0aGUgQ2xpZW50IGRldmljZSB3YW50cyB0byBjb21tdW5pY2F0 ZSB0aGUgVVJJIG92ZXIgYW4gZXh0cmVtZWx5IGJhbmR3aWR0aC1jb25zdHJhaW5lZCBjaGFubmVs Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQpJIGRvbid0IHVuZGVyc3RhbmQgd2hlbiB0aGlzIHdvdWxkIGJlIHRoZSBjYXNl LiBJZiB0aGUgQ2xpZW50IGlzIGdvaW5nIHRvIGRvIGEgcmVkaXJlY3QsIHRoZW4gdGhlIFVSSSBs ZW5ndGggaXMgbm90IHNpZ25pZmljYW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0 OjQuLjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQpBbmQgaXTigJlzIG5vdCBjbGVhciB0byBtZSBob3cgaW5jbHVkaW5nIGEgVVJJ IGxlbmd0aCBsaW1pdGF0aW9uIGluIHRoZSByZXF1ZXN0IGhlbHBzLiBJZiBhIEdTIGlzIGNhcGFi bGUgb2YgZ2VuZXJhdGluZyBhIHNob3J0ZXIgVVJJLCB3aHkgd291bGRu4oCZdCBpdCBhbHdheXMg cmV0dXJuIHRoYXQ/DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjEuMGluIj4NClRoZXJlIG1heSBiZSBhIHZhcmlldHkgb2YgcmVhc29ucyB0 aGF0IGEgR1MgbWF5IHdhbnQgdG8gcHJvdmlkZSBhIGRpZmZlcmVudCBVUkkgZm9yIGEgUVIgY29k ZSB0aGFuIGEgcmVkaXJlY3QsIG9yIGV2ZW4gYSBwb3B1cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDoxLjBpbiI+DQoxKSBQZXJoYXBzIHRoZSBHUyBoYXMgb25seSBiZWVuIHN1cHBv cnRpbmcgcmVkaXJlY3RzLCBhbmQgaGFzIGEgdmVyeSBsb25nIFVSTC4gVGhleSBhZGQgc3VwcG9y dCBmb3IgYSBRUiBjb2RlLCBhbmQgdXNlIGEgM1Agc2VydmljZSB0aGF0IHJlZGlyZWN0cyBmcm9t IHRoZSBzaG9ydCBVUkwgdXNlZCBpbiB0aGUgUVIgY29kZSwgdGhlIHRoZSBsb25nIFVSTC4gVGhl eSBkb24ndCB3YW50IHRvIHBheSBmb3IgdGhlIDNQIHNlcnZpY2UgYW55bW9yZSB0aGFuDQogdGhl eSBoYXZlIHRvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCjIpIFRo ZSBHUyB3YW50cyB0aGUgUVIgY29kZSBhbmQgdXNlciBjb2RlIGZsb3dzIHRvIGdvIHRocm91Z2gg dGhlIHNhbWUgbWFjaGluZXJ5IHRoYXQgbG9va3MgdXAgdGhlIGNvZGUgdG8gZmluZCB0aGUgR3Jh bnQuIFRoZSBVUkkgaW4gYSByZWRpcmVjdCBoYXMgdGhlIGdyYW50IGVtYmVkZGVkIGluIHRoZSBV UkkuIFRoZXkgZG9uJ3Qgd2FudCB0byBoYXZlIHRvIHVzZSB0aGUgY29kZSB0byBHcmFudCBtYWNo aW5lcnkgZm9yIGFsbCBVUklzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu Ij4NCjMpIEEgUVIgY29kZSBmbG93IHdpbGwgdXN1YWxseSBiZSBkb25lIG9uIGEgcGhvbmUsIGFu ZCB0aGUgR1Mgd2FudHMgdG8gYXR0ZW1wdCB0byBsYXVuY2ggYSBuYXRpdmUgYXBwIGluIHNvbWUg d2F5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCldoaWxlIHlvdSBh cmUgY29ycmVjdCwgd2UgY291bGQgbWFrZSBhbGwgVVJJcyBiZSBzaG9ydCBlbm91Z2ggdGhhdCB0 aGV5IGNhbiBiZSBlYXNpbHkgc2Nhbm5lZCwgd2h5IGZvcmNlIHRoYXQgb24gaW1wbGVtZW50b3Jz PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NClRoZSBVUkkg bGVuZ3RoIGxpbWl0YXRpb24gY29uY2VwdCB3YXMgZm9yIHRoZSBkaXNwbGF5X3VyaSBzbyB0aGF0 IGEgY29uc3RyYWluZWQgZGV2aWNlIGhhcyBhbiB1cHBlciBsaW1pdC4gQSBzaW1pbGFyIHVwcGVy IGxpbWl0IG9uIFFSIGNvZGUgd291bGQgYWxsb3cgYSBjb25zdHJhaW5lZCBkZXZpY2UgdG8ga25v dyB0aGUgcGl4ZWwgcmVzb2x1dGlvbiBpdCBuZWVkcyB0byBzaG93IHRoZSBRUiBjb2RlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjQuLjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpPbiB0aGUgY2xpZW50IHNpZGUs IGl0IGNhbiBsb29rIGF0IHRoZSBsZW5ndGggb2YgdGhlIFVSSSBwcm92aWRlZCBhbmQgZGVjaWRl IHdoYXQgdG8gZG8gd2l0aCBpdCAoZS5nLiwgcmVuZGVyIGEgUVIgY29kZSBvciBkaXNwbGF5IGl0 IG9yIGRvIG5vdGhpbmcgd2l0aCBpdCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDox LjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpQZXIgYWJvdmUsIHdoeSB3b3VsZCB0aGUg Q2xpZW50IG5vdCBhbHJlYWR5IGtub3cgd2hhdCBleHBlcmllbmNlIGl0IHdhbnRzIHRvIHByZXNl bnQgdG8gdGhlIFVzZXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K QSBVUkkgdG8gYmUgZGlzcGxheWVkLCBhbmQgYSBVUkkgdG8gYmUgcmVkaXJlY3RlZCB0byBhcmUg bGlrZWx5IGdvaW5nIHRvIGJlIHF1aXRlIGRpZmZlcmVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpUaGUgVVJJIGZvciBhIFVzZXIgdG8gZW50ZXIgYSBj b2RlIHdpbGwgbGlrZWx5IGJlIGEgc3RhdGljIHZhbHVlIHRoYXQgaXMgZWFzeSB0byB0eXBlLiBU aGUgVXNlciB3aWxsIGxpa2VseSBoYXZlIHRvIGF1dGhlbnRpY2F0ZSBhdCB0aGF0IHBhZ2UsIGFu ZCB0aGVuIGJlIHByb21wdGVkIHRvIGVudGVyIHRoZSBjb2RlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0O21hcmdpbi1sZWZ0OjQuLjhwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpTbyB0aGF0IHJlYWxseSBsZWF2 ZXMgdXMgd2l0aCB0d28gaW50ZXJhY3Rpb24gbW9kZXMgdGhhdCB3ZSBuZWVkOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW03MTg2MzM0ODUwODI4ODYwNjQ4Z21haWwtbTg0NTYyNDc5 NTExODMwNjQ4NjVtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW4iPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+4oCcdXJp4oCdLCB3aGljaCByZXR1cm5zIGEgZnVsbCBVUkkgdGhhdCBtYXkgbm90IGJlIGh1 bWFuIGZyaWVuZGx5OyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE4NjMz NDg1MDgyODg2MDY0OGdtYWlsLW04NDU2MjQ3OTUxMTgzMDY0ODY1bXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPuKAnGNvZGXigJ0sIHdoaWNoIHJldHVybnMg YSBjb2RlIGFuZCBVUkkgZm9yIGEgY29kZSBlbnRyeSBwYWdlLCBib3RoIG9mIHdoaWNoIGFyZSBo dW1hbi1mcmllbmRseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpUaG9zZSBjb3VsZCBiZSBjb21iaW5hYmxlIHRvIGdl dCBib3RoLCBhbmQgZXZlbiBpZiB3ZSBkb27igJl0IGdvIGRvd24gdGhlIG11bHRpcGxlIGludGVy YWN0aW9uIG1vZGUgcm91dGUgd2UgY291bGQgYWRkIHRoZSBmdWxsIFVSSSB0byB0aGUg4oCcY29k ZeKAnSBpbnRlcmFjdGlvbiBvYmplY3QuIEl0IHdvdWxkbuKAmXQgaHVydCBhbnl0aGluZyB0byBk byBzby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluIj4NCkluIHRoZSBsYXRlc3QgdmVyc2lvbiwgSSBnYXZlIGVhY2ggVVJJIGl0cyBv d24gbmFtZSBzbyB0aGF0IHRoZSBHUyBjYW4gYmUgY2xlYXIgYWJvdXQgaG93IGl0IHdpbGwgYmUg dXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpXaGlsZSB3ZSBj b3VsZCBzcXVlZXplIGFsbCB0aGUgZnVuY3Rpb25hbGl0eSBpbnRvIGEgY291cGxlIHBhcmFtZXRl cnMsIEkgdGhpbmsgaXQgbWFrZXMgaXQgaGFyZGVyIGZvciBleGlzdGluZyBkZXBsb3ltZW50cyB0 byBtaWdyYXRlIHRvIHRoZSBwcm90b2NvbC4gSSB0aGluayB3ZSBzaG91bGQgbWFrZSBpdCBlYXN5 IGZvciBkZXZlbG9wZXJzIHRvIHRha2Ugd2hhdCB0aGV5IGFscmVhZHkgaGF2ZSBhbmQgdXNlIGl0 IHdpdGggWEF1dGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0Kd3J0 LiBub3QteWV0LWludmVudGVkIGludGVyYWN0aW9ucy4gVGhlc2UgaW50ZXJhY3Rpb25zIGFyZSBm b3Igbm90LXlldC1kZXNjcmliZWQgdXNlIGNhc2VzLiAoaWYgb3RoZXIgdXNlIGNhc2VzIGV4aXN0 LCB0aGVuIGxldCdzIGxvb2sgYXQgdGhlbSBhbmQgYWRkIHRoZSBpbnRlcmFjdGlvbiBtZWNoYW5p c21zIGlmIG5lZWRlZCkgV2UgZG9uJ3Qga25vdyB3aGF0IHBhcmFtZXRlcnMgd2lsbCBiZSBuZWVk ZWQsIGFuZCBvdmVybG9hZGluZyB0aGUgcGFyYW1ldGVycw0KIGFuZCBsZXR0aW5nIHRoZSBDbGll bnQgZG8gd2hhdGV2ZXIgaXQgd2FudHMgZG9lcyBub3Qgc2VlbSBsaWtlIGl0IHdpbGwgaW50ZXJv cGVyYXRlIC0tIHRoZSBDbGllbnQgZGVjaWRlcyBpdCB3YW50cyB0byBkbyBzb21lIG5ldyBpbnRl cmFjdGlvbiwgYW5kIHVzZXMgdGhlIHBhcmFtZXRlcnMgaW4gYSB3YXkgdGhlIEdTIGRvZXMgbm90 IHVuZGVyc3RhbmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxl ZnQ6NC4uOHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+4oCTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUg QmFja21hbiAoc2hlL2hlcik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkFXUyBJZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEg aHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0 eS88L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuNWluIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5UeGF1dGggJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+VHVlc2RheSwgRmVicnVhcnkgMTgsIDIwMjAgYXQgNjowNCBQTTxicj4NCjxi PlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5bVHhhdXRoXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuNWlu Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjEuNWluIj4NCkFkZGVkIGluIHVzZXIgY29kZSBpbnRlcmFjdGlv biBhbmQgYWxpZ25lZCBRUiBjb2RlIHRvIGJlIGEgc3VwZXJzZXQgb2YgdXNlciBjb2RlLg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEu NWluIj4NCkZpeGVkIGRlc2NyaXB0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDoxLjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuNWlu Ij4NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0 OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IFR1ZSwgRmViIDE4 LCAyMDIwIGF0IDY6MDAgUE08YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzLnR4dDxicj4NClRvOiBEaWNrIEhhcmR0 ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDoxLjVpbiI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDMudHh0PGJyPg0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEaWNrIEhhcmR0IGFuZCBwb3N0ZWQg dG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbDxi cj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAzPGJyPg0KVGl0bGU6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgWEF1dGggUHJvdG9jb2w8YnI+DQpE b2N1bWVudCBkYXRlOiZuYnNwOyAyMDIwLTAyLTE4PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDUzPGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1o YXJkdC14YXV0aC1wcm90b2NvbC0wMy50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC88L2E+ PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRo LXByb3RvY29sLTAzPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGFy ZHQteGF1dGgtcHJvdG9jb2wiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLi5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbDwvYT48YnI+DQpEaWZm OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTAz IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWhhcmR0LXhhdXRoLXByb3RvY29sLTAzPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZu YnNwOyAmbmJzcDtDbGllbnQgc29mdHdhcmUgb2Z0ZW4gZGVzaXJlcyByZXNvdXJjZXMgb3IgaWRl bnRpdHkgY2xhaW1zIHRoYXQgYXJlPGJyPg0KJm5ic3A7ICZuYnNwO2luZGVwZW5kZW50IG9mIHRo ZSBjbGllbnQuJm5ic3A7IFRoaXMgcHJvdG9jb2wgYWxsb3dzIGEgdXNlciBhbmQvb3I8YnI+DQom bmJzcDsgJm5ic3A7cmVzb3VyY2Ugb3duZXIgdG8gZGVsZWdhdGUgcmVzb3VyY2UgYXV0aG9yaXph dGlvbiBhbmQvb3IgcmVsZWFzZSBvZjxicj4NCiZuYnNwOyAmbmJzcDtpZGVudGl0eSBjbGFpbXMg dG8gYSBzZXJ2ZXIuJm5ic3A7IENsaWVudCBzb2Z0d2FyZSBjYW4gdGhlbiByZXF1ZXN0IGFjY2Vz czxicj4NCiZuYnNwOyAmbmJzcDt0byByZXNvdXJjZXMgYW5kL29yIGlkZW50aXR5IGNsYWltcyBi eSBjYWxsaW5nIHRoZSBzZXJ2ZXIuJm5ic3A7IFRoZTxicj4NCiZuYnNwOyAmbmJzcDtzZXJ2ZXIg YWNxdWlyZXMgY29uc2VudCBhbmQgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSB1c2VyIGFuZC9vcjxi cj4NCiZuYnNwOyAmbmJzcDtyZXNvdXJjZSBvd25lciBpZiByZXF1aXJlZCwgYW5kIHRoZW4gcmV0 dXJucyB0byB0aGUgY2xpZW50IHNvZnR3YXJlPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBhdXRob3Jp emF0aW9uIGFuZCBpZGVudGl0eSBjbGFpbXMgdGhhdCB3ZXJlIGFwcHJvdmVkLiZuYnNwOyBUaGlz PGJyPg0KJm5ic3A7ICZuYnNwO3Byb3RvY29sIGNhbiBiZSBleHRlbmRlZCB0byBzdXBwb3J0IGFs dGVybmF0aXZlIGF1dGhvcml6YXRpb25zLDxicj4NCiZuYnNwOyAmbmJzcDtjbGFpbXMsIGludGVy YWN0aW9ucywgYW5kIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4N Cjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuNWlu Ij4NCjxpbWcgYm9yZGVyPSIwIiBpZD0iZ21haWwtbV83MTg2MzM0ODUwODI4ODYwNjQ4Z21haWwt bV84NDU2MjQ3OTUxMTgzMDY0ODY1X3gwMDVmX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFp bGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIw JTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTUzM2U1MTE2LTZlMjEtNGE5MC1hMWM5 LWJhN2Q4NzBhODdjOSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_72D44F536AB743C8A337623B31FB584Bamazoncom_-- From nobody Tue Feb 25 07:38:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309633A0F1C for ; Tue, 25 Feb 2020 07:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 gXT_y6p8x1TC for ; Tue, 25 Feb 2020 07:38:49 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 026E93A0F17 for ; Tue, 25 Feb 2020 07:38:48 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01PFcafB032127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 10:38:37 -0500 From: Justin Richer Message-Id: <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DFBD6777-26E1-4FF9-94D6-87F946251D96" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Feb 2020 10:38:36 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" To: Dick Hardt References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 15:38:52 -0000 --Apple-Mail=_DFBD6777-26E1-4FF9-94D6-87F946251D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s good enough for the AS, but is it good enough for the = client? The hash allows the client to make sure that the reference = they=E2=80=99re getting back in the front channel is related to = something they sent out in the first place. We originally had a = =E2=80=9Cstate=E2=80=9D parameter like OAuth 2 for this purpose, but = realized that since the client can push its callback URI we didn=E2=80=99t= need that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80= =9D and =E2=80=9Cc_hash=E2=80=9D have in OIDC, we added this simple hash = parameter that the client can check before it calls the TX endpoint = again. =E2=80=94 Justin > On Feb 21, 2020, at 8:12 PM, Dick Hardt wrote: >=20 >=20 > The Client presents the interact_ref to the AS with the transaction = handle. The AS will be able to tell the Client if the interact_ref = belongs to the transaction. >=20 > Why is that enough? > =E1=90=A7 >=20 > On Fri, Feb 21, 2020 at 1:51 PM Justin Richer > wrote: > The hash offers the same kinds of protections to the client that the = OIDC nonce does =E2=80=94 it binds the front channel return to something = you get from the back channel.=20 >=20 > In other words, the client can be sure that the return value that = it=E2=80=99s getting is related to the request it made in the first = place, and not another one. Clients using per-request redirect URIs can = also help with this, but this is something that the server can provide = directly. >=20 > =E2=80=94 Justin >=20 >> On Feb 21, 2020, at 4:14 PM, Dick Hardt > wrote: >>=20 >> While I can see the value of the interact_ref (aka interaction_ref) = in the return URI that allows the Client to ensure the user that started = the transaction is the same one that interacted at the AS, I don't = understand why a hash is required. Would you elaborate? >> =E1=90=A7 >>=20 >> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer > wrote: >> But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, = which is a very common case. For cases where the client doesn=E2=80=99t = expect the user to come back on the same channel, then they don=E2=80=99t = use the callback mechanism. They might use the =E2=80=9Cfinish = message=E2=80=9D URL that Annabelle mentioned in the other thread, or = they might just print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at = the AS, which is common today. >>=20 >> XYZ=E2=80=99s interaction structure allows the composition of these = things, under the control of the client. This is exactly why it=E2=80=99s = important to be able to specify how to get to the AS and how to get back = as separate items, so that the client can compose the combination that = makes the most sense for that client. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Feb 21, 2020, at 3:52 PM, Dick Hardt > wrote: >>>=20 >>> I got ahead of myself. A completion URI protects the User only if = the User is sent back to the same channel the transaction started so the = Client can confirm it is the same User that started the transaction. >>>=20 >>> so this does not help the security: >>>=20 >>> "Being able to provide a completion URI even if the user is starting = on a device is a great insight on how to address the threat above." >>>=20 >>> =E1=90=A7 >>>=20 >>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt > wrote: >>> The lightbulb finally clicked on for me. Thanks for your patience. >>>=20 >>> The threat you are describing is where the attacker starts a = transaction at the client, and gets the victim to complete it. Correct? >>>=20 >>> I still think the Client should be able to signal if it will be = doing a redirect vs showing a QR code (or wants to do both). >>>=20 >>> Being able to provide a completion URI even if the user is starting = on a device is a great insight on how to address the threat above.=20 >>>=20 >>> I'm going to ponder how to align XAuth more with these features of = XYZ. >>> =E1=90=A7 >>>=20 >>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer > wrote: >>> On Feb 21, 2020, at 1:54 PM, Dick Hardt > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer > wrote: >>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we = realized that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we have: >>>>=20 >>>> This sentence looks to be missing something. >>>=20 >>> Apologies: We realized they both used AS-composed URLs to get the = user to the AS in a web browser for interaction purposes. >>>=20 >>>> =20 >>>>=20 >>>> - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) >>>>=20 >>>> As stated in this thread, it may be useful for the AS to know if = the URL will be in a QR code, or in a full redirect. >>>>=20 >>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a = Client has to do, so it needs to know the difference between a popup, = and a full browser redirect. This is targetted at SPAs, where an = additional URL to redirect to is extra work. >>>> =20 >>>> - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) >>>> - callback: tells the AS that the client can receive the = completion message from a front channel interaction through a redirect. = Note that the client might have gotten to the AS through a redirect = on-device, through a QR-code off device, or through some other magic, = and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s = only concerned with how to get the user :back:. >>>>=20 >>>> In a full redirect, the Client wants the AS to send the user back = so that it can continue. >>>>=20 >>>> The only parameter in the completion message is the nonce, which = seems superfluous. See below. >>>> =20 >>>>=20 >>>> These three can be combined in different ways depending on what you = want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= >>>>=20 >>>> On top of that, they can be combined with other methods. Maybe I = can send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. >>>>=20 >>>> Per my question later in this thread, why would the Client not know = what interaction it wants prior to the request? >>>=20 >>> What do you mean? The client does know what it wants and that=E2=80=99= s why it=E2=80=99s asking for what it wants. We=E2=80=99re debating = different methods for the client to ask for what it wants. This question = does not make sense to me. >>>=20 >>>>=20 >>>> If the AS is doing CIBA, that is not a decision just for the = Client. Both the AS and the Client need to know they are doing CIBA. = (FWIW: I think this work supersedes CIBA) >>>=20 >>> As I=E2=80=99ve stated previously, I believe the interaction methods = here can supersede CIBA. >>>=20 >>>>=20 >>>> Additionally, different interactions have different risk profiles. = Sophisticated ASes will use that signal in the risk assessment, and may = do ask for additional authentication or verification. >>>> =20 >>>=20 >>> Yes, exactly my point. Because different interactions have different = risks, the AS will need to be able to decide which interactions it=E2=80=99= s OK with for a given request. This could vary based on what=E2=80=99s = being requested, or who=E2=80=99s doing the requesting. >>>=20 >>>>=20 >>>> An interesting difference between XYZ and XAuth=E2=80=99s = approaches is that XYZ keeps the concept of the =E2=80=9Cauthorization = code=E2=80=9D in the callback response (which in turn is based on the = OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an = =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of = nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and = the back channel response for a given transaction =E2=80=94 and note = that I=E2=80=99m really open to having a better way to generate and = calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it. >>>>=20 >>>> XAuth has removed the authorization code concept in its redirect = return, and clients only do polling against the GS API in order to get = tokens. While I obviously think it=E2=80=99s very valuable to remove = things from the front channel, I don=E2=80=99t think this is something = we can remove without opening up attack surfaces that have already been = identified in previous protocols. I would like to understand why XAuth = is not susceptible to the same kinds of attacks, or if it is, what = mitigations there are for them.=20 >>>>=20 >>>> Unlike OAuth 2.0, there are no parameters in the front channel = response to the Client. The redirect back to the Client is only needed = to return the interaction back to the Client. >>>=20 >>> This argument rings tautologically hollow =E2=80=94 there are no = parameters because you=E2=80=99ve defined that there aren=E2=80=99t any = in XAuth. XYZ does have parameters, to tie the front and back channel = requests together when doing redirect back and forth. >>>=20 >>> If you=E2=80=99re not doing a redirect back (ie, not sending a = =E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a = polling mechanism like XAuth, the device flow, etc. There are very real = risks to this. >>>=20 >>>>=20 >>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>>>=20 >>>> In OAuth, the AS gives a code to the User to give to the Client = that the Client then gives to the GS. >>>>=20 >>>> In XAuth, the AS gives a "code" to the Client that givers it to the = User to give to the GS. >>>>=20 >>>> In XAuth, the "code" is either a user code, or something embedded = in the URI the User is redirected to. >>>>=20 >>>> Therefore, there is nothing to protect in the redirect back to the = Client. >>>>=20 >>>> If I'm missing an attack, please elaborate how it would happen. >>>=20 >>> One form of impersonation is well documented: = https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7592= 50a0e7 = >>>=20 >>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar = request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, = etc, and it=E2=80=99s susceptible to the same kind of issue. >>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = > wrote: >>>>>=20 >>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my = comments here to interaction mode design, setting aside whether or not = we need =E2=80=9Cpopup=E2=80=9D. :D >>>>> =20 >>>>> Once the GS hands that URI back to the Client, it has zero control = over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of = other as-yet-not-invented things with it. Moreover, the Client may not = know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for =E2=80=9D? >>>>> =20 >>>>> Even if we consider things like QR code data capacity, that=E2=80=99= s really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. And it=E2=80=99s = not clear to me how including a URI length limitation in the request = helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99= t it always return that? On the client side, it can look at the length = of the URI provided and decide what to do with it (e.g., render a QR = code or display it or do nothing with it). >>>>> =20 >>>>> So that really leaves us with two interaction modes that we need: >>>>> =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be = human friendly; and >>>>> =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code = entry page, both of which are human-friendly. >>>>> =20 >>>>> Those could be combinable to get both, and even if we don=E2=80=99t = go down the multiple interaction mode route we could add the full URI to = the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt = anything to do so. >>>>> =20 >>>>> =E2=80=93 >>>>> Annabelle Backman (she/her) >>>>> AWS Identity >>>>> https://aws.amazon.com/identity/ = >>>>> =20 >>>>> =20 >>>>> From: Txauth > on behalf of Dick Hardt = > >>>>> Date: Tuesday, February 18, 2020 at 6:04 PM >>>>> To: "txauth@ietf.org " > >>>>> Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>>>> =20 >>>>> Added in user code interaction and aligned QR code to be a = superset of user code. >>>>> Fixed descriptions. >>>>> =20 >>>>>=20 >>>>> ---------- Forwarded message --------- >>>>> From: > >>>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>>> Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>>>> To: Dick Hardt > >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>>> has been successfully submitted by Dick Hardt and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-hardt-xauth-protocol >>>>> Revision: 03 >>>>> Title: The XAuth Protocol >>>>> Document date: 2020-02-18 >>>>> Group: Individual Submission >>>>> Pages: 53 >>>>> URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = >>>>> Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = >>>>> Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = >>>>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = >>>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >>>>>=20 >>>>> Abstract: >>>>> Client software often desires resources or identity claims that = are >>>>> independent of the client. This protocol allows a user and/or >>>>> resource owner to delegate resource authorization and/or = release of >>>>> identity claims to a server. Client software can then request = access >>>>> to resources and/or identity claims by calling the server. The >>>>> server acquires consent and authorization from the user and/or >>>>> resource owner if required, and then returns to the client = software >>>>> the authorization and identity claims that were approved. This >>>>> protocol can be extended to support alternative authorizations, >>>>> claims, interactions, and client authentication mechanisms. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org . >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>> =E1=90=A7 >>>>> --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>=20 >=20 --Apple-Mail=_DFBD6777-26E1-4FF9-94D6-87F946251D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s good enough for the AS, but is it good enough = for the client? The hash allows the client to make sure that the = reference they=E2=80=99re getting back in the front channel is related = to something they sent out in the first place. We originally had a = =E2=80=9Cstate=E2=80=9D parameter like OAuth 2 for this purpose, but = realized that since the client can push its callback URI we didn=E2=80=99t= need that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80= =9D and =E2=80=9Cc_hash=E2=80=9D have in OIDC, we added this simple hash = parameter that the client can check before it calls the TX endpoint = again.

 =E2=80=94= Justin

On Feb 21, 2020, at 8:12 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:


The Client presents the interact_ref to = the AS with the transaction handle. The AS will be able to tell the = Client if the interact_ref belongs to the transaction.

Why is that = enough?
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
The hash offers the same kinds of protections to = the client that the OIDC nonce does =E2=80=94 it binds the front channel = return to something you get from the back channel. 

In other words, the = client can be sure that the return value that it=E2=80=99s getting is = related to the request it made in the first place, and not another one. = Clients using per-request redirect URIs can also help with this, but = this is something that the server can provide directly.

 =E2=80=94 = Justin

On Feb 21, 2020, at 4:14 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

While I can see the value of the = interact_ref (aka interaction_ref) in the return URI that allows the = Client to ensure the user that started the transaction is the same one = that interacted at the AS, I don't understand why a hash is required. = Would you elaborate?
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
But that=E2=80=99s = exactly the point =E2=80=94 it helps in that case, which is a very = common case. For cases where the client doesn=E2=80=99t expect the user = to come back on the same channel, then they don=E2=80=99t use the = callback mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D = URL that Annabelle mentioned in the other thread, or they might just = print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is = common today.

XYZ=E2=80= =99s interaction structure allows the composition of these things, under = the control of the client. This is exactly why it=E2=80=99s important to = be able to specify how to get to the AS and how to get back as separate = items, so that the client can compose the combination that makes the = most sense for that client.

 =E2=80=94 Justin


On Feb 21, 2020, at 3:52 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

I got ahead of myself. A = completion URI protects the User only if the User is sent back to the = same channel the transaction started so the Client can confirm it is the = same User that started the transaction.

so this does not help the = security:

"Being= able to provide a completion URI even if the user is starting on a = device is a great insight on how to address the threat above."

3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The = lightbulb finally clicked on for me. Thanks for your patience.

The threat you are = describing is where the attacker starts a transaction at the client, and = gets the victim to complete it. Correct?
I still think the Client should be = able to signal if it will be doing a redirect vs showing a QR code (or = wants to do both).

Being able to provide a completion URI even if the user is = starting on a device is a great insight on how to address the threat = above. 

I'm going to ponder how to align XAuth more with these = features of XYZ.
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at = 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Fri, Feb = 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in = complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we = have:

This= sentence looks to be missing = something.

Apologies: We realized they both used = AS-composed URLs to get the user to the AS in a web browser for = interaction purposes.

 

 - redirect: tells = the AS that the client can send the user to an arbitrary URL (and the AS = doesn=E2=80=99t care how the client gets that info to the user; could be = a redirect or an image or send a push notification to a secondary = device, we don=E2=80=99t care as long as the user shows up in a browser = at the AS =E2=80=94 so maybe this field can be renamed to be more = universally accurate)

As stated in this thread, it may be = useful for the AS to know if the URL will be in a QR code, or in a full = redirect.

In = XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has = to do, so it needs to know the difference between a popup, and a full = browser redirect. This is targetted at SPAs, where an additional URL to = redirect to is extra work.
 
 - code: tells the AS that the client can present a = short code the user can type (along with a static URL the user can get = to, maybe by typing the URL manually, but it=E2=80=99s not = dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the client can receive = the completion message from a front channel interaction through a = redirect. Note that the client might have gotten to the AS through a = redirect on-device, through a QR-code off device, or through some other = magic, and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80= =99s only concerned with how to get the user = :back:.

In a full redirect, the Client wants = the AS to send the user back so that it can continue.

The only parameter in = the completion message is the nonce, which seems superfluous. See = below.
 

These three can be = combined in different ways depending on what you want to do at the = client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style = authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain = user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code = together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D = to get the long URL and the short code not he screen at the same = time. 

On = top of that, they can be combined with other methods. Maybe I can send = the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most = sense.

Per my question later in this thread, = why would the Client not know what interaction it wants prior to the = request?

What do you mean? The client does know = what it wants and that=E2=80=99s why it=E2=80=99s asking for what it = wants. We=E2=80=99re debating different methods for the client to ask = for what it wants. This question does not make sense to me.


If the AS is doing CIBA, that is not a = decision just for the Client. Both the AS and the Client need to know = they are doing CIBA. (FWIW: I think this work supersedes = CIBA)

As I=E2=80=99ve stated previously, I = believe the interaction methods here can supersede CIBA.


Additionally, different interactions = have different risk profiles. Sophisticated ASes will use that signal in = the risk assessment, and may do ask for additional authentication or = verification.
 

Yes, exactly my point. Because = different interactions have different risks, the AS will need to be able = to decide which interactions it=E2=80=99s OK with for a given request. = This could vary based on what=E2=80=99s being requested, or who=E2=80=99s = doing the requesting.


An interesting = difference between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps = the concept of the =E2=80=9Cauthorization code=E2=80=9D in the callback = response (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2= =80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D = which is hashed along with a pair of nonces generated by the client and = the AS in the back channel. This binds the front channel response to = both the back channel request and the back channel response for a given = transaction =E2=80=94 and note that I=E2=80=99m really open to having a = better way to generate and calculate such a binding, but I think this = works. In any event, this protects the client from session fixation and = injection on the return from the front channel that it=E2=80=99s = susceptible to in a pure polling model, and the hashing approach = basically combines the security parameters of the OAuth 2 authorization = code and (to an extent) state, PKCE=E2=80=99s code_challenge, and = OIDC=E2=80=99s nonce in one element. This is only applicable if you=E2=80=99= re coming back to the client and you can validate the hash and present = the reference parameter. If you=E2=80=99re doing just plain polling, you = don=E2=80=99t have that protection =E2=80=94 but the client and the AS = are aware of that risk, and there=E2=80=99s an option to prevent = it.

XAuth has = removed the authorization code concept in its redirect return, and = clients only do polling against the GS API in order to get tokens. While = I obviously think it=E2=80=99s very valuable to remove things from the = front channel, I don=E2=80=99t think this is something we can remove = without opening up attack surfaces that have already been identified in = previous protocols. I would like to understand why XAuth is not = susceptible to the same kinds of attacks, or if it is, what mitigations = there are for them. 

Unlike OAuth 2.0, there = are no parameters in the front channel response to the Client. The = redirect back to the Client is only needed to return the interaction = back to the Client.

This argument rings = tautologically hollow =E2=80=94 there are no parameters because you=E2=80=99= ve defined that there aren=E2=80=99t any in XAuth. XYZ does have = parameters, to tie the front and back channel requests together when = doing redirect back and forth.

If you=E2=80=99re not doing a redirect = back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), = then it=E2=80=99s a polling mechanism like XAuth, the device flow, etc. = There are very real risks to this.


XAuth (and XYZ) have a different flow than OAuth 2.0 (or = OAuth 1.0)

In = OAuth, the AS gives a code to the User to give to the Client that the = Client then gives to the GS.

In XAuth, the AS gives a "code" to the = Client that givers it to the User to give to the GS.

In XAuth, the "code" is = either a user code, or something embedded in the URI the User is = redirected to.

Therefore, there is nothing to protect in the redirect back = to the Client.

If I'm missing an attack, please elaborate how it would = happen.

One form of impersonation is well = documented: https://hueniverse.com/explaining-the-oauth-session-fixation-at= tack-aa759250a0e7

OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a = similar request initiation step to what we see in XYZ, XAuth, PAR, = FAPI/OBUK, etc, and it=E2=80=99s susceptible to the same kind of = issue.

 

 =E2=80=94 = Justin

On Feb 20, 2020, at 3:21 PM, = Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

Thanks = for the update, Dick! I=E2=80=99m going to confine my comments here to = interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
 
Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for <some other machine-driven interaction mode>=E2=80=9D?
 
Even if we consider things like QR code data capacity, = that=E2=80=99s really just a URI length limitation, which could apply to = non-QR interaction modes, e.g., if the Client device wants to = communicate the URI over an extremely bandwidth-constrained channel. And = it=E2=80=99s not clear to me how including a URI length limitation in = the request helps. If a GS is capable of generating a shorter URI, why = wouldn=E2=80=99t it always return that? On the client side, it can look = at the length of the URI provided and decide what to do with it (e.g., = render a QR code or display it or do nothing with it).
 
So = that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a = code entry page, both of which are human-friendly.
 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in = user code interaction and aligned QR code to be a superset of user = code.
Fixed = descriptions.

 

----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat

=E1=90=A7
-- 
Txauth mailing = list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth





= --Apple-Mail=_DFBD6777-26E1-4FF9-94D6-87F946251D96-- From nobody Tue Feb 25 07:51:38 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D403A0CEF for ; Tue, 25 Feb 2020 07:51:36 -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, SPF_HELO_NONE=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 BrlQC2TyoIQJ for ; Tue, 25 Feb 2020 07:51:34 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 39D353A0F45 for ; Tue, 25 Feb 2020 07:51:33 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01PFpRXH004819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 10:51:27 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 25 Feb 2020 10:51:26 -0500 Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: <94125F10-6516-4504-8120-B1792C3788B3@mit.edu> References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> To: David Waite X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 15:51:37 -0000 On Feb 22, 2020, at 2:04 AM, David Waite = wrote: >=20 >=20 >=20 >> On Feb 21, 2020, at 9:38 AM, Justin Richer wrote: >>=20 > >> - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) >=20 > This is going to need a different name :-) That=E2=80=99s fair. >=20 >> - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) >> - callback: tells the AS that the client can receive the completion = message from a front channel interaction through a redirect. Note that = the client might have gotten to the AS through a redirect on-device, = through a QR-code off device, or through some other magic, and this = field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:. >=20 >>=20 >> These three can be combined in different ways depending on what you = want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= >=20 > Some implementations may have the redirect and device code + static = URL be the same URLs, but some may actually be de-optimizing for the = device cases where the user may need to type the values in by hand or to = reduce QR code complexity for scanning from across a room on a = television. Having redirect and QR code interaction URLs be the same = seems limiting in this regard. I=E2=80=99m not sure how this is limiting. I think that maybe you=E2=80=99= re misunderstanding what I=E2=80=99m referring to as a QR Code URL here. = There are two URLs in the XYZ implementation: - a static URL used with the short user-code; it can be displayed by = the client or it can be read in documentation, since it=E2=80=99s not = supposed to change - a dynamic (arbitrary) URL used for redirect and rendering QR codes = for second-device interaction The QR Code case that I=E2=80=99ve been referring to is analogous to the = OAuth 2 Device Flow=E2=80=99s =E2=80=9Ccombined=E2=80=9D URL =E2=80=94 = except that it doesn=E2=80=99t have to have anything to do with the user = code anymore, if the AS doesn=E2=80=99t want it to. All that=E2=80=99s = really important is that the AS tells the client =E2=80=9Cget the user = to this URL so I can interact with them=E2=80=9D. How the client manages = to do that isn=E2=80=99t the AS=E2=80=99s job to figure out. If a client decides to also render the static URL as a QR code, then = that=E2=80=99s fine =E2=80=94 but that=E2=80=99s not the kind of QR code = that=E2=80=99s been under discussion here. If there are size = limitations, as per the other thread, then that can be communicated, or = potentially requested alongside the long URL. >=20 > The semantics of trying to leverage the QR code and browser = redirect/callback also make me nervous w.r.t implementations, as in one = case the callback may go back to a local context (e.g. single-page web = application or native app) while the short code/QR code entry case would = have the authentication/consent and subsequent callback happen = =E2=80=9Cunsolicited=E2=80=9D on another device. >=20 > Thats not to say that these initiation and resumption aspects = couldn=E2=80=99t be split, I=E2=80=99m just concerned about these = particular lines being ambitious. This is exactly why the =E2=80=9Ccallback=E2=80=9D parameter was = separated out. If the client doesn=E2=80=99t expect the user to come = back locally, and it expects to poll, it doesn=E2=80=99t send the = =E2=80=9Ccallback=E2=80=9D field. If it expects the user to come back, = it sends one, and doesn=E2=80=99t poll. This is independent of (or at = least orthogonal to) how the user gets TO the AS in the first place. >=20 >> On top of that, they can be combined with other methods. Maybe I can = send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. >=20 > There needs to be fixed semantics for combining interaction facets, = however. Would your client send a prioritized list where the AS chooses = one that they support, or would the expectation be that you would then = need to present the user the option to continue with either a redirect = or via a QR code on another device? I don=E2=80=99t think that=E2=80=99s really true. The client knows how = it can interact with the user, and it=E2=80=99ll give the user the = options that it can handle. This is the value of having an inline = negotiation protocol. Client knows that it can do A, B, or X. So the client sends: C->AS: A, B, X The AS can do A, X, or Z. So the AS responds with: AS->C: A, X The AS doesn=E2=80=99t get to add =E2=80=9CZ=E2=80=9D to the list = because the client didn=E2=80=99t say it could handle that. The client = doesn=E2=80=99t get to present anything using =E2=80=9CB=E2=80=9D = because it didn=E2=80=99t get a response from the AS that allows it to = do so. And if there=E2=80=99s an overlap of zero between the two? Then = these are two incompatible systems and the client can=E2=80=99t interact = with the user =E2=80=94 but also keep in mind that there are MANY use = cases that don=E2=80=99t require user interaction. =E2=80=94 Justin= From nobody Tue Feb 25 15:27:11 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78073A0826 for ; Tue, 25 Feb 2020 15:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 2gZ2PzjPop51 for ; Tue, 25 Feb 2020 15:27:06 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7C84A3A0829 for ; Tue, 25 Feb 2020 15:27:05 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01PNR0Ui006687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 18:27:00 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6C732424-3796-4856-AF53-78DAEEF29984" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Feb 2020 18:26:59 -0500 In-Reply-To: <72D44F53-6AB7-43C8-A337-623B31FB584B@amazon.com> Cc: Dick Hardt , "txauth@ietf.org" To: "Richard Backman, Annabelle" References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <02197105-4C5F-41F1-8A84-8972F25C5132@amazon.com> <72D44F53-6AB7-43C8-A337-623B31FB584B@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 23:27:10 -0000 --Apple-Mail=_6C732424-3796-4856-AF53-78DAEEF29984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Another note about calling out QRCodes as separate from other URL = representations: there are a ton of different scannable formats out = there. QRCodes are among the most common, but they=E2=80=99re hardly the = only ones in use. If a client wants to use JAB or Han Xin or Data Matrix = or whatever to display the URL, it=E2=80=99s not this spec=E2=80=99s = place to say anything about it.=20 The important thing is that there=E2=80=99s a variable URL that needs to = be communicated to the user. If there are length limitations, I think = Annabelle=E2=80=99s idea of allowing the client to specifically ask for = a short URL are a good one. Calling it =E2=80=9Cqrcode=E2=80=9D presumes = way too much of the solution stack on the client=E2=80=99s part and = doesn=E2=80=99t help interoperability or flexibility. =E2=80=94 Justin > On Feb 24, 2020, at 4:18 PM, Richard Backman, Annabelle = wrote: >=20 > I think your summary is accurate, but the line between your two = reasons gets pretty blurry. The Client may not be able to detect on its = own whether its preferred method is working, so your proposal that the = Client could switch methods by making a new request would require the = end user to provide some input. For example: > If a web browser is available but the firewall blocks outbound HTTP = (not unreasonable for a server host), the Client would think that it = successfully opened the URI. > If the local browser lacks the accessibility features needed by the = end user, the Client would successfully open the URI, but it would not = be usable by the end user. > In the =E2=80=9Cshared family tablet=E2=80=9D example in my previous = email, the Client would not be aware that the end user is unable to = interact with the companion app. > =20 > So it=E2=80=99s easier for both Client and end user, and more = generally applicable if the Client can request multiple interaction = modes and present them at the same time. > =20 > If we only have a single =E2=80=9Curi=E2=80=9D parameter, the max = length in the request should be advisory. I.e., the GS SHALL return a = URI, and it SHOULD return one that meets the max length restriction if = it can. Client behavior is effectively the same as if it were treated as = a hard requirement; the only difference is that the Client code branches = based on the actual length of the URI returned (which it already needs = to check) rather than based on the presence or absence of a URI, or an = error response from the GS. Clients that can still make use of a longer = URI are saved the extra round trip to request one. > =20 > I think both =E2=80=9Curi=E2=80=9D and =E2=80=9Ccode=E2=80=9D should = be MTI, but that does not mean they are mandatory to deploy. There=E2=80=99= s lots of cases where a GS will only ever deal with specific types of = Clients such that they=E2=80=99ll always use one or the other, but in = those cases the GS is explicitly not concerned overmuch with = interoperability. > =20 > We need to be careful about defining a maximum length for the code = entry URI. Domain names cost money to register and maintain, so a = maximum length that is too low would effectively impose a monetary = barrier to deployers who have long domain names. We would also have to = make this a maximum Unicode character length with the domain name = expressed in IDN form, not ASCII form. Users of non-Western scripts = should not be penalized by the need to use Punycode. > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth > on behalf of Dick Hardt = > > Date: Friday, February 21, 2020 at 5:37 PM > To: "Richard Backman, Annabelle" > > Cc: "txauth@ietf.org " > > Subject: Re: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt > =20 > Thanks Annabelle.=20 > =20 > FYI: With the requirement to have a interact_ref value come back from = the GS to the Client, the popup and redirect are now the same -- so we = can move past the popup discussion. > =20 > To summarize your examples, > 1) the Client may need to fallback to a different method than it = initially had planned on=20 > 2) the Client may want to offer the User a broader choice of methods > =20 > (1) could be solved by the Client making a new request of the GS > =20 > (2) requires the Client to receive multiple methods so it can offer = the User a choice. > =20 > Am I following along correctly > =20 > A short URI and a long URI are functionally equivalent -- so there = does not seem to be a requirement to have both.=20 > For example, the Client may request a URI, with an optional max = length? > =20 > So that let's the Client ask for one or both of: > =20 > - a URI with an optional max length ( indicate it has a static max = length) > - a short code and code entry URI > =20 > If and when new mechanism for the Client to transfer interactions to = the GS, new parameters are defined.=20 > =20 > Q: what is MTI? > =20 > Q: Is there a minimum length of the short URI? ( think that specifying = a short URI max length will make it easier for Clients and GS as it is = not negotiated) > =20 > =20 > /Dick > =20 > =E1=90=A7 > =20 > On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle = > wrote: >> Okay, you=E2=80=99ve convinced me that there are use cases for a GS = to sometimes provide a shorter URI and sometimes a longer URI. Let=E2=80=99= s see if I can convince you that interaction mode selection is less = deterministic than you think. :D >> =20 >> I *think* the Client can be expected to know if it will transfer = interaction to the GS within the same user agent the end user is = accessing Client through. In other words, I think there are two reliably = differentiable modes: same UA (30X redirect, open in same window, open = in new), and different UA (code, QR code, opening URI in external = browser, etc.). However, within each mode, the Client may not know which = mechanism will be used. (e.g., for =E2=80=9Csame UA=E2=80=9D: will the = Client open the URI in the same window or a new one; for =E2=80=9Cdifferen= t UA=E2=80=9D: will the end user scan a QR code or enter a code or tap = on a URI in an SMS) >> =20 >> The non-determinism comes from two sources: >> 1. Environmental conditions=20 >>=20 >> a. A console app might be able to directly open a URI in the = system=E2=80=99s browser (e.g., when running in a terminal window on a = desktop), or it might not (e.g., on a headless system). The app may not = know the answer until it tries it. >>=20 >> b. That same console app might be running in a remote terminal, = such that the end user would be able to click or copy and paste a URI = printed by the app. >>=20 >> c. An SPA might be able to open a popup, or it might fail for = various reasons. It might decide to fall back to a redirect if it = detects that the popup failed to open. It might want the =E2=80=9Cpopup=E2= =80=9D to gracefully fall back to a redirect-like experience in case the = user agent only supports a single window at a time (e.g., embedded user = agents in apps like Facebook and Twitter). >>=20 >> d. Environmental conditions may make it difficult to scan a QR code = (e..g., the screen is dirty, foggy, cracked, or under direct sunlight), = but still allow for a person to read a short code. The Client likely has = no way of detecting such things. >>=20 >> 2. End user capabilities and preferences=20 >>=20 >> a. They may have a physical disability or other condition that = makes it difficult to impossible for them to scan a QR code. >>=20 >> i. = They may be capable of reading and copying a short code. >>=20 >> ii. = They may be capable of listening to and entering a short code spoken by = the device. >>=20 >> iii. = They may be capable of following a link sent to them via text or email, = which they can access on a device with greater accessibility options. >>=20 >> b. They may not have a device capable of scanning a QR code, or the = device may not be functioning, or the device may be the one that the = code is being displayed on. >>=20 >> c. They may not know what a QR code is, or understand how to use = one. >>=20 >> d. They may want to complete the flow on a device that is incapable = of scanning the QR code (e.g., their desktop). >>=20 >> e. They may prefer to have the URI texted or emailed to them, = rather than having to scan or copy a code. >>=20 >> f. They may not have access to the companion app that the Client = transmitted the URI to (e.g., because it=E2=80=99s on the shared family = tablet, and it=E2=80=99s their sibling=E2=80=99s turn to use it). >>=20 >> =20 >> If we allow that the GS might want to issue long URIs when possible, = then there=E2=80=99s basically three things a Client might want, in any = combination: >> =C2=B7 URI, no length restriction >>=20 >> =C2=B7 URI, with some max length (e.g., because of QR code data = capacity, SMS message size limits, display constraints, etc.) >>=20 >> =C2=B7 Short code and code entry URI, both human-friendly >>=20 >> =20 >> The GS can=E2=80=99t enforce how these are used; they can only = control what they issue, and how they respond when interaction is = transferred to them. Defining interaction object properties in terms of = usage implies constraints and guarantees that don=E2=80=99t exist, and = Clients are going to disregard our prescribed uses anyway (e.g., by = sending a =E2=80=9Cqrcode=E2=80=9D URI in an SMS). >> =20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> =20 >> =20 >> From: Dick Hardt > >> Date: Thursday, February 20, 2020 at 3:13 PM >> To: "Richard Backman, Annabelle" > >> Cc: "txauth@ietf.org " > >> Subject: Re: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >> =20 >> =20 >> =20 >> On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle = > wrote: >>> Thanks for the update, Dick! I=E2=80=99m going to confine my = comments here to interaction mode design, setting aside whether or not = we need =E2=80=9Cpopup=E2=80=9D. :D >>> =20 >>> Once the GS hands that URI back to the Client, it has zero control = over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or = redirect to it, or open it in an external browser, or do any number of = other as-yet-not-invented things with it. Moreover, the Client may not = know yet what it wants to do with it. >> =20 >> Why would the Client not know what it wants to do with it? What would = change between when the Client called the GS, and the GS responded? >> =20 >> I think of the interaction being the Client saying "I want to do a = redirect", and the GS says, "ok, here is the URI". Or the Client says, = "I want to show only a code and a URI", and the GS says "ok, here is a = good, and an easy to read URI for the user to type in and navigate to. >> =20 >> I understand there are interactions that may not yet been invented = yet. More on that further down. >> =20 >>> So what value is there in distinguishing between =E2=80=9CI want a = URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D= vs. =E2=80=9CI want a URI for =E2=80=9D? >>> =20 >>> Even if we consider things like QR code data capacity, that=E2=80=99s = really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. >> =20 >> I don't understand when this would be the case. If the Client is = going to do a redirect, then the URI length is not significant. >> =20 >>> And it=E2=80=99s not clear to me how including a URI length = limitation in the request helps. If a GS is capable of generating a = shorter URI, why wouldn=E2=80=99t it always return that? >> =20 >> There may be a variety of reasons that a GS may want to provide a = different URI for a QR code than a redirect, or even a popup. >> =20 >> 1) Perhaps the GS has only been supporting redirects, and has a very = long URL. They add support for a QR code, and use a 3P service that = redirects from the short URL used in the QR code, the the long URL. They = don't want to pay for the 3P service anymore than they have to. >> =20 >> 2) The GS wants the QR code and user code flows to go through the = same machinery that looks up the code to find the Grant. The URI in a = redirect has the grant embedded in the URI. They don't want to have to = use the code to Grant machinery for all URIs. >> =20 >> 3) A QR code flow will usually be done on a phone, and the GS wants = to attempt to launch a native app in some way, >> =20 >> While you are correct, we could make all URIs be short enough that = they can be easily scanned, why force that on implementors?=20 >> =20 >> The URI length limitation concept was for the display_uri so that a = constrained device has an upper limit. A similar upper limit on QR code = would allow a constrained device to know the pixel resolution it needs = to show the QR code. >> =20 >>> On the client side, it can look at the length of the URI provided = and decide what to do with it (e.g., render a QR code or display it or = do nothing with it). >> =20 >> Per above, why would the Client not already know what experience it = wants to present to the User? >> =20 >> A URI to be displayed, and a URI to be redirected to are likely going = to be quite different.=20 >> =20 >> The URI for a User to enter a code will likely be a static value that = is easy to type. The User will likely have to authenticate at that page, = and then be prompted to enter the code.=20 >> =20 >>> =20 >>> So that really leaves us with two interaction modes that we need: >>> =C2=B7 =E2=80=9Curi=E2=80=9D, which returns a full URI that may = not be human friendly; and >>>=20 >>> =C2=B7 =E2=80=9Ccode=E2=80=9D, which returns a code and URI for = a code entry page, both of which are human-friendly. >>>=20 >>> =20 >>> Those could be combinable to get both, and even if we don=E2=80=99t = go down the multiple interaction mode route we could add the full URI to = the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt = anything to do so. >> =20 >> In the latest version, I gave each URI its own name so that the GS = can be clear about how it will be used. >> =20 >> While we could squeeze all the functionality into a couple = parameters, I think it makes it harder for existing deployments to = migrate to the protocol. I think we should make it easy for developers = to take what they already have and use it with XAuth. >> =20 >> wrt. not-yet-invented interactions. These interactions are for = not-yet-described use cases. (if other use cases exist, then let's look = at them and add the interaction mechanisms if needed) We don't know what = parameters will be needed, and overloading the parameters and letting = the Client do whatever it wants does not seem like it will interoperate = -- the Client decides it wants to do some new interaction, and uses the = parameters in a way the GS does not understand. >> =20 >> =20 >> =20 >> =20 >>> =20 >>> =E2=80=93 >>> Annabelle Backman (she/her) >>> AWS Identity >>> https://aws.amazon.com/identity/ >>> =20 >>> =20 >>> From: Txauth > on behalf of Dick Hardt = > >>> Date: Tuesday, February 18, 2020 at 6:04 PM >>> To: "txauth@ietf.org " > >>> Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>> =20 >>> Added in user code interaction and aligned QR code to be a superset = of user code. >>> Fixed descriptions. >>> =20 >>>=20 >>> ---------- Forwarded message --------- >>> From: > >>> Date: Tue, Feb 18, 2020 at 6:00 PM >>> Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>> To: Dick Hardt > >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>> has been successfully submitted by Dick Hardt and posted to the >>> IETF repository. >>>=20 >>> Name: draft-hardt-xauth-protocol >>> Revision: 03 >>> Title: The XAuth Protocol >>> Document date: 2020-02-18 >>> Group: Individual Submission >>> Pages: 53 >>> URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = >>> Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = >>> Htmlized: = https://datatracker..ietf.org/doc/html/draft-hardt-xauth-protocol = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >>>=20 >>> Abstract: >>> Client software often desires resources or identity claims that = are >>> independent of the client. This protocol allows a user and/or >>> resource owner to delegate resource authorization and/or release = of >>> identity claims to a server. Client software can then request = access >>> to resources and/or identity claims by calling the server. The >>> server acquires consent and authorization from the user and/or >>> resource owner if required, and then returns to the client = software >>> the authorization and identity claims that were approved. This >>> protocol can be extended to support alternative authorizations, >>> claims, interactions, and client authentication mechanisms. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>> =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_6C732424-3796-4856-AF53-78DAEEF29984 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Another note about calling out QRCodes as separate from other = URL representations: there are a ton of different scannable formats out = there. QRCodes are among the most common, but they=E2=80=99re hardly the = only ones in use. If a client wants to use JAB or Han Xin or Data Matrix = or whatever to display the URL, it=E2=80=99s not this spec=E2=80=99s = place to say anything about it. 

The important thing is that there=E2=80=99= s a variable URL that needs to be communicated to the user. If there are = length limitations, I think Annabelle=E2=80=99s idea of allowing the = client to specifically ask for a short URL are a good one. Calling it = =E2=80=9Cqrcode=E2=80=9D presumes way too much of the solution stack on = the client=E2=80=99s part and doesn=E2=80=99t help interoperability or = flexibility.

 =E2=80=94 Justin

On Feb = 24, 2020, at 4:18 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

I think = your summary is accurate, but the line between your two reasons gets = pretty blurry. The Client may not be able to detect on its own whether = its preferred method is working, so your proposal that the Client could = switch methods by making a new request would require the end user to = provide some input. For example:
  • If a web = browser is available but the firewall blocks outbound HTTP (not = unreasonable for a server host), the Client would think that it = successfully opened the URI.
  • If the local browser lacks the = accessibility features needed by the end user, the Client would = successfully open the URI, but it would not be usable by the end = user.
  • In the =E2=80=9Cshared family tablet=E2=80=9D = example in my previous email, the Client would not be aware that the end = user is unable to interact with the companion app.
 
So it=E2=80= =99s easier for both Client and end user, and more generally applicable = if the Client can request multiple interaction modes and present them at = the same time.
 
If we only have a single =E2=80=9Curi=E2=80=9D parameter, the = max length in the request should be advisory. I.e., the GS SHALL return = a URI, and it SHOULD return one that meets the max length restriction if = it can. Client behavior is effectively the same as if it were treated as = a hard requirement; the only difference is that the Client code branches = based on the actual length of the URI returned (which it already needs = to check) rather than based on the presence or absence of a URI, or an = error response from the GS. Clients that can still make use of a longer = URI are saved the extra round trip to request one.
 
I think = both =E2=80=9Curi=E2=80=9D and =E2=80=9Ccode=E2=80=9D should be MTI, but = that does not mean they are mandatory to deploy. There=E2=80=99s lots of = cases where a GS will only ever deal with specific types of Clients such = that they=E2=80=99ll always use one or the other, but in those cases the = GS is explicitly not concerned overmuch with interoperability.
 
We need = to be careful about defining a maximum length for the code entry URI. = Domain names cost money to register and maintain, so a maximum length = that is too low would effectively impose a monetary barrier to deployers = who have long domain names. We would also have to make this a maximum = Unicode character length with the domain name expressed in IDN form, not = ASCII form. Users of non-Western scripts should not be penalized by the = need to use Punycode.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, February 21, = 2020 at 5:37 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Thanks = Annabelle. 
 
FYI: With the requirement to have a = interact_ref value come back from the GS to the Client, the popup and = redirect are now the same -- so we can move past the popup = discussion.
 
To summarize your examples,
1) the Client may need to fallback to a different method than = it initially had planned on 
2) the Client may want to offer the User a = broader choice of methods
 
(1) could be solved by the Client making a new = request of the GS
 
(2) requires the Client to receive multiple = methods so it can offer the User a choice.
 
Am I following along correctly
 
A short URI and a long URI are = functionally equivalent -- so there does not seem to be a requirement to = have both. 
For example, the Client may request a = URI, with an optional max length?
 
So that let's the Client ask for one or both = of:
 
- a URI with an = optional max length ( indicate it has a static max length)
- a short code and code entry URI
 
If and when new mechanism for the = Client to transfer interactions to the GS, new parameters are = defined. 
 
Q: what is MTI?
 
Q: Is there a minimum length of the = short URI? ( think that specifying a short URI max length will make it = easier for Clients and GS as it is not negotiated)
 
 
/Dick
 
=E1=90=A7
 
On Fri, Feb 21, 2020 at 4:46 PM Richard = Backman, Annabelle <richanna@amazon.com> wrote:
Okay, you=E2=80=99ve convinced me that = there are use cases for a GS to sometimes provide a shorter URI and = sometimes a longer URI. Let=E2=80=99s see if I can convince you that = interaction mode selection is less deterministic than you think. :D
 
I *think* the Client can be expected to know if it will = transfer interaction to the GS within the same user agent the end user = is accessing Client through. In other words, I think there are two = reliably differentiable modes: same UA (30X redirect, open in same = window, open in new), and different UA (code, QR code, opening URI in = external browser, etc.). However, within each mode, the Client may not = know which mechanism will be used. (e.g., for =E2=80=9Csame UA=E2=80=9D: = will the Client open the URI in the same window or a new one; for = =E2=80=9Cdifferent UA=E2=80=9D: will the end user scan a QR code or = enter a code or tap on a URI in an SMS)
 
The non-determinism comes from two = sources:

1.   Environmental = conditions 

a.    A console app = might be able to directly open a URI in the system=E2=80=99s browser = (e.g., when running in a terminal window on a desktop), or it might not = (e.g., on a headless system). The app may not know the answer until it = tries it.

b.   That same = console app might be running in a remote terminal, such that the end = user would be able to click or copy and paste a URI printed by the = app.

c.    An SPA might = be able to open a popup, or it might fail for various reasons. It might = decide to fall back to a redirect if it detects that the popup failed to = open. It might want the =E2=80=9Cpopup=E2=80=9D to gracefully fall back = to a redirect-like experience in case the user agent only supports a = single window at a time (e.g., embedded user agents in apps like = Facebook and Twitter).

d.   Environmental = conditions may make it difficult to scan a QR code (e..g., the screen is = dirty, foggy, cracked, or under direct sunlight), but still allow for a = person to read a short code. The Client likely has no way of detecting = such things.

2.   End user = capabilities and preferences 

a.    They may have = a physical disability or other condition that makes it difficult to = impossible for them to scan a QR code.

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;   i.      They may be capable = of reading and copying a short code.

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ; ii.      They may be capable = of listening to and entering a short code spoken by the device.

          &nb= sp;            = ;            &= nbsp;           &nb= sp;           iii.      They may be capable = of following a link sent to them via text or email, which they can = access on a device with greater accessibility options.

b.   They may not = have a device capable of scanning a QR code, or the device may not be = functioning, or the device may be the one that the code is being = displayed on.

c.    They may not = know what a QR code is, or understand how to use one.

d.   They may want = to complete the flow on a device that is incapable of scanning the QR = code (e.g., their desktop).

e.    They may = prefer to have the URI texted or emailed to them, rather than having to = scan or copy a code.

f.     They may not = have access to the companion app that the Client transmitted the URI to = (e.g., because it=E2=80=99s on the shared family tablet, and it=E2=80=99s = their sibling=E2=80=99s turn to use it).

 
If we allow that the GS might want to = issue long URIs when possible, then there=E2=80=99s basically three = things a Client might want, in any combination:

=C2=B7      URI, = no length restriction

=C2=B7      URI, = with some max length (e.g., because of QR code data capacity, SMS = message size limits, display constraints, etc.)

=C2=B7      Short = code and code entry URI, both human-friendly

 
The GS can=E2=80=99t enforce how these = are used; they can only control what they issue, and how they respond = when interaction is transferred to them. Defining interaction object = properties in terms of usage implies constraints and guarantees that = don=E2=80=99t exist, and Clients are going to disregard our prescribed = uses anyway (e.g., by sending a =E2=80=9Cqrcode=E2=80=9D URI in an = SMS).
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thursday, February 20, = 2020 at 3:13 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
 
 
On Thu, Feb 20, 2020 at 12:21 PM = Richard Backman, Annabelle <richanna@amazon.com> wrote:
Thanks for the update, = Dick! I=E2=80=99m going to confine my comments here to interaction mode = design, setting aside whether or not we need =E2=80=9Cpopup=E2=80=9D. = :D
 
Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it.
 
Why would the Client not know what it wants to do with it? = What would change between when the Client called the GS, and the GS = responded?
 
I think of the interaction being the = Client saying "I want to do a redirect", and the GS says, "ok, here is = the URI". Or the Client says, "I want to show only a code and a URI", = and the GS says "ok, here is a good, and an easy to read URI for the = user to type in and navigate to.
 
I understand there are interactions that may not yet been = invented yet. More on that further down.
 
So what value is there in distinguishing between =E2=80=9CI = want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR = code=E2=80=9D vs. =E2=80=9CI want a URI for <some other = machine-driven interaction mode>=E2=80=9D?
 
Even if = we consider things like QR code data capacity, that=E2=80=99s really = just a URI length limitation, which could apply to non-QR interaction = modes, e.g., if the Client device wants to communicate the URI over an = extremely bandwidth-constrained channel.
 
I don't understand when this would be the case. If the Client = is going to do a redirect, then the URI length is not significant.
 
And it=E2=80=99s not clear to me how including a URI length = limitation in the request helps. If a GS is capable of generating a = shorter URI, why wouldn=E2=80=99t it always return that?
 
There may be a variety of reasons that a GS may want to = provide a different URI for a QR code than a redirect, or even a = popup.
 
1) Perhaps the GS has only been supporting redirects, and has = a very long URL. They add support for a QR code, and use a 3P service = that redirects from the short URL used in the QR code, the the long URL. = They don't want to pay for the 3P service anymore than they have to.
 
2) The GS wants the QR code and user = code flows to go through the same machinery that looks up the code to = find the Grant. The URI in a redirect has the grant embedded in the URI. = They don't want to have to use the code to Grant machinery for all = URIs.
 
3) A QR code flow will usually be done on a phone, and the GS = wants to attempt to launch a native app in some way,
 
While you are correct, we could make = all URIs be short enough that they can be easily scanned, why force that = on implementors? 
 
The URI length limitation concept was for the display_uri so = that a constrained device has an upper limit. A similar upper limit on = QR code would allow a constrained device to know the pixel resolution it = needs to show the QR code.
 
On the client side, it can = look at the length of the URI provided and decide what to do with it = (e.g., render a QR code or display it or do nothing with it).
 
Per above, why would the Client not already know what = experience it wants to present to the User?
 
A URI to be displayed, and a URI to be = redirected to are likely going to be quite different. 
 
The URI for a User to enter a code will = likely be a static value that is easy to type. The User will likely have = to authenticate at that page, and then be prompted to enter the = code. 
 
 
So that = really leaves us with two interaction modes that we need:

=C2=B7      =E2=80=9Curi=E2=80=9D,= which returns a full URI that may not be human friendly; and

=C2=B7      =E2=80=9Ccode=E2=80=9D= , which returns a code and URI for a code entry page, both of which are = human-friendly.

 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
In the latest version, I gave each URI its own name so that = the GS can be clear about how it will be used.
 
While we could squeeze all the = functionality into a couple parameters, I think it makes it harder for = existing deployments to migrate to the protocol. I think we should make = it easy for developers to take what they already have and use it with = XAuth.
 
wrt. not-yet-invented interactions. These interactions are = for not-yet-described use cases. (if other use cases exist, then let's = look at them and add the interaction mechanisms if needed) We don't know = what parameters will be needed, and overloading the parameters and = letting the Client do whatever it wants does not seem like it will = interoperate -- the Client decides it wants to do some new interaction, = and uses the parameters in a way the GS does not understand.
 
 
 
 
 
=E2=80=93
Annabelle Backman = (she/her)
AWS = Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in user code interaction and = aligned QR code to be a superset of user code.
Fixed descriptions.

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker..ietf.org/doc/html/draft-hardt-xauth-protoc= ol
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat

=E1=90=A7
-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_6C732424-3796-4856-AF53-78DAEEF29984-- From nobody Wed Feb 26 11:40:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0063A12F3 for ; Wed, 26 Feb 2020 11:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPM1x5QNehZe for ; Wed, 26 Feb 2020 11:40:28 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 D53823A116D for ; Wed, 26 Feb 2020 11:40:27 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 01QJeQkY024861 for ; Wed, 26 Feb 2020 14:40:26 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 01QJeQkY024861 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1582746026; bh=vVIFAcj3NUo/qzXpMcZdUJsARqjJzgNEY7uK1md/+6c=; h=From:To:Subject:Date:References:In-Reply-To:From; b=BCdHLEYlzemmsiez90w6jEhkQBDg1lh8wr/SUy8h8/JvLE8zVaW4XoQeLixyim5vm LsYAFoj0xppQC3sEyGqcFGLOa0TQT8poc04eXEVAkpXX0X/V/I0n4kR4kYGqQQvLlW YYJn0c9ES3BjGrO7kNHpMdPzvExpcKBAOqm7a2Fk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 01QJeNRx011746 for ; Wed, 26 Feb 2020 14:40:23 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 14:40:22 -0500 From: Roman Danyliw To: "txauth@ietf.org" Thread-Topic: [Txauth] Updated Proposed TxAuth Charter Thread-Index: AQHV3dfMz9F1Yb+P+0SFwSkL0slXyagt7q0wgAAAHZA= Date: Wed, 26 Feb 2020 19:40:21 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216F52CF7@marchand> References: <359EC4B99E040048A7131E0F4E113AFC0216F5281B@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F5281B@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 19:40:35 -0000 SGkhDQoNCkEgZmV3IG1pbm9yIG5pdHMgZnJvbSB0aGUgQmVuIGFuZCBtZSBhcyB3ZSBidXR0b24g dXAgdGhpcyB0ZXh0IC4uLg0KDQo+IEZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkg MDcsIDIwMjAgMTE6NTggQU0NCj4gVG86IHR4YXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbVHhh dXRoXSBVcGRhdGVkIFByb3Bvc2VkIFR4QXV0aCBDaGFydGVyDQo+IA0KPiBJ4oCZdmUgdXBkYXRl ZCB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IGJhc2VkIG9uIGZlZWRiYWNrIGFuZCBjb252ZXJz YXRpb24NCj4gaGVyZSBvbiB0aGUgbGlzdDoNCj4gDQo+IA0KPiBUaGlzIGdyb3VwIGlzIGNoYXJ0 ZXJlZCB0byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yDQo+ IGF1dGhvcml6YXRpb24sIGlkZW50aXR5LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3 aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nDQo+IHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBj bGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQNCj4gd2ls bCBleHBhbmQgdXBvbiB0aGUgdXNlcyBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRo IDIuMCBhbmQNCj4gT3BlbklEIENvbm5lY3QgKGl0c2VsZiBhbiBleHRlbnNpb24gb2YgT0F1dGgg Mi4wKSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25zDQo+IHNjb3BlZCBhcyBuYXJyb3dseSBhcyBh IHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBhIGNsZWFyIGZyYW1ld29yayBmb3INCj4gaW50 ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3cs IGFuZCByZW1vdmUNCj4gdW5uZWNlc3NhcnkgZGVwZW5kZW5jZSBvbiBhIGJyb3dzZXIgb3IgdXNl ci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nDQo+IGludGVyYWN0aW9ucy4NCj4gDQo+IFRoZSBkZWxl Z2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4g dGhlIHByb3RvY29sLA0KPiBlYWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJv dG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50ZXJhY3Rpb24NCj4gY2hhbm5lbHMsIHN1Y2ggYXMg dGhlIGVuZCB1c2Vy4oCZcyBicm93c2VyLCBmcm9tIHRoZSBkZWxlZ2F0aW9uIGNoYW5uZWwsDQo+ IHdoaWNoIGhhcHBlbnMgZGlyZWN0bHkgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgKGluDQo+IGNvbnRyYXN0IHdpdGggT0F1dGggMi4wIHdoaWNoIGlzIGlu aXRpYXRlZCBieSB0aGUgY2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1c2Vy4oCZcw0KPiBicm93c2Vy KS4gVGhlIGNsaWVudCBhbmQgQVMgd2lsbCBpbnZvbHZlIGEgdXNlciB0byBtYWtlIGFuIGF1dGhv cml6YXRpb24NCj4gZGVjaXNpb24gYXMgbmVjZXNzYXJ5IHRocm91Z2ggaW50ZXJhY3Rpb24gbWVj aGFuaXNtcyBpbmRpY2F0ZWQgYnkgdGhlDQo+IHByb3RvY29sLiBUaGlzIGRlY291cGxpbmcgYXZv aWRzIG1hbnkgb2YgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwNCj4gY2hhbGxl bmdlcyBvZiBPQXV0aCAyLjAgYW5kIHByb3ZpZGVzIGEgbm9uLWludmFzaXZlIHBhdGggZm9yIHN1 cHBvcnRpbmcNCj4gZnV0dXJlIHR5cGVzIG9mIGNsaWVudHMgYW5kIGludGVyYWN0aW9uIGNoYW5u ZWxzLg0KPiANCj4gQWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxs b3cgZm9yOg0KPiANCj4gLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCj4g LSBBcHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0eSBjbGFpbXMNCj4gLSBBcHBy b3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBBUElzIGluIGEgc2luZ2xl IGludGVyYWN0aW9uDQo+IC0gU2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3Jpemlu ZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVyYXRpbmcNCj4gdGhlIGNsaWVudCByZXF1ZXN0aW5n IGFjY2Vzcw0KPiAtIEEgdmFyaWV0eSBvZiBjbGllbnQgYXBwbGljYXRpb25zLCBpbmNsdWRpbmcg V2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQNCj4gaW50ZXJhY3Rpb24tY29uc3RyYWluZWQg YXBwbGljYXRpb25zDQo+IA0KPiBUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50 cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkNCj4gaW4gYXJlYXMg aW5jbHVkaW5nOg0KPiANCj4gLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3Nh Z2Ugc2lnbmF0dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24NCj4gLSBVc2VyIGludGVyYWN0 aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzDQo+IC0gTWVj aGFuaXNtIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90 aGVyIHBpZWNlcyBvZg0KPiBpbmZvcm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNp b25zDQoNCnMvTWVjaGFuaXNtL01lY2hhbmlzbXMvDQoNCj4gLSBNZWNoYW5pc21zIGZvciBwcmVz ZW50aW5nIHRva2VucyB0byByZXNvdXJjZSBzZXJ2ZXJzIGFuZCBiaW5kaW5nDQo+IHJlc291cmNl IHJlcXVlc3RzIHRvIHRva2VucyBhbmQgYXNzb2NpYXRlZCBjcnlwdG9ncmFwaGljIGtleXMNCg0K SXMgdGhlcmUgYW55IHNjb3Bpbmcgd2UgbmVlZCB0byBhZGQgaGVyZT8NCg0KPiAtIE9wdGltaXpl ZCBpbmNsdXNpb24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdoIHRoZSBkZWxlZ2F0 aW9uDQo+IHByb2Nlc3MgKGluY2x1ZGluZyBpZGVudGl0eSkNCg0KQ2FuIGFueXRoaW5nIGJlIHNh aWQgYWJvdXQgdGhlIHByb3BlcnRpZXMvbWV0cmljIGJlaW5nIG9wdGltaXplZCBoZXJlPw0KDQo+ IEFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5h Z2VtZW50IG9mIHRoZQ0KPiBwcm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOg0KPiANCj4gLSBE aXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQo+IC0gUmV2b2NhdGlvbiBvZiBh Y3RpdmUgdG9rZW5zDQo+IC0gUXVlcnkgb2YgdG9rZW4gcmlnaHRzIGJ5IHJlc291cmNlIHNlcnZl cnMNCj4gDQo+IEFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGlu dGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlDQo+IGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1 dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXANCj4gd2lsbMKgYXR0ZW1wdCB0byBz aW1wbGlmeSBtaWdyYXRpbmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRo ZQ0KPiBuZXcgcHJvdG9jb2wgd2hlcmUgcG9zc2libGUuDQo+IA0KPiBUaGlzIGdyb3VwIGlzIG5v dCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1 Y2gNCj4gd2lsbCBmb2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vz c2FyaWx5IGNvbXBhdGlibGUgd2l0aA0KPiBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBi dWlsZHMgZGlyZWN0bHkgb24gT0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluDQo+IHRoZSBP QXV0aCBXb3JraW5nIEdyb3VwLCBpbmNsdWRpbmcgZnVuY3Rpb25hbGl0eSBiYWNrIHBvcnRlZCBm cm9tIFR4QXV0aA0KPiB0byBPQXV0aCAyLjAuDQo+IA0KPiBUaGUgZ3JvdXAgaXMgY2hhcnRlcmVk IHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcgY3J5cHRvZ3JhcGhpYw0KPiBtZXRo b2RzLCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MuIFRo aXMgZ3JvdXAgaXMgbm90DQo+IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBjcnlwdG9ncmFwaGlj IG1ldGhvZHMuDQo+IA0KPiBUaGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRU UCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZQ0KPiBjbGllbnQgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMN Cj4gb2YgSFRUUDIgYW5kIEhUVFAzwqB3aGVyZSBwb3NzaWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRv IGVuYWJsZSBzaW1wbGUgbWFwcGluZw0KPiB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQ IHdoZW4gZG9pbmcgc28gZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUNCj4gcHJpbWFyeSBmb2N1 cy4NCj4gDQo+IE1pbGVzdG9uZXMgdG8gaW5jbHVkZToNCg0KSXMgdGhlcmUgaW50ZXJlc3QgaW4g cHVibGlzaGluZyBhIGRvY3VtZW50IHRvIGNvdmVyIG5ldyB1c2UgY2FzZXMgbm90IGFscmVhZHkg Y292ZXJlZCBpbiBPQXV0aCAyIG9yIE9wZW4gSUQgc3BlY3M/DQoNCj4gwqAtIENvcmUgZGVsZWdh dGlvbiBwcm90b2NvbA0KPg0KPiDCoC0gS2V5IHByZXNlbnRhdGlvbiBtZWNoYW5pc20gYmluZGlu Z3MgdG8gdGhlIGNvcmUgcHJvdG9jb2wgZm9yIFRMUywNCj4gZGV0YWNoZWQgSFRUUCBzaWduYXR1 cmUsIGFuZCBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZXMNCg0KSXMgdGhpcyBvbmUgbWVjaGFuaXNt PyAgT3IgdGhyZWU/DQoNCkFyZSB0aGVyZSBvdGhlciBXR3Mgd2l0aCB3aGljaCB0aGlzIGFjdGl2 aXR5IHNob3VsZCBiZSBjb29yZGluYXRlZCAoZS5nLiwgSFRUUGJpcyk/DQoNCj4gwqAtIElkZW50 aXR5IGFuZCBhdXRoZW50aWNhdGlvbiBjb252ZXlhbmNlIG1lY2hhbmlzbXMNCg0KV2hhdCBleGFj dGx5IGlzIHRoYXQ/ICBIb3cgbWFueSBhcmUgdGhlcmU/DQoNCj4gwqAtIEd1aWRlbGluZXMgZm9y IGV4dGVuc2lvbiBwb2ludHMNCg0KSXMgdGhpcyB0aGUgc2FtZSBhcyAiSW1wbGVtZW50YXRpb24g R3VpZGFuY2UgZm9yIHB1Ymxpc2hpbmcgZXh0ZW5zaW9uIHBvaW50cyI/DQoNClRoYW5rcywNClJv bWFuDQoNCg== From nobody Wed Feb 26 12:36:27 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C043A13DA for ; Wed, 26 Feb 2020 12:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnonozsjHGrl for ; Wed, 26 Feb 2020 12:36:23 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A66863A13D9 for ; Wed, 26 Feb 2020 12:36:22 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01QKaIPp015845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Feb 2020 15:36:19 -0500 From: Justin Richer Message-Id: <614F13A1-4E2E-40F9-8843-58EC3B9F3EC2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_679BEC31-7427-49B7-85CA-28F6F192785F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Feb 2020 15:36:18 -0500 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F52CF7@marchand> Cc: "txauth@ietf.org" To: "rdd@cert.org" References: <359EC4B99E040048A7131E0F4E113AFC0216F5281B@marchand> <359EC4B99E040048A7131E0F4E113AFC0216F52CF7@marchand> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Updated Proposed TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:36:26 -0000 --Apple-Mail=_679BEC31-7427-49B7-85CA-28F6F192785F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roman, answers inline below. I=E2=80=99m not sure how or if we=E2=80=99= d want to change the text in order to be more clear, but I=E2=80=99m = open to suggestions (from anyone). Thank you! > On Feb 26, 2020, at 2:40 PM, Roman Danyliw wrote: >=20 > Hi! >=20 > A few minor nits from the Ben and me as we button up this text ... >=20 >> From: Txauth On Behalf Of Justin Richer >> Sent: Friday, February 07, 2020 11:58 AM >> To: txauth@ietf.org >> Subject: [Txauth] Updated Proposed TxAuth Charter >>=20 >> I=E2=80=99ve updated the proposed charter text based on feedback and = conversation >> here on the list: >>=20 >>=20 >> This group is chartered to develop a fine-grained delegation protocol = for >> authorization, identity, and API access. This protocol will allow an = authorizing >> party to delegate access to client software through an authorization = server. It >> will expand upon the uses cases currently supported by OAuth 2.0 and >> OpenID Connect (itself an extension of OAuth 2.0) to support = authorizations >> scoped as narrowly as a single transaction, provide a clear framework = for >> interaction among all parties involved in the protocol flow, and = remove >> unnecessary dependence on a browser or user-agent for coordinating >> interactions. >>=20 >> The delegation process will be acted upon by multiple parties in the = protocol, >> each performing a specific role. The protocol will decouple the = interaction >> channels, such as the end user=E2=80=99s browser, from the delegation = channel, >> which happens directly between the client and the authorization = server (in >> contrast with OAuth 2.0 which is initiated by the client redirecting = the user=E2=80=99s >> browser). The client and AS will involve a user to make an = authorization >> decision as necessary through interaction mechanisms indicated by the >> protocol. This decoupling avoids many of the security concerns and = technical >> challenges of OAuth 2.0 and provides a non-invasive path for = supporting >> future types of clients and interaction channels. >>=20 >> Additionally, the delegation process will allow for: >>=20 >> - Fine-grained specification of access >> - Approval of AS attestation to identity claims >> - Approval of access to multiple resources and APIs in a single = interaction >> - Separation between the party authorizing access and the party = operating >> the client requesting access >> - A variety of client applications, including Web, mobile, = single-page, and >> interaction-constrained applications >>=20 >> The group will define extension points for this protocol to allow for = flexibility >> in areas including: >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession >> - User interaction mechanisms including web and non-web methods >> - Mechanism for conveying user, software, organization, and other = pieces of >> information used in authorization decisions >=20 > s/Mechanism/Mechanisms/ OK. >=20 >> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >=20 > Is there any scoping we need to add here? I don=E2=80=99t think so =E2=80=94 I think we want to be open to = different kinds of presentation mechanisms here. The group can decide if = any particular mechanism is worth defining within the group or pushing = it elsewhere if it=E2=80=99s a better fit. >=20 >> - Optimized inclusion of additional information through the = delegation >> process (including identity) >=20 > Can anything be said about the properties/metric being optimized here? The optimization that=E2=80=99s been identified in early conversations = is to include some information in the response to the authorization = call, in addition to a token enabling the client to call an API. So for = a concrete example, you=E2=80=99d be able to ask for an identifier for = the current user but also call a user API (like an OIDC UserInfo = Endpoint or a SCIM endpoint) with the access token to get their profile = information. So you=E2=80=99re optimizing that first bit of information = with a specific part of the request/response within this protocol.=20 >=20 >> Additionally, the group will provide mechanisms for management of the >> protocol lifecycle including: >>=20 >> - Discovery of the authorization server >> - Revocation of active tokens >> - Query of token rights by resource servers >>=20 >> Although the artifacts for this work are not intended or expected to = be >> backwards-compatible with OAuth 2.0 or OpenID Connect, the group >> will attempt to simplify migrating from OAuth 2.0 and OpenID Connect = to the >> new protocol where possible. >>=20 >> This group is not chartered to develop extensions to OAuth 2.0, and = as such >> will focus on new technological solutions not necessarily compatible = with >> OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be = developed in >> the OAuth Working Group, including functionality back ported from = TxAuth >> to OAuth 2.0. >>=20 >> The group is chartered to develop mechanisms for applying = cryptographic >> methods, such as JOSE and COSE, to the delegation process. This group = is not >> chartered to develop new cryptographic methods. >>=20 >> The initial work will focus on using HTTP for communication between = the >> client and the authorization server, taking advantage of optimization = features >> of HTTP2 and HTTP3 where possible, and will strive to enable simple = mapping >> to other protocols such as COAP when doing so does not conflict with = the >> primary focus. >>=20 >> Milestones to include: >=20 > Is there interest in publishing a document to cover new use cases not = already covered in OAuth 2 or Open ID specs? I=E2=80=99m not a fan of publishing use case documents as official WG = documents. I believe they are useful for organizing group thoughts and = activities, but they should not be set in stone (as an RFC, for = instance). Just about every instance of this I=E2=80=99ve been a part of = in the IETF has been a failure and waste of effort. That=E2=80=99s why I = didn=E2=80=99t include it in the milestones, but I=E2=80=99m happy if = the group decides to use it as an organizational tool. >=20 >> - Core delegation protocol >>=20 >> - Key presentation mechanism bindings to the core protocol for TLS, >> detached HTTP signature, and embedded HTTP signatures >=20 > Is this one mechanism? Or three? Three mechanisms to do similar things. There are likely others out there = as well. >=20 > Are there other WGs with which this activity should be coordinated = (e.g., HTTPbis)? Only a little coordination is going to be needed - what we=E2=80=99re = after here is applying work done in other WG=E2=80=99s to this problem. = So we=E2=80=99ll be providing a use case for that specific work, but the = good news is that the editors for that spec are also here in TxAuth. But = we don=E2=80=99t want to invent new things =E2=80=94 that=E2=80=99s why = we=E2=80=99re targeting the HTTPbis signature work, MTLS, and JWS as = three specific mechanisms; the crypto work is outside this group, but = how that fits into this specific protocol would be within scope. There = might be others identified in the course of the working group=E2=80=99s = activities, but I don=E2=80=99t see that as a change in charter if = it=E2=80=99s picked up after we=E2=80=99re done with these. >=20 >> - Identity and authentication conveyance mechanisms >=20 > What exactly is that? How many are there? This is what I=E2=80=99m talking about about above =E2=80=94 a way to = get user info back from the AS. There=E2=80=99s disagreement even in = initial conversations here on the list as to what would be included (how = much of the profile) and what form it would take (plain field vs. signed = assertion), but there=E2=80=99s agreement that we=E2=80=99d want to = return some kind of identity stuff. I don=E2=80=99t think we can be more = specific without pre-determining a solution. >=20 >> - Guidelines for extension points >=20 > Is this the same as "Implementation Guidance for publishing extension = points=E2=80=9D? I=E2=80=99m not sure it=E2=80=99s quite the same. We want to make sure = our artifacts include clear guidance around what the extension points of = this protocol are. Maybe this should be =E2=80=9CGuidelines for use of = protocol extension points=E2=80=9D? >=20 > Thanks, > Roman >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_679BEC31-7427-49B7-85CA-28F6F192785F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Roman, answers inline below. I=E2=80=99m not sure how or if we=E2=80=99d = want to change the text in order to be more clear, but I=E2=80=99m open = to suggestions (from anyone). Thank you!

On Feb = 26, 2020, at 2:40 PM, Roman Danyliw <rdd@cert.org> wrote:

Hi!

A few minor nits from the Ben = and me as we button up this text ...

From: Txauth <txauth-bounces@ietf.org> On Behalf Of Justin Richer
Sent: Friday, February 07, 2020 11:58 AM
To: txauth@ietf.org
Subject: [Txauth] Updated Proposed TxAuth Charter

I=E2=80=99ve updated the proposed charter text = based on feedback and conversation
here on the list:


This group is chartered to = develop a fine-grained delegation protocol for
authorization, identity, and API access. This protocol will = allow an authorizing
party to delegate access to client = software through an authorization server. It
will expand = upon the uses cases currently supported by OAuth 2.0 and
OpenID Connect (itself an extension of OAuth 2.0) to support = authorizations
scoped as narrowly as a single transaction, = provide a clear framework for
interaction among all = parties involved in the protocol flow, and remove
unnecessary dependence on a browser or user-agent for = coordinating
interactions.

The = delegation process will be acted upon by multiple parties in the = protocol,
each performing a specific role. The protocol = will decouple the interaction
channels, such as the end = user=E2=80=99s browser, from the delegation channel,
which = happens directly between the client and the authorization server (in
contrast with OAuth 2.0 which is initiated by the client = redirecting the user=E2=80=99s
browser). The client and AS = will involve a user to make an authorization
decision as = necessary through interaction mechanisms indicated by the
protocol. This decoupling avoids many of the security = concerns and technical
challenges of OAuth 2.0 and = provides a non-invasive path for supporting
future types = of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
-= Approval of access to multiple resources and APIs in a single = interaction
- Separation between the party authorizing = access and the party operating
the client requesting = access
- A variety of client applications, including Web, = mobile, single-page, and
interaction-constrained = applications

The group will define = extension points for this protocol to allow for flexibility
in areas including:

- = Cryptographic agility for keys, message signatures, and proof of = possession
- User interaction mechanisms including web and = non-web methods
- Mechanism for conveying user, software, = organization, and other pieces of
information used in = authorization decisions

s/Mechanism/Mechanisms/

OK.


- = Mechanisms for presenting tokens to resource servers and binding
resource requests to tokens and associated cryptographic = keys

Is there any scoping we need to add here?

I don=E2=80=99= t think so =E2=80=94 I think we want to be open to different kinds of = presentation mechanisms here. The group can decide if any particular = mechanism is worth defining within the group or pushing it elsewhere if = it=E2=80=99s a better fit.


- Optimized inclusion of additional = information through the delegation
process (including = identity)

Can anything be said about the properties/metric being = optimized here?

The optimization that=E2=80=99s been identified in = early conversations is to include some information in the response to = the authorization call, in addition to a token enabling the client to = call an API. So for a concrete example, you=E2=80=99d be able to ask for = an identifier for the current user but also call a user API (like an = OIDC UserInfo Endpoint or a SCIM endpoint) with the access token to get = their profile information. So you=E2=80=99re optimizing that first bit = of information with a specific part of the request/response within this = protocol. 


Additionally, the group will provide = mechanisms for management of the
protocol lifecycle = including:

- Discovery of the authorization = server
- Revocation of active tokens
- Query = of token rights by resource servers

Although = the artifacts for this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the = group
will attempt to simplify migrating from OAuth = 2.0 and OpenID Connect to the
new protocol where = possible.

This group is not chartered to = develop extensions to OAuth 2.0, and as such
will focus on = new technological solutions not necessarily compatible with
OAuth 2.0. Functionality that builds directly on OAuth 2.0 = will be developed in
the OAuth Working Group, including = functionality back ported from TxAuth
to OAuth 2.0.

The group is chartered to develop mechanisms = for applying cryptographic
methods, such as JOSE and COSE, = to the delegation process. This group is not
chartered to = develop new cryptographic methods.

The = initial work will focus on using HTTP for communication between the
client and the authorization server, taking advantage of = optimization features
of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping
to = other protocols such as COAP when doing so does not conflict with the
primary focus.

Milestones to = include:

Is there interest in publishing a document to cover new use = cases not already covered in OAuth 2 or Open ID specs?

I=E2=80=99m = not a fan of publishing use case documents as official WG documents. I = believe they are useful for organizing group thoughts and activities, = but they should not be set in stone (as an RFC, for instance). Just = about every instance of this I=E2=80=99ve been a part of in the IETF has = been a failure and waste of effort. That=E2=80=99s why I didn=E2=80=99t = include it in the milestones, but I=E2=80=99m happy if the group decides = to use it as an organizational tool.


 - Core delegation protocol

 - Key presentation mechanism bindings to = the core protocol for TLS,
detached HTTP signature, and = embedded HTTP signatures

Is this one mechanism?  Or = three?

Three = mechanisms to do similar things. There are likely others out there as = well.


Are there = other WGs with which this activity should be coordinated (e.g., = HTTPbis)?

Only = a little coordination is going to be needed - what we=E2=80=99re after = here is applying work done in other WG=E2=80=99s to this problem. So = we=E2=80=99ll be providing a use case for that specific work, but the = good news is that the editors for that spec are also here in TxAuth. But = we don=E2=80=99t want to invent new things =E2=80=94 that=E2=80=99s why = we=E2=80=99re targeting the HTTPbis signature work, MTLS, and JWS as = three specific mechanisms; the crypto work is outside this group, but = how that fits into this specific protocol would be within scope. There = might be others identified in the course of the working group=E2=80=99s = activities, but I don=E2=80=99t see that as a change in charter if = it=E2=80=99s picked up after we=E2=80=99re done with these.


 -= Identity and authentication conveyance mechanisms

What exactly is that?  How many are there?

This is = what I=E2=80=99m talking about about above =E2=80=94 a way to get user = info back from the AS. There=E2=80=99s disagreement even in initial = conversations here on the list as to what would be included (how much of = the profile) and what form it would take (plain field vs. signed = assertion), but there=E2=80=99s agreement that we=E2=80=99d want to = return some kind of identity stuff. I don=E2=80=99t think we can be more = specific without pre-determining a solution.


 -= Guidelines for extension points

Is this the same as = "Implementation Guidance for publishing extension points=E2=80=9D?<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;" class=3D"">

I=E2=80= =99m not sure it=E2=80=99s quite the same. We want to make sure our = artifacts include clear guidance around what the extension points of = this protocol are. Maybe this should be =E2=80=9CGuidelines for use of = protocol extension points=E2=80=9D?


Thanks,
Roman

-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_679BEC31-7427-49B7-85CA-28F6F192785F-- From nobody Fri Feb 28 14:38:20 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5C3A1F9B; Fri, 28 Feb 2020 14:35:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931855.19931.5173170915982493260@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:18 -0800 Archived-At: Subject: [Txauth] txauth - Requested session has been scheduled for IETF 107 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:25 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. txauth Session 1 (2:00 requested) Wednesday, 25 March 2020, Morning Session I 1000-1200 Room Name: Regency D size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/txauth.ics Request Information: --------------------------------------------------------- Working Group Name: Transactional Authorization and Delegation Area Name: Security Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: oauth saag secdispatch httpbis uta cose ace acme calext curdle detnet dots emu i2nsf ipsecme kitten lake lamps mile mls rats sacm secevent suit teep tls tokbind trans People who must be present: Yaron Sheffer Roman Danyliw Dick Hardt Resources Requested: Special Requests: They would prefer 2.5 hours according to the wiki. --------------------------------------------------------- From nobody Fri Feb 28 14:54:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860E13A1FD9 for ; Fri, 28 Feb 2020 14:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Jcb7ws6-Y7pK for ; Fri, 28 Feb 2020 14:54:42 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A486A3A1F98 for ; Fri, 28 Feb 2020 14:54:41 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id e3so5085451lja.10 for ; Fri, 28 Feb 2020 14:54:41 -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=UdeD0MB0jK3UeeIVwV+kreCppbhPrVBYFXQZFjxokL4=; b=e5fwlAPonBxwFwLkDKHOw2ibpsBBub0ZPBKZbIHs1vI8SstQOdOseayS/zfeCUNneY /6Rh/TYOQRtmUcLrDjwn5OXlh/4pJxzlXPXi/kWEqKLmwrYMcLnAL3mN4VZRXv0Umm5y 4RXSh28VkKBybjs17eo2GeIB4ETUjDEqDmjDSbvbS/bsX0ShX8QDdoSIygmIn7Ymwk+V ha0OK/NUPrpl2vGLM8Qi3Sedkmaz2M9w0NpRngV3tJr0+/L1kPIuLrjgi0haT+mBXG+n 9AgvCDDpPkYsX7SsaiG7FID6aP3QDMbPC5cYXm/cPJGBwSeTgSgboKjxWILVT0yu6A4s d/vQ== 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=UdeD0MB0jK3UeeIVwV+kreCppbhPrVBYFXQZFjxokL4=; b=l0TmWJNCKHgpQDYfN4+TS9r0tu9GjnMZrI2XgqRJ7DJxqVB4pOo1tfjF3I69IViTEL NwKr69u7jxcferOhVN11u3rmS/eztuhFeLzMyr7X/YxBGnU60dzZe2daZ2uzTElboIIx u0uYqE0kTtzeURs/4F8JGRuzHTqgZgXAd9aOKURch/9VBjltWGq1xnJaRcpeFATDAlyV w70+zUzD/CNrhrocUK2R8Nu1YLYSaPW80JFQUHLLRra+v50VR3kJYSvRjjgK0UW6keUc dnVC12Pxw6ECQEz/hpnQmAG/qF9w8AzkYIbGhkuMURUO5fEHc5FKJyFhWPhKnhnPPrtW UCUA== X-Gm-Message-State: ANhLgQ0zexca6cW55ks7nrCpaG/CYn6+GARJxlj4hbmioKsWkcH54H3a k/deMwegq1WxGYproDfn+dZC9wCboAzRLaxWkkZCbEaO X-Google-Smtp-Source: ADFU+vv6hAZ8Zap1S8JgrrAdNXLY0xup9QjUMKnYKJZiP24HdBRXiIfvFYWASDZGPccJd6l+QIMH4akf/uFER4RmLTk= X-Received: by 2002:a05:651c:203:: with SMTP id y3mr4131663ljn.151.1582930479586; Fri, 28 Feb 2020 14:54:39 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <02197105-4C5F-41F1-8A84-8972F25C5132@amazon.com> <72D44F53-6AB7-43C8-A337-623B31FB584B@amazon.com> In-Reply-To: From: Dick Hardt Date: Fri, 28 Feb 2020 14:54:12 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f0a216059faab88f" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:54:51 -0000 --000000000000f0a216059faab88f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good point on their being different scannable formats, and likely more in the future. =E1=90=A7 On Tue, Feb 25, 2020 at 3:27 PM Justin Richer wrote: > Another note about calling out QRCodes as separate from other URL > representations: there are a ton of different scannable formats out there= . > QRCodes are among the most common, but they=E2=80=99re hardly the only on= es in use. > If a client wants to use JAB or Han Xin or Data Matrix or whatever to > display the URL, it=E2=80=99s not this spec=E2=80=99s place to say anythi= ng about it. > > The important thing is that there=E2=80=99s a variable URL that needs to = be > communicated to the user. If there are length limitations, I think > Annabelle=E2=80=99s idea of allowing the client to specifically ask for a= short URL > are a good one. Calling it =E2=80=9Cqrcode=E2=80=9D presumes way too much= of the solution > stack on the client=E2=80=99s part and doesn=E2=80=99t help interoperabil= ity or flexibility. > > =E2=80=94 Justin > > On Feb 24, 2020, at 4:18 PM, Richard Backman, Annabelle < > richanna=3D40amazon.com@dmarc.ietf.org> wrote: > > I think your summary is accurate, but the line between your two reasons > gets pretty blurry. The Client may not be able to detect on its own wheth= er > its preferred method is working, so your proposal that the Client could > switch methods by making a new request would require the end user to > provide some input. For example: > > - If a web browser is available but the firewall blocks outbound HTTP > (not unreasonable for a server host), the Client would think that it > successfully opened the URI. > - If the local browser lacks the accessibility features needed by the > end user, the Client would successfully open the URI, but it would not= be > usable by the end user. > - In the =E2=80=9Cshared family tablet=E2=80=9D example in my previous= email, the > Client would not be aware that the end user is unable to interact with= the > companion app. > > > So it=E2=80=99s easier for both Client and end user, and more generally a= pplicable > if the Client can request multiple interaction modes and present them at > the same time. > > If we only have a single =E2=80=9Curi=E2=80=9D parameter, the max length = in the request > should be advisory. I.e., the GS SHALL return a URI, and it SHOULD return > one that meets the max length restriction if it can. Client behavior is > effectively the same as if it were treated as a hard requirement; the onl= y > difference is that the Client code branches based on the actual length of > the URI returned (which it already needs to check) rather than based on t= he > presence or absence of a URI, or an error response from the GS. Clients > that can still make use of a longer URI are saved the extra round trip to > request one. > > I think both =E2=80=9Curi=E2=80=9D and =E2=80=9Ccode=E2=80=9D should be M= TI, but that does not mean they > are mandatory to deploy. There=E2=80=99s lots of cases where a GS will on= ly ever > deal with specific types of Clients such that they=E2=80=99ll always use = one or the > other, but in those cases the GS is explicitly not concerned overmuch wit= h > interoperability. > > We need to be careful about defining a maximum length for the code entry > URI. Domain names cost money to register and maintain, so a maximum lengt= h > that is too low would effectively impose a monetary barrier to deployers > who have long domain names. We would also have to make this a maximum > Unicode character length with the domain name expressed in IDN form, not > ASCII form. Users of non-Western scripts should not be penalized by the > need to use Punycode. > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, February 21, 2020 at 5:37 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > Thanks Annabelle. > > FYI: With the requirement to have a interact_ref value come back from the > GS to the Client, the popup and redirect are now the same -- so we can mo= ve > past the popup discussion. > > To summarize your examples, > 1) the Client may need to fallback to a different method than it initiall= y > had planned on > 2) the Client may want to offer the User a broader choice of methods > > (1) could be solved by the Client making a new request of the GS > > (2) requires the Client to receive multiple methods so it can offer the > User a choice. > > Am I following along correctly > > A short URI and a long URI are functionally equivalent -- so there does > not seem to be a requirement to have both. > For example, the Client may request a URI, with an optional max length? > > So that let's the Client ask for one or both of: > > - a URI with an optional max length ( indicate it has a static max length= ) > - a short code and code entry URI > > If and when new mechanism for the Client to transfer interactions to the > GS, new parameters are defined. > > Q: what is MTI? > > Q: Is there a minimum length of the short URI? ( think that specifying a > short URI max length will make it easier for Clients and GS as it is not > negotiated) > > > /Dick > > =E1=90=A7 > > On Fri, Feb 21, 2020 at 4:46 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Okay, you=E2=80=99ve convinced me that there are use cases for a GS to so= metimes > provide a shorter URI and sometimes a longer URI. Let=E2=80=99s see if I = can > convince you that interaction mode selection is less deterministic than y= ou > think. :D > > I **think** the Client can be expected to know if it will transfer > interaction to the GS within the same user agent the end user is accessin= g > Client through. In other words, I think there are two reliably > differentiable modes: same UA (30X redirect, open in same window, open in > new), and different UA (code, QR code, opening URI in external browser, > etc.). However, within each mode, the Client may not know which mechanism > will be used. (e.g., for =E2=80=9Csame UA=E2=80=9D: will the Client open = the URI in the > same window or a new one; for =E2=80=9Cdifferent UA=E2=80=9D: will the en= d user scan a QR > code or enter a code or tap on a URI in an SMS) > > The non-determinism comes from two sources: > > 1. Environmental conditions > > a. A console app might be able to directly open a URI in the system=E2= =80=99s > browser (e.g., when running in a terminal window on a desktop), or it mig= ht > not (e.g., on a headless system). The app may not know the answer until i= t > tries it. > > b. That same console app might be running in a remote terminal, such > that the end user would be able to click or copy and paste a URI printed = by > the app. > > c. An SPA might be able to open a popup, or it might fail for various > reasons. It might decide to fall back to a redirect if it detects that th= e > popup failed to open. It might want the =E2=80=9Cpopup=E2=80=9D to gracef= ully fall back to > a redirect-like experience in case the user agent only supports a single > window at a time (e.g., embedded user agents in apps like Facebook and > Twitter). > > d. Environmental conditions may make it difficult to scan a QR code > (e..g., the screen is dirty, foggy, cracked, or under direct sunlight), b= ut > still allow for a person to read a short code. The Client likely has no w= ay > of detecting such things. > > 2. End user capabilities and preferences > > a. They may have a physical disability or other condition that makes > it difficult to impossible for them to scan a QR code. > > i. Th= ey > may be capable of reading and copying a short code. > > ii. The= y > may be capable of listening to and entering a short code spoken by the > device. > > iii. They > may be capable of following a link sent to them via text or email, which > they can access on a device with greater accessibility options. > > b. They may not have a device capable of scanning a QR code, or the > device may not be functioning, or the device may be the one that the code > is being displayed on. > > c. They may not know what a QR code is, or understand how to use one. > > d. They may want to complete the flow on a device that is incapable of > scanning the QR code (e.g., their desktop). > > e. They may prefer to have the URI texted or emailed to them, rather > than having to scan or copy a code. > > f. They may not have access to the companion app that the Client > transmitted the URI to (e.g., because it=E2=80=99s on the shared family t= ablet, and > it=E2=80=99s their sibling=E2=80=99s turn to use it). > > If we allow that the GS might want to issue long URIs when possible, then > there=E2=80=99s basically three things a Client might want, in any combin= ation: > > =C2=B7 URI, no length restriction > > =C2=B7 URI, with some max length (e.g., because of QR code data capa= city, > SMS message size limits, display constraints, etc.) > > =C2=B7 Short code and code entry URI, both human-friendly > > The GS can=E2=80=99t enforce how these are used; they can only control wh= at they > issue, and how they respond when interaction is transferred to them. > Defining interaction object properties in terms of usage implies > constraints and guarantees that don=E2=80=99t exist, and Clients are goin= g to > disregard our prescribed uses anyway (e.g., by sending a =E2=80=9Cqrcode= =E2=80=9D URI in an > SMS). > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > *From: *Dick Hardt > *Date: *Thursday, February 20, 2020 at 3:13 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"txauth@ietf.org" > *Subject: *Re: [Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > > > On Thu, Feb 20, 2020 at 12:21 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Thanks for the update, Dick! I=E2=80=99m going to confine my comments her= e to > interaction mode design, setting aside whether or not we need =E2=80=9Cpo= pup=E2=80=9D. :D > > Once the GS hands that URI back to the Client, it has zero control over > how the Client uses it. The Client could present any URI (of a reasonable > size) into a QR code, or present it as a clickable link, or redirect to i= t, > or open it in an external browser, or do any number of other > as-yet-not-invented things with it. Moreover, the Client may not know yet > what it wants to do with it. > > > Why would the Client not know what it wants to do with it? What would > change between when the Client called the GS, and the GS responded? > > I think of the interaction being the Client saying "I want to do a > redirect", and the GS says, "ok, here is the URI". Or the Client says, "I > want to show only a code and a URI", and the GS says "ok, here is a good, > and an easy to read URI for the user to type in and navigate to. > > I understand there are interactions that may not yet been invented yet. > More on that further down. > > > So what value is there in distinguishing between =E2=80=9CI want a URI fo= r a > redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D vs. = =E2=80=9CI want a URI for other machine-driven interaction mode>=E2=80=9D? > > Even if we consider things like QR code data capacity, that=E2=80=99s rea= lly just > a URI length limitation, which could apply to non-QR interaction modes, > e.g., if the Client device wants to communicate the URI over an extremely > bandwidth-constrained channel. > > > I don't understand when this would be the case. If the Client is going to > do a redirect, then the URI length is not significant. > > > And it=E2=80=99s not clear to me how including a URI length limitation in= the > request helps. If a GS is capable of generating a shorter URI, why wouldn= =E2=80=99t > it always return that? > > > There may be a variety of reasons that a GS may want to provide a > different URI for a QR code than a redirect, or even a popup. > > 1) Perhaps the GS has only been supporting redirects, and has a very long > URL. They add support for a QR code, and use a 3P service that redirects > from the short URL used in the QR code, the the long URL. They don't want > to pay for the 3P service anymore than they have to. > > 2) The GS wants the QR code and user code flows to go through the same > machinery that looks up the code to find the Grant. The URI in a redirect > has the grant embedded in the URI. They don't want to have to use the cod= e > to Grant machinery for all URIs. > > 3) A QR code flow will usually be done on a phone, and the GS wants to > attempt to launch a native app in some way, > > While you are correct, we could make all URIs be short enough that they > can be easily scanned, why force that on implementors? > > The URI length limitation concept was for the display_uri so that a > constrained device has an upper limit. A similar upper limit on QR code > would allow a constrained device to know the pixel resolution it needs to > show the QR code. > > > On the client side, it can look at the length of the URI provided and > decide what to do with it (e.g., render a QR code or display it or do > nothing with it). > > > Per above, why would the Client not already know what experience it wants > to present to the User? > > A URI to be displayed, and a URI to be redirected to are likely going to > be quite different. > > The URI for a User to enter a code will likely be a static value that is > easy to type. The User will likely have to authenticate at that page, and > then be prompted to enter the code. > > > > So that really leaves us with two interaction modes that we need: > > =C2=B7 =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and > > =C2=B7 =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a co= de entry page, both > of which are human-friendly. > > Those could be combinable to get both, and even if we don=E2=80=99t go do= wn the > multiple interaction mode route we could add the full URI to the =E2=80= =9Ccode=E2=80=9D > interaction object. It wouldn=E2=80=99t hurt anything to do so. > > > In the latest version, I gave each URI its own name so that the GS can be > clear about how it will be used. > > While we could squeeze all the functionality into a couple parameters, I > think it makes it harder for existing deployments to migrate to the > protocol. I think we should make it easy for developers to take what they > already have and use it with XAuth. > > wrt. not-yet-invented interactions. These interactions are for > not-yet-described use cases. (if other use cases exist, then let's look a= t > them and add the interaction mechanisms if needed) We don't know what > parameters will be needed, and overloading the parameters and letting the > Client do whatever it wants does not seem like it will interoperate -- th= e > Client decides it wants to do some new interaction, and uses the paramete= rs > in a way the GS does not understand. > > > > > > > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Tuesday, February 18, 2020 at 6:04 PM > *To: *"txauth@ietf.org" > *Subject: *[Txauth] Fwd: New Version Notification for > draft-hardt-xauth-protocol-03.txt > > Added in user code interaction and aligned QR code to be a superset of > user code. > Fixed descriptions. > > > ---------- Forwarded message --------- > From: > Date: Tue, Feb 18, 2020 at 6:00 PM > Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt > To: Dick Hardt > > > > > A new version of I-D, draft-hardt-xauth-protocol-03.txt > has been successfully submitted by Dick Hardt and posted to the > IETF repository. > > Name: draft-hardt-xauth-protocol > Revision: 03 > Title: The XAuth Protocol > Document date: 2020-02-18 > Group: Individual Submission > Pages: 53 > URL: > https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt > Status: > https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ > Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 > Htmlized: > https://datatracker..ietf.org/doc/html/draft-hardt-xauth-protocol > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 > > Abstract: > Client software often desires resources or identity claims that are > independent of the client. This protocol allows a user and/or > resource owner to delegate resource authorization and/or release of > identity claims to a server. Client software can then request access > to resources and/or identity claims by calling the server. The > server acquires consent and authorization from the user and/or > resource owner if required, and then returns to the client software > the authorization and identity claims that were approved. This > protocol can be extended to support alternative authorizations, > claims, interactions, and client authentication mechanisms. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > =E1=90=A7 > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000f0a216059faab88f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good point on their being different scannable formats, and= likely more in the future.
3D""=E1=90=A7

On Tue, Feb 25, 2= 020 at 3:27 PM Justin Richer <jricher= @mit.edu> wrote:
Another note about callin= g out QRCodes as separate from other URL representations: there are a ton o= f different scannable formats out there. QRCodes are among the most common,= but they=E2=80=99re hardly the only ones in use. If a client wants to use = JAB or Han Xin or Data Matrix or whatever to display the URL, it=E2=80=99s = not this spec=E2=80=99s place to say anything about it.=C2=A0

The important thing is that there=E2=80=99s a variable URL that needs= to be communicated to the user. If there are length limitations, I think A= nnabelle=E2=80=99s idea of allowing the client to specifically ask for a sh= ort URL are a good one. Calling it =E2=80=9Cqrcode=E2=80=9D presumes way to= o much of the solution stack on the client=E2=80=99s part and doesn=E2=80= =99t help interoperability or flexibility.

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

On Feb 24, 2020= , at 4:18 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc= .ietf.org> wrote:

I thi= nk your summary is accurate, but the line between your two reasons gets pre= tty blurry. The Client may not be able to detect on its own whether its pre= ferred method is working, so your proposal that the Client could switch met= hods by making a new request would require the end user to provide some inp= ut. For example:
  • If a web browser is available but the firewa= ll blocks outbound HTTP (not unreasonable for a server host), the Client wo= uld think that it successfully opened the URI.
  • = If the local browser lacks the accessibility features needed by the end use= r, the Client would successfully open the URI, but it would not be usable b= y the end user.
  • In the =E2=80=9Cshared family ta= blet=E2=80=9D example in my previous email, the Client would not be aware t= hat the end user is unable to interact with the companion app.
=C2=A0
So it=E2=80=99s ea= sier for both Client and end user, and more generally applicable if the Cli= ent can request multiple interaction modes and present them at the same tim= e.
=C2=A0
If we o= nly have a single =E2=80=9Curi=E2=80=9D parameter, the max length in the re= quest should be advisory. I.e., the GS SHALL return a URI, and it SHOULD re= turn one that meets the max length restriction if it can. Client behavior i= s effectively the same as if it were treated as a hard requirement; the onl= y difference is that the Client code branches based on the actual length of= the URI returned (which it already needs to check) rather than based on th= e presence or absence of a URI, or an error response from the GS. Clients t= hat can still make use of a longer URI are saved the extra round trip to re= quest one.
=C2=A0
I think both =E2=80=9Curi=E2=80=9D and =E2=80=9Ccode=E2=80=9D should be MT= I, but that does not mean they are mandatory to deploy. There=E2=80=99s lot= s of cases where a GS will only ever deal with specific types of Clients su= ch that they=E2=80=99ll always use one or the other, but in those cases the= GS is explicitly not concerned overmuch with interoperability.
=C2=A0
We need to be careful= about defining a maximum length for the code entry URI. Domain names cost = money to register and maintain, so a maximum length that is too low would e= ffectively impose a monetary barrier to deployers who have long domain name= s. We would also have to make this a maximum Unicode character length with = the domain name expressed in IDN form, not ASCII form. Users of non-Western= scripts should not be penalized by the need to use Punycode.=
=C2=A0
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">= https://aws.amazon.com/identity/=
=C2=A0
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:= =C2=A0Friday, February 21, 2020 at 5:37 PM
To:=C2=A0= "Richard Backman, Annabelle" <richanna@amazon.com>
Cc:=C2=A0"<= a href=3D"mailto:txauth@ietf.org" style=3D"color:blue;text-decoration:under= line" target=3D"_blank">txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0Re: [Txaut= h] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt
=C2=A0
=
Thanks Annabelle.=C2=A0
=C2=A0
FYI: With the requirement to have a interact_ref value come back fro= m the GS to the Client, the popup and redirect are now the same -- so we ca= n move past the popup discussion.
=C2=A0
To summariz= e your examples,
1) the Clien= t may need to fallback to a different method than it initially had planned = on=C2=A0
2) the Client = may want to offer the User a broader choice of methods
<= /div>
=C2=A0
(1) could be solved by the Client making a new request of the GS
=C2=A0
<= div>
(2) requires the Client to receive=C2=A0multiple method= s so it can offer the User a choice.
=C2=A0
Am I following= =C2=A0along correctly
= =C2=A0
A short URI and a long URI ar= e functionally equivalent -- so there does not seem to be a requirement to = have both.=C2=A0
For example,= the Client may request a URI, with an optional max length?
=C2=A0
So that let's the Client ask for one or both of:=
=C2=A0
- a URI with an optional max length ( indicate it has a static m= ax length)
- a short code and= code entry URI
=C2=A0=
If and when new mechanism for the C= lient to transfer interactions to the GS, new parameters are defined.=C2=A0=
=C2=A0
Q: what is MTI?
=C2=A0
Q: Is ther= e a minimum length of the short URI? ( think that specifying a short URI ma= x length will make it easier for Clients and GS as it is not negotiated)=
=C2=A0
=C2=A0
= /Dick
=C2=A0
=E1=90=A7
=C2=A0
On Fri, F= eb 21, 2020 at 4:46 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:
Okay, you=E2=80=99ve= convinced me that there are use cases for a GS to sometimes provide a shor= ter URI and sometimes a longer URI. Let=E2=80=99s see if I can convince you= that interaction mode selection is less deterministic than you think. :D
=C2=A0
I *think* the Client can be expected to know if it will transfer in= teraction to the GS within the same user agent the end user is accessing Cl= ient through. In other words, I think there are two reliably differentiable= modes: same UA (30X redirect, open in same window, open in new), and diffe= rent UA (code, QR code, opening URI in external browser, etc.). However, wi= thin each mode, the Client may not know which mechanism will be used. (e.g.= , for =E2=80=9Csame UA=E2=80=9D: will the Client open the URI in the same w= indow or a new one; for =E2=80=9Cdifferent UA=E2=80=9D: will the end user s= can a QR code or enter a code or tap on a URI in an SMS)
=C2=A0
The non-determin= ism comes from two sources:

1.=C2=A0=C2=A0=C2=A0Environmenta= l conditions=C2=A0

a= .=C2=A0=C2=A0=C2=A0=C2=A0A = console app might be able to directly open a URI in the system=E2=80=99s br= owser (e.g., when running in a terminal window on a desktop), or it might n= ot (e.g., on a headless system). The app may not know the answer until it t= ries it.

b.= =C2=A0=C2=A0=C2=A0That same console app might be= running in a remote terminal, such that the end user would be able to clic= k or copy and paste a URI printed by the app.

c.=C2=A0=C2=A0=C2=A0=C2=A0An SPA might be able to open a popup, or it might fail for vari= ous reasons. It might decide to fall back to a redirect if it detects that = the popup failed to open. It might want the =E2=80=9Cpopup=E2=80=9D to grac= efully fall back to a redirect-like experience in case the user agent only = supports a single window at a time (e.g., embedded user agents in apps like= Facebook and Twitter).

d.=C2=A0=C2=A0=C2=A0Environmental co= nditions may make it difficult to scan a QR code (e..g., the screen is dirt= y, foggy, cracked, or under direct sunlight), but still allow for a person = to read a short code. The Client likely has no way of detecting such things= .

2.=C2=A0=C2= =A0=C2=A0End user capabilities and preferences=C2=A0

a.=C2=A0=C2=A0=C2=A0=C2=A0They may have = a physical disability or other condition that makes it difficult to impossi= ble for them to scan a QR code.

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0i.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0They may be capable of reading and copying a short code.

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0ii.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= They may be capable of listening to and entering a short code= spoken by the device.

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0iii.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0They may be capable of follo= wing a link sent to them via text or email, which they can access on a devi= ce with greater accessibility options.

= b.=C2=A0=C2=A0=C2=A0T= hey may not have a device capable of scanning a QR code, or the device may = not be functioning, or the device may be the one that the code is being dis= played on.

c.=C2=A0=C2=A0=C2=A0=C2=A0They may not know what = a QR code is, or understand how to use one.

d.=C2=A0=C2=A0=C2=A0They may want to complete the flow on a device that is incapable of sca= nning the QR code (e.g., their desktop).

=C2=A0=C2=A0=C2=A0=C2=A0= They may prefer to have the URI texted or emailed to them, rather th= an having to scan or copy a code.

f.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>They may not have access to the companion app that the Client transmi= tted the URI to (e.g., because it=E2=80=99s on the shared family tablet, an= d it=E2=80=99s their sibling=E2=80=99s turn to use it).

=C2=A0
If we allow that th= e GS might want to issue long URIs when possible, then there=E2=80=99s basi= cally three things a Client might want, in any combination:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0URI, no length restriction

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>URI, with some max length (e.g., because of QR code data capac= ity, SMS message size limits, display constraints, etc.)

<= p style=3D"margin-right:0in;margin-left:1in;font-size:11pt;font-family:Cali= bri,sans-serif">=C2= =B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Short code and code entry URI, both human-friendly

=C2=A0
The G= S can=E2=80=99t enforce how these are used; they can only control what they= issue, and how they respond when interaction is transferred to them. Defin= ing interaction object properties in terms of usage implies constraints and= guarantees that don=E2=80=99t exist, and Clients are going to disregard ou= r prescribed uses anyway (e.g., by sending a =E2=80=9Cqrcode=E2=80=9D URI i= n an SMS).
=C2=A0
=E2=80=93=
Annabelle Backman = (she/her)
AWS Identity
=C2=A0
= =C2=A0
From:=C2=A0<= /b>Dick Hardt <dick.hardt@gmail.com>
Date:=C2=A0Thursday= , February 20, 2020 at 3:13 PM
To:=C2=A0"Richar= d Backman, Annabelle" <richanna@amazon= .com>
Cc:=C2=A0"txauth@ietf.org" <txauth@ietf.org= >
Subject:=C2=A0Re: [Txauth] Fwd: New Version Not= ification for draft-hardt-xauth-protocol-03.txt
<= /div>
=C2=A0
=C2=A0
=C2=A0
On Thu, Feb 20, 2020 at 12:21 PM Richard Backman,= Annabelle <richanna@amazon.com> wro= te:
Thanks for the update, Dick! I=E2=80=99m going= to confine my comments here to interaction mode design, setting aside whet= her or not we need =E2=80=9Cpopup=E2=80=9D. :D
=C2=A0
Once the GS hands that URI bac= k to the Client, it has zero control over how the Client uses it. The Clien= t could present any URI (of a reasonable size) into a QR code, or present i= t as a clickable link, or redirect to it, or open it in an external browser= , or do any number of other as-yet-not-invented things with it. Moreover, t= he Client may not know yet what it wants to do with it.
=
=C2=A0
Why would the Client not know what it wants to do with = it? What would change between when the Client called the GS, and the GS res= ponded?
=C2=A0
=
I think of the interaction being the Client saying "= ;I want to do a redirect", and the GS says, "ok, here is the URI&= quot;. Or the Client says, "I want to show only a code and a URI"= , and the GS says "ok, here is a good, and an easy to read URI for the= user to type in and navigate to.
=C2=A0
I understand there= are interactions that may not yet been invented yet. More on that further = down.
=C2=A0
So what value is there in distinguishing between =E2=80=9CI want a U= RI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code=E2=80=9D= vs. =E2=80=9CI want a URI for <some other machine-driven interaction mo= de>=E2=80=9D?
=C2=A0
Even if we consider things like QR code data capacity, that= =E2=80=99s really just a URI length limitation, which could apply to non-QR= interaction modes, e.g., if the Client device wants to communicate the URI= over an extremely bandwidth-constrained channel.
=
=C2=A0
=
I don't understand when this would be the case. If the Cl= ient is going to do a redirect, then the URI length is not significant.<= /u>
=C2=A0
An= d it=E2=80=99s not clear to me how including a URI length limitation in the= request helps. If a GS is capable of generating a shorter URI, why wouldn= =E2=80=99t it always return that?
=C2=A0
Th= ere may be a variety of reasons that a GS may want to provide a different U= RI for a QR code than a redirect, or even a popup.
=C2=A0
1) P= erhaps the GS has only been supporting redirects, and has a very long URL. = They add support for a QR code, and use a 3P service that redirects from th= e short URL used in the QR code, the the long URL. They don't want to p= ay for the 3P service anymore than they have to.
<= div>
=C2=A0
2) The= GS wants the QR code and user code flows to go through the same machinery = that looks up the code to find the Grant. The URI in a redirect has the gra= nt embedded in the URI. They don't want to have to use the code to Gran= t machinery for all URIs.
=C2= =A0
3) A QR code flow will usua= lly be done on a phone, and the GS wants to attempt to launch a native app = in some way,
=C2=A0
While you are correct, we could make all U= RIs be short enough that they can be easily scanned, why force that on impl= ementors?=C2=A0
=C2=A0
The URI length limitation concept was f= or the display_uri so that a constrained device has an upper limit. A simil= ar upper limit on QR code would allow a constrained device to know the pixe= l resolution it needs to show the QR code.
=C2=A0
On the client side, it can look= at the length of the URI provided and decide what to do with it (e.g., ren= der a QR code or display it or do nothing with it).
=C2=A0
Per above, why would the Client not already know what exper= ience it wants to present to the User?
=C2=A0
A URI to be disp= layed, and a URI to be redirected to are likely going to be quite different= .=C2=A0
=C2=A0
The URI for a User to enter a code will likely = be a static value that is easy to type. The User will likely have to authen= ticate at that page, and then be prompted to enter the code.=C2=A0
=C2=A0
=C2=A0<= u>
So that really leaves us with two interact= ion modes that we need:

=C2=B7=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=E2=80=9Curi=E2=80=9D, which returns a f= ull URI that may not be human friendly; and

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Ccode=E2=80=9D, w= hich returns a code and URI for a code entry page, both of which are human-= friendly.

=C2=A0
Those could be combinable to get both, and even if we don=E2=80=99t g= o down the multiple interaction mode route we could add the full URI to the= =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt anythi= ng to do so.
=C2=A0
In the latest version, = I gave each URI its own name so that the GS can be clear about how it will = be used.
=C2=A0
While we could squeeze all the functionality i= nto a couple parameters, I think it makes it harder for existing deployment= s to migrate to the protocol. I think we should make it easy for developers= to take what they already have and use it with XAuth.
<= /div>
=C2=A0
= wrt. not-yet-invented interactions. These interactions are for not-yet-desc= ribed use cases. (if other use cases exist, then let's look at them and= add the interaction mechanisms if needed) We don't know what parameter= s will be needed, and overloading the parameters and letting the Client do = whatever it wants does not seem like it will interoperate -- the Client dec= ides it wants to do some new interaction, and uses the parameters in a way = the GS does not understand.
=C2= =A0
=C2=A0
<= /div>
=C2=A0
= =C2=A0
=C2=A0
=E2=80=93
Annabelle Backman (she/her)=
AWS Identi= ty
<= a href=3D"https://aws.amazon.com/identity/" style=3D"color:blue;text-decora= tion:underline" target=3D"_blank">https= ://aws.amazon.com/identity/
=C2=A0
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.= org> on behalf of Dick Hardt <dick.= hardt@gmail.com>
Date:=C2=A0Tuesday, February= 18, 2020 at 6:04 PM
To:=C2=A0"txauth@ietf.org" <txauth@ietf= .org>
Subject:=C2=A0[Txauth] Fwd: New Version= Notification for draft-hardt-xauth-protocol-03.txt
=C2=A0
Added in user code interaction and aligned QR code to be a superset= of user code.
Fixed descriptions.<= u>

=C2=A0

---------- Forwarded message ---------From: <internet-drafts@ietf.org&= gt;
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: New Version Notificat= ion for draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>



A new version of I-D, draft-hardt-x= auth-protocol-03.txt
has been successfully submitted by Dick Hardt and p= osted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 = =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
= Document date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 53
UR= L:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.iet= f.org/internet-drafts/draft-hardt-xauth-protocol-03.txt
Status:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardt-xauth-proto= col/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hardt-xa= uth-protocol-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker..iet= f.org/doc/html/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol= -03

Abstract:
=C2=A0 =C2=A0Client software often desires reso= urces or identity claims that are
=C2=A0 =C2=A0independent of the client= .=C2=A0 This protocol allows a user and/or
=C2=A0 =C2=A0resource owner t= o delegate resource authorization and/or release of
=C2=A0 =C2=A0identit= y claims to a server.=C2=A0 Client software can then request access
=C2= =A0 =C2=A0to resources and/or identity claims by calling the server.=C2=A0 = The
=C2=A0 =C2=A0server acquires consent and authorization from the user= and/or
=C2=A0 =C2=A0resource owner if required, and then returns to the= client software
=C2=A0 =C2=A0the authorization and identity claims that= were approved.=C2=A0 This
=C2=A0 =C2=A0protocol can be extended to supp= ort alternative authorizations,
=C2=A0 =C2=A0claims, interactions, and c= lient authentication mechanisms.




Please note that it may= take a couple of minutes from the time of submission
until the htmlized= version and diff are available at=C2=A0tools.ietf.org.

The IETF Secretariat

<= /div>
=E1=90=A7
--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--000000000000f0a216059faab88f-- From nobody Fri Feb 28 14:57:03 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C13A1FE3 for ; Fri, 28 Feb 2020 14:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 u9VLXFdxpDUi for ; Fri, 28 Feb 2020 14:56:52 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450: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 0AE8C3A1F85 for ; Fri, 28 Feb 2020 14:56:51 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id c23so3288122lfi.7 for ; Fri, 28 Feb 2020 14:56:51 -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=agpi0QyL2NJT9t/kfrC0Dn5f+4KGuRcvC0cLqhRBIJM=; b=RMafeC06NjQXvZyJGoCuMekBv8u3h4IWZrA1NVFV/DmCZaTTzhUeZVrQWJPz2RcnOD fijOhVCzBZ5i5iU+1h0AOq6gOOLOM9WQ/2rAnZ18aHy3SLG4t84/+cTCgdytGOOz5IEM 98z1bzJpGa5899rNhyDRIHaJ0x2YrMmJg1kMrgb30jYwCUK6tjml3A9zkM8PyR2QVb5+ wnGpjlc12x2ldcioYHlJrDEbdxnepPstYvsfkhDzrWWT2g76B7rSgk7OAH6nrgdZW9Co G2pUAqJxNoXXZXpHiHnHP59JR80KTr9jPN1Bir6OgOB26/ZBUXm+083NJDFGM0KwpuGW y6ig== 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=agpi0QyL2NJT9t/kfrC0Dn5f+4KGuRcvC0cLqhRBIJM=; b=gaChlYXeftk0/4SbSyhlDk4nh7H6YCW+G0w6nlQOHBpBvsyUi4azlco+QZDxTCtjaU j/xAf6LyZSBhROO3JdnnRuT5Wa1D6azi3gLStVtto28+6xGPGzVssH46BOhBAzrnAvel ommuS1bbKwLL3ZIgFsK4ogFu/Vd7amrzP3YhVbicWBz/XCP+ZNGY2B23Bs6LQ0V/Wm4H VZbiD2K9vuwjXyMQQxj3rC9mbSQ844S3Fw0nncy1HkVdx7XHiVn1xa2vmp8X5R2Ps4y4 K4Vp7Yyqk7fwItTNY7g8JE5MuLiZrn5mmVhmTbhBdnIaMmO5PFx7GcLisIhbqgeNfSrI 58xQ== X-Gm-Message-State: ANhLgQ0BwKhhICCj383chVy8h6rgJi3bJSsl1neU/Q672sxxe7xPTAYk np3tvdDy55cxhK6j4V5GmWocNkZQ3jD9iqCHAb+1mrHo X-Google-Smtp-Source: ADFU+vtDdeKKbXGm8UE3fWCP02cS8KVE811h6vENJ/VsyX58txdvkRddlmyssPnqg1J0/daqW9RmFTkwyHHjP0vPuRM= X-Received: by 2002:a05:6512:31c2:: with SMTP id j2mr3865774lfe.23.1582930609981; Fri, 28 Feb 2020 14:56:49 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu> In-Reply-To: <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu> From: Dick Hardt Date: Fri, 28 Feb 2020 14:56:23 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b64f8f059faac03b" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:57:02 -0000 --000000000000b64f8f059faac03b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thinking about this, the fixation attack is against the Client where the attacker is at the Client, and the victim is at the AS. Does the AS need to know the attacker and victim are different? IE, if the client knows that the User at the Client is the same as the User that came from the AS, have we prevented the attack? =E1=90=A7 On Tue, Feb 25, 2020 at 7:38 AM Justin Richer wrote: > That=E2=80=99s good enough for the AS, but is it good enough for the clie= nt? The > hash allows the client to make sure that the reference they=E2=80=99re ge= tting back > in the front channel is related to something they sent out in the first > place. We originally had a =E2=80=9Cstate=E2=80=9D parameter like OAuth 2= for this purpose, > but realized that since the client can push its callback URI we didn=E2= =80=99t need > that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80=9D a= nd =E2=80=9Cc_hash=E2=80=9D have > in OIDC, we added this simple hash parameter that the client can check > before it calls the TX endpoint again. > > =E2=80=94 Justin > > On Feb 21, 2020, at 8:12 PM, Dick Hardt wrote: > > > The Client presents the interact_ref to the AS with the transaction > handle. The AS will be able to tell the Client if the interact_ref belong= s > to the transaction. > > Why is that enough? > =E1=90=A7 > > On Fri, Feb 21, 2020 at 1:51 PM Justin Richer wrote: > >> The hash offers the same kinds of protections to the client that the OID= C >> nonce does =E2=80=94 it binds the front channel return to something you = get from >> the back channel. >> >> In other words, the client can be sure that the return value that it=E2= =80=99s >> getting is related to the request it made in the first place, and not >> another one. Clients using per-request redirect URIs can also help with >> this, but this is something that the server can provide directly. >> >> =E2=80=94 Justin >> >> On Feb 21, 2020, at 4:14 PM, Dick Hardt wrote: >> >> While I can see the value of the interact_ref (aka interaction_ref) in >> the return URI that allows the Client to ensure the user that started th= e >> transaction is the same one that interacted at the AS, I don't understan= d >> why a hash is required. Would you elaborate? >> =E1=90=A7 >> >> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer wrote: >> >>> But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, w= hich is a very >>> common case. For cases where the client doesn=E2=80=99t expect the user= to come >>> back on the same channel, then they don=E2=80=99t use the callback mech= anism. They >>> might use the =E2=80=9Cfinish message=E2=80=9D URL that Annabelle menti= oned in the other >>> thread, or they might just print out =E2=80=9Cyou=E2=80=99re done now!= =E2=80=9D at the AS, which is >>> common today. >>> >>> XYZ=E2=80=99s interaction structure allows the composition of these thi= ngs, >>> under the control of the client. This is exactly why it=E2=80=99s impor= tant to be >>> able to specify how to get to the AS and how to get back as separate it= ems, >>> so that the client can compose the combination that makes the most sens= e >>> for that client. >>> >>> =E2=80=94 Justin >>> >>> >>> On Feb 21, 2020, at 3:52 PM, Dick Hardt wrote: >>> >>> I got ahead of myself. A completion URI protects the User only if the >>> User is sent back to the same channel the transaction started so the Cl= ient >>> can confirm it is the same User that started the transaction. >>> >>> so this does not help the security: >>> >>> "Being able to provide a completion URI even if the user is starting on >>> a device is a great insight on how to address the threat above." >>> >>> =E1=90=A7 >>> >>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt >>> wrote: >>> >>>> The lightbulb finally clicked on for me. Thanks for your patience. >>>> >>>> The threat you are describing is where the attacker starts a >>>> transaction at the client, and gets the victim to complete it. Correct= ? >>>> >>>> I still think the Client should be able to signal if it will be doing = a >>>> redirect vs showing a QR code (or wants to do both). >>>> >>>> Being able to provide a completion URI even if the user is starting on >>>> a device is a great insight on how to address the threat above. >>>> >>>> I'm going to ponder how to align XAuth more with these features of XYZ= . >>>> =E1=90=A7 >>>> >>>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer wrote= : >>>> >>>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer wrote= : >>>>> >>>>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized= that >>>>>> both the QR Code and Authorization Code, and that the only differenc= e is >>>>>> how the user gets back to the client. So instead of inventing a new >>>>>> type of interaction, we split them. In XYZ, we have: >>>>>> >>>>> >>>>> This sentence looks to be missing something. >>>>> >>>>> >>>>> Apologies: We realized they both used AS-composed URLs to get the use= r >>>>> to the AS in a web browser for interaction purposes. >>>>> >>>>> >>>>> >>>>>> >>>>>> - redirect: tells the AS that the client can send the user to an >>>>>> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets t= hat info to the >>>>>> user; could be a redirect or an image or send a push notification to= a >>>>>> secondary device, we don=E2=80=99t care as long as the user shows up= in a browser >>>>>> at the AS =E2=80=94 so maybe this field can be renamed to be more un= iversally >>>>>> accurate) >>>>>> >>>>> >>>>> As stated in this thread, it may be useful for the AS to know if the >>>>> URL will be in a QR code, or in a full redirect. >>>>> >>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a >>>>> Client has to do, so it needs to know the difference between a popup,= and a >>>>> full browser redirect. This is targetted at SPAs, where an additional= URL >>>>> to redirect to is extra work. >>>>> >>>>> >>>>>> - code: tells the AS that the client can present a short code the >>>>>> user can type (along with a static URL the user can get to, maybe by= typing >>>>>> the URL manually, but it=E2=80=99s not dynamic/arbitrary like the re= direct method) >>>>>> - callback: tells the AS that the client can receive the completion >>>>>> message from a front channel interaction through a redirect. Note th= at the >>>>>> client might have gotten to the AS through a redirect on-device, thr= ough a >>>>>> QR-code off device, or through some other magic, and this field isn= =E2=80=99t >>>>>> concerned with that =E2=80=94 it=E2=80=99s only concerned with how t= o get the user :back:. >>>>>> >>>>> >>>>> In a full redirect, the Client wants the AS to send the user back so >>>>> that it can continue. >>>>> >>>>> The only parameter in the completion message is the nonce, which seem= s >>>>> superfluous. See below. >>>>> >>>>> >>>>>> >>>>>> These three can be combined in different ways depending on what you >>>>>> want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and= OAuth2 style >>>>>> authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and= =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re >>>>>> doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. I= f you=E2=80=99re doing just a QR code >>>>>> with polling, you use just =E2=80=9Credirect=E2=80=9D to get the lon= g URL. If you=E2=80=99re doing >>>>>> a user code and a QR code together, you use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccode=E2=80=9D to get >>>>>> the long URL and the short code not he screen at the same time. >>>>>> >>>>>> On top of that, they can be combined with other methods. Maybe I can >>>>>> send the user to an arbitrary URL but also display a human-readable >>>>>> verification code (like CIBA), or send something in a push notificat= ion but >>>>>> also give them a message to type, or I=E2=80=99m getting claims from= an agent but I >>>>>> want them redirected back through the browser. The client gets to de= cide >>>>>> what kinds of interaction it can do and how to use these pieces in w= ays >>>>>> that make the most sense. >>>>>> >>>>> >>>>> Per my question later in this thread, why would the Client not know >>>>> what interaction it wants prior to the request? >>>>> >>>>> >>>>> What do you mean? The client does know what it wants and that=E2=80= =99s why >>>>> it=E2=80=99s asking for what it wants. We=E2=80=99re debating differe= nt methods for the >>>>> client to ask for what it wants. This question does not make sense to= me. >>>>> >>>>> >>>>> If the AS is doing CIBA, that is not a decision just for the Client. >>>>> Both the AS and the Client need to know they are doing CIBA. (FWIW: I= think >>>>> this work supersedes CIBA) >>>>> >>>>> >>>>> As I=E2=80=99ve stated previously, I believe the interaction methods = here can >>>>> supersede CIBA. >>>>> >>>>> >>>>> Additionally, different interactions have different risk profiles. >>>>> Sophisticated ASes will use that signal in the risk assessment, and m= ay do >>>>> ask for additional authentication or verification. >>>>> >>>>> >>>>> >>>>> Yes, exactly my point. Because different interactions have different >>>>> risks, the AS will need to be able to decide which interactions it=E2= =80=99s OK >>>>> with for a given request. This could vary based on what=E2=80=99s bei= ng requested, >>>>> or who=E2=80=99s doing the requesting. >>>>> >>>>> >>>>>> An interesting difference between XYZ and XAuth=E2=80=99s approaches= is that >>>>>> XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D in= the callback response >>>>>> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80= =9D field). In XYZ, you >>>>>> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with = a pair of nonces >>>>>> generated by the client and the AS in the back channel. This binds t= he >>>>>> front channel response to both the back channel request and the back >>>>>> channel response for a given transaction =E2=80=94 and note that I= =E2=80=99m really open to >>>>>> having a better way to generate and calculate such a binding, but I = think >>>>>> this works. In any event, this protects the client from session fixa= tion >>>>>> and injection on the return from the front channel that it=E2=80=99s= susceptible to >>>>>> in a pure polling model, and the hashing approach basically combines= the >>>>>> security parameters of the OAuth 2 authorization code and (to an ext= ent) >>>>>> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in on= e element. This is only >>>>>> applicable if you=E2=80=99re coming back to the client and you can v= alidate the >>>>>> hash and present the reference parameter. If you=E2=80=99re doing ju= st plain >>>>>> polling, you don=E2=80=99t have that protection =E2=80=94 but the cl= ient and the AS are >>>>>> aware of that risk, and there=E2=80=99s an option to prevent it. >>>>>> >>>>>> XAuth has removed the authorization code concept in its redirect >>>>>> return, and clients only do polling against the GS API in order to g= et >>>>>> tokens. While I obviously think it=E2=80=99s very valuable to remove= things from >>>>>> the front channel, I don=E2=80=99t think this is something we can re= move without >>>>>> opening up attack surfaces that have already been identified in prev= ious >>>>>> protocols. I would like to understand why XAuth is not susceptible t= o the >>>>>> same kinds of attacks, or if it is, what mitigations there are for t= hem. >>>>>> >>>>> >>>>> Unlike OAuth 2.0, there are no parameters in the front channel >>>>> response to the Client. The redirect back to the Client is only neede= d to >>>>> return the interaction back to the Client. >>>>> >>>>> >>>>> This argument rings tautologically hollow =E2=80=94 there are no para= meters >>>>> because you=E2=80=99ve defined that there aren=E2=80=99t any in XAuth= . XYZ does have >>>>> parameters, to tie the front and back channel requests together when = doing >>>>> redirect back and forth. >>>>> >>>>> If you=E2=80=99re not doing a redirect back (ie, not sending a =E2=80= =9Ccallback=E2=80=9D >>>>> interaction block), then it=E2=80=99s a polling mechanism like XAuth,= the device >>>>> flow, etc. There are very real risks to this. >>>>> >>>>> >>>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>>>> >>>>> In OAuth, the AS gives a code to the User to give to the Client that >>>>> the Client then gives to the GS. >>>>> >>>>> In XAuth, the AS gives a "code" to the Client that givers it to the >>>>> User to give to the GS. >>>>> >>>>> In XAuth, the "code" is either a user code, or something embedded in >>>>> the URI the User is redirected to. >>>>> >>>>> Therefore, there is nothing to protect in the redirect back to the >>>>> Client. >>>>> >>>>> If I'm missing an attack, please elaborate how it would happen. >>>>> >>>>> >>>>> One form of impersonation is well documented: >>>>> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-a= a759250a0e7 >>>>> >>>>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar requ= est initiation step to >>>>> what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s susc= eptible to the >>>>> same kind of issue. >>>>> >>>>> >>>>> >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < >>>>>> richanna=3D40amazon.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my comment= s here to >>>>>> interaction mode design, setting aside whether or not we need =E2=80= =9Cpopup=E2=80=9D. :D >>>>>> >>>>>> Once the GS hands that URI back to the Client, it has zero control >>>>>> over how the Client uses it. The Client could present any URI (of a >>>>>> reasonable size) into a QR code, or present it as a clickable link, = or >>>>>> redirect to it, or open it in an external browser, or do any number = of >>>>>> other as-yet-not-invented things with it. Moreover, the Client may n= ot know >>>>>> yet what it wants to do with it. So what value is there in distingui= shing >>>>>> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI= want a URI for a QR code=E2=80=9D vs. >>>>>> =E2=80=9CI want a URI for =E2=80=9D? >>>>>> >>>>>> Even if we consider things like QR code data capacity, that=E2=80=99= s really >>>>>> just a URI length limitation, which could apply to non-QR interactio= n >>>>>> modes, e.g., if the Client device wants to communicate the URI over = an >>>>>> extremely bandwidth-constrained channel. And it=E2=80=99s not clear = to me how >>>>>> including a URI length limitation in the request helps. If a GS is c= apable >>>>>> of generating a shorter URI, why wouldn=E2=80=99t it always return t= hat? On the >>>>>> client side, it can look at the length of the URI provided and decid= e what >>>>>> to do with it (e.g., render a QR code or display it or do nothing wi= th it). >>>>>> >>>>>> So that really leaves us with two interaction modes that we need: >>>>>> >>>>>> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be= human friendly; >>>>>> and >>>>>> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code= entry page, >>>>>> both of which are human-friendly. >>>>>> >>>>>> >>>>>> Those could be combinable to get both, and even if we don=E2=80=99t = go down >>>>>> the multiple interaction mode route we could add the full URI to the= =E2=80=9Ccode=E2=80=9D >>>>>> interaction object. It wouldn=E2=80=99t hurt anything to do so. >>>>>> >>>>>> =E2=80=93 >>>>>> Annabelle Backman (she/her) >>>>>> AWS Identity >>>>>> https://aws.amazon.com/identity/ >>>>>> >>>>>> >>>>>> *From: *Txauth on behalf of Dick Hardt < >>>>>> dick.hardt@gmail.com> >>>>>> *Date: *Tuesday, February 18, 2020 at 6:04 PM >>>>>> *To: *"txauth@ietf.org" >>>>>> *Subject: *[Txauth] Fwd: New Version Notification for >>>>>> draft-hardt-xauth-protocol-03.txt >>>>>> >>>>>> Added in user code interaction and aligned QR code to be a superset >>>>>> of user code. >>>>>> Fixed descriptions. >>>>>> >>>>>> >>>>>> ---------- Forwarded message --------- >>>>>> From: >>>>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>>>> Subject: New Version Notification for >>>>>> draft-hardt-xauth-protocol-03.txt >>>>>> To: Dick Hardt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>>>> has been successfully submitted by Dick Hardt and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-hardt-xauth-protocol >>>>>> Revision: 03 >>>>>> Title: The XAuth Protocol >>>>>> Document date: 2020-02-18 >>>>>> Group: Individual Submission >>>>>> Pages: 53 >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.t= xt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 >>>>>> Htmlized: >>>>>> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol >>>>>> Diff: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 >>>>>> >>>>>> Abstract: >>>>>> Client software often desires resources or identity claims that a= re >>>>>> independent of the client. This protocol allows a user and/or >>>>>> resource owner to delegate resource authorization and/or release = of >>>>>> identity claims to a server. Client software can then request >>>>>> access >>>>>> to resources and/or identity claims by calling the server. The >>>>>> server acquires consent and authorization from the user and/or >>>>>> resource owner if required, and then returns to the client softwa= re >>>>>> the authorization and identity claims that were approved. This >>>>>> protocol can be extended to support alternative authorizations, >>>>>> claims, interactions, and client authentication mechanisms. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> =E1=90=A7 >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>> >>> >> > --000000000000b64f8f059faac03b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking about this, the fixation attack is against the Cl= ient where the attacker is at the Client, and the victim is at the AS.
=
Does the AS need to know the attacker and victim are differe= nt? IE, if the client knows that the User at the Client is the same as the = User that came from the AS, have we prevented the attack?
3D""=E1=90=A7

On Tue, Feb 25, 2020 at 7:38 AM Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s good enough for the AS, but is it good enough for= the client? The hash allows the client to make sure that the reference the= y=E2=80=99re getting back in the front channel is related to something they= sent out in the first place. We originally had a =E2=80=9Cstate=E2=80=9D p= arameter like OAuth 2 for this purpose, but realized that since the client = can push its callback URI we didn=E2=80=99t need that. But to get the kind = of functionality that =E2=80=9Cnonce=E2=80=9D and =E2=80=9Cc_hash=E2=80=9D = have in OIDC, we added this simple hash parameter that the client can check= before it calls the TX endpoint again.

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

On Feb 21, 2020, at 8:12 = PM, Dick Hardt <dick.hardt@gmail.com> wrote:

<= br>
The Client presents the interact_ref to the AS with the trans= action handle. The AS will be able to tell the Client if the interact_ref b= elongs to the transaction.

Why is that enough?
3D==E1=90=A7

On Fri, Feb 21, 2020 at 1:51 PM Jus= tin Richer <jricher= @mit.edu> wrote:
The hash offers the same kinds of protections to the client th= at the OIDC nonce does =E2=80=94 it binds the front channel return to somet= hing you get from the back channel.=C2=A0

In other words= , the client can be sure that the return value that it=E2=80=99s getting is= related to the request it made in the first place, and not another one. Cl= ients using per-request redirect URIs can also help with this, but this is = something that the server can provide directly.

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

On Feb 21= , 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

While I can see the value of the interact_ref (aka interaction_re= f) in the return URI that allows the Client to ensure the user that started= the transaction is the same one that interacted at the AS, I don't und= erstand why a hash is required. Would you elaborate?
3D""= =E1=90=A7

On Fri, Feb 21, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote= :
But that= =E2=80=99s exactly the point =E2=80=94 it helps in that case, which is a ve= ry common case. For cases where the client doesn=E2=80=99t expect the user = to come back on the same channel, then they don=E2=80=99t use the callback = mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D URL that Ann= abelle mentioned in the other thread, or they might just print out =E2=80= =9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is common today.
=
XYZ=E2=80=99s interaction structure allows the composition o= f these things, under the control of the client. This is exactly why it=E2= =80=99s important to be able to specify how to get to the AS and how to get= back as separate items, so that the client can compose the combination tha= t makes the most sense for that client.

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


On Feb = 21, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I got ahead of myself. A completion URI protects the User only = if the User is sent back to the same channel the transaction started so the= Client can confirm it is the same User that started the transaction.

so this does not help the security:

<= div>"Being able to provide a completion URI even if the user is starti= ng on a device is a great insight on how to address the threat above."=

3D""=E1=90=A7

On Fri, Feb 2= 1, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The lightbulb finall= y clicked on for me. Thanks for your patience.

The threa= t you are describing is where the attacker starts a transaction at the clie= nt, and gets the victim to complete it. Correct?

I s= till think the Client should be able to signal if it will be doing a redire= ct vs showing a QR code (or wants to do both).

Bei= ng able to provide a completion URI even if the user is starting on a devic= e is a great insight on how to address the threat above.=C2=A0

=
I'm going to ponder how to align XAuth more with these featu= res of XYZ.
3D""=E1=90=A7
On Fri, F= eb 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at 1:54 PM, Dick H= ardt <dick.har= dt@gmail.com> wrote:



On Fri, Feb 21, 2020 at 8:38 AM Justin Ri= cher <jricher@mit.e= du> wrote:
In XYZ we realized that both the QR Code and = Authorization Code, and that the only difference is how the user gets back = to the client. So instead of inventing a new type of interaction, we= split them. In XYZ, we have:

This sentence looks to be missing = something.

A= pologies: We realized they both used AS-composed URLs to get the user to th= e AS in a web browser for interaction purposes.

=C2=A0

=C2=A0- redirect: tells the AS that the client can send the user to an arb= itrary URL (and the AS doesn=E2=80=99t care how the client gets that info t= o the user; could be a redirect or an image or send a push notification to = a secondary device, we don=E2=80=99t care as long as the user shows up in a= browser at the AS =E2=80=94 so maybe this field can be renamed to be more = universally accurate)

As stated= in this thread, it may be useful for the AS to know if the URL will be in = a QR code, or in a full redirect.

In XAuth, the GS= (AS min XYA) closes the popup to minimize what a Client has to do, so it ne= eds to know the difference between a popup, and a full browser redirect. Th= is is targetted at SPAs, where an additional URL to redirect to is extra wo= rk.
=C2=A0
=C2=A0- code: tells the AS that the client can present a short c= ode the user can type (along with a static URL the user can get to, maybe b= y typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method)
=C2=A0- callback: tells the AS that the client can= receive the completion message from a front channel interaction through a = redirect. Note that the client might have gotten to the AS through a redire= ct on-device, through a QR-code off device, or through some other magic, an= d this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s only = concerned with how to get the user :back:.

In a full redirect, the Client wants the AS to send the u= ser back so that it can continue.

The only paramet= er in the completion message is the nonce, which seems superfluous. See bel= ow.
=C2=A0

These three can be combined in different way= s depending on what you want to do at the client. Let=E2=80=99s say you=E2= =80=99re doing and OAuth2 style authorization code, you=E2=80=99d use =E2= =80=9Credirect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2= =80=99re doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D.= If you=E2=80=99re doing just a QR code with polling, you use just =E2=80= =9Credirect=E2=80=9D to get the long URL. If you=E2=80=99re doing a user co= de and a QR code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9C= code=E2=80=9D to get the long URL and the short code not he screen at the s= ame time.=C2=A0

On top of that, they can be combin= ed with other methods. Maybe I can send the user to an arbitrary URL but al= so display a human-readable verification code (like CIBA), or send somethin= g in a push notification but also give them a message to type, or I=E2=80= =99m getting claims from an agent but I want them redirected back through t= he browser. The client gets to decide what kinds of interaction it can do a= nd how to use these pieces in ways that make the most sense.

Per my question later in this thread, w= hy would the Client not know what interaction it wants prior to the request= ?

What do you mean?= The client does know what it wants and that=E2=80=99s why it=E2=80=99s ask= ing for what it wants. We=E2=80=99re debating different methods for the cli= ent to ask for what it wants. This question does not make sense to me.

If the AS is doing CIBA, that is not a decision ju= st for the Client. Both the AS and the Client need to know they are doing C= IBA. (FWIW: I think this work supersedes CIBA)

As I=E2=80=99ve stated previously, I believe th= e interaction methods here can supersede CIBA.


Additionally, different interactions have different risk profiles. Sophist= icated ASes will use that signal in the risk assessment, and may do ask for= additional authentication or verification.
=C2=A0

Yes, exactly my point. Because di= fferent interactions have different risks, the AS will need to be able to d= ecide which interactions it=E2=80=99s OK with for a given request. This cou= ld vary based on what=E2=80=99s being requested, or who=E2=80=99s doing the= requesting.


An interesting difference between XYZ and XAuth= =E2=80=99s approaches is that XYZ keeps the concept of the =E2=80=9Cauthori= zation code=E2=80=9D in the callback response (which in turn is based on th= e OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an =E2= =80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of nonces = generated by the client and the AS in the back channel. This binds the fron= t channel response to both the back channel request and the back channel re= sponse for a given transaction =E2=80=94 and note that I=E2=80=99m really o= pen to having a better way to generate and calculate such a binding, but I = think this works. In any event, this protects the client from session fixat= ion and injection on the return from the front channel that it=E2=80=99s su= sceptible to in a pure polling model, and the hashing approach basically co= mbines the security parameters of the OAuth 2 authorization code and (to an= extent) state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in = one element. This is only applicable if you=E2=80=99re coming back to the c= lient and you can validate the hash and present the reference parameter. If= you=E2=80=99re doing just plain polling, you don=E2=80=99t have that prote= ction =E2=80=94 but the client and the AS are aware of that risk, and there= =E2=80=99s an option to prevent it.

XAuth has remo= ved the authorization code concept in its redirect return, and clients only= do polling against the GS API in order to get tokens. While I obviously th= ink it=E2=80=99s very valuable to remove things from the front channel, I d= on=E2=80=99t think this is something we can remove without opening up attac= k surfaces that have already been identified in previous protocols. I would= like to understand why XAuth is not susceptible to the same kinds of attac= ks, or if it is, what mitigations there are for them.=C2=A0

Unlike OAuth 2.0, there are no parameter= s in the front channel response to the Client. The redirect back to the Cli= ent is only needed to return the interaction back to the Client.

This argument rings tautologi= cally hollow =E2=80=94 there are no parameters because you=E2=80=99ve defin= ed that there aren=E2=80=99t any in XAuth. XYZ does have parameters, to tie= the front and back channel requests together when doing redirect back and = forth.

If you=E2=80=99re not doing a redirect back= (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), then it= =E2=80=99s a polling mechanism like XAuth, the device flow, etc. There are = very real risks to this.


XAuth (and XYZ) hav= e a different flow than OAuth 2.0 (or OAuth 1.0)

I= n OAuth, the AS gives a code to the User to give to the Client that the Cli= ent then gives to the GS.

In XAuth, the AS gives a= "code" to the Client that givers it to the User to give to the G= S.

In XAuth, the "code" is either a user= code, or something embedded in the URI the User is redirected to.

Therefore, there is nothing to protect in the redirect bac= k to the Client.

If I'm missing an attack, ple= ase elaborate how it would happen.


OAuth 1.0= =E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar request initiation = step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s su= sceptible to the same kind of issue.

=C2=A0

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

On Feb 20, 2020= , at 3:21 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc= .ietf.org> wrote:

Thank= s for the update, Dick! I=E2=80=99m going to confine my comments here to in= teraction mode design, setting aside whether or not we need =E2=80=9Cpopup= =E2=80=9D. :D
=C2=A0
Once the GS hands that URI back to the Client, it has zero control over= how the Client uses it. The Client could present any URI (of a reasonable = size) into a QR code, or present it as a clickable link, or redirect to it,= or open it in an external browser, or do any number of other as-yet-not-in= vented things with it. Moreover, the Client may not know yet what it wants = to do with it. So what value is there in distinguishing between =E2=80=9CI = want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code= =E2=80=9D vs. =E2=80=9CI want a URI for <some other machine-driven inter= action mode>=E2=80=9D?
=C2=A0=
Even if we consider things like QR code data capacity, that= =E2=80=99s really just a URI length limitation, which could apply to non-QR= interaction modes, e.g., if the Client device wants to communicate the URI= over an extremely bandwidth-constrained channel. And it=E2=80=99s not clea= r to me how including a URI length limitation in the request helps. If a GS= is capable of generating a shorter URI, why wouldn=E2=80=99t it always ret= urn that? On the client side, it can look at the length of the URI provided= and decide what to do with it (e.g., render a QR code or display it or do = nothing with it).
=C2=A0
So that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not b= e human friendly; and
  • =E2=80=9Ccode=E2=80=9D, wh= ich returns a code and URI for a code entry page, both of which are human-f= riendly.
=C2=A0
Those could be combinable to get both, and even if we don=E2=80=99t go d= own the multiple interaction mode route we could add the full URI to the = =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt anythin= g to do so.
=C2=A0
=E2=80=93
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">Annabelle Backman (she/her)<= u>
AWS Identity=
= =C2=A0
=C2=A0
From:=C2=A0Txauth= <txauth-bo= unces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:<= span>=C2=A0Tuesday, February 18, 2020 at 6:04 PM
To:= =C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0[Txau= th] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt<= /u>
=C2=A0
Added in user code interaction and aligned QR c= ode to be a superset of user code.
= Fixed descriptions.

=C2=A0

---------- Forwarded= message ---------
From: <internet-= drafts@ietf.org>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: N= ew Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick H= ardt <dick.hardt@gmail.com><= u>




A new version o= f I-D, draft-hardt-xauth-protocol-03.txt
has been successfully submitted= by Dick Hardt and posted to the
IETF repository.

Name:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2= =A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The = XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.= txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/dr= aft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.or= g/html/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 = =C2=A0ht= tps://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft= -hardt-xauth-protocol-03

Abstract:
=C2=A0 =C2=A0Client softwa= re often desires resources or identity claims that are
=C2=A0 =C2=A0inde= pendent of the client.=C2=A0 This protocol allows a user and/or
=C2=A0 = =C2=A0resource owner to delegate resource authorization and/or release of=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then = request access
=C2=A0 =C2=A0to resources and/or identity claims by calli= ng the server.=C2=A0 The
=C2=A0 =C2=A0server acquires consent and author= ization from the user and/or
=C2=A0 =C2=A0resource owner if required, an= d then returns to the client software
=C2=A0 =C2=A0the authorization and= identity claims that were approved.=C2=A0 This
=C2=A0 =C2=A0protocol ca= n be extended to support alternative authorizations,
=C2=A0 =C2=A0claims= , interactions, and client authentication mechanisms.




Pl= ease note that it may take a couple of minutes from the time of submission<= br>until the htmlized version and diff are available at=C2=A0<= a href=3D"http://tools.ietf.org/" style=3D"color:blue;text-decoration:under= line" target=3D"_blank">tools.ietf.org.

The IETF Secretariat<= /u>

=E1=90=A7
--=C2=A0
T= xauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth





--000000000000b64f8f059faac03b-- From nobody Fri Feb 28 15:20:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211CC3A0E89 for ; Fri, 28 Feb 2020 15:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 w96MSLSxsTIO for ; Fri, 28 Feb 2020 15:20:49 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 B313F3A0E76 for ; Fri, 28 Feb 2020 15:20:48 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id d27so175251lfq.12 for ; Fri, 28 Feb 2020 15:20:48 -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=NIoHjsotueulZh4D8LrPwiCVmKyW9cuNgGV2WEk1PMY=; b=Ul6hynQY7WNvXFsTtbk+KXLWmCa+ISAvlscRd19L2Esx1bf9KgCXPIKlO71PKckNGb +ig8sFafCYgYj6aHu8erlcmLXIpCw7IFOHC7BXr4Al57qg5GWYcWUmXyEdkvSl30uWUV AbpWIUj6JS/6pTdHttuGdfOBtAWU9Ufn/ULcyA8SDHkfcR1exlUMaUuIvKaD/jtLKisJ 4K5AZZpTpHivsExod4KaYtRP0GfccvfTvnJllZjMYJQ+Pjwiel044Tfln/PLYpPmogi7 GQP/Fn5WByKUrTpdAg+Gc7egO0bwCGMQuf80YPSdLFvQ0tNOv0UzHP7iscwucrKlwe0A EvYg== 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=NIoHjsotueulZh4D8LrPwiCVmKyW9cuNgGV2WEk1PMY=; b=NvwcL/jWmLfZn2gZlJgZ2mu28rv3CF6Oq6RzNGrvzH2NbmwNIbtpN+3/HJ/dee0nm8 4mPCjYq9bzLOiPvRJP4LG6RjXP0WLUt4ZXYtO12wBcHGDrqxadZn35e4c8qrKTdAcI6K pQaVHOpVTj5vi08XZOM5HEvMv5g1Al+YyUhq3VdgYuk7eFkJWZV7ZjaV6cesPa8WLszx qKE9uGktCQeYJ44J/iazSnkgkOnukebMNiEFGdzFlGiEEdW8hWrf1ROt3b6tqNCvwRHM c0LYUXzZTj+Mm62sQ0FELoSVKG612wq4lgIR3sdNf/gSUwYRQY1terBgGv9mzl5/F625 UqBA== X-Gm-Message-State: ANhLgQ2NVVSxs61TR1j/E4J+YuLnu0d25ArQo3vMK4vRBcIN4yxRQ9IP Ra+MDSgKWmekagr+YDc+l6r/9apJeoBQMXOAMEreAGZokyU= X-Google-Smtp-Source: ADFU+vtarl/dRs8yVm25N+w4LOJo4/BXg7eZzJesF8wtAoCsTcnuK+YVXiOi/aWDW718WQ870Uv//fm2PC5AA4HH270= X-Received: by 2002:a19:8988:: with SMTP id l130mr3898414lfd.91.1582932046448; Fri, 28 Feb 2020 15:20:46 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Fri, 28 Feb 2020 15:20:20 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000550cdf059fab16ad" Archived-At: Subject: [Txauth] tentative side meetings at 107 Vancouver X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 23:20:50 -0000 --000000000000550cdf059fab16ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The IETF agenda has been finalized, and the TxAuth BoF is 10-12 on Wednesday. I have tentatively reserved a side meeting for a 16 person room from 10-11:30 on Tuesday, and a 40 person room from 3-4PM on Wednesday afternoon. https://trac.ietf.org/trac/ietf/meeting/wiki/107sidemeetings /Dick =E1=90=A7 --000000000000550cdf059fab16ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The IETF agenda has been finalized, and the TxAuth BoF is = 10-12 on Wednesday.

I have tentatively reserved a side m= eeting for a 16 person room from 10-11:30 on Tuesday, and a 40 person room = from 3-4PM on Wednesday afternoon.=C2=A0


<= /div>
/Dick

3D""=E1=90=A7 --000000000000550cdf059fab16ad--
On Fri, Feb 21, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
But that=E2=80=99s exactly the point =E2=80=94 it helps in that c= ase, which is a very common case. For cases where the client doesn=E2=80=99= t expect the user to come back on the same channel, then they don=E2=80=99t= use the callback mechanism. They might use the =E2=80=9Cfinish message=E2= =80=9D URL that Annabelle mentioned in the other thread, or they might just= print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is c= ommon today.

XYZ=E2=80=99s interaction structure allows = the composition of these things, under the control of the client. This is e= xactly why it=E2=80=99s important to be able to specify how to get to the A= S and how to get back as separate items, so that the client can compose the= combination that makes the most sense for that client.

=C2=A0=E2=80=94 Justin


On Feb 21, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I got ahead of myself. A completion URI protects= the User only if the User is sent back to the same channel the transaction= started so the Client can confirm it is the same User that started the tra= nsaction.

so this does not help the security:
<= div>
"Being able to provide a completion URI even if the= user is starting on a device is a great insight on how to address the thre= at above."

3D""=E1=90=A7

On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The l= ightbulb finally clicked on for me. Thanks for your patience.

The threat you are describing is where the attacker starts a transact= ion at the client, and gets the victim to complete it. Correct?
I still think the Client should be able to signal if it will be= doing a redirect vs showing a QR code (or wants to do both).
Being able to provide a completion URI even if the user is star= ting on a device is a great insight on how to address the threat above.=C2= =A0

I'm going to ponder how to align XAuth more = with these features of XYZ.
3D""=E1=90= =A7

On Fri, Feb 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020,= at 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Fri, Feb 21, 2020= at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in complete agreement with Annabell= e. In XYZ we realized that = both the QR Code and Authorization Code, and that the only difference is ho= w the user gets back to the client. So instead of inventing a new ty= pe of interaction, we split them. In XYZ, we have:
<= br>
This sentence= looks to be missing something.
=

Apologies: We realized they both used AS-composed URLs = to get the user to the AS in a web browser for interaction purposes.
<= br>
=C2=A0
=

=C2=A0- redirect: tells the AS that the client can send= the user to an arbitrary URL (and the AS doesn=E2=80=99t care how the clie= nt gets that info to the user; could be a redirect or an image or send a pu= sh notification to a secondary device, we don=E2=80=99t care as long as the= user shows up in a browser at the AS =E2=80=94 so maybe this field can be = renamed to be more universally accurate)

<= /div>
As stated in this thread, it may be useful for the AS to know if = the URL will be in a QR code, or in a full redirect.

In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client = has to do, so it needs to know the difference between a popup, and a full b= rowser redirect. This is targetted at SPAs, where an additional URL to redi= rect to is extra work.
=C2=A0
=C2=A0- code: tells the AS that the client ca= n present a short code the user can type (along with a static URL the user = can get to, maybe by typing the URL manually, but it=E2=80=99s not dynamic/= arbitrary like the redirect method)
=C2=A0- callback: tells the AS = that the client can receive the completion message from a front channel int= eraction through a redirect. Note that the client might have gotten to the = AS through a redirect on-device, through a QR-code off device, or through s= ome other magic, and this field isn=E2=80=99t concerned with that =E2=80=94= it=E2=80=99s only concerned with how to get the user :back:.

In a full redirect, the Client wants t= he AS to send the user back so that it can continue.

The only parameter in the completion message is the nonce, which seems s= uperfluous. See below.
=C2=A0

These three can be combin= ed in different ways depending on what you want to do at the client. Let=E2= =80=99s say you=E2=80=99re doing and OAuth2 style authorization code, you= =E2=80=99d use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D to= gether. If you=E2=80=99re doing a plain user code, you=E2=80=99d use =E2=80= =9Ccode=E2=80=9D. If you=E2=80=99re doing just a QR code with polling, you = use just =E2=80=9Credirect=E2=80=9D to get the long URL. If you=E2=80=99re = doing a user code and a QR code together, you use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccode=E2=80=9D to get the long URL and the short code not h= e screen at the same time.=C2=A0

On top of that, t= hey can be combined with other methods. Maybe I can send the user to an arb= itrary URL but also display a human-readable verification code (like CIBA),= or send something in a push notification but also give them a message to t= ype, or I=E2=80=99m getting claims from an agent but I want them redirected= back through the browser. The client gets to decide what kinds of interact= ion it can do and how to use these pieces in ways that make the most sense.=

Per my question later in= this thread, why would the Client not know what interaction it wants prior= to the request?

Wh= at do you mean? The client does know what it wants and that=E2=80=99s why i= t=E2=80=99s asking for what it wants. We=E2=80=99re debating different meth= ods for the client to ask for what it wants. This question does not make se= nse to me.


If the AS is doing CIBA, that is no= t a decision just for the Client. Both the AS and the Client need to know t= hey are doing CIBA. (FWIW: I think this work supersedes CIBA)

As I=E2=80=99ve stated previousl= y, I believe the interaction methods here can supersede CIBA.


Additionally, different interactions have different risk pr= ofiles. Sophisticated ASes will use that signal in the risk assessment, and= may do ask for additional authentication or verification.
=C2=A0=

Yes, exactly my po= int. Because different interactions have different risks, the AS will need = to be able to decide which interactions it=E2=80=99s OK with for a given re= quest. This could vary based on what=E2=80=99s being requested, or who=E2= =80=99s doing the requesting.


An interesting difference betwe= en XYZ and XAuth=E2=80=99s approaches is that XYZ keeps the concept of the = =E2=80=9Cauthorization code=E2=80=9D in the callback response (which in tur= n is based on the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, = you get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a p= air of nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and the b= ack channel response for a given transaction =E2=80=94 and note that I=E2= =80=99m really open to having a better way to generate and calculate such a= binding, but I think this works. In any event, this protects the client fr= om session fixation and injection on the return from the front channel that= it=E2=80=99s susceptible to in a pure polling model, and the hashing appro= ach basically combines the security parameters of the OAuth 2 authorization= code and (to an extent) state, PKCE=E2=80=99s code_challenge, and OIDC=E2= =80=99s nonce in one element. This is only applicable if you=E2=80=99re com= ing back to the client and you can validate the hash and present the refere= nce parameter. If you=E2=80=99re doing just plain polling, you don=E2=80=99= t have that protection =E2=80=94 but the client and the AS are aware of tha= t risk, and there=E2=80=99s an option to prevent it.

XAuth has removed the authorization code concept in its redirect return,= and clients only do polling against the GS API in order to get tokens. Whi= le I obviously think it=E2=80=99s very valuable to remove things from the f= ront channel, I don=E2=80=99t think this is something we can remove without= opening up attack surfaces that have already been identified in previous p= rotocols. I would like to understand why XAuth is not susceptible to the sa= me kinds of attacks, or if it is, what mitigations there are for them.=C2= =A0

Unlike OAuth 2.0, the= re are no parameters in the front channel response to the Client. The redir= ect back to the Client is only needed to return the interaction back to the= Client.

This argum= ent rings tautologically hollow =E2=80=94 there are no parameters because y= ou=E2=80=99ve defined that there aren=E2=80=99t any in XAuth. XYZ does have= parameters, to tie the front and back channel requests together when doing= redirect back and forth.

If you=E2=80=99re not do= ing a redirect back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interacti= on block), then it=E2=80=99s a polling mechanism like XAuth, the device flo= w, etc. There are very real risks to this.


XAu= th (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0)
=
In OAuth, the AS gives a code to the User to give to the Cli= ent that the Client then gives to the GS.

In XAuth= , the AS gives a "code" to the Client that givers it to the User = to give to the GS.

In XAuth, the "code" = is either a user code, or something embedded in the URI the User is redirec= ted to.

Therefore, there is nothing to protect in = the redirect back to the Client.

If I'm missin= g an attack, please elaborate how it would happen.
<= /blockquote>


<= div>OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar reques= t initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it= =E2=80=99s susceptible to the same kind of issue.

=C2=A0

=C2=A0=E2=80=94 Justin

On = Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <richanna=3D40amaz= on.com@dmarc.ietf.org> wrote:

Thanks for the update, Dick! I=E2=80=99m going to confine my comment= s here to interaction mode design, setting aside whether or not we need =E2= =80=9Cpopup=E2=80=9D. :D
=C2=A0<= /div>
Once the GS hands that URI back to the Client, it has zero c= ontrol over how the Client uses it. The Client could present any URI (of a = reasonable size) into a QR code, or present it as a clickable link, or redi= rect to it, or open it in an external browser, or do any number of other as= -yet-not-invented things with it. Moreover, the Client may not know yet wha= t it wants to do with it. So what value is there in distinguishing between = =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for= a QR code=E2=80=9D vs. =E2=80=9CI want a URI for <some other machine-dr= iven interaction mode>=E2=80=9D?
=C2= =A0
Even if we consider things like QR code data capa= city, that=E2=80=99s really just a URI length limitation, which could apply= to non-QR interaction modes, e.g., if the Client device wants to communica= te the URI over an extremely bandwidth-constrained channel. And it=E2=80=99= s not clear to me how including a URI length limitation in the request help= s. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99t it = always return that? On the client side, it can look at the length of the UR= I provided and decide what to do with it (e.g., render a QR code or display= it or do nothing with it).
=C2=A0
So that really leaves us with two interaction modes that = we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that= may not be human friendly; and
  • =E2=80=9Ccode=E2= =80=9D, which returns a code and URI for a code entry page, both of which a= re human-friendly.
=C2=A0
Those could be combinable to get both, and even if we don=E2= =80=99t go down the multiple interaction mode route we could add the full U= RI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hu= rt anything to do so.
=C2=A0
=E2=80=93
Annabelle Backman (she/he= r)
AWS I= dentity
=C2=A0
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>Date:=C2=A0Tuesday, February 18, 2020 at 6:04 PM
To:=C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0[Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol= -03.txt
=C2=A0<= u>
Added in user code interaction and a= ligned QR code to be a superset of user code.
Fixed descriptions.

=C2=A0

---------= - Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 18, 2020 at 6:00 PMSubject: New Version Notification for draft-hardt-xauth-protocol-03.txtTo: Dick Hardt <dick.hardt@gmail.com&= gt;




A ne= w version of I-D, draft-hardt-xauth-protocol-03.txt
has been successfull= y submitted by Dick Hardt and posted to the
IETF repository.

Name= :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Rev= ision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0https://www.ietf.org/internet-drafts/draft-hardt-xauth-= protocol-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.iet= f.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 = =C2=A0https://t= ools.ietf.org/html/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0 =C2= =A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-hardt-xauth-protocol-03

Abstract:
=C2=A0 =C2=A0Cl= ient software often desires resources or identity claims that are
=C2=A0= =C2=A0independent of the client.=C2=A0 This protocol allows a user and/or<= br>=C2=A0 =C2=A0resource owner to delegate resource authorization and/or re= lease of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software= can then request access
=C2=A0 =C2=A0to resources and/or identity claim= s by calling the server.=C2=A0 The
=C2=A0 =C2=A0server acquires consent = and authorization from the user and/or
=C2=A0 =C2=A0resource owner if re= quired, and then returns to the client software
=C2=A0 =C2=A0the authori= zation and identity claims that were approved.=C2=A0 This
=C2=A0 =C2=A0p= rotocol can be extended to support alternative authorizations,
=C2=A0 = =C2=A0claims, interactions, and client authentication mechanisms.



Please note that it may take a couple of minutes from the time of= submission
until the htmlized version and diff are available at= =C2=A0tools.ietf.org.

The IETF S= ecretariat

=E1=90= =A7
--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/m= ailman/listinfo/txauth

<= /div>